rfc1717.txt

来自「<VC++网络游戏建摸与实现>源代码」· 文本 代码 · 共 1,180 行 · 第 1/4 页

   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, Lloyd, McGregor & Carr                                [Page 11]

RFC 1717                     PPP Multilink                 November 1994


   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, Lloyd, McGregor & Carr                                [Page 12]

RFC 1717                     PPP Multilink                 November 1994


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 option indicates that the system sending it
   implements the PPP Multilink Protocol, and unless rejected, will
   construe all packets receive 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.  A system MUST NOT accept the Multilink MRRU LCP
   Option if it is not willing to symmetrically have the packets it
   sends interpreted in the same fashion.

   This option also advises the peer that the implementation will be
   able to reconstruct a PPP packet whose payload will contain the
   number of bytes as Max-Receive-Reconstructed-Unit.

   A system MAY indicate the desire to conduct multilink operation
   solely by use of the Multilink Short Sequence Number Header Format
   LCP option (discussed next); the default value for MRRU option is
   1600 bytes if not otherwise explicitly negotiated.

   Note: this option corresponds to what would have been the MRU of the
   bundle when conceptualized as a PPP-like entity.

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.  By default
   sequence, numbers are 24 bits long.  When this option is received, an
   implementation MUST either transmit all subsequent multilink packets
   on all links of the bundle with 12 bit sequence numbers or
   configure-NAK or configure-Reject the option.




Sklower, Lloyd, McGregor & Carr                                [Page 13]

RFC 1717                     PPP Multilink                 November 1994


   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.

   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 either of the Multilink MRRU or Short Sequence
   options, 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.

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



Sklower, Lloyd, McGregor & Carr                                [Page 14]

RFC 1717                     PPP Multilink                 November 1994


   (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
   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, 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.





Sklower, Lloyd, McGregor & Carr                                [Page 15]

RFC 1717                     PPP Multilink                 November 1994


   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

        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.