rfc1990.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.


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]