home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Info 1997 December
/
Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso
/
drafts
/
draft_ietf_i
/
draft-ietf-ion-intralis-multicast-00.txt
< prev
next >
Wrap
Text File
|
1997-04-25
|
10KB
|
358 lines
Network Working Group Dino Farinacci
Internet Draft Cisco Systems
David Meyer
University of Oregon
Yakov Rekhter
Cisco Systems
Expiration Date: October 1997 April 1997
Intra-LIS IP multicast among routers over ATM using Sparse Mode PIM
<draft-ietf-ion-intralis-multicast-00.txt>
1. 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
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as ``work in progress.''
To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).
2. Abstract
This document describes how intra-LIS IP multicast can be efficiently
supported among routers over ATM without using the Multicast Address
Resolution Server (MARS). The method described here is specific to
Sparse Mode PIM [PIM-SM], and relies on the explicit join mechanism
inherent in PIM-SM to notify routers when they should create group
specific point-to-multipoint VCs.
Dino Farinacci, David Meyer, Yakov Rekhter FORMFEED[Page 1]
Internet Draft draft-ietf-ion-intralis-multicast-00.txt April 1997
3. Overall model
This document focuses on forwarding of multicast traffic among PIM-SM
routers connected to an ATM network. Routers on an ATM network are
partitioned into Logical IP Subnets, or LISs. This document deals
with handling multicast within a single LIS. Handling inter-LIS
multicast traffic, including handling shortcuts, is outside the scope
of this document. In addition, this document does not address
forwarding of multicast traffic to or from hosts connected to an ATM
network.
4. Router behavior
This document requires that each router within a LIS knows IP and ATM
addresses of all other routers within the LIS. The mapping between IP
and ATM addresses may be provided by an ARP server [RFC1577], or by
any other means (e.g., static configuration).
Each router within a LIS is required to maintain a single (shared)
router distribution point-to-multipoint VC rooted at the router with
all other routers in the LIS as the leaf nodes of that VC. The VC is
expected to be used for forwarding of multicast traffic (both data
and control) among routers within the LIS. For example, this VC
would be used for distributing PIM [PIM-SM] control messages
(Join/Prune messages).
4.1. Establishing Dedicated, Per Group Point-to-Multipoint VCs
Routers may also maintain group specific, dedicated point-to-
multipoint VCs. In particular, an upstream router for a group may
choose to become the root of a group specific point-to-multipoint VC
whose leaves are the downstream routers that have directly connected
or downstream receivers for the group. While the criteria for
establishing a group specific point-to-multipoint VC are local to a
router, issues such as the volume of traffic associated with the
group and the fanout factor within the LIS should be considered.
Finally, note that a router must minimally support a single shared
point-to-multipoint VC for distribution of control messages and data
(to all group addresses).
A router can choose to establish a dedicated point-to-multipoint VC
(or add another leaf to an already established dedicated point-to-
multipoint VC) when it receives a PIM Join messages from another
router in the same LIS. The router sending the joins uses its shared
point-to-multipoint VC. Similarly, when a router that is the root of
a point-to-multipoint VC receives PIM Prune message, it removes the
Dino Farinacci, David Meyer, Yakov Rekhter FORMFEED[Page 2]
Internet Draft draft-ietf-ion-intralis-multicast-00.txt April 1997
originator of the message from its dedicated point-to-multipoint VC.
4.2. Switching to a Source-Rooted Tree
If at least one of the routers within a LIS decides to switch to a
source-rooted tree (by sending (S,G) PIM Joins), then all other
routers within the LIS that have downstream members for G should
switch to that source-rooted tree as well. Since a router that
switches to a source-rooted tree sends PIM Join messages for (S,G)
over its shared point-to-multipoint VC, the other routers within the
LIS are able to detect this. Once a router that has downstream
members for G detects this, the router should send (S,G) PIM Join
message as well (otherwise the router may receive duplicate traffic
from S).
4.2.1. Adding New Members to a Source-Rooted Tree
As mentioned above, this document requires that once one router in a
LIS decides to switch to the source tree for some (S,G), all routers
in the LIS that have downstream members must also switch to the (S,G)
source tree. Now, when a new router wants to receive traffic from G,
it starts sending (*,G)-Joins on it's shared point-to-multipoint VC
toward the RP for G. The root of the (S,G)-source-rooted tree will
know to add the new router to the point-to-multipoint VC servicing
the (S,G)-source-rooted tree by observing the (*,G)-joins on it's
shared point-to-multipoint VC. However, the new router must also
switch to the (S,G)-source-rooted tree. In order to accomplish this,
the newly added router must:
(i). Notice that it has been added to a new
point-to-multipoint VC
(ii). Notice (S,G) traffic coming down this new
point-to-multipoint VC
(iii). Send (S,G) joins toward S, causing it to switch to the
source-rooted tree. The router learns that the VC is
used to distribute (S,G) traffic in the previous
steps.
Dino Farinacci, David Meyer, Yakov Rekhter FORMFEED[Page 3]
Internet Draft draft-ietf-ion-intralis-multicast-00.txt April 1997
4.3. Handing the "Packet Reflection" Problem
When a router receives a multicast packet from another router in its
own LIS, the router should not send the packet on any of the routers
distribution point-to-multipoint VCs associate with the LIS. This
eliminates the problem of "packet reflection". Sending the packet on
the routers' distribution VCs associated with other LISs is
controlled by the multicast routing procedures.
5. Brief Comparison with MARS
The intra-LIS multicast scheme described in this document is intended
to be a less complex solution to an important subset of the
functionality provided by the Multicast Address Resolution Server, or
MARS [MARS]. In particular, it is designed to provide intra-LIS
multicast between routers using PIM-SM, and does not consider the
case of host-rooted point-to-multicast multicast distribution VCs.
Although MARS supports both of the current schemes for mapping the IP
multicast service model to ATM (multicast server and meshes of
point-to-multipoint VCs), it does so at at cost and complexity higher
than of the scheme described in this document. In addition, MARS
requires new encapsulations, whereas this proposal works with either
LLC/SNAP or with NLPID encapsulation. Another important difference is
that MARS allows point-to-multipoint VCs rooted either at a source or
at a multicast server (MCS). The approach taken here is to constrain
complexity by focusing on PIM-SM (taking advantage of information
available in explicit joins), and by allowing point-to-multipoint VCs
to be rooted only at the routers (which is roughly analogous to the
complexity and functionality of rooting point-to-multipoint VCs at
the sources).
In summary, the method described in this document is designed for the
router-to-router case, and takes advantage of the explicit-join
mechanism inherent in PIM-SM to provide a simple mechanism for
intra-LIS multicast between routers. MARS, on the other hand, accepts
different tradeoffs in complexity-functionality design space. In
particular, while the MARS paradigm provides a general neighbor
discovery mechanism, allows host to participate, and is protocol
independent, it does so at considerable cost.
Dino Farinacci, David Meyer, Yakov Rekhter FORMFEED[Page 4]
Internet Draft draft-ietf-ion-intralis-multicast-00.txt April 1997
6. Security Considerations
Security issues are not discussed in this document.
7. References
[MARS] G. Armitage, "Support for Multicast over UNI
3.0/3.1 based ATM Networks.", RFC2022, November
1996.
[PIM-SM] Estrin, D, et. al., "Protocol Independent Multicast
Sparse Mode (PIM-SM): Protocol Specification",
draft-ietf-idmr-PIM-SM-spec-09.ps, October, 1996.
8. Acknowledgments
To be supplied.
9. Author Information
Dino Farinacci
Cisco Systems
170 Tasman Dr.
San Jose, CA 95134
Phone: (408) 526-4696
e-mail: dino@cisco.com
David Meyer
University of Oregon
1225 Kincaid St.
Eugene, OR 97403
Phone: (541) 346-1747
e-mail: meyer@antc.uoregon.edu
Yakov Rekhter
cisco Systems, Inc.
170 Tasman Dr.
San Jose, CA 95134
Phone: (914) 528-0090
email: yakov@cisco.com
Dino Farinacci, David Meyer, Yakov Rekhter FORMFEED[Page 5]
Internet Draft draft-ietf-ion-intralis-multicast-00.txt April 1997
Dino Farinacci, David Meyer, Yakov Rekhter FORMFEED[Page 6]