Network Working Group                                         G. Malkin
Request for Comments: 2701                              Nortel Networks
Category: Informational                                  September 1999
        
Network Working Group                                         G. Malkin
Request for Comments: 2701                              Nortel Networks
Category: Informational                                  September 1999
        

Nortel Networks Multi-link Multi-node PPP Bundle Discovery Protocol

北电网络多链路多节点PPP包发现协议

Status of this Memo

本备忘录的状况

This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.

本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。

Copyright Notice

版权公告

Copyright (C) The Internet Society (1999). All Rights Reserved.

版权所有(C)互联网协会(1999年)。版权所有。

Abstract

摘要

This document specifies a standard way for Multi-link PPP to operate across multiple nodes. Both the mechanism by which the Bundle Head is discovered and the PPP fragment encapsulation are specified.

本文件规定了多链路PPP跨多个节点运行的标准方式。指定了发现束头的机制和PPP片段封装。

Acknowledgements

致谢

I would like to thank Joe Frazier for filling in some of the details and reviewing this document.

我要感谢Joe Frazier填写了一些细节并审阅了此文档。

1. Introduction
1. 介绍

Multi-link PPP [MP] allows a dial-in user to open multiple PPP connections to a given host. In general, this is done on an on-demand basis. That is, a secondary link, or multiple secondary links, are established when the data load on the primary link, and any previously established secondary links, nears capacity. As the load decreases, the secondary link(s) may be disconnected.

多链路PPP[MP]允许拨入用户打开到给定主机的多个PPP连接。一般来说,这是按需完成的。也就是说,当主链路和任何先前建立的辅助链路上的数据负载接近容量时,建立辅助链路或多个辅助链路。随着负载降低,辅助链路可能会断开。

Many dial-in hosts which support multi-link PPP dial the same phone number for all links. This implies that there exists a rotary at the Point Of Presence (POP) which routes incoming calls to a bank of modems. These may be physically independent modems connected to Remote Access Server (RAS) and a rotary of analog phone lines, or a RAS with internal modems connected to analog lines or a T1/E1 or T3/E3 channel. In any case, a given RAS can only handle just so many simultaneous connections. A typical POP may need to support hundreds of connections, but no RAS today can handle that many. This creates a problem when a user's primary PPP connection is established to one

许多支持多链路PPP的拨入主机为所有链路拨相同的电话号码。这意味着在存在点(POP)存在一个转盘,它将传入呼叫路由到一组调制解调器。这些可以是物理上独立的调制解调器,连接到远程访问服务器(RAS)和一组模拟电话线,或者是带有内部调制解调器的RAS,连接到模拟线或T1/E1或T3/E3信道。在任何情况下,给定的RAS只能处理如此多的同时连接。一个典型的POP可能需要支持数百个连接,但目前没有一个RAS能够处理这么多。当用户的主PPP连接建立到一个PPP连接时,这会产生问题

RAS in a POP and a secondary connection is established to another. This may occur because the first RAS has no available modems, or because incoming calls are assigned to ports in a round-robin fashion, for example, and the second call is simply assigned to another RAS.

POP中的RAS和与另一个建立的辅助连接。这可能是因为第一个RAS没有可用的调制解调器,或者因为传入呼叫以循环方式分配给端口,而第二个呼叫只是分配给另一个RAS。

The solution to this problem is to provide a mechanism by which a RAS can determine if a Multi-link PPP connection is a primary or secondary and, if a secondary, where the Bundle Head (the process within a RAS which reassembles the PPP fragments transmitted over the primary and secondary links) resides. If the Bundle Head resides on a different RAS, a protocol must be used to transfer the PPP fragments to the RAS containing the Bundle Head so that the PPP frame can be reassembled.

该问题的解决方案是提供一种机制,通过该机制,RAS可以确定多链路PPP连接是主连接还是次连接,如果是次连接,则可以确定捆绑头(RAS中重新组装通过主链路和次链路传输的PPP片段的过程)所在的位置。如果捆绑头位于不同的RAS上,则必须使用协议将PPP片段传输到包含捆绑头的RAS,以便重新组装PPP帧。

Section 2 of this document specifies the Discovery Mechanism. Section 3 specifies the Transfer Protocol. Section 4 specifies the configuration parameters needed for the Discovery Protocol.

本文档第2节规定了发现机制。第3节规定了传输协议。第4节指定了发现协议所需的配置参数。

2. Bundle Head Discovery Mechanism
2. 束头发现机制

When a user dials into a RAS and negotiates Multi-link PPP (MP) during the Link Control Protocol (LCP) phase, the RAS must determine which one of the following three cases exists:

