As per Relevance of the word multicast, we have this rfc below:
Network Working Group D.
Request for Comments: 2337 Cisco
Category: Experimental D.
Cisco
Y.
Cisco
April 1998
Intra-LIS IP multicast among routers over ATM using Sparse Mode
Status of this
This memo defines an Experimental Protocol for the
community. It does not specify an Internet standard of any kind
Discussion and suggestions for improvement are requested
Distribution of this memo is unlimited
Copyright
Copyright (C) The Internet Society (1998). All Rights Reserved
2.
This document describes how intra-LIS IP multicast can be
supported among routers over ATM without using the Multicast
Resolution Server (MARS). The method described here is specific
Sparse Mode PIM [PIM-SM], and relies on the explicit join
inherent in PIM-SM to notify routers when they should create
specific point-to-multipoint VCs
3. Overall
This document focuses on forwarding of multicast traffic among PIM-
routers connected to an ATM network. Routers on an ATM network
partitioned into Logical IP Subnets, or LISs. This document
with handling multicast within a single LIS. Handling inter-
multicast traffic, including handling shortcuts, is outside the
of this document. In addition, this document does not
forwarding of multicast traffic to or from hosts connected to an
network
Farinacci, et. al. Experimental [Page 1]
RFC 2337 IP multicast over ATM using PIM April 1998
4. Router
This document requires that each router within a LIS knows IP and
addresses of all other routers within the LIS. The mapping between
and ATM addresses may be provided by an ARP server [RFC2225], or
any other means (e.g., static configuration).
Each PIM router within a LIS is required to maintain a
(shared) point-to-multipoint distribution VC rooted at the
with all other PIM routers in the LIS as the leaf nodes. The VC
expected to be used for forwarding of multicast traffic (both
and control) among routers within the LIS. For example, this VC
be used for distributing PIM [PIM-SM] control messages (Join/
messages).
In addition, if a PIM router receives a IGMP report from an non-
neighbor, then the router may add the reporter to the existing
distribution VC or to the group specific distribution VC (if
exists). The PIM router may also create a specific VC for this
proxy
4.1. Establishing Dedicated, Per Group Point-to-Multipoint
Routers may also maintain group specific, dedicated point-to
multipoint VCs. In particular, an upstream router for a group
choose to become the root of a group specific point-to-multipoint
whose leaves are the downstream routers that have directly
or downstream receivers for the group. While the criteria
establishing a group specific point-to-multipoint VC are local to
router, issues such as the volume of traffic associated with
group and the fanout factor within the LIS should be considered
Finally, note that a router must minimally support a single
point-to-multipoint VC for distribution of control messages and
(to all group addresses).
A router can choose to establish a dedicated point-to-multipoint
(or add another leaf to an already established dedicated point-to
multipoint VC) when it receives a PIM Join or IGMP report
from another device in the same LIS. When a router that is the
of a point-to-multipoint VC receives PIM Prune message or IGMP leave
it removes the originator of the message from its dedicated point
to-multipoint VC
Farinacci, et. al. Experimental [Page 2]
RFC 2337 IP multicast over ATM using PIM April 1998
4.2. Switching to a Source-Rooted
If at least one of the routers within a LIS decides to switch to
source-rooted tree (by sending (S,G) PIM Joins), then all
routers within the LIS that have downstream members for G
switch to that source-rooted tree as well. Since a router
switches to a source-rooted tree sends PIM Join messages for (S,G
over its shared point-to-multipoint VC, the other routers within
LIS are able to detect this. Once a router that has
members for G detects this, the router should send (S,G) PIM
message as well (otherwise the router may receive duplicate
from S).
Note that it is possible for a non-PIM router in the LIS to fail
receive data if the injection point moves to router to which there
not an existing VC
4.2.1. Adding New Members to a Source-Rooted
As mentioned above, this document requires that once one router in
LIS decides to switch to the source tree for some (S,G), all
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
toward the RP for G. The root of the (S,G)-source-rooted tree
know to add the new router to the point-to-multipoint VC
the (S,G)-source-rooted tree by observing the (*,G)-joins on it'
shared point-to-multipoint VC. However, the new router must
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
point-to-multipoint
(ii). Notice (S,G) traffic coming down this
point-to-multipoint
(iii). Send (S,G) joins toward S, causing it to switch to
source-rooted tree. The router learns that the VC is
to distribute (S,G) traffic in the previous steps
Farinacci, et. al. Experimental [Page 3]
RFC 2337 IP multicast over ATM using PIM April 1998
4.3. Handing the "Packet Reflection"
When a router receives a multicast packet from another router in
own LIS, the router should not send the packet on any of the
distribution point-to-multipoint VCs associate with the LIS.
eliminates the problem of "packet reflection". Sending the packet
the routers' distribution VCs associated with other LISs
controlled by the multicast routing procedures
5. Brief Comparison with
The intra-LIS multicast scheme described in this document is
to be a less complex solution to an important subset of
functionality provided by the Multicast Address Resolution Server,
MARS [MARS]. In particular, it is designed to provide intra-
multicast between routers using PIM-SM, and does not consider
case of host-rooted point-to-multicast multicast distribution VCs
Although MARS supports both of the current schemes for mapping the
multicast service model to ATM (multicast server and meshes
point-to-multipoint VCs), it does so at at cost and complexity
than of the scheme described in this document. In addition,
requires new encapsulations, whereas this proposal works with
LLC/SNAP or with NLPID encapsulation. Another important difference
that MARS allows point-to-multipoint VCs rooted either at a source
at a multicast server (MCS). The approach taken here is to
complexity by focusing on PIM-SM (taking advantage of
available in explicit joins), and by allowing point-to-multipoint
to be rooted only at the routers (which is roughly analogous to
complexity and functionality of rooting point-to-multipoint VCs
the sources).
In summary, the method described in this document is designed for
router-to-router case, and takes advantage of the explicit-
mechanism inherent in PIM-SM to provide a simple mechanism
intra-LIS multicast between routers. MARS, on the other hand,
different tradeoffs in complexity-functionality design space.
particular, while the MARS paradigm provides a general
discovery mechanism, allows host to participate, and is
independent, it does so at considerable cost
Farinacci, et. al. Experimental [Page 4]
RFC 2337 IP multicast over ATM using PIM April 1998
6. Security
In general, the security issues relevant to the proposal outlined
the memo are subsumed by those faced by PIM-SM. While work
proceeding on security for PIM-SM, it is worthwhile noting
several issues have been raised in conjunction with multicast
and with PIM-SM in particular. These issues include but are
limited to
(i). Unauthorized
(ii). Unauthorized
(iii). Unauthorized use of the
(iv). Unauthorized "last hop" switching to shortest
tree
6.1. General Comments on Multicast Routing Protocol
Historically, routing protocols used within the Internet have
strong authentication mechanisms [RFC1704]. In the late 1980s
analysis revealed that there were a number of security problems
Internet routing protocols then in use [BELLOVIN89]. During
early 1990s it became clear that adversaries were
attacking various intra-domain and inter-domain routing
(e.g. via TCP session stealing of BGP sessions) [CERTCA9501,
RFC1636]. More recently, cryptographic authentication mechanisms
been developed for RIPv2, OSPF, and the proprietary EIGRP
protocols. BGP protection, in the form of a Keyed MD5 option
TCP, has also become widely deployed
At present, most multicast routing protocols lack
cryptographic protection. One possible approach to this is
incorporate a strong cryptographic protection mechanism (e.g.
HMAC MD5 [RFC2104]) within the routing protocol itself. Alternately
the routing protocol could be designed and specified to use the
Authentication Header (AH) [RFC1825, RFC1826, RFC2085] to
cryptographic authentication
Because the intent of any routing protocol is to propagate
information to other parties, confidentiality is not
required in routing protocols. In those few cases where
security policy might require confidentiality, the use of the
Encapsulating Security Payload (ESP) [RFC1825, RFC1827]
recommended
Farinacci, et. al. Experimental [Page 5]
RFC 2337 IP multicast over ATM using PIM April 1998
Scalable dynamic multicast key management is an active research
at this time. Candidate technologies for scalable dynamic
key management include CBT-based key management [RFC1949] and
Group Key Management Protocol (GKMP) [RFC2093,RFC2094]. The IETF
Security Working Group is actively working on GKMP extensions to
standards-track ISAKMP key management protocol being developed in
same working group
7.
[BELLOVIN89] S. Bellovin, "Security Problems in the TCP/
Protocol Suite", ACM Computer Communications Review
Volume 19, Number 2, pp. 32-48, April 1989.
[CERTCA9501] CERT, "IP Spoofing Attacks and Hijacked
Connections", ftp://ftp.cert.org/cert_advisories/,
January 1995.
[MARS] Armitage, G., "Support for Multicast over UNI 3.0/3.1
based ATM Networks.", RFC 2022, November 1996.
[PIM-SM] Estrin, D, et. al., "Protocol Independent
Sparse Mode (PIM-SM): Protocol Specification", Work
Progress
[RFC1636] Braden, R., Clark, D., Crocker, S., and C. Huitema
"Report of IAB Workshop on Security in the
Architecture February 8-10, 1994", RFC 1636, June 1994.
[RFC1704] Haller, N., and R. Atkinson, "On
Authentication", RFC 1704, October 1994.
[RFC1825] Atkinson, R., "IP Security Architecture", RFC 1825,
August 1995.
[RFC1826] Atkinson, R., "IP Authentication Header", RFC 1826,
August 1995.
[RFC1827] Atkinson, R., "IP Encapsulating Security Payload",
RFC 1827, August 1995.
[RFC1949] Ballardie, A., "Scalable Multicast Key Distribution",
RFC1949, June 1996.
[RFC2085] Oehler, M., and R. Glenn, "HMAC-MD5 IP
with Replay Prevention", RFC 2085, February 1997.
Farinacci, et. al. Experimental [Page 6]
RFC 2337 IP multicast over ATM using PIM April 1998
[RFC2093] Harney, H., and C. Muckenhirn, "Group Key
Protocol (GKMP) Specification", RFC 2093, July 1997.
[RFC2094] Harney, H., and C. Muckenhirn, "Group Key
Protocol (GKMP) Architecture", RFC 2094, July 1997.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC:
Hashing for Message Authentication", RFC 2104,
1997.
[RFC2225] Laubach, M., and J. Halpern, "Classical IP and ARP
ATM", RFC 2225, April 1998.
8.
Petri Helenius provided several insightful comments on
versions of this document
9. Author
Dino
Cisco
170 Tasman Dr
San Jose, CA 95134
Phone: (408) 526-4696
EMail: dino@cisco.
David
Cisco
170 Tasman Dr
San Jose, CA 95134
Phone: (541) 687-2581
EMail: dmm@cisco.
Yakov
cisco Systems, Inc
170 Tasman Dr
San Jose, CA 95134
Phone: (914) 528-0090
EMail: yakov@cisco.
Farinacci, et. al. Experimental [Page 7]
RFC 2337 IP multicast over ATM using PIM April 1998
10. Full Copyright
Copyright (C) The Internet Society (1998). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Farinacci, et. al. Experimental [Page 8]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
