Your SlideShare is downloading. ×
Transport architectures using IP Multicast technology for ...
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Transport architectures using IP Multicast technology for ...

2,660
views

Published on


1 Comment
0 Likes
Statistics
Notes
  • thank for your share knowledge
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Be the first to like this

No Downloads
Views
Total Views
2,660
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
202
Comments
1
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Transport architectures using IP Multicast technology for IPTV Services Stefan Kollar Consulting System Engineer, CCIE #10668 skollar@cisco.com Presentation_ID © 2009 Cisco Systems, Inc. All rights reserved. Cisco Confidential 1
  • 2. 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 2 Presentation_ID © 2009 Cisco Systems, Inc. All rights reserved. Cisco Confidential
  • 3. Introduction IPTV and IP Multicast 3 Presentation_ID © 2009 Cisco Systems, Inc. All rights reserved. Cisco Confidential
  • 4. 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 4 Presentation_ID © 2009 Cisco Systems, Inc. All rights reserved. Cisco Confidential
  • 5. Deployment Strategy Overview, 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 5 Presentation_ID © 2009 Cisco Systems, Inc. All rights reserved. Cisco Confidential
  • 6. Architectural Overview 6 Presentation_ID © 2009 Cisco Systems, Inc. All rights reserved. Cisco Confidential
  • 7. 50,000 Feet Architecture IPTV and Multicast IPTV “Services Plane” IP multicast Service gateway IP multicast Receive/process/send Eg: Ad-Splicer, Dserver, Transrater,… IP multicast source receiver Signaling Signaling Signaling Service Interface Multicast traffic The network Multicast traffic “Network Plane” 7 Presentation_ID © 2009 Cisco Systems, Inc. All rights reserved. Cisco Confidential
  • 8. 50,000 Feet Architecture Goals 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 8 Presentation_ID © 2009 Cisco Systems, Inc. All rights reserved. Cisco Confidential
  • 9. IP Multicast Primer 9 Presentation_ID © 2009 Cisco Systems, Inc. All rights reserved. Cisco Confidential
  • 10. 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! 10 Presentation_ID © 2009 Cisco Systems, Inc. All rights reserved. Cisco Confidential
  • 11. 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 11 Presentation_ID © 2009 Cisco Systems, Inc. All rights reserved. Cisco Confidential
  • 12. IP Multicast Services Issues 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 12 Presentation_ID © 2009 Cisco Systems, Inc. All rights reserved. Cisco Confidential
  • 13. 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) 13 Presentation_ID © 2009 Cisco Systems, Inc. All rights reserved. Cisco Confidential
  • 14. End-to-End Protocol View Example: L3 Aggregation Same choices for all access technologies Different by access technology External Core Distribution Aggregation Access Home Net Network / regional BB type Eg: Dis. PE-AGG Home specific STB Content Edge Rtr Gateway provider Video encoder/ multiplexer ? First hop router Content injection: External, national, regional, local PIM-SSM (S,G) joins IGMPv3 (S,G) membership Headend L3 Transport Options in clouds: Opt. Native: PIM-SSM or MVPN/SSM IGMP: MPLS: LSM / mLDP RSVP-TE {Limits} IGMPv3 IGMPv3 IGMPv3 Source {Static-fwd} snooping proxy routing SSM Redundancy PIM-SSM PIM-SSM PIM-SSM 14 Presentation_ID © 2009 Cisco Systems, Inc. All rights reserved. Cisco Confidential
  • 15. Transit Transport Design Options 15 Presentation_ID © 2009 Cisco Systems, Inc. All rights reserved. Cisco Confidential
  • 16. Transport Architecture Overview 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 16 Presentation_ID © 2009 Cisco Systems, Inc. All rights reserved. Cisco Confidential
  • 17. Overview Elements 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 Receiver Content Source P2 PE2 CE2 Tailend LSRs = CE2 PE1 P1 Downstream PEs Upstream PE = P4 PE3 CE3 Headend LSR Receiver 17 Presentation_ID © 2009 Cisco Systems, Inc. All rights reserved. Cisco Confidential
  • 18. Combinations with L3 on PE Current 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 18 Presentation_ID © 2009 Cisco Systems, Inc. All rights reserved. Cisco Confidential
  • 19. 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 IPv4 IPv6 PE-2 CE-2 MC Pkt L20 MC Pkt Receiver IPv4 MC Pkt L100 IPv6 “Pop” PE-1 P-4 CE-1 MC Pkt MPLS Core Content Source MC Pkt L30 MC Pkt “Push” PE-3 IPv4 “Swap” IPv6 CE-3 Receiver 19 Presentation_ID © 2009 Cisco Systems, Inc. All rights reserved. Cisco Confidential
  • 20. 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 20 Presentation_ID © 2009 Cisco Systems, Inc. All rights reserved. Cisco Confidential
  • 21. mLDP Signaling With Native and Direct-MDT PIM-V4 JOIN: VRF IPTV mLDP Label Mapping: FEC = S+ G+RD+ Root Source= 10.10.10.1 Label=(20) Group = 232.0.0.1 mLDP Label Mapping: PIM-V4 Join: VRF IPTV FEC = S+G +RD+Root Source= 10.10.10.1 Label=(100) IPv4 CE-2 Group = 232.0.0.1 Receiver VRF IPTV PE-2 IPv4 PE-1 P-4 CE-1 VRF MPLS Core PIM-V4 JOIN: VRF IPTV Content IPTV Source= 10.10.10.1 Source Group = 232.0.0.1 P2MP LSP mLDP Label Mapping: PE-3 FEC= S + G + RD + Root “Root” Label=(30) VRF IPv4 IPTV CE-3 FEC: Forwarding Equivalency Class Receiver 21 Presentation_ID © 2009 Cisco Systems, Inc. All rights reserved. Cisco Confidential
  • 22. mLDP Signaling Summary 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 22 Presentation_ID © 2009 Cisco Systems, Inc. All rights reserved. Cisco Confidential
  • 23. RSVP-TE P2MP Signaling With Static Native IPv4 to Customer TE tunnel config: Static IGMP/PIM join ERO1: P-4, PE-2 Source= 10.10.10.1 ERO2: P-4, PE-3 PATH P4, PE2 Group = 232.0.0.1 PATH P4, PE2 On interface to CE RESV Label = 20 Static IGMP/PIM join PATH P4, PE3 Source= 10.10.10.1 CE-2 Group = 232.0.0.1 On TE tunnel interface IPv4 Receiver IPv4 PE-2 MPLS Core PE-1 P-4 CE-1 Content Source RESV Label = 100 Static IGMP/PIM join Source= 10.10.10.1 RESV Label = 100 PATH P4, PE3 PE-3 Group = 232.0.0.1 On interface to CE RESV Label = 30 IPv4 P2MP LSP Label merge ! CE-3 Headend Assign same upstream label Receiver For all branches of a tree 23 Presentation_ID © 2009 Cisco Systems, Inc. All rights reserved. Cisco Confidential
  • 24. P2MP RSVP-TE Summary 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 24 Presentation_ID © 2009 Cisco Systems, Inc. All rights reserved. Cisco Confidential
  • 25. Combinations with L3 on PE With 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 25 Presentation_ID © 2009 Cisco Systems, Inc. All rights reserved. Cisco Confidential
  • 26. PIM/mLDP Benefits Over RSVP-TE P2MP Examples (Not Complete) 1. Cost of trees (in node/network) N = # tailend LSR (#PE) Src Headend PIM/mLDP P2MP: ~1, RSVP-TE P2MP: ~N LSR 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 Rcv P2MP. Rcv Rcv 26 Presentation_ID © 2009 Cisco Systems, Inc. All rights reserved. Cisco Confidential
  • 27. RSVP-TE P2MP Benefits Over PIM/mLDP Examples 1. Sub 50 msec protection ? Src Also feasible for PIM/mLDP! Headend 2. Load-split traffic across alternative paths LSR (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. Rcv Rcv Rcv 27 Presentation_ID © 2009 Cisco Systems, Inc. All rights reserved. Cisco Confidential
  • 28. 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 28 Presentation_ID © 2009 Cisco Systems, Inc. All rights reserved. Cisco Confidential
  • 29. 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) 29 Presentation_ID © 2009 Cisco Systems, Inc. All rights reserved. Cisco Confidential
  • 30. Transit Technologies for IPTV Summary / 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. 30 Presentation_ID © 2009 Cisco Systems, Inc. All rights reserved. Cisco Confidential
  • 31. Resiliency 31 Presentation_ID © 2009 Cisco Systems, Inc. All rights reserved. Cisco Confidential
  • 32. Source Redundancy With 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 32 Presentation_ID © 2009 Cisco Systems, Inc. All rights reserved. Cisco Confidential
  • 33. Source Redundancy L2 source redundancy With SSM Src1 Src2 1. L2: Redundant sources in same L2 LAN No interaction with network required Application must ensure only one source active at any time. R1 R2 RPF Recommended/good for collocated sources. … R3 can RPF to either R1 2. L3: Redundant sources in different LANs or R2 and R3 receive traffic from either source Source to announce redundant IP address for PIM- SSM (eg: R3) to know where to RPF/join the L3 source redundancy traffic. Src1 Src2 Both sources may send simultaneously ! But announce address only when sending ! RIPv2 most simple announcement protocol NOT RIPv2 between routers! R1 R2 RPF Add BFD srce<->network for efficient fast failover Announce Redundant IP address R3 When source Is sending 33 Presentation_ID © 2009 Cisco Systems, Inc. All rights reserved. Cisco Confidential
  • 34. Source Redundancy L2/L3 Issue L2 source redundancy 1. When not use L2 Src redundancy on WAN Across WAN Consider Src1/Src2 in different WAN locations with L3 network. Location 1 Location 2 Can create L2 connectivity between them. Src1 Src2 Eg: EoMPLS R1 <-> R2 Does this help to avoid redundant IP source address signaling ? Yes, … but … R1 R2 2. Problem: L2 and L3 topologies overlap EoMPLS traffic may flow multiple times over same physical link. Traffic L3 RPF can not know which edge router (R1, R2) on LAN is “closest” router toward active source RPF R3 That is exactly what the announcement of the redundant IP L3 core/ source address would provide ! distribution network 34 Presentation_ID © 2009 Cisco Systems, Inc. All rights reserved. Cisco Confidential
  • 35. Source Redundancy Anycast/Prioritycast Policies Src A Src B primary secondary 1. Policies 10.2.3.4/32 10.2.3.4/31 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 Rcvr 1 Rcvr 2 length. Example: prioritycast with 35 Presentation_ID © 2009 Cisco Systems, Inc. All rights reserved. Cisco Confidential Prefixlength annuncement
  • 36. Source Redundancy Explicit 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 36 Presentation_ID © 2009 Cisco Systems, Inc. All rights reserved. Cisco Confidential
  • 37. Protected Pseudowires Classic pseudowire R1 R2 1. R1/R2 provide Pseudowire pseudowire R4 R3 over LDP MPLS for R3/R4 accepting/delivering packets from/to physical interface. RSVP-TE (P2P) Tunnels with FRR Protected pseudowire 1. Provide sub 50msec link R1 R2 protection for packets of R4 pseudowire (or any other Pseudowire R3 over LDP MPLS MPLS packets) by configuring RSVP-TE LSP with FRR backup tunnel Terminated(Routed) RSVP-TE (P2P) pseudowire Tunnels with FRR R1 R2 1. R1/R2 terminate pseudowire on internal port instead of physical Terminated interface. Can bridge pseudowire (VLAN) or route from/to over LDP MPLS 37 Presentation_ID © 2009 Cisco Systems, Inc. All rights reserved. Cisco Confidential
  • 38. Sub 50 msec Link Protection With Protected Pseudowires Core R5 R6 R1 Distr-Edge routers R4 Access R2 R3 Access Access Access 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 38 Presentation_ID © 2009 Cisco Systems, Inc. All rights reserved. Cisco Confidential
  • 39. 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 ! 39 Presentation_ID © 2009 Cisco Systems, Inc. All rights reserved. Cisco Confidential
  • 40. (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) 40 Presentation_ID © 2009 Cisco Systems, Inc. All rights reserved. Cisco Confidential
  • 41. (classic) FRR mLDP Link Protection Rcvr1 S(ource) L7 R1 L3 R2 L1 R3 L5 s0 php L1: IIF = s0 L4 L1 L1 L2 L1 R5 R4 L5 L1 L3 L1 R6 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 ! 41 Presentation_ID © 2009 Cisco Systems, Inc. All rights reserved. Cisco Confidential
  • 42. (classical) FRR Node Protection With 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!! Rcvr1 S(ource) R1 R2 R3 Rcvr2 R4 R5 R6 42 Presentation_ID © 2009 Cisco Systems, Inc. All rights reserved. Cisco Confidential
  • 43. cFRR PIM/mLDP Make Before Break 1. Receive RPF change from unicast S(ource) 2. Send joins to A 3. Wait for right time to go to 4. Cost: 10 Cost: 12 Until upstream is forwarding traffic 4. Change RPF to A A B 5. Send prunes to B Should only do Make-before-Break when old path (B) is known to still forward traffic after 1. Path via B failed but protected Path to A better, recovered C Not: path via B fails, unprotected Make before Break could cause more interruption than Break before Make ! R(eceiver) 43 Presentation_ID © 2009 Cisco Systems, Inc. All rights reserved. Cisco Confidential
  • 44. Live-Live with Path Diversity Principles 1. Guarantee: Src Transfer two copies of stream path separated - No single failure Source … in network impacts both copies Or Best: Two network - traditional finance deployment stream splicer Cheaper: Shared network Natural diversity Protection Domain Forced diversity (various solutions) 2. Splice and Join at EDGE of network Naturally In actual source/receivers or In network devices (dedicated or in router) forced No need for time-critical operations in core disjoint 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): Receiver Or Join based on sequence numbers. Protects also against BER stream on both paths !!! joiner … Rcv 44 Presentation_ID © 2009 Cisco Systems, Inc. All rights reserved. Cisco Confidential
  • 45. Basic MoFRR ECMP, IGP Upstream Src 1. Join within network device (router) by RH switching which received copy to forward. Switch is not zero loss – but (close to) 50msec Protection Domain 2. R1 MoFRR operations Expect two RPF paths (from IGP/BGP) ECMP Naturally disjoint Join to both RPF interfaces RU1 RU2 Forward traffic from one of them. If used path is lost, switch to second 3. Various extensions considered Switchover based on traffic loss R1 Full zero-loss (sequence number based join) Support for more topologies: Rcv U-turn via LFA R1a R1b U-turn attachment 45 Presentation_ID © 2009 Cisco Systems, Inc. All rights reserved. Cisco Confidential
  • 46. Path Separation in Rings Rcvr Rcvr eQAM eQAM Redundant Encoder/Multiplexer Rcvr Small metric Rcvr Infinite/large metric Infinite/large Small metric metric 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 46 Presentation_ID © 2009 Cisco Systems, Inc. All rights reserved. Cisco Confidential
  • 47. 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 ! 47 Presentation_ID © 2009 Cisco Systems, Inc. All rights reserved. Cisco Confidential
  • 48. 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. 48 Presentation_ID © 2009 Cisco Systems, Inc. All rights reserved. Cisco Confidential
  • 49. 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 49 Presentation_ID © 2009 Cisco Systems, Inc. All rights reserved. Cisco Confidential
  • 50. 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% ?) Polarizing Non-polarizing Bad: Good: Good Bad ? Link Overload? 4 5 6 7 4 5 6 7 Never 2 Used 3 2 3 1 1 50 Presentation_ID © 2009 Cisco Systems, Inc. All rights reserved. Cisco Confidential
  • 51. Multicast and IPTV Summary 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 51 Presentation_ID © 2009 Cisco Systems, Inc. All rights reserved. Cisco Confidential
  • 52. 52 Presentation_ID © 2009 Cisco Systems, Inc. All rights reserved. Cisco Confidential