rfc2701.txt

来自「著名的RFC文档,其中有一些文档是已经翻译成中文的的.」· 文本 代码 · 共 508 行 · 第 1/2 页

Network Working Group                                         G. Malkin
Request for Comments: 2701                              Nortel Networks
Category: Informational                                  September 1999


                            Nortel Networks
          Multi-link Multi-node PPP Bundle Discovery Protocol

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

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

Abstract

   This document specifies a standard way for Multi-link PPP to operate
   across multiple nodes.  Both the mechanism by which the Bundle Head
   is discovered and the PPP fragment encapsulation are specified.

Acknowledgements

   I would like to thank Joe Frazier for filling in some of the details
   and reviewing this document.

1.  Introduction

   Multi-link PPP [MP] allows a dial-in user to open multiple PPP
   connections to a given host.  In general, this is done on an on-
   demand basis.  That is, a secondary link, or multiple secondary
   links, are established when the data load on the primary link, and
   any previously established secondary links, nears capacity.  As the
   load decreases, the secondary link(s) may be disconnected.

   Many dial-in hosts which support multi-link PPP dial the same phone
   number for all links.  This implies that there exists a rotary at the
   Point Of Presence (POP) which routes incoming calls to a bank of
   modems.  These may be physically independent modems connected to
   Remote Access Server (RAS) and a rotary of analog phone lines, or a
   RAS with internal modems connected to analog lines or a T1/E1 or
   T3/E3 channel.  In any case, a given RAS can only handle just so many
   simultaneous connections.  A typical POP may need to support hundreds
   of connections, but no RAS today can handle that many.  This creates
   a problem when a user's primary PPP connection is established to one



Malkin                       Informational                      [Page 1]

RFC 2701                          MMP                     September 1999


   RAS in a POP and a secondary connection is established to another.
   This may occur because the first RAS has no available modems, or
   because incoming calls are assigned to ports in a round-robin
   fashion, for example, and the second call is simply assigned to
   another RAS.

   The solution to this problem is to provide a mechanism by which a RAS
   can determine if a Multi-link PPP connection is a primary or
   secondary and, if a secondary, where the Bundle Head (the process
   within a RAS which reassembles the PPP fragments transmitted over the
   primary and secondary links) resides.  If the Bundle Head resides on
   a different RAS, a protocol must be used to transfer the PPP
   fragments to the RAS containing the Bundle Head so that the PPP frame
   can be reassembled.

   Section 2 of this document specifies the Discovery Mechanism.
   Section 3 specifies the Transfer Protocol.  Section 4 specifies the
   configuration parameters needed for the Discovery Protocol.

