From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc2701.txt | 507 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 507 insertions(+) create mode 100644 doc/rfc/rfc2701.txt (limited to 'doc/rfc/rfc2701.txt') diff --git a/doc/rfc/rfc2701.txt b/doc/rfc/rfc2701.txt new file mode 100644 index 0000000..59fa82e --- /dev/null +++ b/doc/rfc/rfc2701.txt @@ -0,0 +1,507 @@ + + + + + + +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. + +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. + +Acknowledgements + + I would like to thank Joe Frazier for filling in some of the details + and reviewing this document. + +1. Introduction + + 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. + + 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 + + + +Malkin Informational [Page 1] + +RFC 2701 MMP September 1999 + + + 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. + +2. Bundle Head Discovery Mechanism + + 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: + + 1- This is the primary (first) link of the MP connection. In this + case, the RAS should create the Bundle Head. + + 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). + + 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. + + 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. + + + + + + + + + + +Malkin Informational [Page 2] + +RFC 2701 MMP September 1999 + + +2.1 Packet Format + + See "IANA Considerations" (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]. + + + + + + + + + + + +Malkin Informational [Page 3] + +RFC 2701 MMP September 1999 + + + +------+------+--==--+------+------+--==--+------+--==--+ + |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. + +2.2 Endpoint Identifier Matching + + 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. + + 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. + + + + + + + + +Malkin Informational [Page 4] + +RFC 2701 MMP September 1999 + + + 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. + +2.3 Protocol Operation + + 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. + + 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. + +2.4 Contention Handling + + 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. + + 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 + + + +Malkin Informational [Page 5] + +RFC 2701 MMP September 1999 + + + 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). + +2.5 MP Operation + + 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. + + 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. + + 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. + + 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. + +3. Transfer Protocol + + 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. + +4. Configuration + + There are two required configuration switches and one conditional + configuration switch. None of the switches are optional. + + + + + + + + +Malkin Informational [Page 6] + +RFC 2701 MMP September 1999 + + +4.1 Robustness - required + + 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. + +4.2 Query Interval - required + + 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. + +4.3 TTL - conditional + + 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. + +5. Security Considerations + + 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. + + L2TP security is discussed in [L2TP]. + +6. IANA Considerations + + UDP port number: 581 + Multicast address: 224.0.1.69 + + + + + + + + + +Malkin Informational [Page 7] + +RFC 2701 MMP September 1999 + + +7. References + + [MP] Sklower, K., Lloyd, B., McGregor, G., Carr, D. and + T. Coradetti, "The PPP Multilink Protocol (MP)", RFC 1990, + August 1996. + + [L2TP] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G. + and B. Palter, "Layer Two Tunneling Protocol "L2TP"", RFC + 2661, August 1999. + +Author's Address + + Gary Scott Malkin + Nortel Networks + 11 Elizabeth Drive + Chelmsford, MA 01824-4111 + + Phone: +1 (978) 250-3635 + Email: gmalkin@nortelnetworks.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Malkin Informational [Page 8] + +RFC 2701 MMP September 1999 + + +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. + + + + + + + + + + + + + + + + + + + +Malkin Informational [Page 9] + -- cgit v1.2.3