rfc2125.txt

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

Network Working Group                                     C. Richards
Request for Comments: 2125                          Shiva Corporation
Category: Standards Track                                    K. Smith
                                          Ascend Communications, Inc.
                                                           March 1997


              The PPP Bandwidth Allocation Protocol (BAP)
          The PPP Bandwidth Allocation Control Protocol (BACP)

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Abstract

   This document proposes a method to manage the dynamic bandwidth
   allocation of implementations supporting the PPP multilink protocol
   [2].  This is done by defining the Bandwidth Allocation Protocol
   (BAP), as well as its associated control protocol, the Bandwidth
   Allocation Control Protocol (BACP).  BAP can be used to manage the
   number of links in a multilink bundle.  BAP defines datagrams to co-
   ordinate adding and removing individual links in a multilink bundle,
   as well as specifying which peer is responsible for which decisions
   regarding managing bandwidth during a multilink connection.

Table of Contents

   1.     Introduction ..........................................    2
      1.1       Specification of Requirements ...................    2
      1.2       Terminology .....................................    3
   2.     New LCP Configuration Option ..........................    3
      2.1       Link Discriminator ..............................    3
   3.     BACP Operation ........................................    4
   4.     BACP Configuration Options ............................    5
      4.1       Favored-Peer ....................................    5
   5.     BAP Operation .........................................    7
      5.1       Link Management .................................    7
      5.2       Bandwidth Management ............................    8
      5.3       BAP Packets .....................................    8
      5.4       Race Conditions .................................    9
      5.5       BAP Datagram Format .............................    9
         5.5.1  Call-Request ....................................   12
         5.5.2  Call-Response ...................................   12



Richards & Smith            Standards Track                     [Page 1]

RFC 2125                       PPP BACP                       March 1997


         5.5.3  Callback-Request ................................   13
         5.5.4  Callback-Response ...............................   13
         5.5.5  Link-Drop-Query-Request .........................   13
         5.5.6  Link-Drop-Query-Response ........................   13
         5.5.7  Call-Status-Indication ..........................   14
         5.5.8  Call-Status-Response ............................   14
   6.     BAP Datagram Options ..................................   14
      6.1       Link-Type .......................................   15
      6.2       Phone-Delta .....................................   17
         6.2.1  Phone-Delta Sub-Options .........................   18
      6.3       No-Phone-Number-Needed ..........................   19
      6.4       Reason ..........................................   20
      6.5       Link-Discriminator ..............................   21
      6.6       Call-Status .....................................   21
   Appendix - List of BAP datagrams and associated fields .......   23
   ACKNOWLEDEMENTS ..............................................   23
   SECURITY CONSIDERATIONS ......................................   23
   REFERENCES ...................................................   24
   CHAIR'S ADDRESS ..............................................   24
   EDITORS'S ADDRESSES ..........................................   24

1.  Introduction

   As PPP multilink implementations become increasingly common, there is
   a greater need for some conformity in how to manage bandwidth over
   such links. BACP and BAP provide a flexible yet robust way of
   managing bandwidth between 2 peers.  BAP does this by defining Call-
   Control packets and a protocol that allows peers to co-ordinate the
   actual bandwidth allocation and de-allocation.  Phone number deltas
   may be passed in the Call-Control packets to minimize the end user's
   configuration.

1.1.  Specification of Requirements

   In this document, several words are used to signify the requirements
   of the specification.  These words are often capitalized.

   MUST      This word, or the adjective "required", means that the
             definition is an absolute requirement of the specification.

   MUST NOT  This phrase means that the definition is an absolute
             prohibition of the specification.

   SHOULD    This word, or the adjective "recommended", means that there
             may exist valid reasons in particular circumstances to
             ignore this item, but the full implications must be
             understood and carefully weighed before choosing a
             different course.



Richards & Smith            Standards Track                     [Page 2]

RFC 2125                       PPP BACP                       March 1997


   MAY       This word, or the adjective "optional", means that this
             item is one of an allowed set of alternatives.  An
             implementation which does not include this option MUST be
             prepared to interoperate with another implementation which
             does include the option.

1.2.  Terminology

   This document frequently uses the following terms:

   peer      The other end of the point-to-point link

   silently discard
         This means the implementation discards the packet without
         further processing.  The implementation SHOULD provide the
         capability of logging the error, including the contents of the
         silently discarded packet, and SHOULD record the event in a
         statistics counter.

   BOD (bandwidth on demand)
         BOD refers to the ability of a system to allocate and remove
         links in a multilink system to change the bandwidth of a
         multilink bundle.  This may be done in response to changing
         line conditions and it also may be done in response to changing
         resource conditions.  In either case, changing bandwidth
         dynamically during a multilink connection is referred to as
         BOD.

2.  New LCP Configuration Option

   Implementations MUST implement LCP as defined in [1].  LCP MUST be in
   the Network-Layer Protocol phase before BACP can be negotiated.

