optimalizace přenosových sítí - cisco.com · sp1 • source routing • zdroj vybere cestu,...

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


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


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


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


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 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


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



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


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


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


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


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


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


Initially: OIF to 1

Stage1: {16006, 24065, 16009}



Initially: OIF to 8

Stage1: {16006, 24065, 16009}



Initially: OIF to 7

Stage1: {24065, 16009}


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

http://www.segment-routing.net/home/tutorial

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 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 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

( [email protected]

[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

optimalizace přenosových sítí - cisco.com · sp1 • source routing • zdroj vybere cestu,...

Documents