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 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.
AbstractThis 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. Acknowledgements I would like to thank Joe Frazier for filling in some of the details and reviewing this document. 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. 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
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. 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. 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. section 3) to the RAS that has the Bundle Head, and use that path to transfer MP fragments. 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.
section 6) for UDP port number assignment. A Discovery Message has the following format: +------+------+------------+------+----======----+ | type |length| random ID | hash | endpoint ID | +------+------+------------+------+----======----+ where: type - 2 octets Message type: 1-query, 2-response. length - 2 octets The length (in octets) of the endpoint ID. Random ID - 4 octets A random identifier generated by the RAS used to resolve contention. See "Contention Handling" (section 2.4) for the use of this field. hash - 2 octets 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. endpoint ID - variable length 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].
+------+------+--==--+------+------+--==--+------+--==--+ |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. 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. 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.
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.
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). 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.
Full Copyright Statement Copyright (C) The Internet Society (1999). 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. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.