transport architectures using ip multicast technology for

52
© 2009 Cisco Systems, Inc. All rights reserved. Cisco Confidential Presentation_ID 1 Transport architectures using IP Multicast technology for IPTV Services Stefan Kollar Consulting System Engineer, CCIE #10668 [email protected]

Upload: rockys11

Post on 03-Dec-2014

2.976 views

Category:

Documents


2 download

DESCRIPTION

 

TRANSCRIPT

Page 1: Transport architectures using IP Multicast technology for

© 2009 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID 1

Transport architectures using

IP Multicast technology for IPTV

Services

Stefan Kollar Consulting System Engineer, CCIE #10668 [email protected]

Page 2: Transport architectures using IP Multicast technology for

2

© 2009 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID

Agenda

1. Introduction

2. Architectural overview

3. IP multicast primer (SSM)

4. Transit Transport Design options

5. Wholesale / content distribution

6. Resiliency

Source redundancy, protected pseudowires,

fast convergence, FRR, live-live, MoFRR

7. Path selection

ECMP, multi topologies, RSVP-TE P2MP

Page 3: Transport architectures using IP Multicast technology for

3

© 2009 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID

Introduction

IPTV and IP Multicast

Page 4: Transport architectures using IP Multicast technology for

4

© 2009 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID

Broadcast IPTV = IP Multicast

1. …however transport network transits packets ..

“Native IP multicast”, MPLS, L2, optical

2. IP multicast sources:

Encoder, Transrater, Groomer, Ad-Splicer, …

3. IP multicast receivers:

Transcoder, Groomer, Ad-Splicer, eQAM, STB

4. IP == IPv6 (Japan) or IPv4 (RotW rest of the world)

No address exhaustion issue (SSM)

No/slow move to IPv6 for IPTV in RotW

Page 5: Transport architectures using IP Multicast technology for

5

© 2009 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID

Deployment StrategyOverview, Recommendation

1. Network

Add IP multicast service to your network (for any application)

Choose transport methods based on SLA and operational requirements/preferences

Native IP multicast, MPLS, L2, mix

Solution should minimize involvement in provisioning of individual applications/services

2. IPTV services

Start with traditional broadcast TV

Investigate extending IPTV and add other (IP multicast) services

More RoI on network layer investment

Page 6: Transport architectures using IP Multicast technology for

6

© 2009 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID

Architectural Overview

Page 7: Transport architectures using IP Multicast technology for

7

© 2009 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID

50,000 Feet ArchitectureIPTV and Multicast

“Network Plane”

IPTV “Services Plane”

IP multicast

source IP multicast

receiver

IP multicast

Service gatewayReceive/process/send

Eg: Ad-Splicer, Dserver, Transrater,…

The network

Sig

na

lin

g

Sig

na

lin

g

Sig

na

lin

g

Service Interface

Multicast trafficMulticast traffic

Page 8: Transport architectures using IP Multicast technology for

8

© 2009 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID

50,000 Feet ArchitectureGoals

1. Separate “network” and “services” plane

Network = shared infrastructure for all services

Routers, switches, optical gear, NMS, …

IPTV = encoders, groomers, splicers, VoD server, STB, …

Often operated by different entity/group than network

2. IP multicast

Allow to attach service plane devices (sourcing, receiving) anywhere – global, national, regional, local. Start/stop sending traffic dynamically, best utilize bandwidth only when needed.

One network technology usable for all services (IPTV, MVPN, …)

Different transport options for different services possible

Enable network operator not to provision/worry about individual programming.

3. Service Interface

How network & service operator infrastructure interacts with each other

SLA of IP multicast traffic sent/received, Signaling used

Page 9: Transport architectures using IP Multicast technology for

9

© 2009 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID

IP Multicast Primer

Page 10: Transport architectures using IP Multicast technology for

10

© 2009 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID

Protocols and Services…and IP Multicast

1. multicast / multipoint protocols

Between routers, switches, ..

“Only of interest to network operator”

