1 / 163

Internet2 Multicast Workshop Florida International University February 2003

Internet2 Multicast Workshop Florida International University February 2003. Acknowledgements. Greg Shepherd Marshall Eubanks Bill Nickless Patrick Dorn University of Oregon Cisco Systems Juniper Networks Florida International University. Contents. Overview Multicast on the LAN

angus
Download Presentation

Internet2 Multicast Workshop Florida International University February 2003

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Internet2 Multicast WorkshopFlorida International UniversityFebruary 2003

  2. Acknowledgements Greg Shepherd Marshall Eubanks Bill Nickless Patrick Dorn University of Oregon Cisco Systems Juniper Networks Florida International University

  3. Contents • Overview • Multicast on the LAN • Source-Specific Multicast (SSM) • Any-Source Multicast (ASM) • Intra-domain ASM • Inter-domain ASM • Making the Case for Multicast

  4. Overview

  5. The Basic Idea Rather than sending a separate copy of the data for each recipient, the source sends the data only once, and routers along the way to the destinations make copies as needed. Unicast does mass mailings; multicast does chain letters.

  6. Unicast vs. Multicast Unicast Multicast

  7. Some Uses for Multicast • Any application with multiple receivers • one-to-many or many-to-many • Live video distribution • Collaborative groupware • Periodic data delivery - “push” technology • stock quotes, sports scores, magazines, newspapers • advertisements

  8. Some More Uses for Multicast • Server/web site replication • Reducing network/resource overhead • more efficient to establish multicast tree rather than multiple point-to-point links • Resource discovery • Distributed interactive simulation • war games • virtual reality

  9. What Happened to Multicast? • By 1995, multicast seemed well on its way to adoption. • The MBone (Multicast backBone) had been set up and was growing. • Audiocasts and Videocasts of meetings, seminars, etc., were fairly routine. • Serious interest was coming from industry. • So why isn’t it ubiquitous now ? • The hype got ahead of the technology! • The original technology was not suitable for adoption throughout the Internet. Basic parts had to be re-engineered. • This took from 1997 to early 2001.

  10. The MBone • The original multicast network was called the MBone. It used a simple routing protocol called DVMRP (Distance Vector Multicast Routing Protocol). • As there were only isolated subnetworks that wanted to deal with DVMRP, the old MBone used tunnels to get multicast traffic between DVMRP subnetworks. • i.e., the multicast traffic was hidden and sent between the subnetworks via unicast. • This mechanism was simple, but required manual administration and absolutely could not scale to the entire Internet. • Worse, DVMRP requires substantial routing traffic behind the scenes and this grew with the size of the MBone. • Thus, the legend grew that multicast was a bandwidth hog.

  11. Multicast Grows Up • Starting about 1997, the building blocks for a multicast-enabled Internet were put into place. • An efficient modern multicast routing protocol, Protocol Independent Multicast – Sparse Mode (PIM-SM), was deployed. • The mechanisms for multicast peering were established, using an extension to BGP called Multiprotocol BGP (MBGP), and peering became routine. • The service model was split into: • a many-to-many part (e.g., for videoconferencing): Any-Source Multicast (ASM), and • a one-to-many (or “broadcast”) part: Source-Specific Multicast (SSM). • By 2001, these had completely replaced the old MBone. • This path is not unusual for new technology...

  12. The Life Cycle of New Technologies in General (From Lawrence Orans of Gartner)

  13. The Life Cycle of Multicast in Particular

  14. Deployment of Multicast • Multicast Technologies has been monitoring the state of multicast since April, 2001. Deployment is at 5% to 15%. From http://www.multicasttech.com/status/

  15. e.g., video server Multicast Terminology: the basics IP source = IP unicast addr Ethernet source = MAC addr IP destination = IP multicast addr Ethernet dest = MAC addr receivers source Multicast stream • source = origin of multicast stream • multicast address = an IP address in the Class D range (224.0.0.0 – 239.255.255.255), used to refer to multiple recipients.A multicast address is also called a multicast groupor channel. • multicast stream = stream of IP packets with multicast address for IP destination address. • (S,G) = (source, group) reference • All multicast uses UDP packets • receiver(s) = recipient(s) of multicast stream

  16. Multicast Protocol Summary • IGMP - Internet Group Management Protocol is used by hosts and routers to tell each other about group membership. • PIM-SM - Protocol Independent Multicast-Sparse Mode is used to propagate forwarding state between routers. • MBGP - Multiprotocol Border Gateway Protocol is used to exchange routing information for inter-domain RPF checking. • MSDP - Multicast Source Discovery Protocol is used to exchange active source information between RPs.

  17. (S,G) notation • For every multicast source there must be two pieces of information: the source IP address, S, and the group address, G. • These correspond to the sender and receiver addresses in unicast. • This is generally expressed as (S,G). • Also commonly used is (*,G) - every source for a particular group.

  18. IP Multicast building blocks • The SENDERS send without worrying about receivers • Packets are sent to a multicast address (RFC 1700) • This is in the class D range (224.0.0.0 - 239.255.255.255) • The RECEIVERS inform the routers what they want to receive • done via Internet Group Management Protocol (IGMP), version 2 (RFC 2236) or later • The routers make sure the STREAMS make it to the correct receiving networks. • Multicast routing protocol: PIM-SM

  19. Essential IP Multicast Protocols • Receivers • Group Management Protocol - enables hosts to dynamically join/leave multicast groups. Receivers send group membership reports to the nearest router. • Multicast Routing Protocol - enables routers to build a delivery tree between the sender(s) and receivers of a multicast group. • Delivery tree • Membership reports • Senders Group Management Protocol (e.g. IGMP) Multicast Routing Protocol (e.g. PIM-SM)

  20. Multicast Routing • Multicast Routing can be thought of as the reverse of Unicast Forwarding. • Unicast Forwarding is concerned with where the packet is going. • Multicast Routing is concerned with where the packet will be coming from. • Multicast paths to many receivers form a “tree”. The tree is built (or torn down) from the receiver back toward the source (or, if there is more than one source, the Rendezvous Point, or core).

  21. PIM-SM Protocol Independent Multicast - Sparse Mode • The core multicast protocol: builds and tears down multicast trees • draft-ietf-pim-sm-v2-new-06.txt obsoletes RFC 2362; bootstrap router removed from PIM spec • explicit join: assumes that not everyone wants the data • uses externally-provided reachability table to build forwarding topology

  22. Multicast Distribution Trees • The path taken by data from the source to receivers is called the “tree” • Routing loops are not allowed, so there is always a unique series of branches between the root of the tree and the receivers. • For each receiver, the tree is the shortest path from the source or core / RP to the receiver. The tree is built based on RPF reachability information.

  23. Reachability • When a unicast packet shows up on an interface, the destination address is looked up in the unicast forwarding table to determine where the router should send the packet next. • When a multicast (S,G) Join shows up on an interface, the source address, S, is looked up in the reverse-path forwarding (RPF) table to determine how the router should join the source-based forwarding tree. This information is used to build the multicast forwarding tree. • The unicast forwarding table and the RPF table contain the same kind of information — unicast routes, or reachability information — and may in fact be the same table. • The point of having separate tables is to enable separate policies and paths for unicast forwarding and RPF. You need MBGP, IS-IS, or static mroutes to do this. • Once the multicast forwarding tree is built, multicast forwarding works similarly to unicast forwarding.

  24. Multicast Distribution Trees Shortest-path or Source-based Distribution Tree Source State Information: (S, G) S = Source G = Group Group Member 1 Group Member 2

  25. Multicast Distribution Trees Shared or Core-Based Distribution Tree Source 1 Rendezvous Point (RP), aka Core Source 2 State Information: (*, G) * = Any Source G = Group Group Member 1 Group Member 2

  26. Multicast Distribution Trees Compared • Source or Shortest-Path trees • More resource intensive; requires more state n(S x G) • You get optimal paths from source to all receivers, which minimizes delay • Best for one-to-many distribution • Shared or Core-Based trees • Uses less resources; requires less memory n(G) • You may get suboptimal paths from source to all receivers, depending on topology • The rendezvous point (core) itself and its location may affect performance • Best for many-to-many distribution • Necessary for in-band source discovery

  27. Multicast Addressing • IPv4 Multicast Group Addresses • 224.0.0.0–239.255.255.255 • Class D Address Space • High order bits of 1st Octet = “1110” • Source sends to group address; receiver receives from group address • TTL value defines scope and limits distribution • IP multicast packet must have TTL > interface TTL or it is discarded • No longer recommended as a reliable scoping mechanism

  28. CIDR Address Notation • The multicast address block is 224.0.0.0 to 239.255.255.255 • It is cumbersome to refer to address blocks in the above fashion. Address blocks are usually described using “CIDR notation” • This specifies the start of a block, and the number of bits THAT ARE FIXED. • In this shorthand, the multicast address space can be described as 224.0.0.0/4 or, even more simply, as 224/4. The fixed part of the address is referred to as the prefix, and this block would be pronounced "two twenty four slash four." • Note that the LARGER the number after the slash, the LONGER the prefix and the SMALLER the address block.

  29. Multicast Addressing • RFC 3171 • http://www.iana.org/assignments/multicast-addresses • Examples of Reserved & Link-local Addresses • 224.0.0.0 - 224.0.0.255 reserved & not forwarded • 239.0.0.0 - 239.255.255.255 Administrative Scoping • 224.0.0.1 - All local hosts • 224.0.0.2 - All local routers • 224.0.0.4 - DVMRP • 224.0.0.5 - OSPF • 224.0.0.6 - Designated Router OSPF • 224.0.0.9 - RIP2 • 224.0.0.13 - PIM • 224.0.0.15 - CBT • 224.0.0.18 - VRRP • “Ordinary” multicasts don’t have to request a multicast address from IANA.

  30. Multicast Addressing • Administratively Scoped Addresses – RFC 2365 • 239.0.0.0–239.255.255.255 • Private address space • Similar to RFC 1918 unicast addresses • Not used for global Internet traffic • Used to limit “scope” of multicast traffic • Same addresses may be in used in different sub-networks for different multicast sessions • Examples • Site-local scope: 239.253.0.0/16 • Organization-local scope: 239.192.0.0/14

  31. Multicast Address Allocation • For a long time, this was a sore spot. There was no way to claim or register a Multicast Class D address like unicast address blocks can be registered. • For temporary teleconferences, this is not such a problem, but it does not fit well into a broadcast model. • Now, there are two solutions : • For SSM, addresses don’t matter, as the broadcast address is really unique as long as the (S,G) pair is unique. • For ASM, there is “GLOP”.

  32. Multicast Addressing GLOP addresses • Provides globally available private Class D space • 233.x.x/24 per AS number • RFC 2770 How? • Insert the 16-bit AS number into the middle two octets of the 233/8 • Online GLOP calculator:www.shepfarm.com/multicast/glop.html • If you have an AS, you have multicast addresses.

  33. Multicast on the LAN

  34. Multicast Addressing at Layer 2 • An IPv4 multicast address is 32 bits, of which the first 4 bits are always the same, leaving 28 bits. • A MAC multicast address is 48 bits, of which the first 24 bits are always the same. One of the remaining bits is reserved, leaving 23 bits. • So, one multicast MAC address maps to 32 multicast IP addresses.

  35. Ethernet Multicast Addressing IANA owns 01-00-5E vendor address block; half of it is assigned for IP multicast. 0 8 31 Class D address 32-bit IP address 1110 ignored, leaving 28 bits 48-bit Ethernet address 23 bits IEEE Ethernet multicast bit 0 24 47 0 000000010000000001011110 0 = Internet multicast 1 = Reserved for other use 00-00-00 thru 7F-FF-FF 01-00-5E-

  36. IGMP • Internet Group Management Protocol - how hosts tell routers about group membership • Routers also solicit group membership from directly connected hosts • RFC 1112 specifies version 1 of IGMP • Supported on Windows 95 • RFC 2236 specifies version 2 of IGMP • Supported on latest service pack for Windows, newer Windows releases, and most UNIX systems • RFC 3376 specifies version 3 of IGMP • provides source include-list capabilities (SSM!) • Support? • FreeBSD patch, Linux patch, Window XP • www.shepfarm.com/multicast/

  37. IGMPv2 • Router: • sends Membership Query messages to All Hosts (224.0.0.1) • query-interval = 125 secs default • router with lowest IP address is Querier (rest non-queriers) • If lower-IP address query heard, back off to non-querier state • Other Querier Present Interval default: (robust-count x query-interval) + (0.5 x query-response-interval) = 255 secs • listens for reports (whether querier or not) and adds group to membership list for that interface • query-response-interval = 10 secs default • timeout (Group member interval) default: • (robust-count x query-interval) + (1 x query-response-interval) = 260 sec • robust-count - provides fine-tuning to allow for expected packet loss on a subnet. Default = 2 (tunable from 2-10)

  38. IGMPv2 • Host: • sends Membership Report messages, if joined • waits 0-10 sec (default) • Hosts listen to other host reports • Only 1 host responds • sends unsolicited Membership Reports (i.e., Join Messages) to group address (e.g. 224.10.8.5) • sends Leave messages to All Routers (224.0.0.2) • reports group membership ONLY – no sources. Only the existence of local group members is reported, not the actual members themselves

  39. IGMP Protocol Flow - Join a Group I want to JOIN! 230.0.0.1 Router adds group I want 230.0.0.1 230.0.0.1 230.0.0.1 Forwards stream • Router triggers group membership request to PIM. • Hosts can send unsolicited join membership messages – called reports in the RFC (usually more than 1) • Or hosts can join by responding to periodic query from router

  40. IGMP Protocol Flow - Querier Yes, me! Still interested? (general query) 224.0.0.1 0-10 sec 230.0.0.1 I want 230.0.0.1 230.0.0.1 group 230.0.0.1 • Hosts respond to query to indicate (new or continued) interest in group(s) • only one host should respond per group • Hosts fall into idle-member state when same-group report heard. • After 260 sec with no response, router times out group. 125 sec 224.0.0.1

  41. IGMP Protocol Flow - Leave a Group I want to leave! Anyone still want this group? 224.0.0.2 <230.0.0.1> 224.0.0.1 <230.0.0.1> I don’t want 230.0.0.1 anymore 1 sec (re-transmit timer) 224.0.0.1 <230.0.0.1> 230.0.0.1 group • Hosts that support IGMPv2 send leave messages to all-routers group indicating group they’re leaving. • Router follows up with 2 group-specific queries messages • IGMPv1 hosts leave by not responding to queries(260 sec timeout)

  42. Soft State • Say I set up an active Multicast group, say by issuing a membership report. What happens if my computer goes down and never directly leaves the group ? • This is fixed with “Soft State” • Everything has a timer, and if not periodically reinitiated the timer will expire and the state will be removed. • So there is no danger of some rogue group lasting forever.

  43. H1 wants to receive from S = 1.1.1.1 but not from S = 2.2.2.2 With IGMPv3, specific sources can be pruned back - S = 2.2.2.2 in this case Video Server Video Server IGMPv3 Specified in RFC 3376 Enables hosts to listen only to a specified subset of the sources sending to the group Source = 1.1.1.1 Group = 224.1.1.1 Source = 2.2.2.2 Group = 224.1.1.1 R2 R1 R3 IGMPv3: MODE_IS_INCLUDE Join 1.1.1.1, 224.1.1.1 H1 - Member of 224.1.1.1

  44. IGMPv3 Enhancements • Group-Source Report message is defined. Enables hosts to specify which senders it can receive or not receive data from. • Group-Source Leave message is defined. Enables host to specify the specific IP addresses of a (source,group) that it wishes to leave.

  45. Lab 1: Multicast on the LAN

  46. SSM

  47. PIM-SM • SM stands for “Sparse Mode.” • RFC 2362 and draft-ietf-pim-sm-v2-new-06.txt • There is also a Dense Mode but we don’t recommend using it. • Cisco has a proprietary “Sparse-Dense” mode which they use for RP discovery. • PIM-SM allows for both Shared Trees (STs) from a Rendezvous Point (RP) and Shortest Path Trees (SPTs) from the source. • Note that STs are shortest path, just to the RP. • There are two ways to use PIM-SM…

  48. ASM and SSM • ASM: Any-Source Multicast. Traditional multicast – data and joins are forwarded to a Rendezvous Point (RP). • all routers in a PIM domain must have RP mapping • when load exceeds threshold, forwarding swaps to shortest path tree. The default threshold is one packet; in this case, the sole purpose of the ST is to learn which sources are active (with IGMPv2, the receiver can only specify the group, not specific sources.) • state increases (not everywhere) as number of sources and number of groups increase • source-tree state is refreshed when data is forwarded and with Join/Prune control messages • SSM: Source-Specific Multicast. PIM-SM without RPs – instead, source is learned out-of-band, and shortest-path tree is built directly to it.

  49. SSM • Source-Specific Multicast (SSM) is a subset of ASM, so • SSM concepts apply directly to ASM, but • SSM is a lot simpler than ASM. For these reasons, we cover SSM first in this workshop. • 232 / 8 is assigned to SSM as an address space. Other address ranges can also be set up for SSM -- this is primarily a function of the receiving network. • Source activity and IP addresses are assumed known, say through a web page. • IGMPv3 allows for “Include” lists of (S,G) pairs.

  50. SSM • SSM - draft-ietf-ssm-arch-01.txt • 232/8 – IANA assigned • No shared trees • Guarantees ONE source on any delivery tree • Content security – no unwanted sources • Reduced protocol dependence – more later... • Solves address allocation issues for inter-domain one-to-many • tree address is 64 bits – S,G • Host must learn source address out-of-band (e.g, from a web page) • Host-to-router join request specifies source as well as group • requires IGMPv3 for include-source list • Hard-coded behavior in 232/8 • Configurable to expand range

More Related