RFC 2701

RFC 2701: Multi-link Multi-node PPP Bundle Discovery Protocol 🎀

okay bestie, so RFC 2701 was written by G. Malkin at Nortel Networks 🦋 It's Informational, which means it's sharing info, not setting a standard, and it's dated September 1999. The title page doesn't list anything it obsoletes or updates, so it's just vibing on its own ✨

Status of This Memo 💅

This memo gives info to 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 doc is about a standard way for Multi-link PPP to work across multiple nodes 🧚 It specifies both how the Bundle Head gets discovered and how the PPP fragment encapsulation works.

Acknowledgements 🫶

The author wants to thank Joe Frazier for filling in some of the details and reviewing this doc, bestie 💕

1. Introduction ✨

okay so Multi-link PPP [MP] lets a dial-in user open multiple PPP connections to a given host 🌈 Usually this is on-demand. A secondary link (or several) gets set up when the data load on the primary link, plus any secondary links already up, gets close to capacity. When the load drops, the secondary link(s) may be disconnected 💅

Lots of dial-in hosts that support MP dial the same phone number for every link. That means there's a rotary at the Point Of Presence (POP) that routes incoming calls to a bank of modems. These could be physically independent modems hooked up to a Remote Access Server (RAS) and a rotary of analog phone lines, or a RAS with internal modems on analog lines or a T1/E1 or T3/E3 channel. Either way, a RAS can only handle so many simultaneous connections. A typical POP may need to support hundreds of connections, but no RAS today can handle that many 😭 This gets messy when a user's primary PPP connection lands on one RAS in the POP and the secondary lands on another. That can happen because the first RAS has no free modems, or because calls get assigned to ports round-robin, so the second call just goes to a different RAS 🙈

The fix is a mechanism that lets a RAS figure out whether an MP connection is primary or secondary and, if it's secondary, where the Bundle Head is. The Bundle Head is the process inside a RAS that reassembles the PPP fragments sent over the primary and secondary links 🍓 If the Bundle Head is on a different RAS, a protocol must be used to move the PPP fragments over to the RAS holding the Bundle Head, so the PPP frame can get reassembled 👑

Section 2 covers the Discovery Mechanism. Section 3 covers the Transfer Protocol. Section 4 covers 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 three cases is happening 👀

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 is 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 is 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 checks case 2 first, because it's the easiest and doesn't need to talk to any other RASes 💖 If the Bundle Head isn't local, the Discovery Protocol is used to figure out where the Bundle Head is, if it exists at all 🦋

2.1 Packet Format 📦

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

A Discovery Message looks like this:

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

Here's what each field is:

• type, 2 octets: the message type. 1-query or 2-response.
• length, 2 octets: the length (in octets) of the endpoint ID.
• Random ID, 4 octets: a random identifier generated by the RAS to sort out contention. See "Contention Handling" (section 2.4) for how this field gets used 🎲
• hash, 2 octets: the unsigned sum (modulo 2^16) of the unsigned octets of the Endpoint ID. A value of zero means no hash has been generated. See "Endpoint Identifier Matching" (section 2.2) for how this field gets used ✨
• endpoint ID, variable length: the endpoint identifier of the connection. From the discovery protocol's point of view it's an opaque value. BUT to keep multi-vendor interop working, 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] 🧚

The endpoint ID is laid out like this:

   +------+------+--==--+------+------+--==--+------+--==--+
   |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 means EndPoint Descriminator.
• remote means the dial-in host.
• local means the RAS.
• The class and length fields are 1 octet each.
• The data fields are variable length (zero is allowed).

The MP protocol requires that all the RASes have the same Local EPD. For MMP, this means a RAS may not use its IP or Ethernet address as an EPD 💅 It also means that every RAS on a rotary must have the same EPD. RASes on different rotaries may use different EPDs. The Local EPD goes in the endpoint identifier so that RASes on different rotaries, but sharing a common Ethernet, won't join a particular discovery just because their Remote EPDs happen to match 🙅‍♀️

Except for unicast Response Messages, all messages go to the multicast address listed in "IANA Considerations". If a system can't send multicast messages, the limited broadcast address (255.255.255.255) should be used 📡

2.2 Endpoint Identifier Matching 🔍

Comparing Endpoint IDs can take forever ⏳ First you have to figure out the classes of the EPDs, then compare the values. These comparisons might be fast arithmetic, or slow octet-by-octet compares of 20-octet values. To speed things up (the protocol is time-driven, after all), the hash field may be used for a fast comparison ⚡