2.  Bundle Head Discovery Mechanism

   When a user dials into a RAS and negotiates Multi-link PPP (MP)
   during the Link Control Protocol (LCP) phase, the RAS must determine
   which one of the following three cases exists:

   1- This is the primary (first) link of the MP connection.  In this
      case, the RAS should create the Bundle Head.

   2- This is a secondary link of the MP connection and the Bundle Head
      resides on this RAS.  In this case, the RAS should add the link to
      the Bundle (standard MP).

   3- This is a secondary link of the MP connection and the Bundle Head
      resides on a different RAS.  In this case, the RAS should
      establish a path (see section 3) to the RAS that has the Bundle
      Head, and use that path to transfer MP fragments.

   In operation, a RAS will make the determination for case 2 first
   (because it is the easiest and requires no communication with other
   RASes.  If the Bundle Head is not local, the Discovery Protocol is
   used to determine where the Bundle Head is, if it exists at all.










Malkin                       Informational                      [Page 2]

RFC 2701                          MMP                     September 1999


2.1 Packet Format

   See "IANA Considerations" (section 6) for UDP port number assignment.

   A Discovery Message has the following format:

      +------+------+------------+------+----======----+
      | type |length| random ID  | hash | endpoint ID  |
      +------+------+------------+------+----======----+

   where:

   type - 2 octets

      Message type: 1-query, 2-response.

   length - 2 octets

      The length (in octets) of the endpoint ID.

   Random ID - 4 octets

      A random identifier generated by the RAS used to resolve
      contention.  See "Contention Handling" (section 2.4) for the use
      of this field.

   hash - 2 octets

      The unsigned sum (modulo 2^16) of the unsigned octets of the
      Endpoint ID.  A value of zero indicates that no hash has been
      generated.  See "Endpoint Identifier Matching" (section 2.2) for
      the use of this field.

   endpoint ID - variable length

      The endpoint identifier of the connection.  From the discovery
      protocol's point of view, this is an opaque value.  However, to
      ensure multi-vendor interoperability, the format of this field
      must be defined.  The descriptions of, and legal values for, the
      fields in the endpoint ID are defined in [MP].











Malkin                       Informational                      [Page 3]

RFC 2701                          MMP                     September 1999


         +------+------+--==--+------+------+--==--+------+--==--+
         |remote|remote|remote|local |local |local |user  | user |
         |EPD   |EPD   |EPD   |EPD   |EPD   |EPD   |name  | name |
         |class |length|data  |class |length|data  |length| data |
         +------+------+--==--+------+------+--==--+------+--==--+

      Notes:
         EPD = EndPoint Descriminator.
         remote = dial-in host.
         local = RAS.
         class and length fields are 1-octet in length.
         data fields are of variable (including zero) length.

   The MP protocol requires that the RASes all have the same Local EPD.
   For MMP, this implies that a RAS may not use its IP or Ethernet
   address as an EPD.  This also implies that all RASes on a rotary must
   have the same EPD.  RASes on different rotaries may share different
   EPDs.  The Local EPD is included in the endpoint identifier to ensure
   that RASes on different rotaries, but sharing a common Ethernet, will
   not join a particular discovery if the Remote EPDs just happen to be
   the same.

   Except for unicast Response Messages, all messages are sent to the
   multicast address specified in "IANA Considerations".  If a system
   cannot send multicast messages, the limited broadcast address
   (255.255.255.255) should be used.

2.2 Endpoint Identifier Matching

   Comparing Endpoint IDs can be time consuming.  First, the classes of
   the EPDs must be determined, then the values compared.  These
   comparisons might be fast arithmetic compares or slow octet-wise
   compares of 20-octet long values.  To improve performance, because
   the protocol is time-driven, the hash field may be used for a fast
   comparison.

   When a Bundle Head is created, the hash is created and stored along
   with the Endpoint ID.  When a Query or Response Message is generated,
   the hash is created and stored in the message.  When a RAS receives a
   message, it can do a quick comparison of the hash in the message to
   the hashes in its tables.  If a hash does not match, the Endpoint ID
   cannot match.  However, if a hash does match, the Endpoint IDs must
   be properly compared to verify the match.








Malkin                       Informational                      [Page 4]

RFC 2701                          MMP                     September 1999


   Obviously, there is a cost associated with creating the hashes, but
   they are created only once per message and once for each Bundle Head
   creation.  However, the comparisons occur multiple times in multiple
   RASes for each new secondary connection.  Therefore, there is a net
   savings in processing.

2.3 Protocol Operation

   Throughout this section, configurable variables are specified by
   their names (e.g., ROBUSTNESS refers to the number of transmits).

   The Discovery Protocol begins by multicasting ROBUSTNESS Query
   Messages at QUERY_INTERVAL intervals.  If no Response Message for
   that Request is received within QUERY_INTERVAL of the last broadcast
   (a total time of ROBUSTNESS * QUERY_INTERVAL), the RAS assumes that
   this is the primary link and begins to build the Bundle Head.  It
   then sends a multicast Response Message (in case another link comes
   up after the time-out but before the Bundle Head is built).  If a
   Response Message is received (i.e., a Bundle Head exists on another
   RAS), no additional Query Messages are sent and the RAS establishes a
   path to the RAS containing the Bundle Head.

   If a RAS receives a Query Message for an MP connection for which it
   has the Bundle Head, it sends a unicast Response Message to the