doc: Add RFC documents

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]
+