optimalizace přenosových sítí - cisco.com · sp1 • source routing • zdroj vybere cestu,...
TRANSCRIPT
SP1
Optimalizacepřenosových sítí• SP1
Martin Slinták
SP1
I. Směrování na dobré cestě [DC/METRO/WAN]
II. Bezestavové šíření multicastu [METRO/WAN]
III. Keše na hraně [INTERNET]
Agenda
motto: Abyste měli svou síť (opět) rádi..
SP1 3
Kapitola I.Směrování na dobré cestě:Aplikace Segment Routingu (SR)
SP1
• Source Routing
• zdroj vybere cestu, kterou zakóduje do záhlaví paketu jako uspořádaný seznam Segment IDs (SID)
• zbytek sítě vykonává zakódované instrukce bez jakýchkoliv flow-state
• Segment = identifikátor instrukce:
• Service
• Context
• Locator
• IGP-based forwarding construct
• BGP-based forwarding construct
• Local value or Global Index
Koncepce Segment Routingu (SR)
Segment = instrukce jako např.
”jdi do uzlu N použitím nejkratší cesty"
SP1
• Jednoduché rozšíření IGP pro instalaci segmentů do MPLS dataplane
• Excelentní škálovatelnost: uzel instaluje pouze N+A FIB záznamy
• N (node) segmenty a A (adjacency) segmenty
IGP Segmenty
A B C
M N O
Z
D
P
Node segment to C
Node segment to Z
Adj Segment
Node segment to C
SP1
• Unified• DC + WAN + Aggregation
• from server in the DC, through WAN and to the service edge
• Policy-aware• DC: disjoint planes, flow-based congestion avoidance
• WAN: disjoint services, latency-sensitive traffic, scheduled bulk transfer
• Application programs the end-to-end policy• The end-to-end policy is encoded by the application as an SR segment list in the packet header
• Balance between distributed and centralized intelligence• Distributed: automated sub-30msec FRR link/node in any topology with optimum backup path
• Centralized: traffic optimization for better use of the installed capacity
• Applicable to MPLS and IPv6 dataplanes
• Much simpler to operate than MPLS Classic
Vlastnosti SR
SP1 7
Segment Routing (SR):Škálovatelnost Inter-Domain politik
SP1
• Segment Routing Global Block (SRGB)
• rozsah MPLS labels vyhrazený pro SR, standardně 16000 až 23999
• Homogenní SRGB == jednoduchost
SRGB a SID alokace
vPE1
20001
ToR
20002
Spine
20003
DCI1
17001LSR
17002AGG1
16001
LSR
16003
AGG2
16002
vPE2
20001
ToR
20002Spine
20003DCI2
18001
LSR
18002
DC A1 METRO A METRO BWAN DC B2
20k-24k 20k-24k
17k-18k 18k-19k
16k-17k
16k-24k
SP1
• Each domain runs ISIS/OSPF SR
• Technology available since June 2014
• Incremental deployment and seamless interworking with LDP
IGP/SR ve WAN a Metro doménách
DCI1
17001LSR
17002
AGG1
16001
LSR
16003
AGG2
16002
DCI2
18001
LSR
18002
METRO A METRO BWAN
ISIS/SR 2 ISIS/SR 3ISIS/SR 1
SP1
• 20006 is the BGP Prefix SID to DCI6
• ECMP, simplicity (no LDP/RSVP) and policy
• Available on Nexus/NXOS and NCS5k/XR
SR v DC doméně
vPE1
20001
ToR2
20002Spine4
20004
Leaf3
20003Leaf5
20005
DCI6
20006
vPE11
20011
ToR12
20012Spine1
4
20014
Leaf13
20013Leaf15
20015
DCI16
20016
AS2
AS11
AS3 AS4 AS5 AS6AS1
SP1
• WAN aggs are re-distributed down to Metro and DC
• Nothing is redistributed up
• How does vPE1 reaches vPE2?
Inter-Domain Routing
vPE1
20001
ToR
20002
Spine
20003
DCI1
17001LSR
17002AGG1
16001
LSR
16003
AGG2
16002
vPE2
20001
ToR
20002Spine
20003DCI2
18001
LSR
18002
DC A1 METRO A METRO BWAN DCB2
WAN Aggs WAN AggsWAN AggsWAN Aggs
SP1
• Multi-Domain topology
• Realtime reactive feed via BGP-LS/ISIS/OSPF from multiple domains
• Including ip address and SID
• Compute: stateful with native SRTE algorithms
SR PCE
vPE1
20001
ToR
20002
Spine
20003DCI1
17001LSR
17002AGG1
16001
LSR
16003
AGG2
16002
vPE2
20001
ToR
20002Spine
20003DCI2
18001
LSR
18002
DC A1 METRO A METRO BWAN DCB2
Multi-Domain TopologySR PCE
Compute
SP1
• vPE1 learns about a service route with nexthop vPE2
• How does vPE1 reach the nexthop?
• vPE1 only has routes within DC A1 and to the AGG’s of the WAN domain
• Solution: ODN (next slide)
Service Provisioning
vPE1
20001
ToR
20002
Spine
20003DCI1
17001LSR
17002AGG1
16001
LSR
16003
AGG2
16002
vPE2
20001
ToR
20002Spine
20003DCI2
18001
LSR
18002
DC A1 METRO A METRO BWAN DCB2
BGP RR2: V via vPE2
VPN-LABEL: 99999
1: V via vPE2
VPN-LABEL: 99999
SP1
• vPE1’s ODN functionality automatically request a solution from SR-PCE
• Scalable: vPE1 only gets the inter-domain paths that it needs
• Simple: no BGP3107 pushing all routes everywhere
On-Demand SR Next-Hop (ODN)Reachability
vPE1
20001
ToR
20002
Spine
20003DCI1
17001LSR
17002AGG1
16001
LSR
1600316002
vPE2
20001ToR
20002Spine
2000318001LSR
18002
DC A1 METRO A METRO BWAN DCB2
SR
PCE
3: vPE2 ?
4: {16002, 18001, 20001} 2: V via vPE2
VPN-LABEL: 99999
1: V via vPE2
VPN-LABEL: 99999
BGP RR
SP1
• Inter-domain SLA with scale and simplicity
• No RSVP, no midpoint state, no tunnel to configure !!
On-Demand SR Next-Hop (ODN)SLA enabled
vPE1
20001
ToR
20002
Spine
20003DCI1
17001LSR
17002
AGG1
16001
LSR
16003
AGG2
16002
vPE2
20001
ToR
20002Spine
20003DCI2
18001
LSR
18002
DC A1 METRO A METRO BWAN DCB2
SR
PCE
3: vPE2 with
Low-Latency?
4: {16001, 16003,
16002, 18001, 20001}
2: V via vPE2
VPN-LABEL: 99999
EXT-COM: LATENCY
1: V via vPE2
VPN-LABEL: 99999
EXT-COM: LATENCYBGP RR
SP1
• Best-effort reachability is provided by BGP3107
• ODN and SRTE-PCE provides interdomain reachability with SLA
• Eventually, migration of more/all services over SR PCE
Seamless Transition
SP1
• ODN/SR-PCE automatically computes disjoint primary/sec paths for the PW
• sBFD runs at 3x50msec on each SRTE path
• Upon failure detection of the primary, the secondary SRTE Path is used
• Inter-domain SLA with scale and simplicity
• No RSVP, no midpoint state, no tunnel to configure !!
Inter-Domain PW - Disjoint Primary/Backup
vPE1
20001
ToR
20002
Spine1
20003
DCI1
17001
17901
LSR
17002
AGG1
16001
16901
LSR
16003
AGG2
16002
16902
vPE2
20001
ToR
20002Spine
20003
DCI2
18001
18901
LSR
18002
DC A1 METRO A METRO BWAN DCB2
DCI11
17011
17901
AGG11
16011
16901
AGG12
16012
16902
DCI11
18011
18901
Spine2
20004
Spine2
20004
SR
PCE1
Primary
1: Two disjoint paths to vPE2
2: PRIMARY: {18001, 16003, 16001,
17001, 20001}
SECONDARY: {18011, 16013, 16011,
17011, 20001}
Pri
Sec
SP1
• ODN/SR-PCE automated compute disjoint paths for PW1 and PW2
• PW1 and PW2 do not share the same headend, neither the same tailend
• Inter-domain SLA with scale and simplicity
• No RSVP, no midpoint state, no tunnel to configure !!
Two Disjoint Inter-domain PW’s
SR
PCE
vPE2 disjoint 7
{20003, 16001, 16002,
18001, 20001}
vPE22 disjoint 7
vPE1
20001
ToR2
20002
Spine3
20003
DCI1
17001LSR
17002
AGG1
16001LSR
16003
AGG2
16002vPE2
20001
ToR3
20002Spine4
20003
DCI2
18001LSR
18002
DC A1 METRO A METRO BWAN DCB2
DCI11
17011AGG11
16011AGG12
16012
DCI21
18011vPE11
20011
ToR12
20012
Spine13
20013vPE22
20021
ToR23
20022Spine24
20023
{20013, 16011, 16012,
180011, 20001}
PW1
PW2
SP1
• End-to-end policies can be composed from more basic ones• An SRTE policy is bound by default to a Binding SID
• RSVP-TE tunnels can also be bound to a Binding SID and hence RSVP-TE tunnels can be used within an end-to-end SR policy
• Shorter SID list and churn isolation between domains• Even if the WAN-MetroA sub-path changes, the related Binding SID 4001 is constant
Binding SID to stitch Policies
vPE1
20001
ToR
20002
Spine
20003DCI1
17001LSR
17002AGG1
16001
LSR
16003
AGG2
16002
vPE2
20001
ToR
20002Spine
20003DCI2
18001
LSR
18002
DC A1 METRO A METRO BWAN DCB2
SR
PCE
2: vPE2 with Min LAT?
1: REPORT {16003, 16002, 18002, 18001}, UP,
BindingSID 4001
3: REPLY {16001, 4001, 20001}
instead of
{16001,
16003, 16002, 18002, 18001,
20001}
SP1
• SR-PCE not to be considered as a single “god” box
• SR-PCE deployment model more like RR
• Different vPE’s can use different pairs of SR PCE’s
• SR PCE preference can either be based on proximity or service
Fundamentally Distributed
vPE1
20001
ToR
20002
Spine
20003
DCI1
17001
17901
LSR
17002
AGG1
16001
16901
LSR
16003
AGG2
16002
16902
vPE2
20001
ToR
20002Spine
20003
DCI2
18001
18901
LSR
18002
DC A1 METRO A METRO BWAN DCB2
DCI11
17011
17901
AGG11
16011
16901
AGG12
16012
16902
DCI21
18011
18901
SR
PCE
SR
PCE
SR
PCE
SR
PCESR
PCE
SR
PCE
SR
PCE
SR
PCE
SP1
• Bru learns the routes from Tok and dynamically compute the SRTE policy to nhop
• Elimination of RSVP signalling, midpoint states and headend tunnel configuration !
• Commonality and Distribution: The router’s SRTE functionality is same as SRTE-PCE
• No PBR steering complexity
• No PBR perfomance tax
Fully Distributed SRTE
SFO
16004
Y/y Low-Cost
NY
16005
BRU
16001
MOS
16002
TOK
16003
X/x Low-LatencySR
PCE
FIB @ BRU
X/x via {16002, 16003} Tokyo Latency
Y/y via {16003} Tokyo Low Cost
SP1 22
Segment Routing (SR):Topology Independent LFA (TI-LFA)
SP1
• 50msec Protection upon local link, node or SRLG failure
• Simple to operate and understand
• automatically computed by the router’s IGP process (ISIS and OSPF)
• 100% coverage across any topology
• predictable (backup = postconvergence)
• Optimum backup path
• leverages the post-convergence path, planned to carry the traffic
• avoid any intermediate flap via alternate path
• Incremental deployment
• also protects LDP and IP traffic
TI-LFA - Benefits
SP1
• 2’s computes a primary path to 5
Automated Per-Destination optimization
100 100
PE4 5
2 31
6 7 8
Source
Dest2Default metric: 10
FIB of 2 for destination 5
Incoming Label: 16005
Primary: SWAP 16005 for 16005, oif: 3
SP1
• 2 checks the protection preference for the primary interface of the destination
• Link protection (illustration assumption)
• Node protection
• SRLG protection
Flexible Link vs Node vs SRLG protection
100 100
PE4 5
2 31
6 7 8
Source
Dest2Default metric: 10
SP1
• 2 computes the post-convergence path if the preferred failure would occur• Optimality: the operator planned and dimensioned the post-
convergence path to carry the traffic in the failure case
• 2 uses SR to encode the post-convergence path in a loop-free manner
• 2 updates the FIB with the backup path to 5
Automated and Optimum
100 100
PE4 5
2 31
6 7 8
Source
Dest2Default metric: 10
FIB of 2 for destination 5
Incoming Label: 16005
Primary: SWAP 16005 for 16005, oif: 3
Backup: SWAP 16005 for 16005, PUSH 16007, oif: 6
SP1
Do we need many SID’s? No!
SP1 28
Segment Routing (SR):uLoop Avoidance
SP1
• IP hop-by-hop routing may induce uloop at any topology transition
• Link up/down, metric up/down
uLoop is a day-1 IP drawbackUpon link down convergence
2 3 4
5
8 7 6
11000
Pre-convergence Path
Post-convergence Path
Illustration for the post-convergence
uloop impacting traffic from 1 to 5 after
link45 going down. Default link metric 10
SP1
• Prevent any uloop upon isolated convergence due to
• link up/down event
• metric increase/decrease event
• If multiple back-to-back convergences, fall back to native IP convergence
SR uloop avoidance
microloop avoidance segment-routing
SP1
• No uloop can occur thanks to the 2-stage convergence and the use of non-looping SID lists to implement the post-convergence path in stage1
Illustration – Link Down
2 3 4
5
8 7 6
1
Default link metric 10
100
Pre-convergence Path
Post-convergence Path
FIB @ 1 for Destination 9
Initially: OIF to 2
Stage1: {16006, 24065, 16009}
Finally (stage2): OIF 8
9
FIB @ 8 for Destination 9
Initially: OIF to 1
Stage1: {16006, 24065, 16009}
Finally (stage2): OIF 7
FIB @ 7 for Destination 9
Initially: OIF to 8
Stage1: {16006, 24065, 16009}
Finally (stage2): OIF 6
FIB @ 6 for Destination 9
Initially: OIF to 7
Stage1: {24065, 16009}
Finally (stage2): OIF 5
Illustration for the post-convergence
uloop impacting traffic from 1 to 9 after
link45 going down
SP1 32
Segment Routing: Shrnutí
SP1
Platformy s podporou SR
ASR1000 / ISR400 / cBR8
ASR9000NCS6000 CRS-3 / CRS-X
ASR900
NCS5000
NCS5500
NEXUS
9000FD.io
CSR1000v
IOS classic
IOS XR NXOS
Linux
XRV-9000
SP1
1.fáze 2.fáze
• MPLS SR baseline
• MPLS Control Plane plane simplification
• Automated 50ms convergence
• SR-TE policies • Distributed & Centralized
• Low Latency path
• Disjoint path
• Avoiding specific path
• Capacity optimization
• Basic operation tooling (OAM+BFD)
• SR-TE for dynamic / automatic WAN/CE/DC policies
• Bandwidth auto-measurement
• Delay/Drop performance management
• On demand LSP for L3VPN & L2VPN
• Operation excellence
• Advance OAM, MP tree discovery
• Error detection (example: consistency check)
• YANG
• IPv6 SR
• Initial development to address well defined use-cases (Comcast & Conduit).
SP1
• jednotná fabrika s politikami přes DC, Metro a WAN
• poskytuje dříve nerealizovatelné funkce
• zjednodušení díky automatizaci a redukci protokolů
• kladné přijímání operátory
• multi vendor konsensus
• http://www.segment-routing.net/home/tutorial
SR: základ moderního IP/MPLS networkingu
SP1 36
Kapitola II.Bezestavový Multicast:Bit Indexed Explicit Replication (BIER)
SP1
Základní idea BIER
BitString
BIER Domain
LSA
1 - A/32
LSA
5 – E/32
LSA
4 – D/32
LSA
3 – C/32
LSA
2 – B/32
1. Assign a unique Bit Position from a BitString to each BFER in the BIER domain.
2. Each BFER floods their Bit Position to BFR-prefix mapping using the IGP (OSPF, ISIS)
12345
B/32
A/32
C/32D/32
E/32 12345
SP1
• Based on shortest path route to RID, the Bit Mask Forwarding Table is created
Bit Index Forwarding Table
CA B
D
FE
BM Nbr
0111 B
BM Nbr
0011 C
0100 E
BM Nbr
0001 D
0010 F
BFR-ID 1
BS:0001
BM Nbr
0011 C
B
BM-ER
BM-ERBM-ER
BFR-ID 2
BS:0010BFR-ID 3
BS:0100
SP1
• Based on shortest path route to RID, the Bit Mask Forwarding Table is created
Forwarding Packets
A CA B
D
FE
BM Nbr
0111 B
BM Nbr
0011 C
0100 E
BM Nbr
0001 D
0010 F
00110111
AND ANDAND
0111
BM Nbr
0011 C
B
&0011&0111 &0001
&0100 &0010
AND
BFR-ID 1
BS:0001
BFR-ID 2
BS:0010BFR-ID 3
BS:0100
Suppose A leans about D, E and F’s interest,
in the blue multicast flow.
(via BGP, SDN, STATIC, etc…)
BM-ER
BM-ERBM-ER
SP1
• We translate the BFT neighbor table in to a table sorting on Bit Position
(so not by neighbor)
• We walk the Bit Mask in the packet and Index into the FIB table.
BIER Forwarding, Bit Indexed
BFT Neighbors
5 4 3 2 1 Nbr
1 A
1 B
1 C
1 1 D
BFT Indexed
54321 Nbr
1 10001 D
2 00010 A
3 00100 B
4 01000 C
5 10001 D
SP1
• We walk the Bits in the packet, as soon as we hit a ‘1’, we copy the packet, index into the FIB table with the position of the Bit.
• The Bit Mask entry is reverse ‘&’ with the Bit Mask in the packet.
• This resets the Bits that where processed.
BIER Forwarding, Bit Indexed
BIER FIB Label
Forwarding Table
54321 Nbr
1 10001 D
2 00010 A
3 00100 B
4 01000 C
5 10001 D
10101Packet IN
1
Walk Bit Mask
Packet OUT 10001=
01110
&
10101
Copy
&
SP1
BIER Forwarding, Bit Indexed
BIER FIB Label
Forwarding Table
54321 Nbr
1 10001 D
2 00010 A
3 00100 B
4 01000 C
5 10001 D
00100Packet IN Packet OUT
5 4 3 2
Walk Bit Mask
1000110101 =
Copy
&
00100= Packet OUT 00100 &
Copy
00000
&
11011
• We walk the Bits in the packet, as soon as we hit a ‘1’, we copy the packet, index into the FIB table with the position of the Bit.
• The Bit Mask entry is reverse ‘&’ with the Bit Mask in the packet.
• This resets the Bits that where processed.
SP1
ECMP
CA B
D
FE
Nbr
0111 B
Nbr
0011 C
0110 E
Nbr
0001 D
0010 F
00110111
AND ANDAND
0111
0001
0010
0100Nbr
0011 C
B
0010 F
&0011&0111 &0001
&0110 &0010
AND
Duplicate bit positions need to be resolved,
ECMP logic needs to select based on Hash.
In the example we selected C
SP1
• We distribute the Bit Positions over multiple tables.
• Each Bit Position only appears once in each table.
• Table selection is based on entropy, done before Bit Index lookup
ECMP
ECMP Table 1
5 4 3 2 1
1 1 1
1
1
ECMP Table 2
5 4 3 2 1
1 1 1
1 1
ECMP Table 3
5 4 3 2 1
1 1
1
1 1
ECMP Table 4
5 4 3 2 1
A
1 1 B
C
1 1 1 D
BFT Neighbor
5 4 3 2 1 Nbr
1 1 1 A
1 1 1 B
1 1 C
1 1 1 D
SP1
• The Top Label is allocated by BIER from the downstream platform label space.
• The BIER Header follows directly below the BIER label.
• There is a single BIER label on top, unless the packet is re-encapsulated in to a unicast MPLS tunnel.
• The VPN label is allocated from the upstream context label space (optional).
BIER with MPLS encapsulation
BIER Label BIER Header VPN Label Payload
MPLS Label IPv4/IPv6/L2Upstream Label
(optional)
BIER header
EO
S
EO
S
SP1
• http://www.ietf.org/id/draft-ietf-bier-mpls-encapsulation-01.txt
BIER Header
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 0 1| Ver | Len | Entropy |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BitString (first 32 bits) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ BitString (last 32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|OAM| Reserved | Proto | BFIR-id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
256bits = 32bytes
SP1
• To increase the scale we group the egress routers in Sets.
BIER Sets
I
A
G B
1:0001
C
D
E
F
H
1:0010
1:0100
2:0001
2:0010
2:0100
Set 1
Set 2
1:0111
2:0111
Set BM Nbr
1 0111 I
2 0111 I
Note, Bit Positions 1,2,3
appear in both Sets, and
do not overlap due to Sets.
Note, we create different
forwarding entries for each Set
J
SP1
• A bit Mask only needs to be unique in its own area.
• ABR’s translate Bit Masks between area’s.
• Requires a IP lookup and state on the ABRs.
• This is very similar for ‘Segmented Inter-AS MVPN’.
BIER Area
BA ABR
BM Nbr
0:10 ABR
{0:01} {0:10} {0:10} {0:01}
BM Nbr
0:01 A
BM Nbr
0:01 B
BM Nbr
0:10 ABR
Area 1 Area 2
SP1
• Nodes are configured to be in a BIER sub-domain.
• BIER MPLS labels are not installed between sub-domains
• When IGP changes SPF for B to F, traffic is dropped.
• BIER traffic is never leaked between sub-domains.
BIER Sub-domains
A B C D
E F G H
PIM/
IGMP
PIM/
IGMP
Domain 1
Domain 2
SP1
• E and F announce their Group membership via overlay to all other routers.
• A BIER router connected to the Source can immediately start sending.
Nativní BIER
DC
E
F
A
B
(S1,G)(*,G):0:000
1 IGMP
(*,G)
IGMP
(*,G)
0 Nbr
0001 E
0010 F
1100 C
0 Nbr
0011 D
0100 A
1000 B
0 Nbr
1011 C
0 Nbr
0111 C
0 Nbr
1110 D
0 Nbr
1101 D
(*,G):0:000
1
(*,G):0:000
1
0100
1000
0001
0010
(*,G):0:001
0
(*,G):0:001
0
(*,G):0:001
0
SP1
• When B leans about a new source, it can immediately start sending.
Nativní BIER
DC
E
F
A
B
(S1,G)
(*,G):0:000
1
IGMP
(*,G)
IGMP
(*,G)
0 Nbr
0001 E
0010 F
1100 C
0 Nbr
0011 D
0100 A
1000 B
0 Nbr
1011 C
0 Nbr
0111 C
0 Nbr
1110 D
0 Nbr
1101 D
(*,G):0:000
1
(*,G):0:000
1
0100
1000
0001
0010
(*,G):0:001
0
(*,G):0:001
0
(*,G):0:001
0
(S2,G)
SP1
• The BGP control plane defined for MVPN can be re-used.
• Big difference, there is no Tree per VPN…!!!
• The BIER packets needs to carry Source ID and upstream VPN context label
MVPN přes BIER
C
D
A
B
0100
1000
0001
0010
BIER
PIM
PIM
PIM
PIM
PIM
PIM
RR(*,G):0:0001
(*,G)
(*,G)
(*,G)
(S,G)
(S1,G)
(S2,G)
(*,G):0:0010
(*,G):0:0001
(*,G):0:0001
SP1 54
BIER: Shrnutí
SP1
• Pakety přenášené přes BIER sledují unicast cesty směrem k příjemcivyužívaje vlastností unicastu jako např. FRR či LFA.
• V BIER doméně nejsou žádné per multicast flow stavové informace.
• Konvergence multicastu je stejně rychlá jako pro unicast, nejsou re-konvergence multicast stavů, signalizace, atd.
• Snadná SDN integrace, výměna informací o zdroji a příjemcimulticastu pouze na hranici BIER domény.
• žádný řídící protokol pro multicast uvnitř BIER domény
Výhody BIER multicastu
SP1 56
Kapitola III.Keše na hraně
SP1
Zásady distribuce obsahu
VýkonEfektivnost Nezdolnost
SP1
• Hierarchical
• Distribution Tree from Origin
• Often associated with an Authoritative Source
• Tightly controlled distribution policies
• Peer to peer
• Distributed Hash Table model
• Content can be cached anywhere
• Appropriate in fully meshed topologies
• Multiple sources
Content Distribution Architectural Models
C
C C
C
C
C
C
C
C
SP1
• Concepts
• CDN is a “Proxy” for Origin Servers
• Redirecting clients to CDN
• CDN Functional Cache Elements
• “Traffic Routing” Redirection
• “Origin Server” Library
• “Traffic Server” Caching
• “Traffic Server” Edge Cache
CDN - Introduction to Dynamic Caching
Content Delivery Network
Streams
Ingest
Cache-Fill
OriginServers
Mid-TierCache
EdgeCache
ContentLibrary
CacheStorage
CacheStorage
ServiceRouting
Location Requests
ContentRequests
ContentRequests
ContentRequests
Location Redirects
SP1
• Authorized Delegation
• Explicit Interpretation Provided to Cache
• Authentication or Encryption Viable
• Redirection to Optimal Location
• Cache Hit Ratio
• Distributed Edge
• Edge Cache
• Intermediate Layer
• Reverse Proxy Cache
CDN Caching Basics
Item ([email protected])
Origin Server
CDN
Traffic
Server
(Caching)
Catalog
DNS
Traffic
Server
(Cache)
Item ([email protected])
cdn.com
Asset Mapping
get ([email protected])
get ([email protected])
get ([email protected])
GET ([email protected])
Redirect ([email protected])
1
2
3
4
6
7
5
Traffic
Router8
9
SP1
Content Caching Principles
Content Popularity
Cost Inflection Point
Caching Sites
Bandwidth Costs
Cache Costs
Optimized Costs
Cost
Cache Hit Rates
SP1
Caching Cost:Bandwidth
Cost
Bandwidth Costs
Demand
Contributions / Cache-fill
Source Data
Center
Network
Core
Network
Edge
AccessNetwork
HomeNetwork
SP1
Caching Cost:Cache Storage
Source Data
Center
Network
Core
Network
Edge
AccessNetwork
Storage
HomeNetwork
Cost
SP1
Caching Cost Inflection Point:Optimized Costs
Source Data
Center
Network
Core
Network
Edge
AccessNetwork
Storage
Bandwidth Costs
Optimal Costs!
But what about
performance?Latency?
Jitter?
Congestion?
DemandContributions / Cache-fill
HomeNetwork
Cost
SP1
Net Z
• Assessing Location (Latency)
• Per Delivery Service
• Per Location
• Assessing Status (Availability)
• Analytics from Edge Caches
• Resources Available
• Assessing Content Affinity (Performance)
• Assign Request to Previously Assigned Edge Cache
• Assessing Content Controls
• Quotas
• Thresholds
Traffic Server Assignment
S1 IP
S2 IP
Traffic Monitor
S3 IP
Net X
S1 Status
S3 Status
S2 Status
Client Request
Net Y
Traffic Router
Status
SP1
Net Z
• Separate Content Routing Plane
• Implemented at Traffic Router
• Reference Location Information (MaxMind)
• Traffic Server’s inform Traffic Monitor about status and load using keep-alive messages
• Server Redundancy
• Variety of Traffic Server Selection criteria available
• Load
• Content
• Service availability
Static Location-based Routing
S1 IP
S2 IP
Traffic Router
CIP1S3 IP
CIP LOC
CIP1 == net Y
CIP2 == net Z
CIP2
Net X
Net Y
NODE LOC
S1 IP == net X
S2 IP == net Y
S3 IP == net Z
Lookup
MaxMind DB
SP1
• Content Affinity Traffic Routing
• Hash Calculated on URL (HTTP Only)
• Common URL requests have affinity to same Traffic Server
• Traffic Server Selection
• Hash Calculated on Origin URL
• Common Cache-fill requests have affinity to same Traffic Server
• Origin Selection
• Same as above
Content Delivery
CA 1
S2 IP
S3b IP
Client
CA 2
S3a IP
OS 1 OS 2
Client
Client
Client
SP1
• Origin Server Sizing depends on CDN Cache Hit Rate (CHR) efficiency
• Define CDN topology and apply Hierarchical Caching to achieve efficiency goal
• Example
• CDN Efficiency goal: 90%
• Two-tier CDN (edge + mid-tier-cache)
• Edge CHR (eCHR): 80%
• Mid-tier Cache CHR (mCHR): 50%
• Efficiency =
1 – (1 – eCHR)*(1 – mCHR) = System CHR
1 – (1 – 0.80)*(1 – 0.50) = 90%
Content Delivery Optimization
CA 1
S2 IP
Client
S3a IP
OS 1 OS 2
Client
Client
Edge
Cache Hit Rate
Mid-Tier
Cache Hit Rate
SP1
The Challenges with Distributing ABR Objects
Short fragment / segment sizes High HTTP Request Rate
URL’s can be Absolute or Relative DNS Resolutions
TCP connections should not be short-lived (client code) Pipeline HTTP Requests
CDS object handling configured on a per Delivery Service basis
Progressive Download
ABR Delivery
Movie.mp4
Frag1-1 Frag1-2
Frag2-1
. 2hr movie, 2 sec segments
. 3600 fragments x 7 profiles
. 25,000 objects/movie
Frag1-3 Frag1-4
Frag2-2 Frag2-3 Frag2-4
Frag3-1 Frag3-2 Frag3-3 Frag3-4
Frag4-1 Frag4-2 Frag4-3 Frag4-4
TimeStart + 2 sec + 4 sec + 6 sec
512 kbps
768 kbps
1.0 mbps
1.5 mbps
GET GET GET GET
SP1
OMD Insights – CDN Analytics
Cisco® Open Media Distribution Insights is a
comprehensive analytics solution that provides
meaningful CDN Insights, thereby enabling CDN
operators and Content Providers to optimize content
delivery by accurately measuring QoS and QoE.
Content Based Analytics
Operational Analytics
Geo-User Analytics
Scorecards
Trend analysis
Custom Dashboards and Reports
Near real-time monitoring
Alerts, Search
Alerts
Trends
Monitor
Analyze Metrics with Pivoting
SP1
OMD Insights System Overview
Traffic
ServerTraffic
Server
Traffic
Server
Cluster
Master
Node
Summary
Search
Head
Indexer to
indexer
Replication
1Splunk Forwarder integrated into Edge, Mid Caches
and TR to monitor the log files and forward log
events to Insights-Indexers in real-time
Indexers index the events and build
searchable data sets2Summary Search Head schedules saved searches
to a set of search peers and then merges the results
to send it back to indexers3Search Head handles search management functions
by directing search requests to a set of search peers
and then merging the results back to the user4
Deployment
Server License
Master
Indexer 3
Indexer 2
Indexer 1
Search
Head
Business Insights
Operational Visibility
Proactive Monitoring
Search + Investigation
SP1
• Per Customer Traffic Matrix
• Total Traffic To/From Customer based on Ingress and Egress PE nodes
• Local/Regional/National Traffic percentages
• Input/Output traffic ratio to detect imbalances in traffic flow or peering contract exceptions
Customer Peering Dashboard
SP1
• Who are my top Destinations?
• Who are my Top Potential Peers?
• Who are my Top source ASN?
• Business Opportunities
• New Customer targets
• New Peering targets
BGP AS Path Analytics
SP1
• The 95th percentile is a good number to use for planning so you can ensure you have the needed bandwidth at least 95% of the time.
• http://www.init7.net/en/backbone/95-percent-rule
P95 Traffic Analytics
SP1 75
CDN: Shrnutí
SP1
• přidaná hodnota CDN
• efektivní distribuce obsahu (Audio, Media, Software)
• lepší výkon, škálovatelnost a odolnost vůči výpadkům
• metody kešování
• DNS-based a HTTP Redirect
• možnosti CDN architektury
• strategické hierarchické kešování
• cenová optimalizace: Bandwidth X Storage
• CDN analytika
• optimalizace CDN a peering politik
CDN pro kešování obsahu v síti
Caching Sites
Optimized Costs
Cost
Proxy
Cache
HTTP | DNS
SP1