RFC 1990

The PPP Multilink Protocol (MP)

📅 published August 1996, from ietf

RFC 1990 is a Standards Track doc from the Network Working Group, dated August 1996. It obsoletes RFC 1717, the older PPP Multilink spec, so this one takes its place 🔄. K. Sklower is from the University of California, Berkeley 🎓. B. Lloyd and G. McGregor are listed with Lloyd Internetworking 🌐. D. Carr is from Newbridge Networks Corporation 🦋, and T. Coradetti is from Sidewalk Software 💜. What a team 👑.

Status of This Memo ✨

Okay bestie, first things first 🫶. This doc specifies an Internet standards track protocol for the Internet community, and it's literally asking for discussion and suggestions for improvements 💅. To check the standardization state and status of this protocol, look at the current edition of the "Internet Official Protocol Standards" (STD 1). And the best part? Distribution of this memo is unlimited 🌈, so share it with everyone.

Abstract 🦋

Okay so this doc proposes a method for splitting, recombining and sequencing datagrams across multiple logical data links 🔥. It was originally motivated by wanting to use multiple bearer channels in ISDN, but it's just as useful in any situation where multiple PPP links connect two systems, including async links 💖. The whole thing is done with new PPP [2] options and protocols.

The differences between the current PPP Multilink specification (RFC 1717) and this memo are explained in Section 11. Any system implementing the additional restrictions required by this memo will be backwards compatible with conforming RFC 1717 implementations ✅.

Acknowledgements 🧚

The authors want to give a huge shoutout to Fred Baker of ACC, Craig Fox of Network Systems, Gerry Meyer of Spider Systems, Dan Brennan of Penril Datability Networks, and Vernon Schryver of SGI (for the comprehensive discussion of padding) 🙌. They also thank the members of the IP over Large Public Data Networks and PPP Extensions working groups for all the useful discussion 🫶.

Table of Contents 📋

   1. Introduction ................................................    2
   1.1. Motivation ................................................    2
   1.2. Functional Description ....................................    3
   1.3. Conventions ...............................................    4
   2. General Overview ............................................    4
   3. Packet Formats ..............................................    7
   3.1. Padding Considerations ....................................   10
   4. Trading Buffer Space Against Fragment Loss ..................   10
   4.1. Detecting Fragment Loss ...................................   11
   4.2. Buffer Space Requirements .................................   12
   5. PPP Link Control Protocol Extensions ........................   13
   5.1. Configuration Option Types ................................   13
   5.1.1. Multilink MRRU LCP option ...............................   14
   5.1.2. Short Sequence Number Header Format Option ..............   15
   5.1.3. Endpoint Discriminator Option ...........................   15
   6. Initiating use of Multilink Headers .........................   19
   7. Closing Member links ........................................   20
   8. Interaction with Other Protocols ............................   20
   9. Security Considerations .....................................   21
   10. References .................................................   21
   11. Differences from RFC 1717 ..................................   22
   11.1. Negotiating Multilink, per se ............................   22
   11.2. Initial Sequence Number defined ..........................   22
   11.3. Default Value of the MRRU ................................   22
   11.4. Config-Nak of EID prohibited .............................   22
   11.5. Uniformity of Sequence Space .............................   22
   11.6. Commencing and Abating use of Multilink Headers ..........   23
   11.7. Manual Configuration and Bundle Assignment ...............   23
   12. Authors' Addresses .........................................   24

1. Introduction ✨

1.1. Motivation 💡

Basic Rate and Primary Rate ISDN both let you open multiple simultaneous channels between systems, so users get extra bandwidth on demand (for extra cost, obvs) 💸. Earlier proposals for carrying internet protocols over ISDN listed using this as a goal, e.g., Leifer et al., [1] 🙌.

There are proposals for syncing multiple streams at the bit level (the BONDING proposals) 🔗. But those aren't widely deployed yet, and they may need additional hardware for the end system. So a purely software solution, or at least an interim measure, could be useful 🌸.

There are other places where bandwidth on demand is handy 🍓. For example, you can use a dialup async line at 28,800 baud to back up a leased synchronous line, or open additional X.25 SVCs where the window size is limited to two by international agreement.

