rfc2701.txt

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

   querier.  Note that no repetition of the Response Message is
   necessary because, if it is lost, the querier's next query message
   will trigger a new Response Message.

2.4 Contention Handling

   If, while sending Query Messages, a Query Message for the same MP
   connection is received, it indicates that the Dial-in Node has
   brought up multiple links simultaneously.  The resolution to this
   contention is to elect the bundle head.  To do this, each RAS waits
   until all Query Messages are sent (ROBUSTNESS * QUERY_INTERVAL).  At
   that time, the RAS with the lowest Random ID becomes the Bundle Head.
   If two or more RASes have the same Random ID, the RAS with the lowest
   IP address becomes the Bundle Head.  That RAS then sends TWO Response
   Messages, with a QUERY_INTERVAL interval, and indicates to the MP
   process that a Bundle Head should be formed.  When the other RAS(es)
   receive the Response Message, they cease broadcasting (if they
   haven't already sent ROBUSTNESS Query Messages), stop listening for
   additional Response Messages, and indicate to their respective MP
   processes where the Bundle Head resides.

   Note that a RAS generates a Random ID for each connection and uses
   that value for all Query and Response messages associated with that
   connection.  The same Random ID must not be reused until it can be



Malkin                       Informational                      [Page 5]

RFC 2701                          MMP                     September 1999


   guaranteed that another RAS will not mistake the message for an old
   message from a previous connection.  For this reason, it is
   recommended that the Random ID be either monotonically increasing or
   a clock value (either time since boot or time of day).

2.5 MP Operation

   MP must use the following algorithm to ensure that there are no
   windows of vulnerability during which multiple Bundle Heads might be
   created for the same MP connection.

   When an MP link is negotiated, MP first checks to see if it already
   has the Bundle Head for this connection (i.e., is this a secondary
   link).  If it does, it should attach to it and not initiate a
   discovery.  As an optimization, if MP does not have a Bundle Head for
   this connection, but does have a existing secondary link for it, MP
   should attach to the known Bundle Head without initiating discovery.

   If MP knows of no Bundle Head for this connection, it should initiate
   a discovery.  If the discovery should locate a Bundle Head, it should
   attach to the indicated bundle head.  If no Bundle Head is found, MP
   should create a Bundle Head.

   When a RAS determines that it is to become the Bundle Head for a
   connection, it should establish the Bundle Head as quickly as
   possible so Query Messages for that connection from other RASes will
   be recognized.  If a RAS indicates that it will become the Bundle
   Head, but delays establishment of it, other RASes may time out on
   their discovery and begin to establish additional Bundle Heads of
   their own.

3.  Transfer Protocol

   The Layer 2 Tunneling Protocol (L2TP) [L2TP] will be used to transfer
   PPP fragments from a RAS containing a secondary link to the RAS
   containing the Bundle Head.  By specifying the use of an existing
   protocol, it is neither necessary to create nor implement a new
   protocol.

4.  Configuration

   There are two required configuration switches and one conditional
   configuration switch.  None of the switches are optional.








Malkin                       Informational                      [Page 6]

RFC 2701                          MMP                     September 1999


4.1 Robustness - required

   This switch sets the number of transmits (repetitions) for Query
   Messages.  It may be set between 1 and 15.  The default is 3.  Be
   aware that lower settings may create windows of vulnerability.
   Higher settings may cause MP timeouts, but may be needed on very
   lossy or congested networks.

4.2 Query Interval - required

   This switch sets the interval between Query Messages and the interval
   between multicast Response Messages.  It should be calibrated in
   deciseconds (1/10 second) and may be set between 1 and 15.  The
   default is 1.  Be aware that higher settings may cause MP timeouts,
   but may be needed on very slow systems/networks.

4.3 TTL - conditional

   This switch sets the IP Time-To-Live (TTL) of all Discovery packets.
   For systems which are using the limited broadcast address, this
   switch should not be implemented and the TTL should be set to 1.  The
   default value should be 1.

5.  Security Considerations

   No security is designed into the Discovery Mechanism.  When not
   forwarding multicast packets (or when using the limited broadcast
   address), the discovery packets are restricted to a single LAN.  If
   the LAN is physically secure, there is no need for software security.
   If the multicast packets are forwarded, but the range is limited to a
   small, physically secure network (e.g., a POP), there is still no
   need for software security.  If the discovery packets are allowed to
   cross an internet (and this is NOT recommended for timing reasons),
   authentication of RASes may be done with IPSEC.  For increased
   security on a LAN, or in a POP, IPSEC may still be used.

   L2TP security is discussed in [L2TP].

6.  IANA Considerations

   UDP port number: 581
   Multicast address: 224.0.1.69









Malkin                       Informational                      [Page 7]

RFC 2701                          MMP                     September 1999


7.  References

   [MP]    Sklower, K., Lloyd, B., McGregor, G., Carr, D. and
           T. Coradetti, "The PPP Multilink Protocol (MP)", RFC 1990,
           August 1996.

   [L2TP]  Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G.
           and B. Palter, "Layer Two Tunneling Protocol "L2TP"",  RFC
           2661, August 1999.

Author's Address

   Gary Scott Malkin
   Nortel Networks
   11 Elizabeth Drive
   Chelmsford, MA  01824-4111

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
































Malkin                       Informational                      [Page 8]

RFC 2701                          MMP                     September 1999


Full Copyright Statement

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Malkin                       Informational                      [Page 9]