rfc1990.txt

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

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:  [phone]
   EMail:  [e-mail]


   Brian Lloyd
   Lloyd Internetworking
   3031 Alhambra Drive
   Cameron Park, CA 95682

   Phone: [phone]
   EMail:  [e-mail]


   Glenn McGregor
   Lloyd Internetworking
   3031 Alhambra Drive
   Cameron Park, CA 95682

   Phone: [phone]
   EMail: [e-mail]


   Dave Carr
   Newbridge Networks Corporation
   600 March Road
   P.O. Box 13600
   Kanata, Ontario,
   Canada, K2K 2E6

   Phone:  [phone]
   EMail:  [e-mail]


   Tom Coradetti
   Sidewalk Software
   1190 Josephine Road
   Roseville, MN 55113

   Phone: [phone]
   EMail: [e-mail]



Sklower, et. al.            Standards Track                    [Page 24]