Upload
reyna-nailor
View
214
Download
1
Embed Size (px)
Citation preview
1© 2004 Cisco Systems, Inc. All rights reserved.
Session NumberPresentation_ID
IP Multicast update
Apricot 2006
Toerless Eckert [email protected]
222© 2004 Cisco Systems, Inc. All rights reserved.Presentation_ID
Agenda
• Network Services
• Traditional ASM “Any Source Multicast”
• Source Specific Multicast (SSM) with source redundancy
• IPv4 multicast protocols
• IGMP, PIM-SM/MSDP, Bidir-PIM, PIM-SSM, …
• IPv6 multicast
• Addressing, Embedded-RP
• Multicast RPF
• ECMP, MP-BGP, IGP incongruency: one/two topologies
• Reliable multicast transport protocols
• PGM, ALC/Tornado-Codecs – content preprovisioning/nVoD
IP MulticastNetwork ServicesASM, SSM, Source redundancy
333© 2004, Cisco Systems, Inc. All rights reserved.Presentation_ID
444© 2004 Cisco Systems, Inc. All rights reserved.Presentation_ID
IP Multicast Network ServicesASM
IP multicast service models describe how applications can send and receive multicast packets
Everything application developers need to know aboutIP multicast (“protocol stuff is for network operators”)
• ASM: Classical IP Multicast service (rfc1112, ~1990)• Called “Any Source Multicast” today
• Sources send IP multicast packets to a IP multicast group
• Receivers “join to IP multicast group”.
• Network will deliver packets sent by any source to an IP multicast group to all receivers that have joined the IP multicast group.
555© 2004 Cisco Systems, Inc. All rights reserved.Presentation_ID
IP multicast servicesSSM and Source redundancy
• SSM: Source Specific Multicast (~2000)• Source(s) still send IP multicast to IP multicast group address – but
called “send packet to (S,G) channel”!
• Receivers need to “subscribe to (S,G) channel” – indicate to network not only IP multicast group but also the source(S) !!
• Network will deliver packets on a per-channel basis only
• Need application based source discovery mechanisms for multi-source applications
• “Redundant IP address” for source-redundancy:• Primary target for SSM: “Single-Source” –
TV/Audio/Data-”broadcast” applications
• Require source-redundancy – Use single IP address (with anycast/prioritycase) to avoid dynamic source-discovery
• But why SSM, is ASM not good enough or better ?• ASM is simpler for application developers !
Reluctance to adopt SSM
666© 2004 Cisco Systems, Inc. All rights reserved.Presentation_ID
IP multicast network servicesIssues with ASM – resolved with SSM
• DoS attacks by unwanted sources• Receivers can ignore packets, but network resources can only be protected by
extensive network source access control == network level application control.
• Address allocation• Try to get “global scope” IPv4 multicast address (GLOB, …) –
“Oh, let’s do multicast group NAT then…”
• Complexity of protocol operations required• PIM-SM (Shared trees, shortest path trees, RPT/SPT switchover)/MSDP, RP
announcement (AutoRP/BSR), RP placement, RP redundancy
• Operating PIM-SM over core networks (MVPN, Multicast and MPLS)
• Futures: Bandwidth reservation (RSVP, per group ? Per source ?), Link/Node Protection with PIM-SM
• Scalability, Speed of protocol operations (convergence)• Operations for both SPT and RPT needed – and their interaction
777© 2004 Cisco Systems, Inc. All rights reserved.Presentation_ID
IP multicast network servicesSummary
• SSM is a key recent enhancement to IP multicast• Network operators should be very interested to use it / promote it’s use
over ASM (where appropriate) to provider better (manageable/scalable) multicast services
• SSM can not replace ASM in all applications• Many-source applications
• Source-discovery with IP multicast
• ASM and SSM can coexist
• Recent means of improvement / simplification of ASM• Easier protocols for ASM
• Bidir-PIM (intradomain only today)
• Easier RP-redundancy (PIM-Anycast-RP, Prioritycast)
• IPv6 multicast (address allocation, embedded-RP)
IPv4 multicast protocols
888© 2004, Cisco Systems, Inc. All rights reserved.Presentation_ID
999© 2004 Cisco Systems, Inc. All rights reserved.Presentation_ID
Protocols for IP multicastHost to Router signaling: membership reporting
• IPv4:IGMP “Internet Group Management Protocol”IPv6:MLD “Multicast Listener Discovery”
• MLD<n> = IGMP<n+1>
• IGMPv2/MLDv1: group memberships• Sufficient for ASM
• IGMPv3/MLDv2: group and source memberships• Required for SSM, also support ASM
• No IGMPv2/MLDv1 report suppression:
• Enables tracking per-receiver on a LAN
• Enables null leave latency
• IGMPv3/MLDv2 fully backward compatible (router/host)• But not snooping devices – must support IGMPv3/MLDv2!
• IGMPv3/MLD support in host != SSM support• OS may support IGMPv3, must application may still only
signaling group membership report
• SSM transition solutions available to map group membership reports to (S,G) channel subscriptions (eg: SSM mapping)
Rcvr
MembershipReports
MembershipQueries
Router
101010© 2004 Cisco Systems, Inc. All rights reserved.Presentation_ID
Protocols for IP multicastHost to Router signaling: redundant source reporting
• No IETF standard available
• “Multicast and Anycast Group Membership” MAGMA) IETF WG never got around working on it … and is now getting isbanded ;-(
• Pragmatic solutionSource announces redundant source address via RIP:
• Easily done from application (RIP uses UDP)
• No protocol machinery required – only periodic sending.
• Fast periodic sending for fast source failure detection
• All routers support RIP, but RIP is seldomnly used in production networks
• Allows router to be configured to easily limit RIP to only redundant source announcements
• Already used in MPEG video sourcing products
Src
RIP(v2)Report (UDP)
Router
111111© 2004 Cisco Systems, Inc. All rights reserved.Presentation_ID
“eierlegende Wollmilchsau” (german)== egg-laying wool-milk-sow
(The pig that gives meat, sausage,wool, feathers, milk and eggs)
Aka: the universal solution that can do everything.
IPv4
PIM-SM / MSDP
MP-BGP(SAFI2), AutoRP/BSRAnycast-RP
Protocols for IP multicastRoadmap? of IP multicast protocol evolution
RPF-flooding
DVMRPPIM-DM
Spanning-Tree-floodingBGP
CBT
RPFv4v6:Multi-
topologiesIGP + BGP
ASMv4/v6:Bidir-PIM
Intradomain only
SSMv4v6:PIM-SSM
Intra/Interdomain
ASMv6:PIM-SM+
Embedded-RPIntra/Interdomain
IGPsEg: OSPF
MOSPF PA
ST
PR
ES
EN
TF
UU
RE
121212© 2004 Cisco Systems, Inc. All rights reserved.Presentation_ID
Protocols for IP multicastIPv4 ASM standard model protocols: PIM-SM / MSDP
• PIM-SM
• Shared-Tree and Shortest-Path-Tree Forwarding
• Efficient traffic pruning in all cases
• Complex operations: Register-tunnel operations, RPT/SPT switchover, RP placement, RP announcement/RP redundancy
• BSR and AutoRP
• RP-annoncements
• RP redundancy
• MSDP
• For Interdomain connecting of PIM-SM domains
• Complex and set of MSDP-RPF rules. Works correctly only if MSDP overlay topology is matched with unicast/BGP routing information
• For RP redundancy (“MSDP mesh-group”) – no need for MSDP-RPF check.
• Anycast-RP
• For RP redundancy with MSDP mesh groups – faster than AutRP/BSR
• Typically uses static-RP config for RP announcements
131313© 2004 Cisco Systems, Inc. All rights reserved.Presentation_ID
Protocols for IP multicastIPv4 recent additions to the protocols
• PIM-SSM
• Protocol used for SSM: Built P2MP (S,G) SPT’s rooted in the source S
• No separate spec!. Subset of PIM-SM: No RP or RP = 0.0.0.0 !
• Very simple: no RP == no register-tunnel/first-hop-DR, RP placement, announcement, redundancy, no RPT operations, no RPT/SPT switchover
• Separate PIM-SSM spec would be 1/10th of PIM-SM spec ?
• Bidir-PIM
• New PIM family protocol: Shared tree ( (*,G)) tree building only
• Very good for enterprise applications with many source per group (scalability, convergence)
• RP-redundancy
• PIM-Anycast-RP: functions like MSDP mesh-group – without MSDP
• Prioritycast-RP: Eg: for Bidir-PIM – RP redundancy without any protocol between redundant instances – because only one is active
141414© 2004 Cisco Systems, Inc. All rights reserved.Presentation_ID
IP Protocols for IP multicastRedundant IP address policies and support
• Different policies possible:
• Anycast: clients connect to the closest instance of redundant IP address
• Prioritycast: clients connect to the highest-priority instance of the redundant IP address
• IP multicast: Redundant IP addresses for sources (SSM) and RP (PIM-SM, Bidir-PIM).
• Bidir today only supports only one active RP == needs prioritycast.
• Sources (video) may have different Quality – prioritycast.
• Redundant IP addresses implemented by redistributing them into IGP
• Anycast comes for free (closest instance = SPF)
• Prioritycast requires engineering.
• Elegant solution: Prefixlengths
Src Bsecondary
10.2.3.4/32
Rcvr 2Rcvr 1
Src Aprimary
10.2.3.4/31
Example: prioritycast withPrefixlength annuncement
IPv6 multicast
151515© 2004, Cisco Systems, Inc. All rights reserved.Presentation_ID
161616© 2004 Cisco Systems, Inc. All rights reserved.Presentation_ID
IPv6 multicastSummary
• Everything like IPv4…• ASM/SSM service models
• Everything PIM: PIM-SM(PIM-SSM), Bidir-PIM, (PIM-DM), BSR
• Except:• IPv6 multicast addressing
• Global IPv6 multicast addresses for free(with the purchase of your IPv6 unicast addresses).
• Scoping is easy and free!
• MLDv<n> = IGMPv<n+1>
• No AutoRP (use BSR).
• No MSDP
• Use PIM-anycast or Prioritycast-RP for RP redundancy
• Use embedded-RP (IPv6 specific!) for Interdomain PIM-SM
• No “old BGP4”, but only MP-BGP SAFI2
• Will discuss in RPF section of presentation
171717© 2004 Cisco Systems, Inc. All rights reserved.Presentation_ID
IPv6 Multicast Addresses (RFC 2373)
128 bits
Scope =
Flags =
T = 0, permanent IANA groupsT= 1, FF1X::/12 -> user groupsP proposed for unicast-based assignments
8 bits 8 bits
F P T Scope
1111 1111 Flags
group ID0
F1 = Interface-local 2 = Link 4 = Admin-local 5 = Site 8 = Organization E = Global
181818© 2004 Cisco Systems, Inc. All rights reserved.Presentation_ID
IPv6 Unicast Based Multicast Addresses (RFC3306)
FF3E:0040:3FFE:0C15:C003:1109:0000:11113 hexUni-pfx
E hexGlobal
40 hexPrefix=64
8 4 4 8 8 64 32
FF | Flags | Scope | Rsvd | Plen | Network prefix | Group id
• Solves the old IPv4 address assignment problem:How can I get global IPv4 multicast addresses?
• In IPv6, if you own an IPv6 unicast address prefix you implicitly own an RFC3306 IPv6 multicast address prefix:
Flags = 00PT, P = 1, T = 1=> Unicast based addressSSM:Special case of unicast prefix-based addressesP=T=1, plen=0, network prefix=0FF3x::/96
191919© 2004 Cisco Systems, Inc. All rights reserved.Presentation_ID
Embedded Rendezvous PointAddresses
• Special case of Unicast prefix based addresses
• Flags = 0RPT, R = 1, P = 1, T = 1=> Rendezvous Point address embedded
• Rendezvous Point address = network prefix = Rpad
• Sixteen Rendezvous Point addresses per network prefix
202020© 2004 Cisco Systems, Inc. All rights reserved.Presentation_ID
Embedded – Rendezvous Point Usage
• PIM-SM protocol operations with embedded-Rendezvous Point:
• No change in PIM-SM protocol operationsJust an automatic replacement to static Rendezvous Point configuration
• Can replace BSR for Group-to-RP mapping
• Method requires large IPv6 addresses - No equivalent possible in IPv4
• Not usable for Bidir-PIM either ;-(
RPRPDRDRR S
ASM across single shared PIM domain, one Rendezvous Point
IP multicast RPF
212121© 2004, Cisco Systems, Inc. All rights reserved.Presentation_ID
222222© 2004 Cisco Systems, Inc. All rights reserved.Presentation_ID
IP multicast RPFOverview
• RPF – Reverse Path Selection• Unlike DVMRP, PIM based multicast tree building does not come with it’s own
protocol to determine the shortest paths towards an RP or a source. Instead it relies on unicast routing protocols
• Initial PIM architects assumed that exactly the same routes (IGP/BGP) as for unicast could be used. And then there was reality…
• Static multicast routes
• ECMP (Equal Cost multipath)• Necessarily per multicast-flow, not per-packet, tailend driven
• MP-BGP (MBGP)• For interdomain incongruency (IPv4/IPv6)
• Separate topology for multicast in IGPs• When asymmetric metrics are required
• For cost optimization
• Dual topologies for multicast• For live-live traffic redundancy
232323© 2004 Cisco Systems, Inc. All rights reserved.Presentation_ID
IP multicast RPFECMP – Equal cost multipath
• Decision in unicast is made by upstream (sending) router• Decision in multicast is made during RPF select on downstream
router. Router local choice – no network dependency• Polarizing: i = ( hash(S) % n)
• ..but good for L3 link bundles – predictable traffic distribution
• Non-polarizing: i = i | max( hash(S, Nbr-i ))• Also stable in case of link failure or unaffected flows.
Multicast RPF Selection for different source addresses
1
32
4 5 6 7Given 1..n (eg: 2) ECMPs, if all routers select the same neighbor I for a source S, then polarization may happen: A rtr2 will only be joined to by rtr1 for Sources that it’s own ECMP would RPF to rtr4, but never to rtr5!
Polarizing Non-Polarizing Polarizing
242424© 2004 Cisco Systems, Inc. All rights reserved.Presentation_ID
IP multicast RPFBGP – IPv4 / IPv6
• IPv4: MP-BGP introduced SAFI:
• SAFI1 = unicast only, SAFI2 = multicast only, SAFI3 = both
• Traditional implementations only use SAFI2 and non-SAFI BGP4 (unicast)
• Lazyness (not wanting to have all multicast routes in SAFI2) requires complex route-preference rules – prefer shorter prefix SAFI2 over longer prefix non-SAFI2
• IPv6: Uses latest version of MP-BGP (RFC2858)
• No non-SAFI route announcements (never defined), no SAFI 3 (removed by IETF)Only SAFI 1 for unicast, SAFI 2 for multicast
• Should never use SAFI 1 routes for multicast to keep RPF rules simple(and to use MP-BGP as intended by wording of BGP spec)
SR AS4AS1
AS2
AS3Unicast only
131.188.1.1
BGP SAFI2:131.188.0.0/16
BGP4:131.188.1.0/24
252525© 2004 Cisco Systems, Inc. All rights reserved.Presentation_ID
IP multicast RPFSeparate multicast topology for cost optimization
• Consider simplified example core/distribution network toplogy
• Core pops have redundant core routers, connectivity via (10Gbps)WAN links, redundant. Simple setup: A/B core routers, A/B links
• Regions use ring(s) for redundant connectivity
Rcvr
Src1
Src2
Rcvr
B1 A2
B3
A1
A3
B2
Rcvr
Rcvr
Rcvr
Rcvr
Rcvr
RcvrRcvr
RcvrCore POP3
CorePOP1
CorePOP2Region1 Region2
Region3
WANLinks
262626© 2004 Cisco Systems, Inc. All rights reserved.Presentation_ID
IP multicast RPFSeparate multicast topology for cost optimization
• IGP metric are set to achieve good load distribution across redundant core.
• Manual IGP metric setting and/or tools
• Assume in the idealized topology cost of 1 on all links.
• Result: Unicast traffic is load split across redundant core links
Load splitting acrossWANLinks
Rcvr
Src1
Src2
Rcvr
B1 A2
B3
A1
A3
B2
Rcvr
Rcvr
Rcvr
Rcvr
Rcvr
RcvrRcvr
RcvrCore POP3
CorePOP1
CorePOP2Region1 Region2
Region3
272727© 2004 Cisco Systems, Inc. All rights reserved.Presentation_ID
IP multicast RPFSeparate multicast topology for cost optimization
• The same metric good for unicast load splitting cause multicast traffic to go unnecessarily across both the A and B WAN links.
• 10 Gbps WAN links, 1..2 Gbs multicast => 10..20% WAN waste (cost factor)
• Can not resolve problem well without multicast specific topology
Unnecessary use ofWANLinks
Rcvr
Src1
Src2
Rcvr
B1 A2
B3
A1
A3
B2
Rcvr
Rcvr
Rcvr
Rcvr
Rcvr
RcvrRcvr
RcvrCore POP3
CorePOP1
CorePOP2Region1 Region2
Region3
282828© 2004 Cisco Systems, Inc. All rights reserved.Presentation_ID
IP multicast RPFSeparate multicast topology for cost optimization
• Simple? to minimize tree costs with a multicast specific topology
• Manual or tool based
• Example toplogy: make B links very expensive for multicast (cost 100),so they are only us as last resort (no A connectivity)
Efficient use ofWANLinks
Rcvr
Src1
Src2
Rcvr
B1 A2
B3
A1
A3
B2
Rcvr
Rcvr
Rcvr
Rcvr
Rcvr
RcvrRcvr
RcvrCore POP3
CorePOP1
CorePOP2Region1 Region2
Region3
292929© 2004 Cisco Systems, Inc. All rights reserved.Presentation_ID
IP multicast RPFDual multicast topologies for resiliency
• Send traffic twice to different multicast groups(eg: green = 232.1.0.1, red = 232.1.0.2)
• Use path separation in network to pass red/green across different pathsNote: dual topologies just one solution (VRFs, virtual routers, …)
• Receivers receive both copies, remove duplicates by sequence numbers (eg: MPEG timestamp).
• No single network failure will cause any service interruption
• Same bandwidth allocation needed as in traditional SONET rings, but solution even better: 0 loss instead of 50 msec.
RedundantEncoder/Multiplexer
RedundantDecoder / Ad-Inserter/..
HFC
STBs
303030© 2004 Cisco Systems, Inc. All rights reserved.Presentation_ID
IP multicast RPFDual multicast topologies for resiliency
• Traditional application:• Market data distribution in finance network (NASDAQ, etc..)
• Based on two completely separate networks !
• With two topology solution• No separate physical networks required
• Can provide different subsets of the network to different classes of traffic.
• Can share links to reduce cost (two unidirection links).
• Can share nodes to reduce cost.
• Vs virtual routers or similar “virtual network”:
• No need for subnet encaps ifor multiple topologies
• Vs. RSVP-TE P2MP
• DIffserv type approach (not per flow/tree)
313131© 2004 Cisco Systems, Inc. All rights reserved.Presentation_ID
IP multicast RPFDual multicast topologies for resiliency
• Topology sharing of links:
• Particular useful in rings.
• Two topologies also useful forunicast (eg: VoD load splitting)
• Requires unidirectionaly “infinite” link metric to avoid reconvergence of topologies (if wanted)
• Available in ISIS today, not in OSPF
• Part of OSPF/UDLR draft in IETF
RedundantEncoder/Multiplexer
Rcvr Rcvr
Rcvr
Rcvr
Rcvr
Rcvr
IGP cost in differentTopologies:
Unicast traffic flows inthe reverse directionof unicast
Small metric
Infinite/largemetric
Multicast traffic flowUnicast traffic flow
Infinite/large
Small metric Multicast traffic flowUnicast traffic flow
Reliable multicasttransport protocols
323232© 2004, Cisco Systems, Inc. All rights reserved.Presentation_ID
333333© 2004 Cisco Systems, Inc. All rights reserved.Presentation_ID
Reliable MulticastOverview
• PGM (Pragmatic Generic Multicast)
• Near-real-time delivery with TCP compliant flow-control, optional network level scalability support (DLR, NE)
• NAK-based: Preferred to small to mid-size receiver groups with tight delivery schedules
• Used in many finance/comerical applications today, supported by Windows-XP and later, etc. Router support little used.
• ALC (Asynchronuous Layered Codec)
• Non-real-time delivery without any feedback from receivers – can support arbitrary large receiver population (eg: STBs).
• Relies on FEC. Interesting with “Tornado Codecs” (large block codecs.
• Target applications eg: Content Distribution to VoD servers, STB with HD, PC software upgrade, nVoD
343434© 2004 Cisco Systems, Inc. All rights reserved.Presentation_ID
Reliable multicastPGM components
PGM(Server/Source) Stack
ServerServer
NetworkNetwork
PGM(Host/Receiver) Stack
HostHost
Optional PGM functions
Network Element = Router Assist
DLR: DesignatedLocal Repairer
353535© 2004 Cisco Systems, Inc. All rights reserved.Presentation_ID
Reliable multicastcontent carousels – before ALC/Tornado-Codecs
• In a traditional carousel, a file is repeatedly sent,receivers start receiving in the middle receive the tail of the file and then continue to receive until they have received the head of the next iteration.
• Works only well if network has little packet loss
• Need to potentially receive content for many iterations in face of higher packet loss
File
Receive
Received File
363636© 2004 Cisco Systems, Inc. All rights reserved.Presentation_ID
Reliable multicastcontent carousels – with ALC/Tornado-Codecs
• ALC encodes file into eg: 2^32 different packets.
• Receiver needs to receive just sufficiently many arbitrary packet from encoding to reconstruct file (original file size +5% overhead)
FileTornado Encode
Received File
Receive arbitrary packets
Tornado Decode
373737© 2004 Cisco Systems, Inc. All rights reserved.Presentation_ID
Reliable multicastcontent carousels – with ALC/Tornado-Codecs
• Allows to carry reliable multicast content as scavenger class traffic (less than best effort).
• Use free bandwidth in network !
• Limit of basic carousel:
• Can only start encoding after whole file is available
• Not directly usable for real-time transmission
• Break up file into segments,apply ALC encoding separately,start transmission after first segment.
383838© 2004 Cisco Systems, Inc. All rights reserved.Presentation_ID
Reliable multicastnVoD – with ALC/Tornado-Codecs
Movie1. Segment movie: S1 = 1 min, S2 = 2 min , S3 = 4min, 8, 16, …
S1
S2 S3 S4 S5 S6
2. Carousel each segment simultaneously ALC encoded At double speed:
S2
S3S3
S4S5
S6
393939© 2004 Cisco Systems, Inc. All rights reserved.Presentation_ID
3. Receiver IGMP joins to one segment at a time. Once segment is fully received, it is decoded and receiver receives next segment. Because segments are transmitted faster than realtime (example: factor 2), playout takes as long as receiving next segment.
S1S2
S3S3
S4S5
S6
Reliable multicastnVoD – with ALC/Tornado-Codecs
404040© 2004 Cisco Systems, Inc. All rights reserved.Presentation_ID
• Never more traffic than unicast, never more traffic than 14 unicast user (in example)
• VoD starts after 30 seconds• Total bandwidth in network is 7 segments * double speed
== same bandwidth as 14 unicast VOD viewers require.• As soon as more than 14 user watch same content (independent of their
starting time), no more bandwidth is required.• If less than 14 users watch, bandwidth utilized is still the same as in unicast
(because only traffic joined to by IGMP is being forwarded).• Just transmission is more bursty than unicast !
• Parameters can easily be varied
• Beneficial for top 3?% of VoD libraryZipf distribution – majority of market share
Reliable multicastnVoD – with ALC/Tornado-Codecs
414141© 2004 Cisco Systems, Inc. All rights reserved.Presentation_ID
Questions
?
424242© 2003, Cisco Systems, Inc. All rights reserved.Presentation_ID