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 DiscriminatorSklower, et. al.            Standards Track                    [Page 13]RFC 1990                     PPP Multilink                   August 19965.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 19965.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 haveSklower, 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 BlockSklower, 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]