2.1.  Link Discriminator

   Description

      This LCP Configuration Option is used to declare a unique
      discriminator for the link that the option is sent over.  This
      option MUST be negotiated by LCP on every link.  BAP uses the link
      discriminator to differentiate the various links in a multilink
      bundle. Each link in a multilink bundle MUST have a unique
      discriminator.  The discriminator is independent for each peer, so
      each link may have 2 different LCP Link Discriminator values, one
      for each peer. When the Link Discriminator is sent in a BAP
      packet, the transmitter sends the Link Discriminator Option value
      received from its peer in the peer's LCP Configure Request packet.




Richards & Smith            Standards Track                     [Page 3]

RFC 2125                       PPP BACP                       March 1997


   A summary of the Link Discriminator LCP Option format is shown below.
   The fields are transmitted from left to right.

    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      |     Length    |       Link Discriminator      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type

      23 for Link Discriminator option.

   Length

      4

   Link Discriminator

      The Link Discriminator field is 2 octets in Length, and it
      contains a unique identifier used to indicate a particular link in
      a multilink bundle.  The Link Discriminator for a link MUST be
      unique among the Link Discriminators assigned by this endpoint for
      this bundle.  The Link Discriminator MAY be assigned in a
      sequential, monotonically increasing manner.

3.  BACP Operation

   BACP uses the same packet exchange mechanism as the Link Control
   Protocol defined in [1].  BACP packets MUST NOT be exchanged until
   PPP has reached the Network-Layer Protocol phase.  BACP packets
   received before this phase is reached should be silently discarded.

   BACP is negotiated once per multilink bundle.  If BACP is negotiated
   on any of the links in a multilink bundle, it is opened for all of
   the links in the bundle.

   The Bandwidth Allocation Control Protocol is exactly the same as the
   Link Control Protocol [1] with the following exceptions:

      Data Link Layer Protocol Field

         Exactly one BACP packet is encapsulated in the Information
         field of PPP Data Link Layer frames where the Protocol field
         indicates Type hex c02b (Bandwidth Allocation Control
         Protocol).





Richards & Smith            Standards Track                     [Page 4]

RFC 2125                       PPP BACP                       March 1997


      Code field

         Only Codes 1 through 7 (Configure-Request, Configure-Ack,
         Configure-Nak, Configure-Reject, Terminate-Request, Terminate-
         Ack and Code-Reject) are used.  Other Codes should be treated
         as unrecognized and should result in Code-Rejects.

   Configuration Option Types

         BACP has a distinct set of Configuration Options, which are
         defined in the next section.

4.  BACP Configuration Options

   BACP Configuration Options allow negotiation of desirable BACP
   parameters.  These options are used in Config-Request, Config-Ack,
   Config-Nak, and Config-Reject packets.  BACP uses the same
   Configuration Option format defined for LCP [1], with a seperate set
   of Options.

   Current values of BACP Configuration Options are assigned as follows:

      1     Favored-Peer

4.1.  Favored-Peer

   Description

      This Configuration Option is used to determine which peer is
      favored in the event of a race condition in which 2 peers
      simultaneously transmit the same BAP request.  Each peer
      negotiates a 4 octet magic number, which is successfully
      negotiated when the 2 Magic-Numbers are different.  The favored
      peer is the peer that transmits the lowest Magic-Number in its
      Favored-Peer Configuration Option.

      The Favored-Peer Configuration Option MUST be implemented.














Richards & Smith            Standards Track                     [Page 5]

RFC 2125                       PPP BACP                       March 1997


      BACP will usually be negotiated after only one link of a multilink
      bundle has reached the Network-Layer Protocol phase. In this
      situation, it is acceptable for the peer that initiated the
      connection to use a Magic-Number of 1, and the peer that responded
      to the connection to use a Magic-Number of 0xFFFFFFFF.  If a
      multilink bundle has been established with links that were
      originated by each peer, or if it is not clear which peer has
      initiated a link (on a leased line, for example), then a random
      number MUST be used for the Magic-Number.  Refer to the
      description of the LCP Magic-Number Configuration Option in [1]
      for an explanation of how to create a useful random number.

      When a Configure-Request is received with a Favored-Peer
      Configuration Option, the received Magic-Number is compared with
      the Magic-Number of the last Configure-Request sent to the peer.
      If the two Magic-Numbers are different, then the Favored-Peer
      negotiation has been successful, and the Favored-Peer Option
      SHOULD be acknowledged.  If the two Magic-Numbers are equal, a
      Configure-Nak MUST be sent specifying a different Magic-Number
      value.  A new Configure-Request SHOULD NOT be sent to the peer
      until normal processing would cause it to be sent (that is, until
      a Configure-Nak is received or the Restart timer runs out).

   A summary of the Favored-Peer Option format is shown below.  The
   fields are transmitted from left to right.

    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      |    Length     |          Magic-Number
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         Magic-Number (cont)       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type

      1 for Favored-Peer

   Length

      6

   Magic-Number

      The Magic-Number field is four octets, and indicates a number
      which is very likely to be unique to one end of the link.  A
      Magic-Number of zero is illegal and MUST always be Nak'd.