rfc1717.txt

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

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


        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.

        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.





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


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

   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.




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


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

8.  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.





















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


9.  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, Work in Progress.

   [6] Rand, D., "PPP Reliable Transmission", PPP Extensions Working
       Group, Work in Progress.

   [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.

  [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.












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


10.  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]












Sklower, Lloyd, McGregor & Carr                                [Page 21]