summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc2337.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc2337.txt')
-rw-r--r--doc/rfc/rfc2337.txt451
1 files changed, 451 insertions, 0 deletions
diff --git a/doc/rfc/rfc2337.txt b/doc/rfc/rfc2337.txt
new file mode 100644
index 0000000..c86a686
--- /dev/null
+++ b/doc/rfc/rfc2337.txt
@@ -0,0 +1,451 @@
+
+
+
+
+
+
+Network Working Group D. Farinacci
+Request for Comments: 2337 Cisco Systems
+Category: Experimental D. Meyer
+ Cisco Systems
+ Y. Rekhter
+ Cisco Systems
+ April 1998
+
+
+ Intra-LIS IP multicast among routers over ATM using Sparse Mode PIM
+
+Status of this Memo
+
+ This memo defines an Experimental Protocol for the Internet
+ 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 Notice
+
+ Copyright (C) The Internet Society (1998). All Rights Reserved.
+
+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.
+
+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.
+
+
+
+
+
+
+
+
+
+
+Farinacci, et. al. Experimental [Page 1]
+
+RFC 2337 IP multicast over ATM using PIM April 1998
+
+
+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 [RFC2225], or by
+ any other means (e.g., static configuration).
+
+ Each PIM router within a LIS is required to maintain a single
+ (shared) point-to-multipoint distribution VC rooted at the router
+ with all other PIM routers in the LIS as the leaf nodes. 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).
+
+ In addition, if a PIM router receives a IGMP report from an non-PIM
+ neighbor, then the router may add the reporter to the existing shared
+ distribution VC or to the group specific distribution VC (if it
+ exists). The PIM router may also create a specific VC for this IGMP
+ proxy.
+
+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 or IGMP report messages
+ from another device in the same LIS. When a router that is the root
+ 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 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).
+
+ Note that it is possible for a non-PIM router in the LIS to fail to
+ receive data if the injection point moves to router to which there is
+ not an existing VC.
+
+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.
+
+
+
+
+
+
+
+
+
+
+
+Farinacci, et. al. Experimental [Page 3]
+
+RFC 2337 IP multicast over ATM using PIM April 1998
+
+
+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.
+
+
+
+
+
+
+
+
+
+
+
+Farinacci, et. al. Experimental [Page 4]
+
+RFC 2337 IP multicast over ATM using PIM April 1998
+
+
+6. Security Considerations
+
+ In general, the security issues relevant to the proposal outlined in
+ the memo are subsumed by those faced by PIM-SM. While work in
+ proceeding on security for PIM-SM, it is worthwhile noting that
+ several issues have been raised in conjunction with multicast routing
+ and with PIM-SM in particular. These issues include but are not
+ limited to:
+
+ (i). Unauthorized Senders
+
+ (ii). Unauthorized Receivers
+
+ (iii). Unauthorized use of the RP
+
+ (iv). Unauthorized "last hop" switching to shortest path
+ tree.
+
+6.1. General Comments on Multicast Routing Protocol Security
+
+ Historically, routing protocols used within the Internet have lacked
+ strong authentication mechanisms [RFC1704]. In the late 1980s,
+ analysis revealed that there were a number of security problems in
+ Internet routing protocols then in use [BELLOVIN89]. During the
+ early 1990s it became clear that adversaries were selectively
+ attacking various intra-domain and inter-domain routing protocols
+ (e.g. via TCP session stealing of BGP sessions) [CERTCA9501,
+ RFC1636]. More recently, cryptographic authentication mechanisms have
+ been developed for RIPv2, OSPF, and the proprietary EIGRP routing
+ protocols. BGP protection, in the form of a Keyed MD5 option for
+ TCP, has also become widely deployed.
+
+ At present, most multicast routing protocols lack strong
+ cryptographic protection. One possible approach to this is to
+ incorporate a strong cryptographic protection mechanism (e.g. Keyed
+ HMAC MD5 [RFC2104]) within the routing protocol itself. Alternately,
+ the routing protocol could be designed and specified to use the IP
+ Authentication Header (AH) [RFC1825, RFC1826, RFC2085] to provide
+ cryptographic authentication.
+
+ Because the intent of any routing protocol is to propagate routing
+ information to other parties, confidentiality is not generally
+ required in routing protocols. In those few cases where local
+ security policy might require confidentiality, the use of the IP
+ Encapsulating Security Payload (ESP) [RFC1825, RFC1827] is
+ 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 area
+ at this time. Candidate technologies for scalable dynamic multicast
+ key management include CBT-based key management [RFC1949] and the
+ Group Key Management Protocol (GKMP) [RFC2093,RFC2094]. The IETF IP
+ Security Working Group is actively working on GKMP extensions to the
+ standards-track ISAKMP key management protocol being developed in the
+ same working group.
+
+7. References
+
+ [BELLOVIN89] S. Bellovin, "Security Problems in the TCP/IP
+ Protocol Suite", ACM Computer Communications Review,
+ Volume 19, Number 2, pp. 32-48, April 1989.
+
+ [CERTCA9501] CERT, "IP Spoofing Attacks and Hijacked Terminal
+ 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 Multicast
+ Sparse Mode (PIM-SM): Protocol Specification", Work in
+ Progress.
+
+ [RFC1636] Braden, R., Clark, D., Crocker, S., and C. Huitema,
+ "Report of IAB Workshop on Security in the Internet
+ Architecture February 8-10, 1994", RFC 1636, June 1994.
+
+ [RFC1704] Haller, N., and R. Atkinson, "On Internet
+ 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 Authentication
+ 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 Management
+ Protocol (GKMP) Specification", RFC 2093, July 1997.
+
+ [RFC2094] Harney, H., and C. Muckenhirn, "Group Key Management
+ Protocol (GKMP) Architecture", RFC 2094, July 1997.
+
+ [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed
+ Hashing for Message Authentication", RFC 2104, February
+ 1997.
+
+ [RFC2225] Laubach, M., and J. Halpern, "Classical IP and ARP over
+ ATM", RFC 2225, April 1998.
+
+8. Acknowledgments
+
+ Petri Helenius provided several insightful comments on earlier
+ versions of this document.
+
+9. Author Information
+
+ Dino Farinacci
+ Cisco Systems
+ 170 Tasman Dr.
+ San Jose, CA 95134
+
+ Phone: (408) 526-4696
+ EMail: dino@cisco.com
+
+
+ David Meyer
+ Cisco Systems
+ 170 Tasman Dr.
+ San Jose, CA 95134
+
+ Phone: (541) 687-2581
+ EMail: dmm@cisco.com
+
+
+ Yakov Rekhter
+ cisco Systems, Inc.
+ 170 Tasman Dr.
+ San Jose, CA 95134
+
+ Phone: (914) 528-0090
+ EMail: yakov@cisco.com
+
+
+
+
+
+
+Farinacci, et. al. Experimental [Page 7]
+
+RFC 2337 IP multicast over ATM using PIM April 1998
+
+
+10. Full Copyright Statement
+
+ Copyright (C) The Internet Society (1998). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Farinacci, et. al. Experimental [Page 8]
+