PIM-SM, MSDP, (M)BGP, AutoRP, BSR, mLDP, RSVP-TE, …), IGPs (OSPF, ISIS), …

2. multicast services

How end-devices can use IP multicast

“Of interest to network and service operator”

ASM, SSM (and protocols “IGMP/MLD”)

Service operator just need to add SLA requirements!

Page 11: Transport architectures using IP Multicast technology for

11

© 2009 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID

IP Multicast Services

1. ASM: “Any Source Multicast” (1990, rfc1112)

The “traditional IP multicast service” (collaborative)

Sources send packets to multicast groups

Receivers join to (G) groups, receive from any source

2. SSM “Source Specific Multicast” (~2000, rfc4607/4604)

The multicast variant for IPTV (or other “content distribution”)

Unchanged: Sources send packets to multicast groups

Receivers subscribe (S,G) channels,receive only traffic from S sent to G

Primarily introduced (by IETF) for IPTV type services

Because of limitations of standard (protocol) model for ASM

Page 12: Transport architectures using IP Multicast technology for

12

© 2009 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID

IP Multicast ServicesIssues with ASM – Resolved with SSM

1. ASM

DoS attacks by unwanted sources

Address allocation (IPv4 only, not IPv6)

2. Standard protocol suite PIM-SM/MSDP/Anycast-RP

Complexity of protocol operations required

PIM-SM (RPT+SPT+Switchover), RP redundancy, announce, location

MSDP (RPF), BGP congruency,

Interactions with MPLS cores, bandwidth reservation, protection

Scalability, Speed of protocol operations (convergence)

RPT + SPT operations needed

Page 13: Transport architectures using IP Multicast technology for

13

© 2009 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID

Model / Protocols for SSM

1. IETF standardized:

Receiver host to router (eg: IP-STB, eQAM)

IGMPv3(IPv4) / MLDv2(IPv6) with (S,G) signaling

MUST be supported in host stack and host middleware (app)

Between routers

PIM-SSM == subset of PIM-SM for SSM (nothing new!)

IGMPv3 proxy routing / (snooping) on HAG, L2 access

Simple point to multipoint tree building == (S,G) SPTs only

2. Not IETF standardized

“Anycast” source redundancy

L3: Signaling of Anycast/Prioritycast source addresses

Transition support

SSM-mapping, (URD, IGMPv3lite)

Page 14: Transport architectures using IP Multicast technology for

14

© 2009 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID

End-to-End Protocol ViewExample: L3 Aggregation

PIM-SSM (S,G) joins IGMPv3 (S,G) membership

STBHome

Gateway

BB typespecific

PE-AGG

Core Distribution/ regional

Aggregation Home NetAccessExternalNetwork

Eg:Contentprovider

Headend

Video encoder/multiplexer

First hoprouter

IGMPv3proxy routing

IGMPv3snooping

IGMP:{Limits}

{Static-fwd}PIM-SSMPIM-SSM

L3 Transport Options in clouds:Native: PIM-SSM or MVPN/SSM

MPLS: LSM / mLDP RSVP-TEOpt.

SourceRedundancy

Content injection:External, national, regional, local

Dis.Edge Rtr

IGMPv3SSM

PIM-SSM

Same choices for all access technologies Different by access technology

?

Page 15: Transport architectures using IP Multicast technology for

15

© 2009 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID

Transit Transport

Design Options

Page 16: Transport architectures using IP Multicast technology for

16

© 2009 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID

Transport ArchitectureOverview

1. Common deployments: Native PIM-SSM or MVPN

Native, GRE IP Multicast

2. Concentrate on futures / components

Support for MPLS multicast (LSM)

Build P2MP / MP2MP label switched delivery trees

mLDP (P2MP, MP2MP), RSVP-TE P2MP

Put traffic into a VPN context

As a method of service isolation / multiplexing

Using L2 vs. L3 on PE nodes

To “integrate” better into an L2 service model

Redefine PE-PE signaling for MVPN

Page 17: Transport architectures using IP Multicast technology for

17

© 2009 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID

OverviewElements of Transport Architecture for Tree Building