When a Bundle Head gets created, its hash is made and stored along with the Endpoint ID. When a Query or Response Message is generated, the hash is made and stored in the message. When a RAS receives a message, it can quickly compare the hash in the message to the hashes in its tables. If the hash doesn't match, the Endpoint ID can't match. But if the hash does match, the Endpoint IDs have to be properly compared to confirm it 🫶

Making the hashes costs something, but they only get made once per message and once per Bundle Head creation. The comparisons, though, happen many times across many RASes for every new secondary connection. So overall there's a net savings in processing 🌈

2.3 Protocol Operation 🎬

In this section, configurable variables are named (e.g., ROBUSTNESS is the number of transmits) 🔧

The Discovery Protocol starts by multicasting ROBUSTNESS Query Messages at QUERY_INTERVAL intervals. If no Response Message for that Request arrives within QUERY_INTERVAL of the last broadcast (a total time of ROBUSTNESS * QUERY_INTERVAL), the RAS assumes this is the primary link and starts building the Bundle Head. It then sends a multicast Response Message, just in case another link comes up after the time-out but before the Bundle Head is finished 💖 If a Response Message does come in (meaning a Bundle Head already exists on another RAS), no more Query Messages are sent and the RAS sets up a path to the RAS holding the Bundle Head 🦋

If a RAS gets a Query Message for an MP connection where it has the Bundle Head, it sends a unicast Response Message back to the querier. No need to repeat the Response Message, btw. If it gets lost, the querier's next query will trigger a new Response Message anyway 🙌

2.4 Contention Handling ⚔️

If a Query Message for the same MP connection arrives while a RAS is still sending its own Query Messages, it means the Dial-in Node brought up multiple links at the same time 😳 The fix is to elect a Bundle Head. Each RAS waits until all its Query Messages have been sent (ROBUSTNESS * QUERY_INTERVAL). At that point, 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 wins 👑 That RAS then sends TWO Response Messages, QUERY_INTERVAL apart, and tells the MP process that a Bundle Head should be formed. When the other RAS(es) get the Response Message, they stop broadcasting (if they haven't already sent ROBUSTNESS Query Messages), stop listening for more Response Messages, and tell their own MP processes where the Bundle Head is 🧚

Also, a RAS generates a Random ID for each connection and uses that same value for all the Query and Response messages tied to that connection. The same Random ID must not be reused until it can be guaranteed that another RAS won't mistake the message for an old one 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 so there are no windows of vulnerability where multiple Bundle Heads might get created for the same MP connection 🚨

When an MP link is negotiated, MP first checks whether 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 start a discovery. As an optimization, if MP doesn't have a Bundle Head for this connection but does have an existing secondary link for it, MP should attach to the known Bundle Head without starting discovery 💅

If MP knows of no Bundle Head for this connection, it should start a discovery. If the discovery finds a Bundle Head, MP should attach to the indicated Bundle Head. If no Bundle Head is found, MP should create one 🌸

When a RAS decides it's going to become the Bundle Head for a connection, it should set up the Bundle Head as quickly as possible, so Query Messages for that connection from other RASes get recognized. If a RAS says it will become the Bundle Head but waits to set it up, other RASes may time out on their discovery and start creating extra Bundle Heads of their own 😭

3. Transfer Protocol ✨

okay so the Layer 2 Tunneling Protocol (L2TP) [L2TP] is what gets used to carry PPP fragments from a RAS that has a secondary link over to the RAS holding the Bundle Head 🚀 and bestie, the genius part is that we're just reusing an existing protocol, so nobody has to create or implement something brand new 🧚💜

4. Configuration ⚙️

there are two required configuration switches and one conditional configuration switch 🎀 none of the switches are optional, no cap 💅

4.1. Robustness - required 🛡️

this switch sets the number of transmits (repetitions) for Query Messages 🔁 it can be set between 1 and 15, and the default is 3 ✨ heads up: lower settings may create windows of vulnerability 👀 higher settings may cause MP timeouts, but they might 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 can be set between 1 and 15, with the default being 1 🍓 be aware that higher settings may cause MP timeouts, but they may be needed on very slow systems or networks 🐢

Wait, I need to correct that. The original says "It should be calibrated," and the key word there must stay exactly as written. Here is the corrected passage:

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 can be set between 1 and 15, with the default being 1 🍓 be aware that higher settings may cause MP timeouts, but they may be needed on very slow systems or networks 🐢

4.3. TTL - conditional 🌐

this switch sets the IP Time-To-Live (TTL) of all Discovery packets 📦 for systems that 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 the discovery packets are not forwarded as multicast (or when the limited broadcast address is used), they 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

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

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. ✨