The simplest possible algorithm, alternating packets between channels on a space available basis (which might be called the Bank Teller's algorithm) 🏦, may have undesirable side effects due to reordering of packets 💀.

By using a four-byte sequencing header and simple synchronization rules, you can split packets among parallel virtual circuits between systems so that packets don't get reordered, or at least the chance of it is greatly reduced 💅.

1.2. Functional Description 🎀

The method here is similar to the multilink protocol described in ISO 7776 [4], but it adds the ability to split and recombine packets. That reduces latency and can potentially increase the effective maximum receive unit (MRU) 📈. Also, there's no requirement here for acknowledged-mode operation on the link layer, although that is optionally permitted 🙈.

Multilink is based on an LCP option negotiation that lets a system tell its peer it's capable of combining multiple physical links into a "bundle" 🧶. Only under exceptional conditions would a given pair of systems need more than one bundle connecting them 👀.

Multilink is negotiated during the initial LCP option negotiation. A system tells its peer it's willing to do multilink by sending the multilink option as part of that initial LCP option negotiation. This negotiation indicates three things:

  1. The system offering the option is capable of combining multiple physical links into one logical link;
  2. The system is capable of receiving upper layer protocol data units (PDU) fragmented using the multilink header (described later) and reassembling the fragments back into the original PDU for processing;
  3. The system is capable of receiving PDUs of size N octets where N is specified as part of the option even if N is larger than the maximum receive unit (MRU) for a single physical link.

Once multilink has been successfully negotiated, the sending system is free to send PDUs encapsulated and/or fragmented with the multilink header 🎉.

1.3. Conventions 📚

Here's the decoder ring for the capital words, because they're doing a LOT 🔑. The following language conventions are used in the items of specification in this document:

  • MUST, SHALL or MANDATORY -- the item is an absolute requirement of the specification. 😤
  • SHOULD or RECOMMENDED -- the item should generally be followed for all but exceptional circumstances. 🤝
  • MAY or OPTIONAL -- the item is truly optional and may be followed or ignored according to the needs of the implementor. 🫧

2. General Overview ✨

Okay so bestie, first things first: to get two systems talking over a point-to-point link, each end has to send LCP packets to set up the data link during the Link Establishment phase 🎀 Once the link is up, PPP gives you an Authentication phase where the authentication protocols can figure out the identifiers tied to each system on the link 🔐

Now the fun part, multilink! 🦋 The goal is to coordinate several independent links between a fixed pair of systems so you get one virtual link with more bandwidth than any single member. That combined link (the bundle) is named by the pair of identifiers for the two systems. A system identifier can include info from PPP Authentication [3] and info from LCP negotiation. The bundled links can be totally different physical links, like multiple async lines, or they can be multiplexed links like ISDN, X.25, or Frame Relay. They can even be different kinds of links, like pairing dialup async links with leased synchronous links. Mix and match, no cap 💅

Here's the way we think about it: multilink can be modeled as a virtual PPP link-layer entity 🧚 Packets that come in over different physical link-layer entities get tagged as belonging to a separate PPP network protocol (the Multilink Protocol, or MP), and then they're recombined and sequenced based on info in a multilink fragmentation header. Every packet from a link in the multilink arrangement goes to the same network-layer protocol processing machine, whether it has a multilink header or not. Iconic 👑

The packets sent using the multilink procedure get encapsulated by the normal PPP rules, with these options manually configured:

  • No async control character Map
  • No Magic Number
  • No Link Quality Monitoring
  • Address and Control Field Compression
  • Protocol Field Compression
  • No Compound Frames
  • No Self-Describing-Padding

Now, according to the rules in RFC1661, an implementation MUST accept reassembled packets whether or not there are leading zeroes in the Protocol Field of the reassembled packet. ✨ Also, even though it's explicitly forbidden further down to include the Address and Control fields (usually the two bytes FF 03) in the stuff being fragmented, it's a smart defensive programming move to accept the packet anyway and just ignore those two bytes if they're there. That's literally what RFC1661 says to do 🫶

Here's a little courtesy for implementations that run better when certain alignment is in place 🌸 When a bundle gets created, it's suggested that you decide whether to transmit leading zeroes by checking whether PFC was negotiated on the first link admitted into the bundle. That decision should be kept in force for as long as the bundle persists.

Individual links are totally allowed to have different settings for these options, though. As described below, member links SHOULD negotiate Self-Describing-Padding, even though pre-fragmented packets MUST NOT be padded 🙈 And since the Protocol Field Compression mode on a member link lets the sending system choose whether or not to include a leading zero byte, that's another way to generate even-length packets 🍓

LCP negotiations are not permitted on the bundle itself. Not even a little bit 💀

So, an implementation MUST NOT transmit LCP Configure-Request, -Reject, -Ack, -Nak, Terminate-Request or -Ack packets via the multilink procedure, and an implementation that receives them MUST silently discard them. (By "silently discard" we mean don't generate any PPP packets in response. An implementation is free to log the unexpected packet, though.) On the flip side, other LCP packets that have control functions not tied to changing the bundle's defaults are allowed. An implementation MAY transmit LCP Code-Reject, Protocol-Reject, Echo-Request, Echo-Reply and Discard-Request Packets 💜

The effective MRU for the logical-link entity gets negotiated via an LCP option. Once a link says it belongs to a multilink arrangement, it doesn't matter whether Network Control Protocol packets are wrapped in multilink headers or not, or even which link they travel over 🦋

Heads up: network protocols that aren't sent using multilink headers can't be sequenced. (So they get delivered in whatever convenient way they can 🤷‍♀️)

Let's look at an example. Figure 1 shows Link 1 negotiating network layers NL 1, NL 2, and MP between two systems. Then the two systems negotiate MP over Link 2. ⭐

Frames received on Link 1 get demultiplexed at the data link layer by the PPP network protocol identifier, and they can go to NL 1, NL 2, or MP. Link 2 accepts frames with all the same network protocol identifiers that Link 1 does.

Frames that MP receives get demultiplexed again at the network layer by the PPP network protocol identifier and sent to NL 1 or NL 2. Any frames MP gets for other network layer protocols are rejected with the normal protocol reject mechanism 😤

Figure 1. Multilink Overview.

     Network Layer
     -------------
                    ______           ______
                   /      \         /      \
                  |  NL 1  |       |  NL 2  |
                   \______/         \______/
                     | | |             | | |
                     | | +-------------o-o-o-+
                     | +------+  +-----+ | | |
                     |        |  |       | | |
                     | +------o--o-------+ + |
                     | |      |__|_        | |
                     | |     /      \      | |
                     | |    |  MLCP  | <--- Link Layer
                     | |     \______/    Demultiplexing
                     | |        |          | |
                     | |        |          | |
                     | |        | <--- Virtual Link
                     | |        |          | |
                     | |        |          | |
                     | |        |          | |
                     | |        +          | |
                  ___|_|        |       ___|_|
                 /      \       |      /      \
                |   LCP  |------+-----|  LCP   | <--- Link Layer
                 \______/              \______/       Demultiplexing
                    |                      |
                    |                      |
                  Link 1                 Link 2

3. Packet Formats 🧩

Okay, this section is where we get into the layout of the individual fragments, which are the "packets" in the Multilink Protocol 🎀 Network Protocol packets get encapsulated first (but not framed) using the normal PPP procedures, and big packets get chopped up into segments sized for the multiple physical links.

Here's the thing: even though the PPP spec would otherwise allow it, implementations MUST NOT include the Address and Control Field in the logical entity that gets fragmented. A new PPP header, made of the Multilink Protocol Identifier and the Multilink header, gets inserted before each section. (So the first fragment of a multilink packet in PPP ends up with two headers: one for the fragment, followed by the header for the packet itself. Two headers, bestie 💅)

Implementations doing the multilink procedure aren't required to fragment small packets 🌈 There's also no requirement that the segments be the same size, or that packets have to be broken up at all. One strategy for dealing with member links that have different transmission rates is to split packets into segments proportional to those rates. Another is to split them into many equal fragments and spread multiple fragments across each link, with the counts proportional to the relative speeds of the links ⚡

PPP multilink fragments are encapsulated using the protocol identifier 0x00-0x3d 🍓 Right after the protocol identifier comes a four byte header with a sequence number, plus two one-bit fields that say whether the fragment begins a packet or ends one. After an extra PPP LCP option is negotiated, that four byte header can optionally be swapped for a two byte header with only a 12 bit sequence space. Address & Control and Protocol ID compression are assumed to be in effect, so individual fragments look like this:

Figure 2: Long Sequence Number Fragment Format.

           +---------------+---------------+
PPP Header:  | Address 0xff  | Control 0x03  |
           +---------------+---------------+
           | PID(H)  0x00  | PID(L)  0x3d  |
           +-+-+-+-+-+-+-+-+---------------+
MP Header:   |B|E|0|0|0|0|0|0|sequence number|
           +-+-+-+-+-+-+-+-+---------------+
           |      sequence number (L)      |
           +---------------+---------------+
           |        fragment data          |
           |               .               |
           |               .               |
           |               .               |
           +---------------+---------------+
PPP FCS:     |              FCS              |
           +---------------+---------------+

Figure 3: Short Sequence Number Fragment Format.

           +---------------+---------------+
PPP Header:  | Address 0xff  | Control 0x03  |
           +---------------+---------------+
           | PID(H)  0x00  | PID(L)  0x3d  |
           +-+-+-+-+-------+---------------+
MP Header:   |B|E|0|0|    sequence number    |
           +-+-+-+-+-------+---------------+
           |    fragment data              |
           |               .               |
           |               .               |
           |               .               |
           +---------------+---------------+
PPP FCS:     |              FCS              |
           +---------------+---------------+

The (B)eginning fragment bit is a one-bit field. It's set to 1 on the first fragment derived from a PPP packet, and set to 0 on all the other fragments from that same PPP packet 🦋

The (E)nding fragment bit is also a one-bit field. It's set to 1 on the last fragment and set to 0 on all the others. A fragment can have both the (B)eginning and (E)nding bits set to 1 at the same time, so it's giving one-fragment-does-it-all ✨

The sequence field is a 24 bit or 12 bit number that goes up by one for every fragment transmitted 🔢 By default it's 24 bits long, but it can be negotiated down to 12 bits with an LCP configuration option (more on that below).

Between the (E)nding bit and the sequence number sits a reserved field. Its use isn't defined right now, and it MUST be set to zero 🧊 It's 2 bits long when short sequence numbers have been negotiated, and 6 bits otherwise.

Last but not least: a single reassembly structure is associated with the bundle, and the multilink headers get interpreted in the context of that structure 🧩

The FCS field in the diagrams is inherited from the normal framing mechanism of the member link the packet is transmitted on. There's no separate FCS applied to the reconstituted packet as a whole when it's sent in more than one fragment 💖

3.1. Padding Considerations 🎀

okay so systems that support multilink SHOULD implement Self-Describing-Padding 🫶 A system that does will either put the padding option right in its initial LCP Configure-Requests, or (to skip the delay of a Configure-Reject 😭) add the padding option after it gets a NAK containing that option 🧚

A system that has to pad its own transmissions but doesn't use Self-Describing-Padding when it's not doing multilink MAY keep skipping it, as long as it makes sure, by picking its fragment lengths carefully, that only the (E)nding fragments of packets get padded 💅 A system MUST NOT add padding to any packet that the peer can't recognize as padded 🙈 Non-terminal fragments MUST NOT be padded with trailing material by any method other than Self-Describing-Padding 🚫

A system MUST ensure that Self-Describing-Padding, as described in RFC 1570 [11], is negotiated on the individual link before it sends any multilink data packets, if it might pad non-terminal fragments or if it would use network or compression protocols that are vulnerable to padding, as described in RFC 1570 🔥 If it's needed, the system that adds padding MUST use LCP Configure-NAK's to get the peer to send a Configure-Request for Self-Describing-Padding 👑

Quick reminder: LCP Configure-Requests can be sent at any time on any link, and the peer will always answer with a Configure-Request of its own 💌 A system that pads its transmissions, but uses no protocols besides multilink that are vulnerable to padding, MAY hold off on making sure the peer has Configure-Requested Self-Describing-Padding until it seems like a good time to negotiate Multilink itself 🌸 This means a system that pads can still play nice with older peers that support neither Multilink nor Self-Describing-Padding 🦋

4. Trading Buffer Space Against Fragment Loss ✨

So in a multilink procedure, one channel can be delayed compared to the other channels in the bundle ⏳ That can make fragments arrive out of order, which makes it harder to notice when a fragment has been lost 😵 Figuring out how much buffer space the receiver needs gets more complicated too 🧠 In this section we talk about a technique for declaring a fragment lost, with the goal of keeping the buffer space small while also not throwing away packets we didn't have to 💜

4.1. Detecting Fragment Loss 🔍

Okay, rule number one: on each member link in a bundle, the sender MUST transmit fragments with strictly increasing sequence numbers (modulo the size of the sequence space) 📈 This is what lets the receiver figure out lost fragments by comparing sequence numbers 🧐 The sequence number doesn't reset with each new PPP packet 🔄, and a sequence number gets used up even by a fragment that holds an entire PPP packet all by itself (one where both the (B)eginning and (E)nding bits are set) ✨

An implementation MUST set the sequence number of the first fragment transmitted on a newly-constructed bundle to zero 0️⃣ (Joining a secondary link to an existing bundle is invisible to the protocol, so an implementation MUST NOT reset the sequence number space in that situation 🫠)

The receiver keeps track of the incoming sequence numbers on each link in the bundle, and it maintains the current minimum of the most recently received sequence number across all the member links in the bundle (we'll call that M) 👀 The receiver detects the end of a packet when it gets a fragment bearing the (E)nding bit 🏁 Reassembly of that packet is complete once all sequence numbers up to that fragment have been received 🎉

A lost fragment is detected when M advances past the sequence number of a fragment bearing the (E)nding bit of a packet that never got fully reassembled (in other words, not all the sequence numbers between the fragment with the (B)eginning bit and the fragment with the (E)nding bit have shown up) 💔 This works because of the increasing sequence number rule over the whole bundle 📏 Any sequence number detected this way is assumed to correspond to a fragment that was lost 🫥

An implementation MUST assume that if a fragment bears a (B)eginning bit, the previously numbered fragment bore an (E)nding bit 🧩 So if a packet is lost along with its (E)nding bit, and the packet whose fragment number is M contains a (B)eginning bit, the implementation MUST discard fragments for all unassembled packets through M-1, but SHOULD NOT discard the fragment bearing the new (B)eginning bit on this basis alone 🗑️

When a lost fragment is detected, with its sequence number deduced to be U, the receiver discards all fragments up to the lowest-numbered fragment with an ending bit (possibly deduced) greater than or equal to U 🧹 Heads up though: M might jump into the middle of a chain of packets that could have been successfully completed 🙃

Fragments may be lost because of corruption of individual packets, or because of a catastrophic loss of the link (which may occur in only one direction) 💀 This version of the multilink protocol mandates no specific procedure for detecting failed links 🙅 The PPP link quality management facility, or the periodic issuance of LCP echo-requests, could be used to achieve this 💡

Senders SHOULD avoid keeping any member links idle, so the receiver can detect lost fragments as early as possible 🏃 This matters because the value of M is not incremented on idle links. Senders SHOULD also rotate traffic among the member links if there isn't enough traffic to overflow the capacity of one link, so that no link sits idle 🔁

Losing the final fragment of a transmission can leave the receiver stalled until new packets arrive 🥶 The chance of this can go down by sending a null fragment on each member link that would otherwise become idle right after it transmits a fragment bearing the (E)nding bit ✨ A null fragment is one that consists only of a multilink header with both the (B)egin and (E)nding bits set (no payload at all) 🫧 Implementations that are concerned about wasting bandwidth or about per-packet costs are not required to send null fragments, and they may choose to defer sending them until a timer expires, with a slightly higher chance of longer stalls in the receiver ⏰ The receiver SHOULD implement some type of link idle timer to guard against indefinite stalls 🛡️

The increasing sequence per link rule rules out reallocating fragments queued up behind a failing link to a working one 🚫🔗 That's a pretty common move for implementations of ISO multilink over LAPB [4] 🤓

4.2. Buffer Space Requirements 🧺

Honestly, there's no amount of buffering that guarantees correct detection of fragment loss 😭 An adversarial peer can withhold a fragment on one channel and send arbitrary amounts on the others 👿 For the usual case where all channels are transmitting, you can show that there's a minimum amount below which you couldn't correctly detect packet loss 📉 That amount depends on the relative delay between channels (D[channel-i,channel-j]), the data rate of each channel (R[c]), the maximum fragment size permitted on each channel (F[c]), and the total amount of buffering the transmitter has allocated across the channels 🧮

When you're using PPP, the delay between channels can be estimated with LCP echo request and echo reply packets 📡 (If the links have different transmission rates, the round trip times should be adjusted to take that into account 🧠) The slippage for each channel is defined as the bandwidth times the delay for that channel relative to the channel with the longest delay: S[c] = R[c] * D[c,c-worst] (S[c-worst] will be zero, of course! 💁)

Now the spicy part 🌶️ A situation that would make sequence number skew worse is extremely bursty traffic (almost enough to drain all the channels), where the transmitter first queues up as many consecutively numbered packets on one link as it can, then queues the next batch on a second link, and so on 🌪️ Since transmitters must be able to buffer at least a maximum-sized fragment for each link (and will usually buffer at least two) 📦, a receiver that allocates any less than S[1] + S[2] + ... + S[N] + F[1] + ... + F[N] will be at risk for incorrectly assuming packet loss 😬 so it SHOULD allocate at least twice that 💖

If reliable multilink operation is desired, PPP Reliable Transmission [6] (essentially the use of ISO LAPB) MUST be negotiated prior to the use of the Multilink Protocol on each member link 🤝

Whether or not reliable delivery is employed over member links, an implementation MUST present a signal to the NCPs running over the multilink arrangement that a loss has occurred 🚨

Compression may be used separately on each member link, or run over the bundle (as a logical group link) 🗜️ Using multiple compression streams under the bundle (i.e., on each link separately) is indicated by running the Compression Control Protocol [5] but with an alternative PPP protocol ID 🪄

5.1. Configuration Option Types 🧾

The Multilink Protocol introduces some additional LCP Configuration Options, and they're giving main character energy 👑

  • Multilink Maximum Received Reconstructed Unit
  • Multilink Short Sequence Number Header Format
  • Endpoint Discriminator

Figure 4: Multilink MRRU LCP option

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Type = 17   |   Length = 4  | Max-Receive-Reconstructed-Unit|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

okay so this LCP option is basically the "hey, I do Multilink!" flag 🦋 Sending it tells the other side that the system implements the PPP Multilink Protocol. If it doesn't get rejected, the system treats every packet it receives on this link as something a common protocol machine can handle, alongside packets from that same peer arriving on any other link where this option was accepted 💅

The Max-Receive-Reconstructed-Unit field is two octets 🎀 and it says the maximum number of octets allowed in the Information fields of reassembled packets. A system MUST be able to receive the full 1500 octet Information field of any reassembled PPP packet, although it MAY attempt to negotiate a smaller or larger value. The 1500 comes from the MRU LCP option in PPP, and if this requirement is changed in a future version of RFC 1661, the same rules will apply here 🌸

A system MUST include the LCP MRRU option in every LCP negotiation intended to instantiate a bundle or to join an existing bundle 🫶 If the LCP MRRU option is offered on a link that's meant to join an existing bundle, a system MUST offer the same Max-Receive-Reconstruct-Unit value that was previously negotiated for the bundle. no cap, this part is iconic 👑

A system MUST NOT send any multilink packets on any link unless its peer has offered the MMRU LCP option and the system has configure-Ack'ed it during the most recent LCP negotiation on that link 😭 A system MAY include the MMRU LCP option in a configure-NAK, if its peer has not offered it (until, according to PPP rules, the peer configure-Reject's it) 🧚

Note: the MRRU value conveyed im this option corresponds to the MRU of the bundle when conceptualized as a PPP entity. But the rules for the Multilink MRRU option are different from the LCP MRU option, because some value MUST be offered in every LCP negotiation, and that confirmation of this option is required prior to multilink interpretation. Main character energy for sure 💜

5.1.2. Short Sequence Number Header Format Option 🦋

Figure 5: Short Sequence Number Header Format Option

    0                   1
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Type = 18   |  Length = 2   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

This option is how the implementation lets its peer know it wants to receive fragments with short, 12 bit sequence numbers 🍓 When a peer system configure-Acks this option, it MUST transmit all multilink packets on all links of the bundle with 12 bit sequence numbers, or it MUST configure-Reject the option. If 12 bit sequence numbers are wanted, this option MUST be negotiated when the bundle is instantiated, and MUST be explicitly included in every LCP configure request offered by a system when that system intends to include the link in an existing bundle that's using 12 bit sequence numbers. If this option is never negotiated during the life of a bundle, the sequence numbers are 24 bits long ✨

An implementation that wants to transmit multilink fragments with short sequence numbers MAY include the multilink short sequence number in a configure-NAK, asking the peer to respond with a request to receive short sequence numbers. The peer is not compelled to respond with the option 🙈💀

5.1.3. Endpoint Discriminator Option 🎀

okay bestie, this one is the Endpoint Discriminator Option 🔥 it's basically a system going "hi, this is who I am" 💅 Here's the layout:

Figure 7:  Endpoint Discriminator Option

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Type = 19   |     Length    |    Class      |  Address ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

So the option represents identification of the system transmitting the packet 🪪 It's a tiny ID badge that tells the other side the peer might be the same as a peer on another existing link 👀 If the badge is totally unique, a new bundle MUST be established from the link being negotiated. If it matches the class and address of some other peer on an existing link, the new link MUST be joined to the bundle containing the link to the matching peer or MUST establish a new bundle 🌸 which one depends on the decision tree in (1) through (4) below.

To securely join an existing bundle, a PPP authentication protocol [3] must be used to get authenticated info from the peer. Otherwise a sneaky hostile peer could just show up with a falsified discriminator option and crash the party 💀 not on my watch 😤

This option is not required for multilink operation 🦋 If a system doesn't get the Multilink MRRU option, but does get the Endpoint Discriminator Option, and there's no manual configuration giving outside info, the implementation MUST NOT assume multilink operation is being requested on that basis alone 🙈

Since there's also no requirement for authentication, there are four sets of scenarios 🧚 here they are:

(1)  No authentication, no discriminator:
     All new links MUST be joined to one bundle, unless
     there is manual configuration to the contrary.
     It is also permissible to have more than one manually
     configured bundle connecting two given systems.

(2)  Discriminator, no authentication:
     Discriminator match -> MUST join matching bundle,
     discriminator mismatch -> MUST establish new bundle.

(3)  No discriminator, authentication:
     Authenticated match -> MUST join matching bundle,
     authenticated mismatch -> MUST establish new bundle.

(4)  Discriminator, authentication:
     Discriminator match and authenticated match -> MUST join bundle,
     discriminator mismatch -> MUST establish new bundle,
     authenticated mismatch -> MUST establish new bundle.

The option has a Class, which picks the identifier address space, and an Address, which picks a unique identifier inside that class's space 🗂️ This identifier is expected to refer to the mechanical equipment on the transmitting system ⚙️ For some classes the uniqueness is global, not limited to one admin domain 🌍 Within each class, how address values get handed out is up to a class-dependent policy 📜

Each endpoint can choose an identifier class without restriction 🎀 The goal is to catch endpoints that were wrongly assumed to be alike, so a mismatch on class alone is enough 🔍 No single class is recommended, but classes with universally unique values are preferred ✨

This option doesn't have to be supported by the system or the peer 💖 If it's missing from a Configure-Request, the system MUST NOT generate a Configure-Nak of this option for any reason. Instead it SHOULD act like it got the option with Class = 0, Address = 0. And if a system gets a Configure-Nak or Configure-Reject of this option, it MUST remove it from any additional Configure-Request 🧹

The size comes from the Length field. Some classes have a fixed length and others are variable 📏 The option is invalid if the Length field is smaller than the minimum for the class 🚫

An implementation MAY use the Endpoint Discriminator to look up admin or authentication records in a local database 🗄️ That's incidental to what the option is for, though, and it's deprecated when a PPP Authentication protocol [3] can be used instead 🥀 Some classes let the peer make up random or locally assigned values, so using this option as a database key needs prior agreement between peer admins 🤝

Here are the subfields, bestie 📋

Type

  • 19 = for Endpoint Discriminator

Length

  • 3 + length of Address

Class

  • One octet, picks the identifier address space. The most up-to-date values of the LCP Endpoint Discriminator Class field are in the most recent "Assigned Numbers" RFC [7]. Current values:
0    Null Class

1    Locally Assigned Address

2    Internet Protocol (IP) Address

3    IEEE 802.1 Globally Assigned MAC Address

4    PPP Magic-Number Block
5    Public Switched Network Directory Number

Address

  • One or more octets, picks the identifier inside the selected class. Length and content depend on the Class:

Class 0 - Null Class 🫥

  • Maximum Length: 0
  • This class is the default value if the option isn't present in a received Configure-Request.

Class 1 - Locally Assigned Address 🔧

  • Maximum Length: 20
  • This class exists so you can make a local assignment when a globally unique class isn't possible. A device serial number is suggested. Its use is deprecated, since uniqueness isn't guaranteed 😬

Class 2 - Internet Protocol (IP) Address 🌐

  • Fixed Length: 4
  • An address in this class contains an IP host address as defined in [8].

Class 3 - IEEE 802.1 Globally Assigned MAC Address 💜

  • Fixed Length: 6
  • An address in this class contains an IEEE 802.1 MAC address in canonical (802.3) format [9]. The address MUST have the global/local assignment bit clear and MUST have the multicast/specific bit clear. Locally assigned MAC addresses should be represented using Class 1.

Class 4 - PPP Magic-Number Block 🪄

  • Maximum Length: 20
  • This isn't an address, it's a block of 1 to 5 concatenated 32 bit PPP Magic-Numbers as defined in [2]. It gives you automatic generation of a value that's likely, but not guaranteed, to be unique. The same block MUST be used by an endpoint continuously during any period in which at least one link is in the LCP Open state. Its use is deprecated.
  • Fun fact: PPP Magic-Numbers are used in [2] to detect unexpected loopbacks of a link from an endpoint to itself. There's a small chance two distinct endpoints generate matching magic-numbers. That chance shrinks a lot when LCP negotiation is repeated looking for the desired mismatch, if a peer can generate uncorrelated magic-numbers 📉
  • Here's the thing: magic-numbers are used to tell whether two links are really from the same peer endpoint or from two distinct endpoints. They always match when there's one endpoint 👯 With two endpoints there's a small chance they'll match anyway. To get the same confidence against a false match as LCP loopback detection gives, you can combine several uncorrelated magic-numbers in one block 🧩

Class 5 - Public Switched Network Directory Number ☎️

  • Maximum Length: 15
  • An address in this class contains an octet sequence as defined by I.331 (E.164), representing an international telephone directory number that can be used to reach the endpoint over the public switched telephone network [10] 📞

When Multilink has been negotiated on a link (say Y), and that link is being added to a bundle that currently has a single existing link (say X), a system MUST transmit a Multilink-encapsulated packet on X before transmitting any Multilink-encapsulated packets on Y 🚦

Links can be added and removed from a bundle without wiping out the bundle's state 🧠 so the fragment should get the appropriate (next) fragment number. As noted earlier, the first fragment sent in the life of a bundle gets fragment number 0 🌟

Member links can be terminated using the normal PPP LCP procedures, with LCP Terminate-Request and Terminate-Ack packets on that member link 🎬 Member links usually don't reorder packets, so getting a terminate ack is enough to assume any multilink protocol packets ahead of it are at no special risk of loss 💅

Getting an LCP Terminate-Request on one link does NOT wrap up the procedure on the remaining links 🙅‍♀️ (Lowercase fine, it's just not a rule keyword, but the point stands 😉)

As long as any member links in the bundle are active, the PPP state for the bundle sticks around as its own separate entity 🫶 However, if there's a unique link left in the bundle and all the other links were closed gracefully (with Terminate-Ack), an implementation MAY stop using multilink headers 🦋

If Multilink is used together with PPP reliable transmission, and a member link isn't closed gracefully, the implementation should expect to receive packets that violate the increasing sequence number rule 😭

8. Interaction with Other Protocols 🌈

In the common case, LCP and the Authentication Control Protocol get negotiated over each member link 🔗 The Network Protocols and their control exchanges would normally happen once, on the bundle 🎀

Sometimes it's desirable for some Network Protocols to be exempt from sequencing requirements. If the MRU sizes of the link didn't cause fragmentation, those protocols can go straight over the member links 🚀

Okay, this part is kind of a plot twist 🙈 Even though it was discouraged above, say you have several member links between two implementations and you want independent sequencing of two protocol sets, but you don't want one blocking the other. You could describe two multilink procedures by giving a system multiple endpoint identifiers. Each member link still belongs to only one bundle, though 🧃 Think of a physical router housing two logically separate implementations, each configured independently 🏠

A simpler solution is to have one link refuse to join the bundle, by sending a Configure-Reject in response to the Multilink LCP option 🙅‍♀️✨

9. Security Considerations 🔐

Okay, real talk, this one's serious 😤 Operation of this protocol is no more and no less secure than operation of the PPP authentication protocols [3]. Go there for further discussion, and don't skip it 🫡💀

10. References 🧾

okay bestie, here's the full bibliography, the receipts for everything this spec is built on 📚✨ every single one is listed below, title and all 💅

  • [1] Leifer, D., Sheldon, S., and B. Gorsline, "A Subnetwork Control Protocol for ISDN Circuit-Switching", University of Michigan (unpublished), March 1991.
  • [2] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, Daydreamer, July 1994.
  • [3] Lloyd, B., and W. Simpson, "PPP Authentication Protocols", RFC 1334, Lloyd Internetworking, Daydreamer, October 1992.
  • [4] International Organisation for Standardization, "HDLC - Description of the X.25 LAPB-Compatible DTE Data Link Procedures", International Standard 7776, 1988
  • [5] Rand, D., "The PPP Compression Control Protocol (CCP)", PPP Extensions Working Group, RFC 1962, June 1996.
  • [6] Rand, D., "PPP Reliable Transmission", RFC 1663, Novell, July 1994
  • [7] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700, USC/Information Sciences Institute, October 1994.
  • [8] Postel, J., Editor, "Internet Protocol - DARPA Internet Program Protocol Specification", STD 5, RFC 791, USC/Information Sciences Institute, September 1981.
  • [9] Institute of Electrical and Electronics Engineers, Inc., "IEEE Local and Metropolitan Area Networks: Overview and Architecture", IEEE Std. 802-1990, 1990.
  • [10] The International Telegraph and Telephone Consultative Committee (CCITT), "Numbering Plan for the ISDN Area", Recommendation I.331 (E.164), 1988.
  • [11] Simpson, W., Editor, "PPP LCP Extensions", RFC 1570, Daydreamer, January 1994.

11. Differences from RFC 1717 🔄

okay so this section is the tea on everything that's different from RFC 1717 ☕💅 there are some restrictions on implementations that just weren't in RFC 1717 at all, but the good news is that systems following these restrictions are still fully interoperable with RFC 1717-compliant systems 🫶🦋

so RFC 1717 let you use either the Short Sequence Number Header Format (SSNHF) option or the Maximum Reconstructed Receive Unit (MRRU) option all by itself to say "hey, I want to negotiate multilink" 🙈 this spec says nope to using the SSNHF option by itself 🚫, but it totally allows both options together 💖 any implementation that otherwise conforms to RFC 1717 and also follows this restriction will interoperate with any RFC 1717 implementation, no drama ✨

11.2. Initial Sequence Number defined 🔢

this one is simple but iconic 👑 the first sequence number transmitted after the virtual link has reached the open state must be 0 🌸

11.3. Default Value of the MRRU 🌈

this spec removes the default value for the MRRU, since it always has to be negotiated with some value 💅 and an implementation must support an MRRU with the same value as the default MRU size for PPP 🫶

11.4. Config-Nak of EID prohibited 🙅‍♀️

this spec forbids Config-Naking an EID (the Endpoint Discriminator) for any reason, full stop 🛑😭

11.5. Uniformity of Sequence Space 🧚

all the links in a bundle have to use the same sequence format 💜 no mixing and matching, bestie, it's giving uniformity ✨

this memo spells out how you should start using Multilink Headers when a link gets added to a bundle, and under what circumstances it's safe to stop using them 🍓 very important stuff, so read it carefully 👀

11.7. Manual Configuration and Bundle Assignment 🌸

this one is giving freedom 🕊️ the document explicitly permits multiple bundles to be manually configured in the absence of both the Endpoint Discriminator (EID) and any form of authentication 💖

13. Authors' Addresses 💌

and finally, the squad behind this doc, with all their contact info so you can slide into their inboxes 📬🫶

Keith Sklower

Computer Science Department
384 Soda Hall, Mail Stop 1776
University of California
Berkeley, CA 94720-1776

Phone:  (510) 642-9587
EMail:  sklower@CS.Berkeley.EDU

Brian Lloyd

Lloyd Internetworking
3031 Alhambra Drive
Cameron Park, CA 95682

Phone: (916) 676-1147
EMail:  brian@lloyd.com

Glenn McGregor

Lloyd Internetworking
3031 Alhambra Drive
Cameron Park, CA 95682

Phone: (916) 676-1147
EMail: glenn@lloyd.com

Dave Carr

Newbridge Networks Corporation
600 March Road
P.O. Box 13600
Kanata, Ontario,
Canada, K2K 2E6

Phone:  (613) 591-3600
EMail:  dcarr@Newbridge.COM

Tom Coradetti

Sidewalk Software
1190 Josephine Road
Roseville, MN 55113

Phone: (612) 490 7856
EMail: 70761.1664@compuserve.com
📦 where this page comes from