1. C(ustomer)-tree building protocols

IPTV: IGMPv3 / PIM-SSM

2. P(rovider)-tree (PMSI) building protocols

Native: PIM-SSM/SM/Bidir, MPLS: mLDP, RSVP-TE

3. PE mapping: C-tree(s) to P-tree

1:1/N:1 (aggregation) ; „native‟/VPN (L2, L3) ; static/dynamic

4. PE-PE (“overlay”) tree signaling protocols

Optional PIM or BGP (extensions)

Not needed: native IPv4/IPv6, „direct-MDT‟ mLDP, static mapping

PE1 P1

PE2 CE2P2

P4 PE3 CE3Upstream PE =

Headend LSR

Tailend LSRs =

Downstream PEsCE2

Content Source

Receiver

Receiver

Page 18: Transport architectures using IP Multicast technology for

18

© 2009 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID

Combinations with L3 on PECurrent Widely Deployed

1. “Native IP multicast” (IPv4/IPv6)

IPv4/IPv6 PIM-SSM in core

User side = core tree: No PE-PE signaling required.

“RPF-Vector” for “BGP free core”

2. “MVPN”(-GRE)

Carries traffic across RFC2547 compatible L3 VPN.

With aggregation

IPv4 PIM-SSM/SM/Bidir in core (IPv4)

RFC2547 BGP ; GRE encap/decap on PE

PE-PE signaling required

I-PMSI = Default-MDT ; SI-PMSI = Data-MDT

BGP extensions for InterAS and SSM support

Page 19: Transport architectures using IP Multicast technology for

19

© 2009 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID

Content Source

PE-1

PE-2

PE-3

P-4CE-1

CE-2

CE-3

MPLS Core

Receiver

Receiver

IPv4IPv6

IPv4IPv6

IPv4IPv6

MPLS Traffic Forwarding

1. Same forwarding (HW requirements) with mLDP / RSVP-TE

2. Initial: “Single label tree” for both non-aggregated & aggregated

3. No PHP: receive PE can identify tree

Put packet after pop into correct VRF for IP multicast lookup

L100

“Push”

MC Pkt L20

L30

“Swap”

“Pop”

MC Pkt

MC Pkt

MC Pkt

MC Pkt

MC Pkt

Page 20: Transport architectures using IP Multicast technology for

20

© 2009 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID

mLDP + PE Mapping Options(Candidate Futures)

1. mLDP native – multicast for „4PE‟ (unicast)

mLDP P2MP trees build pretty much like PIM-SSM trees

No additional PE-PE signaling required

Just standard IPv4 BGP on PE (for IPv4 and IPv6 user side!)

2. mLDP “Direct-MDT” in VPN context

Exactly like mLDP native! – just rfc2547 VPNv4 BGP AF

No “MVPN” or similar signaling required

3. mLDP “MVPN”

Exactly like MVPN signaling

Just replaces PIM-SSM+GRE with mLDP

MP2MP mLDP replaces Bidir-PIM (MP2MP) Default-MDT

Page 21: Transport architectures using IP Multicast technology for

21

© 2009 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID

mLDP SignalingWith Native and Direct-MDT

Content Source

PE-1

PE-2

PE-3

P-4CE-1

CE-2

CE-3

MPLS Core

Receiver

Receiver

IPv4

IPv4

IPv4

PIM-V4 JOIN: VRF IPTV

Source= 10.10.10.1

Group = 232.0.0.1

PIM-V4 JOIN: VRF IPTV

Source= 10.10.10.1

Group = 232.0.0.1

mLDP Label Mapping:FEC = S+ G+RD+ RootLabel=(20)

mLDP Label Mapping:FEC = S+G +RD+RootLabel=(100)

PIM-V4 Join: VRF IPTV

Source= 10.10.10.1

Group = 232.0.0.1

mLDP Label Mapping:FEC= S + G + RD + RootLabel=(30)

P2MP LSP“Root”

VRF

IPTV

VRF

IPTV

VRF

IPTV

FEC: Forwarding Equivalency Class

