--- 1/draft-ietf-mboned-intro-multicast-01.txt 2006-02-05 00:19:55.000000000 +0100 +++ 2/draft-ietf-mboned-intro-multicast-02.txt 2006-02-05 00:19:55.000000000 +0100 @@ -1,18 +1,18 @@ INTERNET-DRAFT T. Maufer - C. Semeria +Expire in six months C. Semeria Category: Informational 3Com Corporation March 1997 Introduction to IP Multicast Routing - + Status of this Memo This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other @@ -354,100 +354,102 @@ | Island | | Island| ---------| Island | | B | | C | Tunnel | D | ++++++++ +++++++ --------- ++++++++ \ \ | \T\ | \U\ | \N\ | \N\ +++++++ \E\ |Island | \L\| E | - v v | _ - |_|-|- - >|Router| <- + - + - + -> |Router|<- -|-|_| - '_' | | '_' - _ | | _ - |_|-| |-|_| - '_' | | '_' - v v + \ +++++++ -LEGEND +Figure 2: Internet Multicast Backbone (MBone) -<- - - -> Group Membership Protocol -<-+-+-+-> Multicast Routing Protocol +======================================================================== -Figure 1: Multicast IP Delivery Service -======================================================================= +As multicast routing software features become more widely available on +the routers of the Internet, providers may gradually decide to use +"native" multicast as an alternative to using lots of tunnels. -1.3 Multicast Routing Protocols +The MBone carries audio and video multicasts of Internet Engineering +Task Force (IETF) meetings, NASA Space Shuttle Missions, US House and +Senate sessions, and live satellite weather photos. There are public +and private sessions on the MBone. Sessions that are menat for public +viewing or participation are announced via the session directory (SDR) +tool. A user of this tool can see a list of current and future public +sessions provided the user is within the administrative scope of the +sender. -Multicast routers execute a multicast routing protocol to define -delivery paths that enable the forwarding of multicast datagrams -across an internetwork. +4. MULTICAST ADDRESSING -1.3.1 Multicast Routing vs. Multicast Forwarding +A multicast address is assigned to a set of receivers defining a +multicast group. Senders use the multicast address as the destination +IP address of a packet that is to be transmitted to all group members. -Multicast routing protocols establish or help establish the distribution -tree for a given group, which enables multicast forwarding of packets -addressed to the group. In the case of unicast, routing protocols are -also used to build a forwarding table (commonly called a routing table). -Unicast destinations are entered in the routing table, and associated -with a metric and a next-hop router toward the destination. The key -difference between unicast forwarding and multicast forwarding is that -multicast packets must be forwarded away from their source. If a packet -is ever forwarded back toward its source, a forwarding loop could have -formed, possibly leading to a multicast "storm." +4.1 Class D Addresses -Each routing protocol constructs a forwarding table in its own way; the -forwarding table tells each router that for a certain source, or for a -given source sending to a certain group (called a (source, group) pair), -packets are expected to arrive on a certain "inbound" or "upstream" -interface and must be copied to certain (set of) "outbound" or -"downstream" interface(s) in order to reach all known subnetworks with -group members. +An IP multicast group is identified by a Class D address. Class D +addresses have their high-order four bits set to "1110" followed by +a 28-bit multicast group ID. Expressed in standard "dotted-decimal" +notation, multicast group addresses range from 224.0.0.0 to +239.255.255.255 (shorthand: 224.0.0.0/4). -2. MULTICAST SUPPORT FOR EMERGING INTERNET APPLICATIONS +Figure 3 shows the format of a 32-bit Class D address. -Today, the majority of Internet applications rely on point-to-point -transmission. The utilization of point-to-multipoint transmission has -traditionally been limited to local area network applications. Over the -past few years the Internet has seen a rise in the number of new -applications that rely on multicast transmission. Multicast IP -conserves bandwidth by forcing the network to do packet replication only -when necessary, and offers an attractive alternative to unicast -transmission for the delivery of network ticker tapes, live stock -quotes, multiparty videoconferencing, and shared whiteboard applications -(among others). It is important to note that the applications for IP -Multicast are not solely limited to the Internet. Multicast IP can also -play an important role in large commercial internetworks. +======================================================================== -2.1 Reducing Network Load + 0 1 2 3 31 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |1|1|1|0| Multicast Group ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |------------------------28 bits------------------------| -Assume that a stock ticker application is required to transmit packets -to 100 stations within an organization's network. Unicast transmission -to this set of stations will require the periodic transmission of 100 -packets where many packets may in fact be traversing the same link(s). -Multicast transmission is the ideal solution for this type of -application since it requires only a single packet stream to be -transmitted by the source which is replicated at forks in the multicast -delivery tree. +Figure 3: Class D Multicast Address Format +======================================================================== -Broadcast transmission is not an effective solution for this type of -application since it affects the CPU performance of each and every -station that sees the packet. Besides, it wastes bandwidth. +The Internet Assigned Numbers Authority (IANA) maintains a list of +registered IP multicast groups. The base address 224.0.0.0 is reserved +and cannot be assigned to any group. The block of multicast addresses +ranging from 224.0.0.1 to 224.0.0.255 is reserved for permanent +assignment to various uses, including routing protocols and other +protocols that require a well-known permanent address. Multicast +routers should not forward any multicast datagram with destination +addresses in this range, (regardless of the packet's TTL). -2.2 Resource Discovery +Some of the well-known groups include: -Some applications utilize multicast instead of broadcast transmission -to transmit packets to group members residing on the same subnetwork. -However, there is no reason to limit the extent of a multicast -transmission to a single LAN. The time-to-live (TTL) field in the IP -(hex); to be clear, the range from 01-00-5E-00-00-00 + "all systems on this subnet" 224.0.0.1 + "all routers on this subnet" 224.0.0.2 + "all DVMRP routers" 224.0.0.4 + "all OSPF routers" 224.0.0.5 + "all OSPF designated routers" 224.0.0.6 + "all RIP2 routers" 224.0.0.9 + "all PIM routers" 224.0.0.13 + "all CBT routers" 224.0.0.15 + +The remaining groups ranging from 224.0.1.0 to 239.255.255.255 are +assigned to various multicast applications or remain unassigned. From +this range, the addresses from 239.0.0.0 to 239.255.255.255 are being +reserved for various "administratively scoped" applications, not +necessarily Internet-wide applications. + +The complete list may be found in the Assigned Numbers RFC (RFC 1700 or +its successor) or at the IANA Web Site: + + + +4.2 Mapping a Class D Address to an IEEE-802 MAC Address + +The IANA has been allocated a reserved portion of the IEEE-802 MAC-layer +multicast address space. All of the addresses in IANA's reserved block +begin with 01-00-5E (hex); to be clear, the range from 01-00-5E-00-00-00 to 01-00-5E-FF-FF-FF is reserved for IP multicast groups. A simple procedure was developed to map Class D addresses to this reserved MAC-layer multicast address block. This allows IP multicasting to easily take advantage of the hardware-level multicasting supported by network interface cards. The mapping between a Class D IP address and an IEEE-802 (e.g., FDDI, Ethernet) MAC-layer multicast address is obtained by placing the low- order 23 bits of the Class D address into the low-order 23 bits of @@ -1739,106 +1741,94 @@ Upstream Datagrams matching this row's Dest. Group and Source must be received on this interface. Downstream If a datagram matching this row's Dest. Group and Source is received on the correct Upstream interface, then it is forwarded across the listed Downstream interfaces. TTL The minimum number of hops a datagram must cross to reach any of the Dest. Group's members. An - MOSPF router may discard a stem is a single area (and the source is inside that area...). The -following discussion assumes that the reader is familiar with OSPF. - -7.2.1.1 Local Group Database + MOSPF router may discard a datagram if it can see + that the datagram has insufficient TTL to reach + even the closest group member. -Similar to all other multicast routing protocols, MOSPF routers use the -Internet Group Management Protocol (IGMP) to monitor multicast group -membership on directly-attached subnetworks. MOSPF routers maintain a -"local group database" which lists directly-attached groups and -determines the local router's responsibility for delivering multicast -datagrams to these groups. +The information in the forwarding cache is not aged or periodically +refreshed: It is maintained as long as there are system resources +available (e.g., memory) or until the next topology change. The +contents of the forwarding cache will change when: -On any given subnetwork, the transmission of IGMP Host Membership -Queries is performed solely by the Designated Router (DR). However, -the responsibility of listening to IGMP Host Membership Reports is -performed by not only the Designated Router (DR) but also the Backup -Designated Router (BDR). Therefore, in a mixed LAN containing both -MOSPF and OSPF routers, an MOSPF router must be elected the DR for the -subnetwork. This can be achieved by setting the OSPF RouterPriority to -zero in each non-MOSPF router to prevent them from becoming the (B)DR. + o The topology of the OSPF internetwork changes, forcing all of + the shortest path trees to be recalculated. (Once the cache + has been flushed, entries are not rebuilt. If another packet + for one of the previous (Dest. Group, Source) pairs is + received, then a "new" cache entry for that pair will be + created then.) -The DR is responsible for communicating group membership information to -all other routers in the OSPF area by flooding Group-Membership LSAs. -Similar to Router-LSAs and Network-LSAs, Group-Membership LSAs are only -flooded within a single area. + o There is a change in the Group-Membership LSAs indicating that + the distribution of individual group members has changed. -7.2.1.2 Datagram's Shortest Path Tree +7.2.2 Mixing MOSPF and OSPF Routers -The datagram's shortest path tree describes the path taken by a -multicast datagram as it travels through the area from the source -subnetwork to each of the group members' subnetworks. The shortest -path tree for each (source, group) pair is built "on demand" when a -router receives the first multicast datagram for a particular (source, -group) pair. +MOSPF routers can be combined with non-multicast OSPF routers. This +permits the gradual deployment of MOSPF and allows experimentation with +multicast routing on a limited scale. -When the initial datagram arrives, the source subnetwork is located in -the MOSPF link state database. The MOSPF link state database is simply -the standard OSPF link state database with the addition of Group- -Membership LSAs. Based on the Router- and Network-LSAs in the OSPF -link state database, a source-based shortest-path tree is constructed -using Dijkstra's algorithm. After the tree is built, Group-Membership -LSAs are used to prune the tree such that the only remaining branches -lead to subnetworks containing members of this group. The output of -these algorithms is a pruned source-based tree rooted at the datagram's -source. +It is important to note that an MOSPF router is required to eliminate +all non-multicast OSPF routers when it builds its source-based shortest- +path delivery tree. (An MOSPF router can determine the multicast +capability of any other router based on the setting of the multicast- +capable bit (MC-bit) in the Options field of each router's link state +advertisements.) The omission of non-multicast routers may create a +number of potential problems when forwarding multicast traffic: -======================================================================== + o The Designated Router for a multi-access network must be an + MOSPF router. If a non-multicast OSPF router is elected the + DR, the subnetwork will not be selected to forward multicast + datagrams since a non-multicast DR cannot generate Group- + Membership LSAs for its subnetwork (because it is not running + IGMP, so it won't hear IGMP Host Membership Reports). - S - | - | - A # - / \ - / \ - 1 2 - / \ - B # # C - / \ \ - / \ \ - 3 4 5 - / \ \ - D # # E # F - / \ \ - / \ \ - 6 7 8 - / \ \ - G # # H # I + o Even though there may be unicast connectivity to a destination, + there may not be multicast connectivity. For example, the only + path between two points could require traversal of a non- + multicast-capable OSPF router. -LEGEND + o The forwarding of multicast and unicast datagrams between two + points may follow different paths, making some routing problems + a bit more challenging to solve. - # Router +7.2.3 Inter-Area Routing with MOSPF -Figure 15. Shortest Path Tree for a (S, G) pair -======================================================================== +Inter-area routing involves the case where a datagram's source and some +of its destination group members reside in different OSPF areas. It +should be noted that the forwarding of multicast datagrams continues to +be determined by the contents of the forwarding cache which is still +built from the local group database and the datagram source-based trees. +The major differences are related to the way that group membership +information is propagated and the way that the inter-area source-based +tree is constructed. -To forward multicast datagrams to downstream members of a group, each -router must determine its position in the datagram's shortest path tree. -Assume that Figure 15 illustrates the shortest path tree for a given -(source, group) pair. Router E's upstream node is Router B and there -are two downstream interfaces: one connecting to Subnetwork 6 and -another connecting to Subnetwork 7. +7.2.3.1 Inter-Area Multicast Forwarders -Note the following properties of the basic MOSPF routing algorithm: +In MOSPF, a subset of an area's Area Border Routers (ABRs) function as +"inter-area multicast forwarders." An inter-area multicast forwarder is +responsible for the forwarding of group membership information and +multicast datagrams between areas. Configuration parameters determine +whether or not a particular ABR also functions as an inter-area +multicast forwarder. - o For a given multicast datagram, all routers within an OSPF - is flooded into the +Inter-area multicast forwarders summarize their attached areas' group +membership information to the backbone by originating new Group- +Membership LSAs into the backbone area. Note that the summarization of +group membership in MOSPF is asymmetric. This means that while group +membership information from non-backbone areas is flooded into the backbone, but group membership from the backbone (or from any other non-backbone areas) is not flooded into any non-backbone area(s). To permit the forwarding of multicast traffic between areas, MOSPF introduces the concept of a "wild-card multicast receiver." A wild-card multicast receiver is a router that receives all multicast traffic generated in an area. In non-backbone areas, all inter-area multicast forwarders operate as wild-card multicast receivers. This guarantees that all multicast traffic originating in any non-backbone area is delivered to its inter-area multicast forwarder, and then if necessary @@ -2426,94 +2416,107 @@ import routes, the DVMRP backbone needs to import routes to any sources of traffic which are inside the CBT domain. The routes must be imported so that DVMRP can perform its RPF check. 9. INTEROPERABILITY FRAMEWORK FOR MULTICAST BORDER ROUTERS In late 1996, the IETF IDMR working group began discussing a formal structure that would describe the way different multicast routing protocols should interact inside a multicast border router (MBR). The work can be found in the following internet draft: , or its successor. The draft covers explicit rules for +the major multicast routing protocols that existed at the end of 1996: +DVMRP, MOSPF, PIM-DM, PIM-SM, and CBT, but applies to any potential +multicast routing protocol as well. -In a significant departure from PIM-SM, CBT has decided to maintain it's -scaling characteristics by not offering the option of shifting from a -Shared Tree (e.g., PIM-SM's RP-Tree) to a Shortest Path Tree (SPT) to -optimize delay. The designers of CBT believe that this is a critical -decision since when multicasting becomes widely deployed, the need for -routers to maintain large amounts of state information will become the -overpowering scaling factor. +The IDMR standards work will focus on this generic inter-protocol MBR +scheme, rather than having to write 25 documents, 20 detailing how each +of those 5 protocols must interwork with the 4 others, plus 5 detailing +how two disjoint regions running the same protocol must interwork. -Finally, unlike PIM-SM's shared tree state, CBT state is bi-directional. -Data may therefore flow in either direction along a branch. Thus, data -from a source which is directly attached to an existing tree branch need -not be encapsulated. +9.1 Requirements for Multicast Border Routers -8.2.1 Joining a Group's Shared Tree +In order to ensure reliable multicast delivery across a network with an +arbitrary mixture of multicast routing protocols, some constraints are +imposed to limit the scope of the problem space. -A host that wants to join a multicast group issues an IGMP host -membership report. This message informs its local CBT-aware router(s) -that it wishes to receive traffic addressed to the multicast group. -Upon receipt of an IGMP host membership report for a new group, the -local CBT router issues a JOIN_REQUEST hop-by-hop toward the group's -core router. +Each multicast routing domain, or region, may be connected in a "tree +of regions" topology. If more arbitrary inter-regional topologies are +desired, a hierarchical multicast routing protocol (such as, H-DVMRP) +must be employed, because it carries topology information about how the +regions are interconnected. Until this information is available, we +must consider the case of a tree of regions with one centrally-placed -If the JOIN_REQUEST encounters a router that is already on the group's -shared tree before it reaches the core router, then that router issues a -JOIN_ACK hop-by-hop back toward the sending router. If the JOIN_REQUEST -does not encounter an on-tree CBT router along its path towards the -core, then the core router is responsible for responding with a -JOIN_ACK. In either case, each intermediate router that forwards the -JOIN_REQUEST towards the core is required to create a transient "join -state." This transient "join state" includes the multicast group, and -the JOIN_REQUEST's incoming and outgoing interfaces. This information -allows an intermediate router to forward returning JOIN_ACKs along the -exact reverse path to the CBT router which initiated the JOIN_REQUEST. +"backbone" region. Each pair of regions is interconnected one or more +MBR(s). -As the JOIN_ACK travels towards the CBT router that issued the -JOIN_REQUEST, each intermediate router creates new "active state" for -this group. New branches are established by having the intermediate -routers remember which interface is upstream, and which interface(s) -is(are) downstream. Once a new branch is created, each child router -monitors the status of its parent router with a keepalive mechanism, -the CBT "Echo" protocol. A child router periodically unicasts a -CBT_ECHO_REQUEST to its parent router, which is then required to respond -with a unicast CBT_ECHO_REPLY message. +A MBR is responsible for injecting a default route into its "child +regions," and also injecting subnetwork reachability information into +its "parent region," optionally using aggregation techniques to reduce +the volume of the information while preserving its meaning. MBRs which +comply with have other characteristics and +duties, including: -======================================================================== +o The MBR consists at least two active routing components, each + an instance of some multicast routing protocol. No assumption is + made about the type of routing protocol (e.g., broadcast-and-prune + or explicit-join; distance-vector or link-state; etc.) any component + runs, or the nature of a "component". Multiple components running + the same protocol are allowed. - #- - - -#- - - - -# - | \ - | # - | - # - - - - # - member | | - host --| | - | --Join--> --Join--> --Join--> | - |- [DR] - - - [:] - - - -[:] - - - - [@] - | <--ACK-- <--ACK-- <--ACK-- - | +o An MBR forwards packets between two or more independent regions, with + one or more active interfaces per region, but only one component per + region. -LEGEND +o Each interface for which multicast is enabled is "owned" by exactly + one of the components at a time. - [DR] CBT Designated Router - [:] CBT Router - [@] Target Core Router - # CBT Router that is already on the shared tree +o All components share a common forwarding cache of (S,G) entries, + which are created when data packets are received, and can be + deleted at any time. The component owning an interface is the only + component that may change forwarding cache entries pertaining to + that interface. Each forwarding cache entry has a single incoming + interface (iif) and a list of outgoing interfaces (oiflist). -Figure 21: CBT Tree Joining Process -======================================================================== +[This space was intentionally left blank.] + +10. REFERENCES + +10.1 Requests for Comments (RFCs) + + 1075 "Distance Vector Multicast Routing Protocol," D. Waitzman, + C. Partridge, and S. Deering, November 1988. + + 1112 "Host Extensions for IP Multicasting," Steve Deering, + August 1989. + + 1583 "OSPF Version 2," John Moy, March 1994. + + 1584 "Multicast Extensions to OSPF," John Moy, March 1994. + + 1585 "MOSPF: Analysis and Experience," John Moy, March 1994. + + 1700 "Assigned Numbers," J. Reynolds and J. Postel, October + 1994. (STD 2) + + 1812 "Requirements for IP version 4 Routers," Fred Baker, + Editor, June 1995 + + 2000 "Internet Official Protocol Standards," Jon Postel, + Editor, February 1997. + +10.2 Internet-Drafts + + "Core Based Trees (CBT) Multicast: Architectural Overview," + , A. J. Ballardie, March 1997. + + "Core Based Trees (CBT) Multicast: Protocol Specification," , A. J. Ballardie, March 1997. "Core Based Tree (CBT) Multicast Border Router Specification for Connecting a CBT Stub Region to a DVMRP Backbone," , A. J. Ballardie, March 1997. "Distance Vector Multicast Routing Protocol," , T. Pusateri, February 19, 1997. "Internet Group Management Protocol, Version 2,"