当用户拨入RAS并在链路控制协议(LCP)阶段协商多链路PPP(MP)时,RAS必须确定以下三种情况中的哪一种存在:

1- This is the primary (first) link of the MP connection. In this case, the RAS should create the Bundle Head.

1-这是MP连接的主(第一)链路。在这种情况下,RAS应创建束头。

2- This is a secondary link of the MP connection and the Bundle Head resides on this RAS. In this case, the RAS should add the link to the Bundle (standard MP).

2-这是MP连接的二级链路,捆绑头位于该RAS上。在这种情况下,RAS应该将链接添加到Bundle(标准MP)。

3- This is a secondary link of the MP connection and the Bundle Head resides on a different RAS. In this case, the RAS should establish a path (see section 3) to the RAS that has the Bundle Head, and use that path to transfer MP fragments.

3-这是MP连接的二级链路,捆绑头位于不同的RAS上。在这种情况下,RAS应该建立到具有束头的RAS的路径(参见第3节),并使用该路径传输MP片段。

In operation, a RAS will make the determination for case 2 first (because it is the easiest and requires no communication with other RASes. If the Bundle Head is not local, the Discovery Protocol is used to determine where the Bundle Head is, if it exists at all.

在操作中,RAS将首先确定情况2(因为这是最简单的,并且不需要与其他RAS通信。如果捆绑头不是本地的,则使用发现协议确定捆绑头的位置(如果它存在)。

2.1 Packet Format
2.1 数据包格式

See "IANA Considerations" (section 6) for UDP port number assignment.

有关UDP端口号分配,请参阅“IANA注意事项”(第6节)。

A Discovery Message has the following format:

发现消息具有以下格式:

      +------+------+------------+------+----======----+
      | type |length| random ID  | hash | endpoint ID  |
      +------+------+------------+------+----======----+
        
      +------+------+------------+------+----======----+
      | type |length| random ID  | hash | endpoint ID  |
      +------+------+------------+------+----======----+
        

where:

哪里:

type - 2 octets

2型八位组

Message type: 1-query, 2-response.

消息类型:1-查询,2-响应。

length - 2 octets

长度-2个八位字节

The length (in octets) of the endpoint ID.

端点ID的长度(以八位字节为单位)。

Random ID - 4 octets

随机ID-4八位组

A random identifier generated by the RAS used to resolve contention. See "Contention Handling" (section 2.4) for the use of this field.

由RAS生成的用于解决争用的随机标识符。有关此字段的使用,请参阅“争用处理”(第2.4节)。

hash - 2 octets

哈希-2八位字节

The unsigned sum (modulo 2^16) of the unsigned octets of the Endpoint ID. A value of zero indicates that no hash has been generated. See "Endpoint Identifier Matching" (section 2.2) for the use of this field.

端点ID的无符号八位字节的无符号和(模2^16)。值为零表示未生成哈希。有关此字段的使用,请参见“端点标识符匹配”(第2.2节)。

endpoint ID - variable length

端点ID-可变长度

The endpoint identifier of the connection. From the discovery protocol's point of view, this is an opaque value. However, to ensure multi-vendor interoperability, the format of this field must be defined. The descriptions of, and legal values for, the fields in the endpoint ID are defined in [MP].

连接的端点标识符。从发现协议的角度来看,这是一个不透明的值。但是,为了确保多供应商的互操作性,必须定义此字段的格式。[MP]中定义了端点ID中字段的描述和合法值。

         +------+------+--==--+------+------+--==--+------+--==--+
         |remote|remote|remote|local |local |local |user  | user |
         |EPD   |EPD   |EPD   |EPD   |EPD   |EPD   |name  | name |
         |class |length|data  |class |length|data  |length| data |
         +------+------+--==--+------+------+--==--+------+--==--+
        
         +------+------+--==--+------+------+--==--+------+--==--+
         |remote|remote|remote|local |local |local |user  | user |
         |EPD   |EPD   |EPD   |EPD   |EPD   |EPD   |name  | name |
         |class |length|data  |class |length|data  |length| data |
         +------+------+--==--+------+------+--==--+------+--==--+
        

Notes: EPD = EndPoint Descriminator. remote = dial-in host. local = RAS. class and length fields are 1-octet in length. data fields are of variable (including zero) length.

注:EPD=端点描述符。远程=拨入主机。本地=RAS。类和长度字段的长度为1-octet。数据字段的长度可变(包括零)。

The MP protocol requires that the RASes all have the same Local EPD. For MMP, this implies that a RAS may not use its IP or Ethernet address as an EPD. This also implies that all RASes on a rotary must have the same EPD. RASes on different rotaries may share different EPDs. The Local EPD is included in the endpoint identifier to ensure that RASes on different rotaries, but sharing a common Ethernet, will not join a particular discovery if the Remote EPDs just happen to be the same.

MP协议要求所有RASE都具有相同的本地EPD。对于MMP,这意味着RAS可能不会将其IP或以太网地址用作EPD。这也意味着一个扶轮社的所有扶轮社必须有相同的环保署。不同扶轮社的扶轮社员可能共用不同的EPD。端点标识符中包含本地EPD,以确保如果远程EPD恰好相同,则共享公共以太网的不同Rotary上的RASE不会加入特定发现。

Except for unicast Response Messages, all messages are sent to the multicast address specified in "IANA Considerations". If a system cannot send multicast messages, the limited broadcast address (255.255.255.255) should be used.

除单播响应消息外,所有消息都发送到“IANA注意事项”中指定的多播地址。如果系统无法发送多播消息,则应使用有限的广播地址(255.255.255.255)。

2.2 Endpoint Identifier Matching
2.2 端点标识符匹配

Comparing Endpoint IDs can be time consuming. First, the classes of the EPDs must be determined, then the values compared. These comparisons might be fast arithmetic compares or slow octet-wise compares of 20-octet long values. To improve performance, because the protocol is time-driven, the hash field may be used for a fast comparison.

比较端点ID可能非常耗时。首先,必须确定EPD的类别,然后比较值。这些比较可能是20个八位元长值的快速算术比较或慢速八位元比较。为了提高性能,因为协议是时间驱动的,所以可以使用散列字段进行快速比较。

When a Bundle Head is created, the hash is created and stored along with the Endpoint ID. When a Query or Response Message is generated, the hash is created and stored in the message. When a RAS receives a message, it can do a quick comparison of the hash in the message to the hashes in its tables. If a hash does not match, the Endpoint ID cannot match. However, if a hash does match, the Endpoint IDs must be properly compared to verify the match.

创建束头时,将创建散列并将其与端点ID一起存储。生成查询或响应消息时,将创建散列并将其存储在消息中。当RAS收到消息时,它可以将消息中的哈希值与其表中的哈希值进行快速比较。如果哈希不匹配,则端点ID无法匹配。但是,如果哈希不匹配,则必须正确比较端点ID以验证匹配。

Obviously, there is a cost associated with creating the hashes, but they are created only once per message and once for each Bundle Head creation. However, the comparisons occur multiple times in multiple RASes for each new secondary connection. Therefore, there is a net savings in processing.

显然,创建散列会带来一定的成本,但每个消息只创建一次散列,每个束头创建一次散列。但是,对于每个新的辅助连接,在多个RASE中多次进行比较。因此,在处理过程中有净节省。

2.3 Protocol Operation
2.3 协议操作

Throughout this section, configurable variables are specified by their names (e.g., ROBUSTNESS refers to the number of transmits).

在本节中,可配置变量由其名称指定(例如,稳健性指传输次数)。

The Discovery Protocol begins by multicasting ROBUSTNESS Query Messages at QUERY_INTERVAL intervals. If no Response Message for that Request is received within QUERY_INTERVAL of the last broadcast (a total time of ROBUSTNESS * QUERY_INTERVAL), the RAS assumes that this is the primary link and begins to build the Bundle Head. It then sends a multicast Response Message (in case another link comes up after the time-out but before the Bundle Head is built). If a Response Message is received (i.e., a Bundle Head exists on another RAS), no additional Query Messages are sent and the RAS establishes a path to the RAS containing the Bundle Head.

发现协议首先以查询间隔多播健壮性查询消息。如果在最后一次广播的查询间隔(健壮性的总时间*查询间隔)内未收到该请求的响应消息,则RAS假定这是主链路,并开始构建捆绑头。然后,它发送一条多播响应消息(以防在超时后但在构建束头之前出现另一条链路)。如果收到响应消息(即,另一个RAS上存在捆绑头),则不会发送额外的查询消息,RAS会建立到包含捆绑头的RAS的路径。

If a RAS receives a Query Message for an MP connection for which it has the Bundle Head, it sends a unicast Response Message to the querier. Note that no repetition of the Response Message is necessary because, if it is lost, the querier's next query message will trigger a new Response Message.

如果RAS接收到其具有捆绑头的MP连接的查询消息,它将向查询器发送单播响应消息。请注意,不需要重复响应消息,因为如果消息丢失,查询器的下一条查询消息将触发新的响应消息。

2.4 Contention Handling
2.4 争用处理

If, while sending Query Messages, a Query Message for the same MP connection is received, it indicates that the Dial-in Node has brought up multiple links simultaneously. The resolution to this contention is to elect the bundle head. To do this, each RAS waits until all Query Messages are sent (ROBUSTNESS * QUERY_INTERVAL). At that time, the RAS with the lowest Random ID becomes the Bundle Head. If two or more RASes have the same Random ID, the RAS with the lowest IP address becomes the Bundle Head. That RAS then sends TWO Response Messages, with a QUERY_INTERVAL interval, and indicates to the MP process that a Bundle Head should be formed. When the other RAS(es) receive the Response Message, they cease broadcasting (if they haven't already sent ROBUSTNESS Query Messages), stop listening for additional Response Messages, and indicate to their respective MP processes where the Bundle Head resides.

如果在发送查询消息时,收到同一MP连接的查询消息,则表示拨入节点已同时启动多个链路。解决这一争论的办法是选出捆绑头。为此,每个RAS等待所有查询消息发送(健壮性*查询间隔)。此时,随机ID最低的RAS成为束头。如果两个或多个RAS具有相同的随机ID,则IP地址最低的RAS将成为捆绑头。然后,RAS发送两条响应消息(带有查询间隔),并向MP进程指示应形成束头。当其他RA接收到响应消息时,它们停止广播(如果尚未发送健壮性查询消息),停止侦听其他响应消息,并向各自的MP进程指示捆绑头所在的位置。

Note that a RAS generates a Random ID for each connection and uses that value for all Query and Response messages associated with that connection. The same Random ID must not be reused until it can be

请注意,RAS为每个连接生成一个随机ID,并将该值用于与该连接关联的所有查询和响应消息。同一个随机ID在可以使用之前不得重复使用

guaranteed that another RAS will not mistake the message for an old message from a previous connection. For this reason, it is recommended that the Random ID be either monotonically increasing or a clock value (either time since boot or time of day).

保证另一个RAS不会将该消息误认为来自先前连接的旧消息。因此,建议随机ID为单调递增或时钟值(自启动后的时间或一天中的时间)。

2.5 MP Operation
2.5 MP操作

MP must use the following algorithm to ensure that there are no windows of vulnerability during which multiple Bundle Heads might be created for the same MP connection.

MP必须使用以下算法来确保没有漏洞窗口,在此期间可能会为同一MP连接创建多个捆绑头。

When an MP link is negotiated, MP first checks to see if it already has the Bundle Head for this connection (i.e., is this a secondary link). If it does, it should attach to it and not initiate a discovery. As an optimization, if MP does not have a Bundle Head for this connection, but does have a existing secondary link for it, MP should attach to the known Bundle Head without initiating discovery.

协商MP链路时,MP首先检查它是否已经具有此连接的捆绑头(即,这是一个辅助链路)。如果有,它应该附加到它,而不是启动发现。作为优化,如果MP没有用于此连接的捆绑头,但有用于此连接的现有辅助链路,则MP应连接到已知的捆绑头,而无需启动发现。

If MP knows of no Bundle Head for this connection, it should initiate a discovery. If the discovery should locate a Bundle Head, it should attach to the indicated bundle head. If no Bundle Head is found, MP should create a Bundle Head.

如果MP知道此连接没有捆绑头,则应启动发现。如果discovery应找到捆绑头,则应连接到指定的捆绑头。如果未找到捆绑头,MP应创建捆绑头。

When a RAS determines that it is to become the Bundle Head for a connection, it should establish the Bundle Head as quickly as possible so Query Messages for that connection from other RASes will be recognized. If a RAS indicates that it will become the Bundle Head, but delays establishment of it, other RASes may time out on their discovery and begin to establish additional Bundle Heads of their own.

当RAS确定它将成为连接的Bundle Head时,它应该尽快建立Bundle Head,以便识别来自其他RAS的该连接的查询消息。如果一个RAS指示它将成为捆绑头,但延迟了它的建立,其他RAS可能会在发现时超时,并开始建立自己的额外捆绑头。

3. Transfer Protocol
3. 传输协议

The Layer 2 Tunneling Protocol (L2TP) [L2TP] will be used to transfer PPP fragments from a RAS containing a secondary link to the RAS containing the Bundle Head. By specifying the use of an existing protocol, it is neither necessary to create nor implement a new protocol.

第2层隧道协议(L2TP)[L2TP]将用于将PPP片段从包含二级链路的RAS传输到包含束头的RAS。通过指定现有协议的使用,无需创建或实现新协议。

4. Configuration
4. 配置

There are two required configuration switches and one conditional configuration switch. None of the switches are optional.

有两个必需的配置开关和一个条件配置开关。这些开关都不是可选的。

4.1 Robustness - required
4.1 稳健性-必需

This switch sets the number of transmits (repetitions) for Query Messages. It may be set between 1 and 15. The default is 3. Be aware that lower settings may create windows of vulnerability. Higher settings may cause MP timeouts, but may be needed on very lossy or congested networks.

此开关设置查询消息的传输(重复)次数。它可以设置在1和15之间。默认值为3。请注意,较低的设置可能会创建漏洞窗口。较高的设置可能会导致MP超时,但在非常有损或拥挤的网络上可能需要。

4.2 Query Interval - required
4.2 查询间隔-必需

This switch sets the interval between Query Messages and the interval between multicast Response Messages. It should be calibrated in deciseconds (1/10 second) and may be set between 1 and 15. The default is 1. Be aware that higher settings may cause MP timeouts, but may be needed on very slow systems/networks.

此开关设置查询消息之间的间隔和多播响应消息之间的间隔。它应以分秒(1/10秒)为单位进行校准,并可设置在1到15之间。默认值为1。请注意,较高的设置可能会导致MP超时,但在速度非常慢的系统/网络上可能需要。

4.3 TTL - conditional
4.3 TTL-条件

This switch sets the IP Time-To-Live (TTL) of all Discovery packets. For systems which are using the limited broadcast address, this switch should not be implemented and the TTL should be set to 1. The default value should be 1.

此开关设置所有发现数据包的IP生存时间(TTL)。对于使用有限广播地址的系统,不应实施此开关,且TTL应设置为1。默认值应为1。

5. Security Considerations
5. 安全考虑

No security is designed into the Discovery Mechanism. When not forwarding multicast packets (or when using the limited broadcast address), the discovery packets are restricted to a single LAN. If the LAN is physically secure, there is no need for software security. If the multicast packets are forwarded, but the range is limited to a small, physically secure network (e.g., a POP), there is still no need for software security. If the discovery packets are allowed to cross an internet (and this is NOT recommended for timing reasons), authentication of RASes may be done with IPSEC. For increased security on a LAN, or in a POP, IPSEC may still be used.

发现机制中没有设计任何安全性。当不转发多播数据包时(或当使用有限的广播地址时),发现数据包仅限于单个LAN。如果局域网在物理上是安全的,就不需要软件安全。如果多播数据包被转发,但范围仅限于物理安全的小型网络(例如,POP),则仍然不需要软件安全。如果允许发现数据包跨internet(由于时间原因,不建议这样做),则可以使用IPSEC对RASE进行身份验证。为了提高LAN或POP上的安全性,仍可使用IPSEC。

L2TP security is discussed in [L2TP].

L2TP安全性在[L2TP]中进行了讨论。

6. IANA Considerations
6. IANA考虑

UDP port number: 581 Multicast address: 224.0.1.69

UDP端口号:581多播地址:224.0.1.69

7. References
7. 工具书类

[MP] Sklower, K., Lloyd, B., McGregor, G., Carr, D. and T. Coradetti, "The PPP Multilink Protocol (MP)", RFC 1990, August 1996.

[MP]Sklower,K.,Lloyd,B.,McGregor,G.,Carr,D.和T.Coradetti,“PPP多链路协议(MP)”,RFC 1990,1996年8月。

[L2TP] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G. and B. Palter, "Layer Two Tunneling Protocol "L2TP"", RFC 2661, August 1999.

[L2TP]汤斯利,W.,瓦伦西亚,A.,鲁本斯,A.,帕尔,G.,佐恩,G.和B.帕尔特,“第二层隧道协议”L2TP“,RFC 26611999年8月。

Author's Address

作者地址

Gary Scott Malkin Nortel Networks 11 Elizabeth Drive Chelmsford, MA 01824-4111

加里·斯科特·马尔金北电网络公司马萨诸塞州切姆斯福德伊丽莎白大道11号01824-4111

   Phone: +1 (978) 250-3635
   Email: gmalkin@nortelnetworks.com
        
   Phone: +1 (978) 250-3635
   Email: gmalkin@nortelnetworks.com
        

Full Copyright Statement

完整版权声明

Copyright (C) The Internet Society (1999). All Rights Reserved.

版权所有(C)互联网协会(1999年)。版权所有。

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.

本文件和其中包含的信息是按“原样”提供的,互联网协会和互联网工程任务组否认所有明示或暗示的保证,包括但不限于任何保证,即使用本文中的信息不会侵犯任何权利,或对适销性或特定用途适用性的任何默示保证。

Acknowledgement

确认

Funding for the RFC Editor function is currently provided by the Internet Society.

RFC编辑功能的资金目前由互联网协会提供。