Page 22: Transport architectures using IP Multicast technology for

22

© 2009 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID

mLDP SignalingSummary

1. Best of PIM + MPLS

Receiver side originated explicit joins – scalable trees

PIM-SSM = mLDP P2MP, Bidir-PIM ~= mLDP MP2MP

RPF-vector implicit (mLDP root)

2. Best of LDP

Neighbor discovery, graceful restart, share unicast TCP session

No interaction with unicast label assignment (ships in the night)

3. Variable length FEC

Allows overlay signaling tree 1:1 tree building for ANY (vpn, v6,..) tree

4. All PIM complexity avoided

No direct source/receiver support (DR) (just PE to PE)

No PIM-SM (need to emulate), No Bidir-PIM DF process

No hop-by-hop RP config (AutoRP, BSR, static) needed)

No asserts, other data-triggered events

Page 23: Transport architectures using IP Multicast technology for

23

© 2009 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID

RSVP-TE P2MP SignalingWith Static Native IPv4 to Customer

Content Source

PE-1

PE-2

PE-3

P-4CE-1

CE-2

CE-3

MPLSCore

Receiver

Receiver

IPv4

IPv4

IPv4

PATH P4, PE2

P2MP LSPHeadend

Static IGMP/PIM join

Source= 10.10.10.1

Group = 232.0.0.1

On interface to CE

Static IGMP/PIM join

Source= 10.10.10.1

Group = 232.0.0.1

On TE tunnel interface

Static IGMP/PIM join

Source= 10.10.10.1

Group = 232.0.0.1

On interface to CE

TE tunnel config:

ERO1: P-4, PE-2

ERO2: P-4, PE-3

PATH P4, PE3

PATH P4, PE2

RESV Label = 20

RESV Label = 30

RESV Label = 100

RESV Label = 100

Label merge !

Assign same upstream label

For all branches of a tree

PATH P4, PE3

Page 24: Transport architectures using IP Multicast technology for

24

© 2009 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID

P2MP RSVP-TESummary

1. RSVP-TE P2P LSP

Path explicitly (hop-by-hop) built by headend LSR towards tailend LSR

RSVP PATH messages answered by RESV message

2. P2MP RSVP-TE LSP

A P2MP LSP is built by building a P2P LSP for every tailend of P2MP LSP

Midpoint LSR performs “label merge” during RESVP:

Use same upstream label for all branches

3. Almost all details shared with RSVP-TE P2P

All RSVP parameters (for bandwidth reservation)

ERO or CSPF, affinities

link protection

Node protection more difficult

not currently supported

Page 25: Transport architectures using IP Multicast technology for

25

© 2009 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID

Combinations with L3 on PEWith RSVP-TE P2MP (Possible Futures)

1. RSVP-TE P2MP static / native

Core trees statically provisioned on Headend-PE:

Set of tailend-PE

All IP multicast traffic that need to be passed into the tree.

2. RSVP-TE P2MP static in L3VPN context

TBD: Possible, some more per-VRF/VPN config

3. RSVP-TE P2MP dynamic

TBD: MVPN or new PE-PE signaling (work in IETF, vendors)

Required / beneficial ?

Reason for RSVP-TE often explicit path definition

Not as easy predictable dynamic as static

Page 26: Transport architectures using IP Multicast technology for

26

© 2009 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID

PIM/mLDP Benefits Over RSVP-TE P2MPExamples (Not Complete)

1. Cost of trees (in node/network)

N = # tailend LSR (#PE)

PIM/mLDP P2MP: ~1, RSVP-TE P2MP: ~N

Full mesh of RSVP-TE P2MP LSP: ~(N * N)

Bidir-PIM/mLDP MP2MP: ~1

Summary: No scaling impact of N for PIM/mLDP

2. Locality:

Affects convergence/reoptimization speed:

PIM/mLDP: Failure in network affects only router in region (eg: in pink region).

RSVP: impact headend and all affected midpoint and tailends for RSVP-TE reoptimization.

Join/leave of members affect only routers up to first router on the tree in mLDP/PIM. Will

