Network Working Group D. Farinacci
Request for Comments: 2337 Cisco Systems
Category: Experimental D. Meyer
Cisco Systems
Y. Rekhter
Cisco Systems
April 1998
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
基于稀疏模式PIM的ATM路由器间LIS内IP组播
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.
版权所有（C）互联网协会（1998年）。版权所有。
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.
本文档描述了如何在不使用多播地址解析服务器（MARS）的情况下，通过ATM在路由器之间有效地支持LIS内部IP多播。这里描述的方法特定于稀疏模式PIM[PIM-SM]，并且依赖于PIM-SM中固有的显式连接机制来通知路由器何时应该创建组特定的点对多点VCs。
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.
本文档重点介绍连接到ATM网络的PIM-SM路由器之间的多播流量转发。ATM网络上的路由器被划分为逻辑IP子网或LIS。本文档介绍如何在单个LIS中处理多播。处理LIS间多播通信，包括处理快捷方式，不在本文档范围内。此外，本文件不涉及连接到ATM网络的主机之间的多播流量转发。
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).
本文件要求LIS中的每个路由器都知道LIS中所有其他路由器的IP和ATM地址。IP和ATM地址之间的映射可由ARP服务器[RFC2225]或任何其他方式（例如，静态配置）提供。
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).
LIS中的每个PIM路由器都需要维护一个以路由器为根的单（共享）点对多点分布VC，并将LIS中的所有其他PIM路由器作为叶节点。VC预计将用于在LIS内的路由器之间转发多播流量（数据和控制）。例如，此VC将用于分发PIM[PIM-SM]控制消息（加入/删除消息）。
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.
此外，如果PIM路由器接收到来自非PIM邻居的IGMP报告，则路由器可以将报告器添加到现有共享分发VC或组特定分发VC（如果存在）。PIM路由器也可以为此IGMP代理创建特定的VC。
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).
路由器还可以维护特定于组的专用点对多点VCs。具体地，组的上游路由器可以选择成为组特定点对多点VC的根，其叶子是直接连接到组的下游路由器或组的下游接收器。虽然建立特定于组的点对多点VC的标准是路由器的本地标准，但应考虑与组相关的通信量和LIS内的扇出系数等问题。最后，请注意，路由器必须最低限度地支持单个共享点对多点VC，以便（向所有组地址）分发控制消息和数据。
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.
当路由器从同一LIS中的另一设备接收到PIM连接或IGMP报告消息时，可以选择建立专用点对多点VC（或将另一个叶添加到已建立的专用点对多点VC）。当作为点对多点VC根的路由器接收到PIM Prune消息或IGMP LEVE时，它会将消息的发起人从其专用点对多点VC中删除。
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).
如果LIS中至少有一个路由器决定切换到源根树（通过发送（S，G）PIM联接），则LIS中具有G下游成员的所有其他路由器也应切换到该源根树。由于切换到源根树的路由器通过其共享点对多点VC发送（S，G）的PIM连接消息，LIS中的其他路由器能够检测到这一点。一旦具有G下游成员的路由器检测到这一点，路由器也应该发送（S，G）PIM Join消息（否则路由器可能会从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.
请注意，如果注入点移动到不存在VC的路由器，则LIS中的非PIM路由器可能无法接收数据。
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:
如上所述，本文件要求，一旦LIS中的一个路由器决定为某些（S，G）切换到源树，LIS中具有下游成员的所有路由器也必须切换到（S，G）源树。现在，当一个新路由器想要接收来自G的流量时，它开始向G的RP发送共享点对多点VC上的（*，G）-连接。（s，G）-源根树的根将知道通过观察（*，G）将新路由器添加到服务于（s，G）-源根树的点对多点VC-连接到它的共享点对多点VC。然而，新路由器还必须切换到（S，G）源根树。为了实现这一点，新添加的路由器必须：
(i). Notice that it has been added to a new point-to-multipoint VC
（i） 。请注意，它已添加到新的点对多点VC
(ii). Notice (S,G) traffic coming down this new point-to-multipoint VC
(ii)。请注意（S，G）流量从这个新的点对多点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.
(iii)。向S发送（S，G）连接，使其切换到源根目录树。路由器了解到VC在前面的步骤中用于分配（S，G）流量。
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.
当路由器在其自己的LIS中从另一个路由器接收多播数据包时，路由器不应在任何路由器分发点向与LIS关联的多点VCs发送数据包。这消除了“包反射”的问题。在与其他LIS关联的路由器分发VCs上发送数据包由多播路由过程控制。
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.
本文档中描述的LIS内多播方案旨在成为多播地址解析服务器（MARS）提供的功能的重要子集的较不复杂的解决方案。特别地，它被设计为在使用PIM-SM的路由器之间提供内部LIS组播，并且不考虑主机根点到多播多播分发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).
尽管MARS支持将IP多播服务模型映射到ATM（多播服务器和点对多点VCs的网格）的两种当前方案，但其成本和复杂性都高于本文所述方案。此外，MARS需要新的封装，而本提案可用于LLC/SNAP或NLPID封装。另一个重要的区别是MARS允许在源或多播服务器（MCS）上建立点对多点VCs。这里采用的方法是通过关注PIM-SM（利用显式连接中可用的信息）和允许点对多点VCs仅在路由器上生根（这大致类似于在源处生根点对多点VCs的复杂性和功能性）来限制复杂性。
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.
总之，本文中描述的方法是针对路由器到路由器的情况设计的，并利用PIM-SM中固有的显式连接机制，为路由器之间的LIS内多播提供了一种简单的机制。另一方面，MARS在复杂功能设计空间中接受不同的权衡。特别是，尽管MARS范例提供了一种通用的邻居发现机制，允许主机参与，并且与协议无关，但它这样做的成本相当高。
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:
一般而言，备忘录中概述的与提案相关的安全问题属于PIM-SM面临的问题。在继续研究PIM-SM的安全性时，值得注意的是，在多播路由方面，特别是在PIM-SM方面，已经提出了几个问题。这些问题包括但不限于：
(i). Unauthorized Senders
（i） 。未经授权的发件人
(ii). Unauthorized Receivers
(ii)。未经授权的接收者
(iii). Unauthorized use of the RP
(iii)。未经授权使用RP
(iv). Unauthorized "last hop" switching to shortest path tree.
(四)。未经授权的“最后一跳”切换到最短路径树。
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.
从历史上看，互联网中使用的路由协议缺乏强大的身份验证机制[RFC1704]。在20世纪80年代末，分析显示当时使用的互联网路由协议存在许多安全问题[BELLOVIN89]。在20世纪90年代早期，很明显，对手有选择地攻击各种域内和域间路由协议（例如，通过TCP会话窃取BGP会话）[CERTCA9501，RFC1636]。最近，为RIPv2、OSPF和专有EIGRP路由协议开发了加密身份验证机制。BGP保护，以TCP键控MD5选项的形式，也得到了广泛部署。
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.
目前，大多数组播路由协议缺乏强大的密码保护。一种可能的方法是在路由协议本身中加入强大的密码保护机制（例如，密钥HMAC MD5[RFC2104]）。或者，路由协议可以被设计和指定为使用IP认证头（AH）[RFC1825，RFC1826，RFC2085]来提供加密认证。
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.
因为任何路由协议的目的都是将路由信息传播给其他方，所以在路由协议中通常不需要保密。在本地安全策略可能需要保密的少数情况下，建议使用IP封装安全负载（ESP）[RFC1825，RFC1827]。
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.
可伸缩的动态组播密钥管理是当前一个活跃的研究领域。可伸缩动态多播密钥管理的候选技术包括基于CBT的密钥管理[RFC1949]和组密钥管理协议（GKPP）[RFC2093，RFC2094]。IETF IP安全工作组正在积极致力于对同一工作组正在开发的ISAKMP密钥管理协议的标准轨道进行GKP扩展。
[BELLOVIN89] S. Bellovin, "Security Problems in the TCP/IP Protocol Suite", ACM Computer Communications Review, Volume 19, Number 2, pp. 32-48, April 1989.
[BELLOVIN89]S.Bellovin，“TCP/IP协议套件中的安全问题”，ACM计算机通信评论，第19卷，第2期，第32-48页，1989年4月。
[CERTCA9501] CERT, "IP Spoofing Attacks and Hijacked Terminal Connections", ftp://ftp.cert.org/cert_advisories/, January 1995.
[CERTCA9501]证书，“IP欺骗攻击和被劫持的终端连接”，ftp://ftp.cert.org/cert_advisories/，1995年1月。
[MARS] Armitage, G., "Support for Multicast over UNI 3.0/3.1 based ATM Networks.", RFC 2022, November 1996.
[MARS]Armitage，G.“支持基于UNI 3.0/3.1的ATM网络上的多播”，RFC 2022，1996年11月。
[PIM-SM] Estrin, D, et. al., "Protocol Independent Multicast Sparse Mode (PIM-SM): Protocol Specification", Work in Progress.
[PIM-SM]Estrin，D，等，“协议独立多播稀疏模式（PIM-SM）：协议规范”，正在进行的工作。
[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.
[RFC1636]Braden，R.，Clark，D.，Crocker，S.，和C.Huitema，“IAB互联网体系结构安全研讨会报告，1994年2月8日至10日”，RFC 1636，1994年6月。
[RFC1704] Haller, N., and R. Atkinson, "On Internet Authentication", RFC 1704, October 1994.
[RFC1704]Haller，N.和R.Atkinson，“互联网认证”，RFC17041994年10月。
[RFC1825] Atkinson, R., "IP Security Architecture", RFC 1825, August 1995.
[RFC1825]阿特金森，R.，“IP安全架构”，RFC18251995年8月。
[RFC1826] Atkinson, R., "IP Authentication Header", RFC 1826, August 1995.
[RFC1826]阿特金森，R.，“IP认证头”，RFC18261995年8月。
[RFC1827] Atkinson, R., "IP Encapsulating Security Payload", RFC 1827, August 1995.
[RFC1827]阿特金森，R.，“IP封装安全有效载荷”，RFC18271995年8月。
[RFC1949] Ballardie, A., "Scalable Multicast Key Distribution", RFC1949, June 1996.
[RFC1949]Ballardie，A.，“可伸缩多播密钥分发”，RFC1949，1996年6月。
[RFC2085] Oehler, M., and R. Glenn, "HMAC-MD5 IP Authentication with Replay Prevention", RFC 2085, February 1997.
[RFC2085]Oehler，M.和R.Glenn，“具有重放预防的HMAC-MD5 IP认证”，RFC 2085，1997年2月。
[RFC2093] Harney, H., and C. Muckenhirn, "Group Key Management Protocol (GKMP) Specification", RFC 2093, July 1997.
[RFC2093]Harney，H.和C.Muckenhirn，“组密钥管理协议（GKPP）规范”，RFC 2093，1997年7月。
[RFC2094] Harney, H., and C. Muckenhirn, "Group Key Management Protocol (GKMP) Architecture", RFC 2094, July 1997.
[RFC2094]Harney，H.和C.Muckenhirn，“组密钥管理协议（GKP）体系结构”，RFC 2094，1997年7月。
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed Hashing for Message Authentication", RFC 2104, February 1997.
[RFC2104]Krawczyk，H.，Bellare，M.，和R.Canetti，“HMAC：用于消息认证的键控哈希”，RFC 2104，1997年2月。
[RFC2225] Laubach, M., and J. Halpern, "Classical IP and ARP over ATM", RFC 2225, April 1998.
[RFC2225]Laubach，M.和J.Halpern，“ATM上的经典IP和ARP”，RFC 2225，1998年4月。
Petri Helenius provided several insightful comments on earlier versions of this document.
Petri Helenius就本文件的早期版本提供了一些有见地的评论。
Dino Farinacci Cisco Systems 170 Tasman Dr. San Jose, CA 95134
迪诺·法里纳奇思科系统170塔斯曼博士，加利福尼亚州圣何塞，邮编95134
Phone: (408) 526-4696 EMail: dino@cisco.com
电话：（408）526-4696电子邮件：dino@cisco.com
David Meyer Cisco Systems 170 Tasman Dr. San Jose, CA 95134
David Meyer Cisco Systems 170加利福尼亚州圣何塞塔斯曼博士，邮编95134
Phone: (541) 687-2581 EMail: dmm@cisco.com
电话：（541）687-2581电子邮件：dmm@cisco.com
Yakov Rekhter cisco Systems, Inc. 170 Tasman Dr. San Jose, CA 95134
雅科夫·雷克特思科系统公司，170塔斯曼博士，加利福尼亚州圣何塞市，邮编95134
Phone: (914) 528-0090 EMail: yakov@cisco.com
电话：（914）528-0090电子邮件：yakov@cisco.com
Copyright (C) The Internet Society (1998). All Rights Reserved.
版权所有（C）互联网协会（1998年）。版权所有。
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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。