diff options
Diffstat (limited to 'doc/rfc/rfc1990.txt')
| -rw-r--r-- | doc/rfc/rfc1990.txt | 1347 |
1 files changed, 1347 insertions, 0 deletions
diff --git a/doc/rfc/rfc1990.txt b/doc/rfc/rfc1990.txt new file mode 100644 index 0000000..a4f7ffe --- /dev/null +++ b/doc/rfc/rfc1990.txt @@ -0,0 +1,1347 @@ + + + + + + +Network Working Group K. Sklower +Request for Comments: 1990 University of California, Berkeley +Obsoletes: 1717 B. Lloyd +Category: Standards Track G. McGregor + Lloyd Internetworking + D. Carr + Newbridge Networks Corporation + T. Coradetti + Sidewalk Software + August 1996 + + + The PPP Multilink Protocol (MP) + + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Abstract + + This document proposes a method for splitting, recombining and + sequencing datagrams across multiple logical data links. This work + was originally motivated by the desire to exploit multiple bearer + channels in ISDN, but is equally applicable to any situation in which + multiple PPP links connect two systems, including async links. This + is accomplished by means of 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 specifically wish to thank Fred Baker of ACC, Craig Fox + of Network Systems, Gerry Meyer of Spider Systems, Dan Brennan of + Penril Datability Networks, Vernon Schryver of SGI (for the + comprehensive discussion of padding), and the members of the IP over + Large Public Data Networks and PPP Extensions working groups, for + much useful discussion on the subject. + + + + + + +Sklower, et. al. Standards Track [Page 1] + +RFC 1990 PPP Multilink August 1996 + + +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 offer the possibility of + opening multiple simultaneous channels between systems, giving users + additional bandwidth on demand (for additional cost). Previous + proposals for the transmission of internet protocols over ISDN have + stated as a goal the ability to make use of this capability, (e.g., + Leifer et al., [1]). + + There are proposals being advanced for providing synchronization + between multiple streams at the bit level (the BONDING proposals); + such features are not as yet widely deployed, and may require + additional hardware for end system. Thus, it may be useful to have a + purely software solution, or at least an interim measure. + + + +Sklower, et. al. Standards Track [Page 2] + +RFC 1990 PPP Multilink August 1996 + + + There are other instances where bandwidth on demand can be exploited, + such as using a dialup async line at 28,800 baud to back up a leased + synchronous line, or opening additional X.25 SVCs where the window + size is limited to two by international agreement. + + The simplest possible algorithms of 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 means of a four-byte sequencing header, and simple synchronization + rules, one can split packets among parallel virtual circuits between + systems in such a way that packets do not become reordered, or at + least the likelihood of this is greatly reduced. + +1.2. Functional Description + + The method discussed here is similar to the multilink protocol + described in ISO 7776 [4], but offers the additional ability to split + and recombine packets, thereby reducing latency, and potentially + increase the effective maximum receive unit (MRU). Furthermore, + there is 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 permits a system + to indicate to its peer that it is capable of combining multiple + physical links into a "bundle". Only under exceptional conditions + would a given pair of systems require the operation of more than one + bundle connecting them. + + Multilink is negotiated during the initial LCP option negotiation. A + system indicates to its peer that it is willing to do multilink by + sending the multilink option as part of the 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. + + + + + +Sklower, et. al. Standards Track [Page 3] + +RFC 1990 PPP Multilink August 1996 + + + 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 + + The following language conventions are used in the items of + specification in this document: + + o MUST, SHALL or MANDATORY -- the item is an absolute requirement + of the specification. + + o SHOULD or RECOMMENDED -- the item should generally be followed + for all but exceptional circumstances. + + o MAY or OPTIONAL -- the item is truly optional and may be + followed or ignored according to the needs of the implementor. + +2. General Overview + + In order to establish communications over a point-to-point link, each + end of the PPP link must first send LCP packets to configure the data + link during Link Establishment phase. After the link has been + established, PPP provides for an Authentication phase in which the + authentication protocols can be used to determine identifiers + associated with each system connected by the link. + + The goal of multilink operation is to coordinate multiple independent + links between a fixed pair of systems, providing a virtual link with + greater bandwidth than any of the constituent members. The aggregate + link, or bundle, is named by the pair of identifiers for two systems + connected by the multiple links. A system identifier may include + information provided by PPP Authentication [3] and information + provided by LCP negotiation. The bundled links can be different + physical links, as in multiple async lines, but may also be instances + of multiplexed links, such as ISDN, X.25 or Frame Relay. The links + may also be of different kinds, such as pairing dialup async links + with leased synchronous links. + + We suggest that multilink operation can be modeled as a virtual PPP + link-layer entity wherein packets received over different physical + link-layer entities are identified as belonging to a separate PPP + network protocol (the Multilink Protocol, or MP) and recombined and + sequenced according to information present in a multilink + fragmentation header. All packets received over links identified as + belonging to the multilink arrangement are presented to the same + network-layer protocol processing machine, whether they have + multilink headers or not. + + + +Sklower, et. al. Standards Track [Page 4] + +RFC 1990 PPP Multilink August 1996 + + + The packets to be transmitted using the multilink procedure are + encapsulated according to the rules for PPP where the following + options would have been manually configured: + + o No async control character Map + o No Magic Number + o No Link Quality Monitoring + o Address and Control Field Compression + o Protocol Field Compression + o No Compound Frames + o No Self-Describing-Padding + + According to the rules specified in RFC1661, this means that an + implementation MUST accept reassembled packets with and without + leading zeroes present in the Protocol Field of the reassembled + packet. Although it is explicitly forbidden below to include the + Address and Control fields (usually, the two bytes FF 03) in the + material to be fragmented, it is a good defensive programming + practice to accept the packet anyway, ignoring the two bytes if + present, as that is what RFC1661 specifies. + + As a courtesy to implementations that perform better when certain + alignment obtains, it is suggested that a determination be made when + a bundle is created on whether to transmit leading zeroes by + examining whether PFC has been negotiated on the first link admitted + into a bundle. This determination should be kept in force so long as + a bundle persists. + + Of course, individual links are permitted to have different settings + for these options. As described below, member links SHOULD negotiate + Self-Describing-Padding, even though pre-fragmented packets MUST NOT + be padded. Since the Protocol Field Compression mode on the member + link allows a sending system to include a leading byte of zero or not + at its discretion, this is an alternative mechanism for generating + even-length packets. + + LCP negotiations are not permitted on the bundle itself. An + implementation MUST NOT transmit LCP Configure-Request, -Reject, + -Ack, -Nak, Terminate-Request or -Ack packets via the multilink + procedure, and an implementation receiving them MUST silently discard + them. (By "silently discard" we mean to not generate any PPP packets + in response; an implementation is free to generate a log entry + registering the reception of the unexpected packet). By contrast, + other LCP packets having control functions not associated with + changing the defaults for the bundle itself are permitted. An + implementation MAY transmit LCP Code-Reject, Protocol-Reject, Echo- + Request, Echo-Reply and Discard-Request Packets. + + + + +Sklower, et. al. Standards Track [Page 5] + +RFC 1990 PPP Multilink August 1996 + + + The effective MRU for the logical-link entity is negotiated via an + LCP option. It is irrelevant whether Network Control Protocol + packets are encapsulated in multilink headers or not, or even over + which link they are sent, once that link identifies itself as + belonging to a multilink arrangement. + + Note that network protocols that are not sent using multilink headers + cannot be sequenced. (And consequently will be delivered in any + convenient way). + + For example, consider the case in Figure 1. Link 1 has negotiated + network layers NL 1, NL 2, and MP between two systems. The two + systems then negotiate MP over Link 2. + + Frames received on link 1 are demultiplexed at the data link layer + according the PPP network protocol identifier and can be sent to NL + 1, NL 2, or MP. Link 2 will accept frames with all network protocol + identifiers that Link 1 does. + + Frames received by MP are further demultiplexed at the network layer + according to the PPP network protocol identifier and sent to NL 1 or + NL 2. Any frames received by MP for any other network layer + protocols are rejected using the normal protocol reject mechanism. + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Sklower, et. al. Standards Track [Page 6] + +RFC 1990 PPP Multilink August 1996 + + + 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 + + In this section we describe the layout of individual fragments, which + are the "packets" in the Multilink Protocol. Network Protocol + packets are first encapsulated (but not framed) according to normal + PPP procedures, and large packets are broken up into multiple + segments sized appropriately for the multiple physical links. + Although it would otherwise be permitted by the PPP spec, + implementations MUST NOT include the Address and Control Field in the + logical entity to be fragmented. A new PPP header consisting of the + Multilink Protocol Identifier, and the Multilink header is inserted + before each section. (Thus the first fragment of a multilink packet + in PPP will have two headers, one for the fragment, followed by the + header for the packet itself). + + + + + +Sklower, et. al. Standards Track [Page 7] + +RFC 1990 PPP Multilink August 1996 + + + Systems implementing the multilink procedure are not required to + fragment small packets. There is also no requirement that the + segments be of equal sizes, or that packets must be broken up at all. + A possible strategy for contending with member links of differing + transmission rates would be to divide the packets into segments + proportion to the transmission rates. Another strategy might be to + divide them into many equal fragments and distribute multiple + fragments per link, the numbers being proportional to the relative + speeds of the links. + + PPP multilink fragments are encapsulated using the protocol + identifier 0x00-0x3d. Following the protocol identifier is a four + byte header containing a sequence number, and two one bit fields + indicating that the fragment begins a packet or terminates a packet. + After negotiation of an additional PPP LCP option, the four byte + header may be optionally replaced by a two byte header with only a 12 + bit sequence space. Address & Control and Protocol ID compression + are assumed to be in effect. Individual fragments will, therefore, + have the following format: + + 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 | + +---------------+---------------+ + + + + + + + + + + + + +Sklower, et. al. Standards Track [Page 8] + +RFC 1990 PPP Multilink August 1996 + + + 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 set to 1 on the first + fragment derived from a PPP packet and set to 0 for all other + fragments from the same PPP packet. + + The (E)nding fragment bit is a one bit field set to 1 on the last + fragment and set to 0 for all other fragments. A fragment may have + both the (B)eginning and (E)nding fragment bits set to 1. + + The sequence field is a 24 bit or 12 bit number that is incremented + for every fragment transmitted. By default, the sequence field is 24 + bits long, but can be negotiated to be only 12 bits with an LCP + configuration option described below. + + Between the (E)nding fragment bit and the sequence number is a + reserved field, whose use is not currently defined, which MUST be set + to zero. It is 2 bits long when the use of short sequence numbers + has been negotiated, 6 bits otherwise. + + In this multilink protocol, a single reassembly structure is + associated with the bundle. The multilink headers are interpreted in + the context of this structure. + + The FCS field shown in the diagram is inherited from the normal + framing mechanism from the member link on which the packet is + transmitted. There is no separate FCS applied to the reconstituted + packet as a whole if transmitted in more than one fragment. + + + + + + + +Sklower, et. al. Standards Track [Page 9] + +RFC 1990 PPP Multilink August 1996 + + +3.1. Padding Considerations + + Systems that support the multilink protocol SHOULD implement Self- + Describing-Padding. A system that implements self-describing-padding + by definition will either include the padding option in its initial + LCP Configure-Requests, or (to avoid the delay of a Configure-Reject) + include the padding option after receiving a NAK containing the + option. + + A system that must pad its own transmissions but does not use Self- + Describing-Padding when not using multilink, MAY continue to not use + Self-Describing-Padding if it ensures by careful choice of fragment + lengths that only (E)nding fragments of packets are padded. A system + MUST NOT add padding to any packet that cannot be recognized as + padded by the peer. Non-terminal fragments MUST NOT be padded with + trailing material by any other method 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 transmitting + 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 necessary, the system that + adds padding MUST use LCP Configure-NAK's to elicit a Configure- + Request for Self-Describing-Padding from the peer. + + Note that LCP Configure-Requests can be sent at any time on any link, + and that the peer will always respond with a Configure-Request of its + own. A system that pads its transmissions but uses no protocols + other than multilink that are vulnerable to padding MAY delay + ensuring that the peer has Configure-Requested Self-Describing- + Padding until it seems desireable to negotiate the use of Multilink + itself. This permits the interoperability of a system that pads with + older peers that support neither Multilink nor Self-Describing- + Padding. + +4. Trading Buffer Space Against Fragment Loss + + In a multilink procedure one channel may be delayed with respect to + the other channels in the bundle. This can lead to fragments being + received out of order, thus increasing the difficulty in detecting + the loss of a fragment. The task of estimating the amount of space + required for buffering on the receiver becomes more complex because + of this. In this section we discuss a technique for declaring that a + fragment is lost, with the intent of minimizing the buffer space + required, yet minimizing the number of avoidable packet losses. + + + + + + +Sklower, et. al. Standards Track [Page 10] + +RFC 1990 PPP Multilink August 1996 + + +4.1. Detecting Fragment Loss + + 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 requirement supports a strategy for the + receiver to detect lost fragments based on comparing sequence + numbers. The sequence number is not reset upon each new PPP packet, + and a sequence number is consumed even for those fragments which + contain an entire PPP packet, i.e., one in which both the (B)eginning + and (E)nding bits are set. + + An implementation MUST set the sequence number of the first fragment + transmited on a newly-constructed bundle to zero. (Joining a + secondary link to an exisiting bundle is invisible to the protocol, + and an implementation MUST NOT reset the sequence number space in + this situation). + + The receiver keeps track of the incoming sequence numbers on each + link in a bundle and maintains the current minimum of the most + recently received sequence number over all the member links in the + bundle (call this M). The receiver detects the end of a packet when + it receives a fragment bearing the (E)nding bit. Reassembly of the + packet is complete if 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 an (E)nding bit of a packet which has not been + completely reassembled (i.e., not all the sequence numbers between + the fragment bearing the (B)eginning bit and the fragment bearing the + (E)nding bit have been received). This is because of the increasing + sequence number rule over the bundle. Any sequence number so + detected is assumed to correspond to a fragment which has been lost. + + An implementation MUST assume that if a fragment bears a (B)eginning + bit, that the previously numbered fragment bore an (E)nding bit. + Thus if a packet is lost bearing the (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. + + The detection of a lost fragment, whose sequence number was deduced + to be U, causes the receiver to discard all fragments up to the + lowest numbered fragment with an ending bit (possibly deduced) + greater than or equal to U. However, the quantity M may jump into + the middle of a chain of packets which can be successful completed. + + + + + +Sklower, et. al. Standards Track [Page 11] + +RFC 1990 PPP Multilink August 1996 + + + Fragments may be lost due to corruption of individual packets or + catastrophic loss of the link (which may occur only in one + direction). This version of the multilink protocol mandates no + specific procedures for the detection of 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 to maximize early + detection of lost fragments by the receiver, since the value of M is + not incremented on idle links. Senders SHOULD rotate traffic among + the member links if there isn't sufficient traffic to overflow the + capacity of one link to avoid idle links. + + Loss of the final fragment of a transmission can cause the receiver + to stall until new packets arrive. The likelihood of this may be + decreased by sending a null fragment on each member link in a bundle + that would otherwise become idle immediately after having transmitted + a fragment bearing the (E)nding bit, where a null fragment is one + consisting only of a multilink header bearing both the (B)egin and + (E)nding bits (i.e., having no payload). Implementations concerned + about either wasting bandwidth or per packet costs are not required + to send null fragments and may elect to defer sending them until a + timer expires, with the marginally increased possibility of lengthier + 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 prohibits the reallocation of + fragments queued up behind a failing link to a working one, a + practice which is not unusual for implementations of ISO multilink + over LAPB [4]. + +4.2. Buffer Space Requirements + + There is no amount of buffering that will guarantee correct detection + of fragment loss, since an adversarial peer may 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 is a minimum amount below which you could not correctly detect + packet loss. The amount depends on the relative delay between the + 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 amongst + the channels. + + When using PPP, the delay between channels could be estimated by + using LCP echo request and echo reply packets. (In the case of links + of different transmission rates, the round trip times should be + adjusted to take this into account.) The slippage for each channel + + + +Sklower, et. al. Standards Track [Page 12] + +RFC 1990 PPP Multilink August 1996 + + + 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!) + + A situation which would exacerbate sequence number skew would be one + in which there is extremely bursty traffic (almost allowing all + channels to drain), and then where the transmitter would first queue + up as many consecutively numbered packets on one link as it could, + then queue up 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 up 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, + and therefore, SHOULD allocate at least twice that. + +5. PPP Link Control Protocol Extensions + + 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 NCP's 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). The use of 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 the use of additional LCP + Configuration Options: + + o Multilink Maximum Received Reconstructed Unit + o Multilink Short Sequence Number Header Format + o Endpoint Discriminator + + + + + + + + + + + + +Sklower, et. al. Standards Track [Page 13] + +RFC 1990 PPP Multilink August 1996 + + +5.1.1. Multilink MRRU LCP option + + 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| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + The presence of this LCP option indicates that the system sending it + implements the PPP Multilink Protocol. If not rejected, the system + will construe all packets received on this link as being able to be + processed by a common protocol machine with any other packets + received from the same peer on any other link on which this option + has been accepted. + + The Max-Receive-Reconstructed unit field is two octets, and specifies + the maximum number of octets 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 number 1500 + here comes from the specification for the MRU LCP option in PPP; 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 which is intended to join an + existing bundle, a system MUST offer the same Max-Receive- + Reconstruct-Unit value previously negotiated for the bundle. + + 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, as + some value MUST be offered in every LCP negotiation, and that + confirmation of this option is required prior to multilink + interpretation. + + + + + + +Sklower, et. al. Standards Track [Page 14] + +RFC 1990 PPP Multilink August 1996 + + +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 advises the peer that the implementation wishes to + receive fragments with short, 12 bit sequence numbers. When a peer + system configure-Ack's this option, it MUST transmit all multilink + packets on all links of the bundle with 12 bit sequence numbers or + configure-Reject the option. If 12 bit sequence numbers are desired, + 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 the system intends to include that link in an existing + bundle using 12 bit sequence numbers. If this option is never + negotiated during the life of a bundle, sequence numbers are 24 bits + long. + + An implementation wishing to transmit multilink fragments with short + sequence numbers MAY include the multilink short sequence number in a + configure-NAK to ask that the peer 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 + + 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 ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + The Endpoint Discriminator Option represents identification of the + system transmitting the packet. This option advises a system that + the peer on this link could be the same as the peer on another + existing link. If the option distinguishes this peer from all + others, a new bundle MUST be established from the link being + negotiated. If this option matches the class and address of some + other peer of 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, depending on the decision tree shown in (1) through (4) + below. + + + +Sklower, et. al. Standards Track [Page 15] + +RFC 1990 PPP Multilink August 1996 + + + To securely join an existing bundle, a PPP authentication protocol + [3] must be used to obtain authenticated information from the peer to + prevent a hostile peer from joining an existing bundle by presenting + a falsified discriminator option. + + This option is not required for multilink operation. If a system + does not receive the Multilink MRRU option, but does receive the + Endpoint Discriminator Option, and there is no manual configuration + providing outside information, the implementation MUST NOT assume + that multilink operation is being requested on this basis alone. + + As there is also no requirement for authentication, there are four + sets of scenarios: + + (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 contains a Class which selects an identifier address space + and an Address which selects a unique identifier within the class + address space. + + This identifier is expected to refer to the mechanical equipment + associated with the transmitting system. For some classes, + uniqueness of the identifier is global and is not bounded by the + scope of a particular administrative domain. Within each class, + uniqueness of address values is controlled by a class dependent + policy for assigning values. + + Each endpoint may chose an identifier class without restriction. + Since the objective is to detect mismatches between endpoints + erroneously assumed to be alike, mismatch on class alone is + sufficient. Although no one class is recommended, classes which have + + + +Sklower, et. al. Standards Track [Page 16] + +RFC 1990 PPP Multilink August 1996 + + + universally unique values are preferred. + + This option is not required to be supported either by the system or + the peer. If the option is not present in a Configure-Request, the + system MUST NOT generate a Configure-Nak of this option for any + reason; instead it SHOULD behave as if it had received the option + with Class = 0, Address = 0. If a system receives a Configure-Nak or + Configure-Reject of this option, it MUST remove it from any + additional Configure-Request. + + The size is determined from the Length field of the element. For + some classes, the length is fixed, for others the length is variable. + The option is invalid if the Length field indicates a size below the + minimum for the class. + + An implementation MAY use the Endpoint Discriminator to locate + administration or authentication records in a local database. Such + use of this option is incidental to its purpose and is deprecated + when a PPP Authentication protocol [3] can be used instead. Since + some classes permit the peer to generate random or locally assigned + address values, use of this option as a database key requires prior + agreement between peer administrators. + + The specification of the subfields are: + + Type + 19 = for Endpoint Discriminator + + Length + 3 + length of Address + + Class + The Class field is one octet and indicates the identifier + address space. The most up-to-date values of the LCP Endpoint + Discriminator Class field are specified in the most recent + "Assigned Numbers" RFC [7]. Current values are assigned as + follows: + + 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 + + + + +Sklower, et. al. Standards Track [Page 17] + +RFC 1990 PPP Multilink August 1996 + + + 5 Public Switched Network Directory Number + + Address + The Address field is one or more octets and indicates the + identifier address within the selected class. The length and + content depend on the value of the Class as follows: + + Class 0 - Null Class + + Maximum Length: 0 + + Content: + This class is the default value if the option is not + present in a received Configure-Request. + + Class 1 - Locally Assigned Address + + Maximum Length: 20 + + Content: + + This class is defined to permit a local assignment in the + case where use of one of the globally unique classes is not + possible. Use of a device serial number is suggested. The + use of this class is deprecated since uniqueness is not + guaranteed. + + Class 2 - Internet Protocol (IP) Address + + Fixed Length: 4 + + Content: + + 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 + + Content: + + 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. + + + + +Sklower, et. al. Standards Track [Page 18] + +RFC 1990 PPP Multilink August 1996 + + + Class 4 - PPP Magic-Number Block + + Maximum Length: 20 + + Content: + + This is not an address but a block of 1 to 5 concatenated + 32 bit PPP Magic-Numbers as defined in [2]. This class + provides for automatic generation of a value 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. The use of this class + is deprecated. + + Note that PPP Magic-Numbers are used in [2] to detect + unexpected loopbacks of a link from an endpoint to itself. + There is a small probability that two distinct endpoints + will generate matching magic-numbers. This probability is + geometrically reduced when the LCP negotiation is repeated + in search of the desired mismatch, if a peer can generate + uncorrelated magic-numbers. + + As used here, magic-numbers are used to determine if two + links are in fact from the same peer endpoint or from two + distinct endpoints. The numbers always match when there is + one endpoint. There is a small probability that the + numbers will match even if there are two endpoints. To + achieve the same confidence that there is not a false match + as for LCP loopback detection, several uncorrelated magic- + numbers can be combined in one block. + + Class 5 - Public Switched Network Directory Number + + Maximum Length: 15 + + Content: + + An address in this class contains an octet sequence as + defined by I.331 (E.164) representing an international + telephone directory number suitable for use to access the + endpoint via the public switched telephone network [10]. + +6. Initiating use of Multilink Headers + + When the use of the Multilink protocol has been negotiated on a link + (say Y), and the link is being added to a bundle which currently + contains a single existing link (say X), a system MUST transmit a + Multilink-encapsulated packet on X before transmitting any Multilink- + + + +Sklower, et. al. Standards Track [Page 19] + +RFC 1990 PPP Multilink August 1996 + + + encapsulated packets on Y. + + Since links may be added and removed from a bundle without destroying + the state associated with it, the fragment should be assigned the + appropriate (next) fragment number. As noted earlier, the first + fragment transmitted in the life of a bundle is assigned fragment + number 0. + +7. Closing Member links + + Member links may be terminated according to normal PPP LCP procedures + using LCP Terminate-Request and Terminate-Ack packets on that member + link. Since it is assumed that member links usually do not reorder + packets, receipt of a terminate ack is sufficient to assume that any + multilink protocol packets ahead of it are at no special risk of + loss. + + Receipt of an LCP Terminate-Request on one link does not conclude the + procedure on the remaining links. + + So long as any member links in the bundle are active, the PPP state + for the bundle persists as a separate entity. However, if the there + is a unique link in the bundle, and all the other links were closed + gracefully (with Terminate-Ack), an implementation MAY cease using + multilink + headers. + + If the multilink procedure is used in conjunction with PPP reliable + transmission, and a member link is not closed gracefully, the + implementation should expect to receive packets which violate the + increasing sequence number rule. + +8. Interaction with Other Protocols + + In the common case, LCP, and the Authentication Control Protocol + would be negotiated over each member link. The Network Protocols + themselves and associated control exchanges would normally have been + conducted once, on the bundle. + + In some instances it may be desirable for some Network Protocols to + be exempted from sequencing requirements, and if the MRU sizes of the + link did not cause fragmentation, those protocols could be sent + directly over the member links. + + Although explicitly discouraged above, if there were several member + links connecting two implementations, and independent sequencing of + two protocol sets were desired, but blocking of one by the other was + not, one could describe two multilink procedures by assigning + + + +Sklower, et. al. Standards Track [Page 20] + +RFC 1990 PPP Multilink August 1996 + + + multiple endpoint identifiers to a given system. Each member link, + however, would only belong to one bundle. One could think of a + physical router as housing two logically separate implementations, + each of which is independently configured. + + A simpler solution would be to have one link refuse to join the + bundle, by sending a Configure-Reject in response to the Multilink + LCP option. + +9. Security Considerations + + Operation of this protocol is no more and no less secure than + operation of the PPP authentication protocols [3]. The reader is + directed there for further discussion. + +10. References + + [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. + + + + +Sklower, et. al. Standards Track [Page 21] + +RFC 1990 PPP Multilink August 1996 + + + [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 + + This section documents differences from RFC 1717. There are + restrictions placed on implementations that were absent in RFC 1717; + systems obeying these restrictions are fully interoperable with RFC + 1717 - compliant systems. + +11.1. Negotiating Multilink, per se + + RFC 1717 permitted either the use of the Short Sequence Number Header + Format (SSNHF) or the Maximum Reconstructed Receive Unit (MRRU) + options by themselves to indicate the intent to negotiate multilink. + This specification forbids the use of the SSNHF option by itself; but + does permit the specific of both options together. Any + implementation which otherwise conforms to rfc1717 and also obeys + this restriction will interoperate with any RFC 1717 implementation. + +11.2. Initial Sequence Number defined + + This specification requires that the first sequence number + transmitted after the virtual link has reached to open state be 0. + +11.3. Default Value of the MRRU + + This specfication removes the default value for the MRRU, (since it + must always be negotiated with some value), and specifies that an + implementation must be support an MRRU with same value as the default + MRU size for PPP. + +11.4. Config-Nak of EID prohibited + + This specification forbids the config-Naking of an EID for any + reason. + +11.5. Uniformity of Sequence Space + + This specification requires that the same sequence format be employed + on all links in a bundle. + + + + + + +Sklower, et. al. Standards Track [Page 22] + +RFC 1990 PPP Multilink August 1996 + + +11.6. Commencing and Abating use of Multilink Headers + + This memo specifies how one should start the use of Multilink Headers + when a link is added, and under what circumstances it is safe to + discontinue their use. + +11.7. Manual Configuration and Bundle Assignment + + The document explicitly permits multiple bundles to be manually + configured in the absence of both the Endpoint Descriminator and any + form of authentication. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Sklower, et. al. Standards Track [Page 23] + +RFC 1990 PPP Multilink August 1996 + + +13. Authors' Addresses + + 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 + + + +Sklower, et. al. Standards Track [Page 24] + |