affect headend and all midpoints in RSVP-TE P2MP.

Src

Rcv

Rcv

Rcv

HeadendLSR

Page 27: Transport architectures using IP Multicast technology for

27

© 2009 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID

RSVP-TE P2MP Benefits Over PIM/mLDPExamples

1. Sub 50 msec protection ?

Also feasible for PIM/mLDP!

2. Load-split traffic across alternative paths (ECMP or not)

PIM/mLDP tree follows shortest path, “dense” receiver population == dense use of links

RSVP-TE P2MP ERO trees (RED/PINK) under

control of headend LSR.

CSPF load split based on available bandwidth.

Src

Rcv

Rcv

Rcv

HeadendLSR

Page 28: Transport architectures using IP Multicast technology for

28

© 2009 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID

Virtualization Considerations“Internet/Walled-Garden” or L3VPN ?

1. L3VPN (MVPN) developed as multicast component of (unicast/RFC2547) L3VPN

Primarily for “Enterprise VPN” services

Usable for IPTV as well (with MVPN-GRE or MVPN-mLDP)

2. Why ?

Core - operator policy for all services (VPN, IPTV, Internet, …)

Edge - wholesale considerations (VPN per wholesaler)

Service separation considerations (service per VPN)

3. Use only when needed !

Native IP multicast with PIM-SSM or mLDP most simple!

L3VPN adds complexity, convergence, reliability considerations.

No need for L3VPN for access control policy reasons!

All possible with native IP SSM access control

Page 29: Transport architectures using IP Multicast technology for

29

© 2009 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID

L2VPN Considerations

1. L2 preferred by non-IP „communities‟

IP address transparency (unicast only issue)

PE “invisible” = customer free to choose protocols independent of provider

Not true if PE uses PIM/IGMP snooping!

2. No (dynamic) P/PE L2 solution with P2MP trees

VPLS: full-mesh/hub&spoke P2P pseudowire only

Non P/PE models available: single-hop protected pseudowires.

3. Recommended directions:

Most simple: one mLDP MP2MP LSP per L2VPN (broadcast)

Not to use IGMP/PIM snooping on L2VPN-PE!

Unless customer is provider (eg: broadband edge design)

Page 30: Transport architectures using IP Multicast technology for

30

© 2009 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID

Transit Technologies for IPTVSummary / Recommendations

1. Native PIM-SSM + RPF-Vector

Most simple, most widely deployed, resilient solution.

2. MVPN-GRE

Also many years deployed (Cisco/rosen specification).

Recommended for IPTV when VRF-isolation necessary !

3. mLDP

Recommended Evolution for MPLS networks for all IP multicast transit:

„Native‟ (m4PE/m6PE)

„Direct-MDT/MVPN-mLDP‟ (IPv4/IPv6)

4. RSVP-TE P2MP

Strength in TE elements (ERO/CSPF + protection)

Recommended for limited scale, explicit engineered designs,

eg: IPTV contribution networks.

Page 31: Transport architectures using IP Multicast technology for

31

© 2009 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID

Resiliency

Page 32: Transport architectures using IP Multicast technology for

32

© 2009 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID

Source RedundancyWith SSM

1. Receivers explicitly „join‟ to (S,G) Group AND Source

2. What to do if source fails ?

3. Initially ok: join to two sources (S1,G), (S2,G)

Supported by transition solutions like SSM mapping

Double state in network (convergence speed)

Makes operations more difficult

(CAC, RSVP, management, acces control, …)

4. Best: use same source-IP address

Known as Anycast, better: Redundant IP address

Redundant IP address should be additional/secondary address

Primary address of router always has to be unique

Page 33: Transport architectures using IP Multicast technology for

33

© 2009 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID

Source RedundancyWith SSM

1. L2: Redundant sources in same L2 LAN

No interaction with network required

Application must ensure only one source active at any time.

Recommended/good for collocated sources.

2. L3: Redundant sources in different LANs

Source to announce redundant IP address for PIM-SSM (eg: R3) to know where to RPF/join the

traffic.

