Internet DRAFT - draft-crawley-mcast-rout-over-atm
draft-crawley-mcast-rout-over-atm
HTTP/1.1 200 OK
Date: Mon, 08 Apr 2002 23:22:25 GMT
Server: Apache/1.3.20 (Unix)
Last-Modified: Sat, 02 Mar 1996 13:56:40 GMT
ETag: "304b62-5684-31385398"
Accept-Ranges: bytes
Content-Length: 22148
Connection: close
Content-Type: text/plain
Internet Engineering Task Force E. Crawley
INTERNET-DRAFT Bay Networks
draft-crawley-mcast-rout-over-atm-00 February 22, 1996
Multicast Routing over ATM
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 documents at any time. It is not appropriate to use Internet
Drafts as reference material or to cite them other than as a "working
draft" or "work in progress."
Please check the I-D abstract listing contained in each Internet
Draft directory to learn the current status of this or any other
Internet Draft.
Abstract
As the use of IP multicasting and Asynchronous Transfer Mode (ATM)
technologies increases, it becomes important to think about ways that
IP multicast routing protocols interface to ATM networks. The
Multicast Address Resolution Server (MARS) [1] addresses the problem
of determining group membership within a single ATM Logical IP Subnet
(LIS) and provides a mapping between IP multicast addresses and ATM
addresses while [2] looks at the issues of short cut routing for PIM
Sparse Mode and CBT. In this document, the general problems of IP
multicast routing protocols over ATM networks are explored and the
issues related to the different forms of multicast routing protocols;
dense vs. sparse, shared tree vs. source tree, etc. are addressed.
Additionally, the issues related to short cut and QoS routing are
discussed. This document is intended as a starting point for
exploring the issues of IP multicast routing over ATM.
1. Introduction
Asynchronous Transfer Mode is a unique technology that provides some
features and challenges to layer 3 protocols that utilize it. While
ATM can be used to emulate traditional point-to-point links between
network nodes, it makes sense to utilize some of the additional
features of ATM if they can provide a benefit to the higher level
protocols. Some of the features in ATM can provide benefit to IP
multicast routing protocols. However, the benefits vary based on the
multicast routing protocol and the ATM features used. The way
Expires August 22, 1996 Page 1
INTERNET-DRAFT Multicast Routing over ATM February 22, 1996
different multicast routing protocols distribute data and control
information is very important when mapping to ATM. Further, there
are some additional issues that come up in ATM networks that need to
be addressed if such issues as short cut ATM paths, scaleability, and
Quality of Service (QoS) are considered. The issues and problems
presented are by no means a complete list but they are a starting
point for further discussion.
2. Data Plane and Control Plane
It is important to note the distinction between the control plane and
the data plane for IP multicast services. For IP multicasting in an
IP over ATM environment, the control plane is made up of an IP
multicasting protocol such as Core Based Trees (CBT)[3], Distance
Vector Multicast Routing Protocol (DVMRP)[4], Multicast Extensions to
OSPF (MOSPF)[5], Protocol Independent Multicasting-Sparse Mode
(PIM-SM)[6], Protocol Independent Multicasting-Dense Mode
(PIM-DM)[7], and optionally, MARS. The Internet Group Management
Protocol (IGMP) is not necessary over the ATM cloud but its presence
is not precluded. The control plane is responsible for setting up
the multicast tree and maintaining its state. In an IP over ATM
environment, the messages used to set up the tree may possibly be
forwarded over a different path than the multicast data. This issue
can become very important if the control data path is used for other
control protocols such as RSVP [8].
The data plane in an IPATM environment consists of the virtual
circuits (VCs) that are involved in the actual forwarding multicast
data. These can either be point-to- point (pt-to-pt) or
point-to-multipoint (pt-to-mpt) VCs. The control plane can use the
same VCs but it may use a different set. Additionally, changes in
the control plane may cause changes in the VCs used in the data
plane.
3. Dense Mode and Sparse Mode
The exiting multicast routing protocols are divided into two classes,
dense mode and sparse mode. PIM-DM [7] and DVMRP [4] are dense mode
protocols and use a "broadcast and prune" model. Broadcast and prune
protocols forward data from senders to all subnets away from the
sender until a router indicates that it has no clients interested in
receiving the multicast by sending a control plane "prune" message
toward the sending router. Broadcast and prune protocols are best
suited to campus LAN environments where bandwidth is widely available
and simplicity of configuration is paramount.
In contrast, sparse mode protocols such as PIM-SM [6], MOSPF [5], and
CBT [3] use control plane messages for setting up multicast trees
Expires August 22, 1996 Page 2
INTERNET-DRAFT Multicast Routing over ATM February 22, 1996
such that data is only sent to the networks that have interested
receivers. Sparse mode protocols are used when the receivers are
widely dispersed.
Mapping these models to the Non-Broadcast MultiAccess (NBMA)
environment of ATM presents a bit of a problem. If ATM VCs are
considered "expensive," require a significant setup time, or a fully
interconnected mesh does not exist, then it may be best to use a
sparse mode protocol to avoid setting up VCs to destinations that may
not be interested in receiving the multicast data. Sparse mode
protocols can also make use of pt-to-pt VCs when transiting ATM
subnetworks that do not have any receivers. In contrast,
environments that consist mostly of permanent virtual circuits (PVCs)
can utilize dense mode or sparse mode protocols since there is no
dynamic set up cost.
4. Shared Trees and Source Trees
A further division of the exiting multicast routing protocols exists
in the type of multicast distribution tree that is created. A source
tree is "rooted" at the sender with a separate tree, and
corresponding state, for each sending network. A shared tree is
rooted at a node in the network with all senders using the same tree
for distribution of multicast data. The dense mode protocols, by
their very nature, create source trees. MOSPF and one mode of
operation for PIM-SM also use source trees. CBT and the other mode
of operation for PIM-SM use shared trees. Source trees and shared
trees present different problems when used over ATM.
Source trees more closely map the model of ATM pt-to-mpt VCs. This
makes them easier to visualize on the ATM network but presents more
scaleability problems regarding the use of VCs, depending on the
configuration. However, for a small number of senders per multicast
group, this is not an important issue. As the number of senders (and
corresponding ATM network ingress points) increases, the number of
pt-to-mpt VCs in the network increases. As the number of receivers
(and corresponding ATM network egress points) increases, each of the
pt-to-mpt VCs will require additional the additional ATM parties to
be added.
Shared trees, while requiring less state in the network, are more
likely to have multiple hops in the ATM network. It is quite
possible for a router on a shared tree in an ATM network to have
packets entering and exiting the same ATM interface if MARS or a
short-cutting mechanism such as NHRP is not used.
Expires August 22, 1996 Page 3
INTERNET-DRAFT Multicast Routing over ATM February 22, 1996
5. ATM Hosts and MARS
Naturally, any use of IP multicast routing over ATM has to take into
consideration hosts directly attached to the ATM network. MARS
essentially performs the function of IGMP for an ATM LIS and is
required, if there is a mix of hosts and routers on the ATM network.
If the ATM LIS is made up of only routers, it is possible to operate
without MARS but additional hops and packet copying may occur as
packets are routed through the ATM network.
If MARS is used, the ATM LIS looks like a multicast capable
subnetwork to the multicast routing protocol (see Figure 1). MARS
allows the multicast routing protocol to track the nodes on the ATM
LIS that are part of the multicast group and therefore can allow the
nodes to set up the appropriate pt-to-mpt VCs.
[Figure not in text version of document.]
Figure 1
The MARS specification also discusses the use of MARS in conjunction
with a ATM multicast server. A multicast server can be used to
relieve the burden of managing pt-to-mpt VCs for a router but incurs
a possible delay and bottleneck at the server. The issues and
performance of these configurations should be investigated further.
6. Short Cut Routing
The ability to make connections directly from a node on one ATM LIS
to a node on another ATM LIS, bypassing intermediate hops, is a very
attractive feature of ATM and other NBMA protocols. NHRP [9]
provides one mechanism for determining the ATM address of the egress
node in an ATM cloud based on the destination IP address. Of course,
this doesn't mean much if the destination address requested is an IP
multicast address so short cut mechanisms have to be used in concert
with a multicast routing protocol that can take advantage of the
abilities of the underlying unicast routing structure. This means
that PIM and CBT are best suited to the use of short cuts since they
are independent of the underlying unicast routing protocol. It is
unclear whether short cuts can be used with MOSPF or DVMRP but
warrants additional investigation. [2] describes how NHRP can be
used with PIM or CBT for building the multicast tree by using short
cuts from a joining node to a Core/Rendezvous Point (RP)/Source
Router
There are some possible problems that need to be thought through with
short cuts and their use with multicast routing. Some of these
problems can come from changes in the routing over time. These
problems need to be investigated fully before making widespread use
of short cuts with multicast routing.
Expires August 22, 1996 Page 4
INTERNET-DRAFT Multicast Routing over ATM February 22, 1996
There are also scaling issues for large multicasts when using short
cuts that need to be examined. Short cuts can cause a larger amount
of state to be stored in the nodes, from the additional short cut end
points, and can require larger fanouts for pt-to-mpt VCs. Depending
on the size of the ATM network, these can present problems.
7. Considerations for ATM VC Usage
ATM provides several different types of VCs and each has their own
properties, advantages, and disadvantages. In this section, the
implications of different types of VCs and their usage are discussed
in relation to IP multicast routing. This is not intended to be a
complete list.
7.1 Permanent Virtual Circuits (PVCs)
PVCs are the simplest form of ATM VCs and closely emulate common
pt-to-pt links. Obviously, these links can be easily used by IP
multicast routing and do not require any special treatment.
Multicast routers are likely to have multiple PVCs running out of the
same physical ATM interface and will have the extra burden copying
packets for each PVC even though the packets travel out of the same
physical interface. This is not the best use of resources but can be
tolerated for a relatively small number of PVCs.
7.2 Switched Virtual Circuits (SVCs)
SVCs allow for more dynamic connection setup but bring along the
burden of the time to setup the VCs and what to do with the data
during SVC setup. Additionally, a routing overlay is needed to
determine where to route SVCs.
For the moment, we can assume that an overlay of VCs exists to at
least some neighbors on he same LIS so that there is connectivity to
all the nodes on the LIS, albeit not necessarily one hop away. If a
node determines, perhaps via incoming data rates, that an SVC needs
to be established to a neighbor, it must continue to route data via
an indirect path until the SVC is setup or it will have to drop data.
These policies must be understood for multicast routing since the
first data arriving may be control messages to set up the tree and
dropping these messages may be catastrophic to tree setup.
The unicast routing that IP multicast routing protocols depend on
must be flexible enough to provide next hops in the ATM environment
such that SVCs can be set up as needed to get to a particular
destination. Further, it may be worthwhile to set up parallel VCs
especially when QoS is considered.
Expires August 22, 1996 Page 5
INTERNET-DRAFT Multicast Routing over ATM February 22, 1996
7.3 Point-to-Multipoint VCs
Point to multipoint (pt-to-mpt) VCs are the only way that ATM
networks can be used to replicate IP multicast data. This relieves
the router from duplicating data over multiple VCs. Of course,
point-to-multipoint VCs are unidirectional and come with a different
set of problems relating to management and scaling.
7.4 VC Fanout
An important consideration when dealing with pt-to-mpt VCs is the
number of destinations that can be supported. There may be limits in
the equipment in the ATM network that limit the number of parties on
a pt-to-mpt VC therefore it may be important to limit the fanout or
number of parties on a pt- to-mpt VC for IP multicasting. This is
especially true with large clouds where short cut routing is used.
7.5 VC Management
The MARS specification [1] discusses the issues of SVC management
with respect to a single multicast group but there are some
interesting issues that come up when dealing with multiple multicast
groups. For the most part, VC management is a local problem that
does not require standardization as long as a receiving node can
accept VCs from different ATM sources and an identical hop-wise path
can be made back to the ATM source node for use with protocols such
as RSVP [8].
One method of managing multiple multicast groups is to assign each
group to a different pt-to-mpt VC but this limits the number of
groups that can be supported to the number of VCs available. A
second method looks for an existing pt-to-mpt VC that goes to the
same set of ATM destinations. If one is found the data is sent on
the VC. If not, a new VC is set up or multiple VCs that go to the
right set of ATM addresses can be used. This model can be extended
for further aggregation to include policies that would allow VCs that
go to a superset of the ATM destinations desired. Of course, this
method can quickly hit a point of diminishing returns, but can be
applied in cases where VCs are at a premium or a very large number of
multicast groups need to be supported.
7.6 ATM Hard State vs. Soft-State Protocols
ATM networks use reliable messaging and hard state connections. PIM
uses a soft state mechanism to periodically refresh multicast routing
state. [2] discusses reducing the frequency of the periodic soft
state messages when using PIM over ATM. The reasoning is that since
Expires August 22, 1996 Page 6
INTERNET-DRAFT Multicast Routing over ATM February 22, 1996
ATM provides a reliable hard state connection, with easy detection of
VC failure, there is a lesser need for soft state refresh messages to
detect the same kind of failures. Note, the soft state refresh
messages should not be eliminated because there are still classes of
failures that cannot be detected by the loss of a VC, such as the
failure of a process on an ingress or egress router.
CBT uses hard state with periodic echoing to determine neighbor
status. Over ATM, the frequency of these echoes can be reduced, if
necessary. MOSPF depends on link state changes as well as infrequent
hellos for state management so no changes would be necessary in this
respect when running over ATM.
8. ATM Futures that Impact Multicast Routing
The ATM Forum has been evolving the ATM specifications and some of
the changes currently planned and those being discussed can improve
the ability of IP multicast routing to run more effectively over ATM.
As these features become available, multicast routing should try to
take advantage of them.
8.1 Leaf Initiated Join
ATM Forum Release 4.0 contains a Leaf Initiated Join (LIJ) capability
to allow an ATM end point to join an existing pt- to-mpt VC without
necessarily contacting the root of the VC. This more closely matches
the receiver-based model of IP multicasting. There are issues about
determining the correct VC to join when a root can be managing
multiple and possibly parallel pt-to-mpt VCs that must be addressed
in order for this feature to be used.
8.2 Variegated Point-to-Multipoint
There have been discussions and contributions that consider the
possibility of a pt-to-mpt VC that would allow different QoS
parameters for each branch of the VC. This would be a benefit to
RSVP over ATM and multicast routing would need to know how to set up
and utilize such VCs.
8.3 Group Addressing
In order to make ATM multipoint communications more closely match the
IP multicast model, schemes that allow ATM group addresses that could
be directly mapped to IP multicast addresses have been discussed.
This is contrary to the traditional one-to-many communications of ATM
so it may take a bit of work to fit into the model. An important
issue is to make whatever scheme is developed be scaleable to the
needs of IP multicasting over ATM.
Expires August 22, 1996 Page 7
INTERNET-DRAFT Multicast Routing over ATM February 22, 1996
9. QoS Routing
Since ATM networks have QoS capabilities and these capabilities are
advertised in the PNNI (Private Network-to- Network Interface)
routing information, it makes sense for IP multicast routing over ATM
to make use of this information in concert with RSVP. The work in
this area is just starting but it will have an impact on multicast
routing, particularly over ATM.
10. Conclusions
In this draft, an initial attempt has been made at gathering, and
addressing, some of the issues related to IP multicast routing over
ATM. There are some areas that need to be documented and
investigated further. They include:
- The handling of control plane vs. data plane flows in ATM where
they can possibly follow different paths.
- The use of dense mode protocols in an ATM SVC environment
- The use of IGMP in an IP over ATM environment
- The impact of source tree vs. shared tree data distribution in ATM
- The impact of short cut routing for IP multicasting in ATM
- The impact of multicast servers on IP multicast routing
- Guidelines for VC management and usage for all multicast protocols
- Tweaking of soft-state mechanisms over ATM to reduce refresh
intervals
- Integrating new ATM features with multicast routing protocols
- The impact of multicast QoS routing schemes over ATM
These items should be considered as work items for the IDMR and IPATM
IETF working groups.
11. References
[1] G. Armitage, "Support for Multicast over UNI 3.0/3.1 based ATM
Networks", draft-ietf-ipatm-ipmc-09.txt, December 1995.
Expires August 22, 1996 Page 8
INTERNET-DRAFT Multicast Routing over ATM February 22, 1996
[2] Y. Rekhter, D. Farinacci, "Support for Sparse Mode PIM over ATM",
draft-rekhter-pim-atm-00.txt, February 1996.
[3] A. Ballardie, S. Reeve, N. Jain, "Core Based Trees (CBT)
Multicast-- Protocol Specification", draft-ietf-idmr-
cbt-spec-04.txt, February 1996.
[4] D. Waitzman, C. Partridge, S. Deering. "Distance Vector Multicast
Routing Protocol". RFC 1075, November 1988.
[5] J. Moy, Multicast Extensions to OSPF, RFC 1584, March 1994.
[6] S. Deering, D. Estrin, D. Farinacci, V. Jacobson, C. Liu, L.Wei,
P. Sharma, S. Helmy, "Protocol Independent Multicast-Sparse Mode
(PIM-SM): Protocol Specification", draft-ietf-idmr-pim-spec-02.txt,
September 1995.
[7] S. Deering, D. Estrin, D. Farinacci, V. Jacobson, C. Liu, L.Wei,
P. Sharma, S. Helmy, "Protocol Independent Multicast-Dense Mode
(PIM-DM): Protocol Specification",
draft-ietf-idmr-pim-dm-spec-01.txt, January 1996.
[8] R. Braden, L. Zhang, S. Berson, S. Herzog, S. Jamin. "Resource
ReSerVation Protocol (RSVP) -- Version 1 Functional Specification",
draft-ietf-rsvp-spec-09.txt, February 1996.
[9] D. Katz, D. Piscitello, B. Cole, J. Luciani, "NBMA Next Hop
Resolution Protocol (NHRP)", draft-ietf-rolc-nhrp- 07.txt, December
1995.
12. Author's Address
Eric S. Crawley
Bay Networks, Inc.
3 Federal Street
Billerica, MA 01821
+1 508 670-8888
esc@baynetworks.com
Expires August 22, 1996 Page 9
