draft-ietf-mboned-intro-multicast-01.txt   draft-ietf-mboned-intro-multicast-02.txt 
INTERNET-DRAFT T. Maufer INTERNET-DRAFT T. Maufer
C. Semeria Expire in six months C. Semeria
Category: Informational 3Com Corporation Category: Informational 3Com Corporation
March 1997 March 1997
Introduction to IP Multicast Routing Introduction to IP Multicast Routing
<draft-ietf-mboned-intro-multicast-01.txt> <draft-ietf-mboned-intro-multicast-02.txt>
Status of this Memo Status of this Memo
This document is an Internet Draft. Internet Drafts are working This document is an Internet Draft. Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its Areas, and documents of the Internet Engineering Task Force (IETF), its Areas, and
its Working Groups. Note that other groups may also distribute working its Working Groups. Note that other groups may also distribute working
documents as Internet Drafts. documents as Internet Drafts.
Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts are draft documents valid for a maximum of six months.
Internet Drafts may be updated, replaced, or obsoleted by other Internet Drafts may be updated, replaced, or obsoleted by other
skipping to change at page 5, line 171 skipping to change at page 8, line 26
| Island | | Island| ---------| Island | | Island | | Island| ---------| Island |
| B | | C | Tunnel | D | | B | | C | Tunnel | D |
++++++++ +++++++ --------- ++++++++ ++++++++ +++++++ --------- ++++++++
\ \ | \ \ |
\T\ | \T\ |
\U\ | \U\ |
\N\ | \N\ |
\N\ +++++++ \N\ +++++++
\E\ |Island | \E\ |Island |
\L\| E | \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 4. MULTICAST ADDRESSING
delivery paths that enable the forwarding of multicast datagrams
across an internetwork.
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 4.1 Class D Addresses
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."
Each routing protocol constructs a forwarding table in its own way; the An IP multicast group is identified by a Class D address. Class D
forwarding table tells each router that for a certain source, or for a addresses have their high-order four bits set to "1110" followed by
given source sending to a certain group (called a (source, group) pair), a 28-bit multicast group ID. Expressed in standard "dotted-decimal"
packets are expected to arrive on a certain "inbound" or "upstream" notation, multicast group addresses range from 224.0.0.0 to
interface and must be copied to certain (set of) "outbound" or 239.255.255.255 (shorthand: 224.0.0.0/4).
"downstream" interface(s) in order to reach all known subnetworks with
group members.
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 Figure 3: Class D Multicast Address Format
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.
Broadcast transmission is not an effective solution for this type of The Internet Assigned Numbers Authority (IANA) maintains a list of
application since it affects the CPU performance of each and every registered IP multicast groups. The base address 224.0.0.0 is reserved
station that sees the packet. Besides, it wastes bandwidth. 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 "all systems on this subnet" 224.0.0.1
to transmit packets to group members residing on the same subnetwork. "all routers on this subnet" 224.0.0.2
However, there is no reason to limit the extent of a multicast "all DVMRP routers" 224.0.0.4
transmission to a single LAN. The time-to-live (TTL) field in the IP "all OSPF routers" 224.0.0.5
(hex); to be clear, the range from 01-00-5E-00-00-00 "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:
<URL:http://www.isi.edu/div7/iana/assignments.html>
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. 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 A simple procedure was developed to map Class D addresses to this
reserved MAC-layer multicast address block. This allows IP multicasting reserved MAC-layer multicast address block. This allows IP multicasting
to easily take advantage of the hardware-level multicasting supported by to easily take advantage of the hardware-level multicasting supported by
network interface cards. network interface cards.
The mapping between a Class D IP address and an IEEE-802 (e.g., FDDI, 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- 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 order 23 bits of the Class D address into the low-order 23 bits of
skipping to change at page 33, line 189 skipping to change at page 36, line 41
Upstream Datagrams matching this row's Dest. Group and Upstream Datagrams matching this row's Dest. Group and
Source must be received on this interface. Source must be received on this interface.
Downstream If a datagram matching this row's Dest. Group Downstream If a datagram matching this row's Dest. Group
and Source is received on the correct Upstream and Source is received on the correct Upstream
interface, then it is forwarded across the listed interface, then it is forwarded across the listed
Downstream interfaces. Downstream interfaces.
TTL The minimum number of hops a datagram must cross TTL The minimum number of hops a datagram must cross
to reach any of the Dest. Group's members. An 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 MOSPF router may discard a datagram if it can see
following discussion assumes that the reader is familiar with OSPF. that the datagram has insufficient TTL to reach
even the closest group member.
7.2.1.1 Local Group Database
Similar to all other multicast routing protocols, MOSPF routers use the The information in the forwarding cache is not aged or periodically
Internet Group Management Protocol (IGMP) to monitor multicast group refreshed: It is maintained as long as there are system resources
membership on directly-attached subnetworks. MOSPF routers maintain a available (e.g., memory) or until the next topology change. The
"local group database" which lists directly-attached groups and contents of the forwarding cache will change when:
determines the local router's responsibility for delivering multicast
datagrams to these groups.
On any given subnetwork, the transmission of IGMP Host Membership o The topology of the OSPF internetwork changes, forcing all of
Queries is performed solely by the Designated Router (DR). However, the shortest path trees to be recalculated. (Once the cache
the responsibility of listening to IGMP Host Membership Reports is has been flushed, entries are not rebuilt. If another packet
performed by not only the Designated Router (DR) but also the Backup for one of the previous (Dest. Group, Source) pairs is
Designated Router (BDR). Therefore, in a mixed LAN containing both received, then a "new" cache entry for that pair will be
MOSPF and OSPF routers, an MOSPF router must be elected the DR for the created then.)
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.
The DR is responsible for communicating group membership information to o There is a change in the Group-Membership LSAs indicating that
all other routers in the OSPF area by flooding Group-Membership LSAs. the distribution of individual group members has changed.
Similar to Router-LSAs and Network-LSAs, Group-Membership LSAs are only
flooded within a single area.
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 MOSPF routers can be combined with non-multicast OSPF routers. This
multicast datagram as it travels through the area from the source permits the gradual deployment of MOSPF and allows experimentation with
subnetwork to each of the group members' subnetworks. The shortest multicast routing on a limited scale.
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.
When the initial datagram arrives, the source subnetwork is located in It is important to note that an MOSPF router is required to eliminate
the MOSPF link state database. The MOSPF link state database is simply all non-multicast OSPF routers when it builds its source-based shortest-
the standard OSPF link state database with the addition of Group- path delivery tree. (An MOSPF router can determine the multicast
Membership LSAs. Based on the Router- and Network-LSAs in the OSPF capability of any other router based on the setting of the multicast-
link state database, a source-based shortest-path tree is constructed capable bit (MC-bit) in the Options field of each router's link state
using Dijkstra's algorithm. After the tree is built, Group-Membership advertisements.) The omission of non-multicast routers may create a
LSAs are used to prune the tree such that the only remaining branches number of potential problems when forwarding multicast traffic:
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.
======================================================================== 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 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-
A # multicast-capable OSPF router.
/ \
/ \
1 2
/ \
B # # C
/ \ \
/ \ \
3 4 5
/ \ \
D # # E # F
/ \ \
/ \ \
6 7 8
/ \ \
G # # H # I
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 7.2.3.1 Inter-Area Multicast Forwarders
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.
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 Inter-area multicast forwarders summarize their attached areas' group
is flooded into the 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 backbone, but group membership from the backbone (or from any other
non-backbone areas) is not flooded into any non-backbone area(s). non-backbone areas) is not flooded into any non-backbone area(s).
To permit the forwarding of multicast traffic between areas, MOSPF To permit the forwarding of multicast traffic between areas, MOSPF
introduces the concept of a "wild-card multicast receiver." A wild-card introduces the concept of a "wild-card multicast receiver." A wild-card
multicast receiver is a router that receives all multicast traffic multicast receiver is a router that receives all multicast traffic
generated in an area. In non-backbone areas, all inter-area multicast generated in an area. In non-backbone areas, all inter-area multicast
forwarders operate as wild-card multicast receivers. This guarantees forwarders operate as wild-card multicast receivers. This guarantees
that all multicast traffic originating in any non-backbone area is that all multicast traffic originating in any non-backbone area is
delivered to its inter-area multicast forwarder, and then if necessary delivered to its inter-area multicast forwarder, and then if necessary
skipping to change at page 47, line 176 skipping to change at page 50, line 30
import routes, the DVMRP backbone needs to import routes to any sources 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 of traffic which are inside the CBT domain. The routes must be imported
so that DVMRP can perform its RPF check. so that DVMRP can perform its RPF check.
9. INTEROPERABILITY FRAMEWORK FOR MULTICAST BORDER ROUTERS 9. INTEROPERABILITY FRAMEWORK FOR MULTICAST BORDER ROUTERS
In late 1996, the IETF IDMR working group began discussing a formal In late 1996, the IETF IDMR working group began discussing a formal
structure that would describe the way different multicast routing structure that would describe the way different multicast routing
protocols should interact inside a multicast border router (MBR). The protocols should interact inside a multicast border router (MBR). The
work can be found in the following internet draft: <draft-thaler- work can be found in the following internet draft: <draft-thaler-
interop-0at CBT has adopted the core discovery interop-00.ps>, or its successor. The draft covers explicit rules for
mechanism ("bootstrap" ) defined in the PIM-SM specification. For the major multicast routing protocols that existed at the end of 1996:
inter-domain discovery, efforts are underway to standardize (or at least DVMRP, MOSPF, PIM-DM, PIM-SM, and CBT, but applies to any potential
separately specify) a common RP/Core discovery mechanism. The intent is multicast routing protocol as well.
that any shared tree protocol could implement this common discovery
mechanism using its own protocol message types.
In a significant departure from PIM-SM, CBT has decided to maintain it's The IDMR standards work will focus on this generic inter-protocol MBR
scaling characteristics by not offering the option of shifting from a scheme, rather than having to write 25 documents, 20 detailing how each
Shared Tree (e.g., PIM-SM's RP-Tree) to a Shortest Path Tree (SPT) to of those 5 protocols must interwork with the 4 others, plus 5 detailing
optimize delay. The designers of CBT believe that this is a critical how two disjoint regions running the same protocol must interwork.
decision since when multicasting becomes widely deployed, the need for
routers to maintain large amounts of state information will become the
overpowering scaling factor.
Finally, unlike PIM-SM's shared tree state, CBT state is bi-directional. 9.1 Requirements for Multicast Border Routers
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.
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 Each multicast routing domain, or region, may be connected in a "tree
membership report. This message informs its local CBT-aware router(s) of regions" topology. If more arbitrary inter-regional topologies are
that it wishes to receive traffic addressed to the multicast group. desired, a hierarchical multicast routing protocol (such as, H-DVMRP)
Upon receipt of an IGMP host membership report for a new group, the must be employed, because it carries topology information about how the
local CBT router issues a JOIN_REQUEST hop-by-hop toward the group's regions are interconnected. Until this information is available, we
core router. 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 "backbone" region. Each pair of regions is interconnected one or more
shared tree before it reaches the core router, then that router issues a MBR(s).
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.
As the JOIN_ACK travels towards the CBT router that issued the A MBR is responsible for injecting a default route into its "child
JOIN_REQUEST, each intermediate router creates new "active state" for regions," and also injecting subnetwork reachability information into
this group. New branches are established by having the intermediate its "parent region," optionally using aggregation techniques to reduce
routers remember which interface is upstream, and which interface(s) the volume of the information while preserving its meaning. MBRs which
is(are) downstream. Once a new branch is created, each child router comply with <draft-thaler-interop-00.ps> have other characteristics and
monitors the status of its parent router with a keepalive mechanism, duties, including:
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.
======================================================================== 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.
#- - - -#- - - - -# 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.
|
# - - - - #
member | |
host --| |
| --Join--> --Join--> --Join--> |
|- [DR] - - - [:] - - - -[:] - - - - [@]
| <--ACK-- <--ACK-- <--ACK--
|
LEGEND o Each interface for which multicast is enabled is "owned" by exactly
one of the components at a time.
[DR] CBT Designated Router o All components share a common forwarding cache of (S,G) entries,
[:] CBT Router which are created when data packets are received, and can be
[@] Target Core Router deleted at any time. The component owning an interface is the only
# CBT Router that is already on the shared tree 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,"
<draft-ietf-idmr-cbt-arch-04.txt>, A. J. Ballardie, March 1997.
"Core Based Trees (CBT) Multicast: Protocol Specification," <draft-
ietf-idmr-cbt-spec-07.txt>, A. J. Ballardie, March 1997. ietf-idmr-cbt-spec-07.txt>, A. J. Ballardie, March 1997.
"Core Based Tree (CBT) Multicast Border Router Specification for "Core Based Tree (CBT) Multicast Border Router Specification for
Connecting a CBT Stub Region to a DVMRP Backbone," <draft-ietf- Connecting a CBT Stub Region to a DVMRP Backbone," <draft-ietf-
idmr-cbt-dvmrp-00.txt>, A. J. Ballardie, March 1997. idmr-cbt-dvmrp-00.txt>, A. J. Ballardie, March 1997.
"Distance Vector Multicast Routing Protocol," <draft-ietf-idmr- "Distance Vector Multicast Routing Protocol," <draft-ietf-idmr-
dvmrp-v3-04.ps>, T. Pusateri, February 19, 1997. dvmrp-v3-04.ps>, T. Pusateri, February 19, 1997.
"Internet Group Management Protocol, Version 2," <draft-ietf- "Internet Group Management Protocol, Version 2," <draft-ietf-
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/