Both sources may send simultaneously !

But announce address only when sending !

RIPv2 most simple announcement protocol

NOT RIPv2 between routers!

Add BFD srce<->network for efficient fast failover

Src1 Src2

Src1 Src2

R3

L2 source redundancy

L3 source redundancy

Announce

RedundantIP addressWhen source

Is sending

RPF

R3

RPF

R3 can RPF

to either R1

or R2 and

receive traffic

from either source

R1 R2

R2R1

Page 34: Transport architectures using IP Multicast technology for

34

© 2009 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID

Source RedundancyL2/L3 Issue

1. When not use L2 Src redundancy on WAN

Consider Src1/Src2 in different WAN locations with L3 network.

Can create L2 connectivity between them.

Eg: EoMPLS R1 <-> R2

Does this help to avoid redundant IP source address signaling ?

Yes, … but …

2. Problem:

L2 and L3 topologies overlap

traffic may flow multiple times over same physical link.

L3 RPF can not know which edge router (R1, R2) on

LAN is “closest” router toward active source

That is exactly what the announcement of the redundant IP source address would provide !

Src1 Src2

L2 source redundancy

Across WAN

R3RPF

R1 R2

Location 1 Location 2

L3 core/

distribution

network

EoMPLS

Traffic

Page 35: Transport architectures using IP Multicast technology for

35

© 2009 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID

Source RedundancyAnycast/Prioritycast Policies

1. Policies

Anycast:clients connect to the closest instance of redundant IP address

Prioritycast:clients connect to the highest-priority instance of the redundant IP address

2. Also used in other places

Eg: PIM-SM, Bidir-PIM RP redundancy, DNS

3. Policy simply determined by routing announcement and routing config

Anycast well understood

Prioritycast: engineer metrics of announcements or use different prefix length.

Src B

secondary

Rcvr 2Rcvr 1

Src A

primary

10.2.3.4/31

Example: prioritycast with

Prefixlength annuncement

10.2.3.4/32

Page 36: Transport architectures using IP Multicast technology for

36

© 2009 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID

Source RedundancyExplicit Signaling Benefits

1. Subsecond failover possible

2. Represent program channel as single (S,G)

SSM: single tree, no signaling, ASM: no RPT/SPT

3. Move instances “freely” around the network

Most simply within IGP area

Careful across national network (BGP)

4. No vendor proprietary source sync proto required

5. Per program, not only per-source-device failover

Use different source address per program

Page 37: Transport architectures using IP Multicast technology for

37

© 2009 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID

Terminatedpseudowire

over LDP MPLS

Protected Pseudowires

Classic pseudowire

1. R1/R2 provide pseudowirefor R3/R4

accepting/delivering packets from/to physical interface.

Protected pseudowire

1. Provide sub 50msec link

protection for packets of pseudowire (or any other MPLS packets) by

configuring RSVP-TE LSP with FRR backup tunnel

Terminated(Routed) pseudowire

1. R1/R2 terminate pseudowire on internal port instead of physical

interface. Can bridge (VLAN) or route from/to port.

R3R4

R1 R2

R2R1

R3

R4R1 R2

Pseudowireover LDP MPLS

Pseudowireover LDP MPLS

RSVP-TE (P2P) Tunnels with FRR

RSVP-TE (P2P) Tunnels with FRR

Page 38: Transport architectures using IP Multicast technology for

38

© 2009 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID

Sub 50 msec Link ProtectionWith Protected Pseudowires

1. Consider aggregation network (R-R6). L2 (bridged) or L3 (routed)

2. Configure L2 or L3 multicast to not use physical links between R1-R6, but terminated pseudowires (one-hop). Sub 50 link protection against link failures in ring!

3. Problem: as long as outage persists, traffic will flow duplicate on links

R1

Access

Core

Distr-Edge routers

R2 R3

R4

R5R6

Access

AccessAccess

Page 39: Transport architectures using IP Multicast technology for

39

© 2009 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID

Multicast Fast Convergence (FC)

1. FC (unicast and multicast) heavily optimized in IOS/IOS-XR

Limitations in basic principle of tree building:

2. IP multicast

All failures / recoveries / topology changes corrected by re-converging the trees. Same interruption for all causes !!!

Re-convergence time is sum of:

Failure detection time (only for failure cases)

Unicast routing re-convergence time

~ #Multicast-trees PIM re-convergence time

Possible

~ minimum of 400 msec initial

~ 500 ... 4000 trees convergence/sec (perf)

3. Same targets with mLDP !

Page 40: Transport architectures using IP Multicast technology for

40

© 2009 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID

(classic) Fast Reroute (FRR)RSVP-TE (P2P, P2MP), IP-FRR (PIM, mLDP)

1. Principles

Local reaction to failure (no signaling) == 50 msec

Send traffic on pre-established (Link, Node) backup path (tunnel)

Only in failure case, only necessary on unexpected failures !

“Make before break” reconvergence / reoptimization

Backup tunnel almost never ideal path

Less able not sustain another error while using tunnel !

2. RSVP-TE P2MP: All included (ietf) !

Not covered: Headend redundancy !

3. Native IP multicast, mLDP

Optional, not part of protocols themselves

Unicast IP-FRR principles already in IETF.

To be leveraged by multicast IP-FRR (for backup tunnels)

Page 41: Transport architectures using IP Multicast technology for

41

© 2009 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID

(classic) FRRmLDP Link Protection

1. RSVP-TE P2P backup tunnel or IPFRR / LDP backup tunnel

2. Simple:

When R3 sees link to R going down it takes mLDP packet as it would send it to R2 and sends it into the backup tunnel

PHP in R1 will cause backup tunnel labels to be removed

R2 will receive same packet as from s0, just from different interface

Same forwarding !

S(ource)Rcvr1R1 R2 R3

R4

R5

R6

s0

L1: IIF = s0

L2

L3

L4

php

L5L3L7 L1

L1

L1

L1 L1

L5 L1

Page 42: Transport architectures using IP Multicast technology for

42

© 2009 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID

(classical) FRR Node ProtectionWith p2p Backup Tunnels

1. If router with fan-out of N fails, N-times as much backup bandwidth as otherwise is needed.

Provisioning issue depending on topology !

2. Some ideas to use multipoint backup to resolve this, but…

3. Recommendation?: Rely on Node HA instead!!

S(ource)Rcvr1

R1 R2 R3

R4 R5 R6

Rcvr2

Page 43: Transport architectures using IP Multicast technology for

43

© 2009 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID

cFRRPIM/mLDP Make Before Break

1. Receive RPF change from unicast

2. Send joins to A

3. Wait for right time to go to 4.

Until upstream is forwarding traffic

4. Change RPF to A

5. Send prunes to B

Should only do Make-before-Break when oldpath (B) is known to still forward traffic after 1.

Path via B failed but protected

Path to A better, recovered

Not: path via B fails, unprotected

Make before Break could cause more interruption than Break before Make !

A B

S(ource)

Cost: 10

C

Cost: 12

R(eceiver)

Page 44: Transport architectures using IP Multicast technology for

44

© 2009 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID

Live-Live with Path DiversityPrinciples

1. Guarantee:

Transfer two copies of stream path separated - No single failure in network impacts both copies

Best: Two network - traditional finance deployment

Cheaper: Shared network

Natural diversity

Forced diversity (various solutions)

2. Splice and Join at EDGE of network

In actual source/receivers

In network devices (dedicated or in router)

No need for time-critical operations in core

3. Live-live service:

receive/deliver two copies, splice/join on customer side. Limited to customers whose app/equip. can support this

4. Zero-Loss service (using live-live):

Join based on sequence numbers. Protects also against BER on both paths !!!

Src…

Naturallyor

forceddisjoint

…Rcv

Pro

tectio

n D

om

ain

SourceOr

stream

splicer

ReceiverOr

stream

joiner

Page 45: Transport architectures using IP Multicast technology for

45

© 2009 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID

Basic MoFRRECMP, IGP Upstream

1. Join within network device (router) by switching which received copy to forward.

Switch is not zero loss – but (close to) 50msec

2. R1 MoFRR operations

Expect two RPF paths (from IGP/BGP)

ECMP

Join to both RPF interfaces

Forward traffic from one of them.

If used path is lost, switch to second

3. Various extensions considered

Switchover based on traffic loss

Full zero-loss (sequence number based join)

Support for more topologies:

U-turn via LFA

Src

R1

RU1 RU2

Naturallydisjoint

Rcv

RH

Pro

tectio

n D

om

ain

R1a R1b

U-turn attachment

Page 46: Transport architectures using IP Multicast technology for

46

© 2009 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID

Path Separation in Rings

1. Can provide live-live guarantee in rings ! Cost saving!

Used in eg: MSO / digital cable

2. Various techniques to create two counterclockwise traffic flows

3. Candidate: Two IGP topologies – with asymmetric link costs

RedundantEncoder/Multiplexer

RcvrRcvr

Rcvr

Rcvr Small metric

Infinite/largemetric Infinite/large

metricSmall metric

eQAM

eQAM

Page 47: Transport architectures using IP Multicast technology for

47

© 2009 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID

Application Side Resiliency

1. FEC – Forward error correction

Compensate for statistical packet loss

Use existing FEC eg: for MPEG transport to overcome BER errors. Potentially applicable to sub 50 msec correction.

2. ARQ - Retransmissions

Done eg: with Cisco VQE – unicast retransmissions

Candidate large bursts of retransmissions

Multicast retransmissions would help improve

3. Live-live exception

4. FEC/ARQ introduce delay !

Page 48: Transport architectures using IP Multicast technology for

48

© 2009 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID

RSVP-TE P2P Workarounds

1. Without improvements (classical FRR or other), IP multicast can not benefit from RSVP-TE P2P tunnels

P2P tunnels break multicast without workarounds:

2. Classic: Auto-tunnel (one-hop) / strategic

TE routes calculated independent of IGP -> IGP still has native route.

mpls traffic-eng multicast-intact

Changes multicast RPF: If RPF is tunnel, retrieve original IGP route to source from multicast RIB.

3. MPLS TE forwarding adjacency (12.0(15)S, …)

tunnel mpls traffic-eng forwarding-adjacency

IGP considers TE tunnel as “normal” interfaces.

No guarantee that “native” paths are calculated.

Page 49: Transport architectures using IP Multicast technology for

49

© 2009 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID

IP Multicast (PIM/mLDP) ECMP (Equal Cost Multipath)

1. Pseudo-random selection of RPF

… if Unicast routing has more than one available path.

2. Polarizing == predictable

(consistent across network), IOS only

ip multicast multipath s-g-hash basic

3. Non-polarizing

IOS and XR (XR default & only option, no config)

ip multicast multipath s-g-hash next-hop-based

4. IOS default: no ECMP – use highest IP address neighbor

Page 50: Transport architectures using IP Multicast technology for

50

© 2009 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID

IP Multicast (and mLDP) ECMP Non-Polarizing Means Non-Predictable

1. Polarization:

All routers along network path choose same relative interface for a multicast tree.

2. Predictability:

With algorithm known, group addresses G of (S,G) can be assigned by operator such that traffic is well split across multiple hops (link bundles)

Workaround, not recommended – for highly utilized links (> 85% ?)

1

32

4 5 6 7

Polarizing

Bad ?Good:Bad:

NeverUsed

1

32

4 5 6 7

Non-polarizing

GoodLink

Overload?

Page 51: Transport architectures using IP Multicast technology for

51

© 2009 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID

Multicast and IPTVSummary

1. Design IP multicast WITH SSM as generic infrastructure service – for IPTV and beyond

2. Select transport design

Native IP multicast or mLDP (MPLS core) for most networks to the future

RSVP-TE P2MP for eg: contribution network

3. Determine appropriate resilience support

4. Path selection

ECMP and multicast or multiple topologies

Page 52: Transport architectures using IP Multicast technology for

52

© 2009 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID