rfc2125.txt

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

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


5.  BAP Operation

5.1.  Link Management

   BAP defines packets, parameters and negotiation procedures to allow
   two endpoints to negotiate gracefully adding and dropping links from
   a multilink bundle.  An implementation can:

      o Request permission to add a Link to a bundle (Call-Request)

      o Request that the peer add a link to a bundle via a callback
        (Callback-Request)

      o Negotiate with the peer to drop a link from a bundle (this
        implies that the peer can refuse) (Link-Drop-Query-Request)

   After BACP reaches the opened state, either peer MAY request that
   another link be added to the bundle by sending a BAP Call- or
   Callback-Request packet.  A Call-Request packet is sent if the
   implementation wishes to originate the call for the new link, and a
   Callback-Request packet is sent if the implementation wishes its peer
   to originate the call for the new link.  The implementation receiving
   a Call- or Callback-Request MUST respond with a Call- or Callback-
   Response with a valid Response Code.

   After BACP reaches the opened state, either peer MAY request that a
   link be dropped from the bundle.  A BAP Link-Drop-Query-Request
   packet is sent to the peer to negotiate dropping a link.  The peer
   MUST respond with a Link-Drop-Query-Response.   If the peer is
   agreeable to dropping the link the implementation MUST issue an LCP
   Terminate-Request to initiate dropping the link.

   If an implementation wishes to force dropping a link without
   negotiation, it should simply send an LCP Terminate-Request packet on
   the link (without sending any BAP Link-Drop-Query-Request).

   After an LCP Terminate-Request is sent an implementation SHOULD stop
   transmitting data packets on that link, but still continue to receive
   and process data packets normally until receipt of a Terminate-Ack
   from the peer.  The receiver of an LCP Terminate-Request SHOULD stop
   transmitting packets before issuing the Terminate-Ack.  This
   procedure will insure that no data is lost in either direction.









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


5.2.  Bandwidth Management

   BAP allows two peer implementations to manage the bandwidth available
   to the protocols using the multilink bundle by negotiating when to
   add and drop links (See Link Management).  Use of the negotiation
   features of BAP makes it unnecessary to require a 'common' algorithm
   for determining when to add and remove links in a multilink bundle.

   BOD decisions can be based on link utilization.  A BAP implementation
   may monitor its transmit traffic, both transmit and receive traffic,
   or choose not to monitor traffic in either direction.  If a server
   system implements bi-directional monitoring, it will allow BOD
   operation with a client that does not monitor traffic in either
   direction, which will minimize the end-user's configuration.  When an
   implementation decides that it is time to remove a link due to
   traffic monitoring, it MUST transmit a Link-Drop-Query-Request to
   inquire if the peer agrees to drop a link from the current multilink
   bundle.  When an implementation receives a Link-Drop-Query-Request,
   it SHOULD base its response on the traffic it is monitoring.  It MUST
   NOT base its response solely on its receive data heuristics.

   The operation of the Link-Drop-Query-Request and -Response datagrams
   causes a link in a multilink bundle to be left up as long as either
   implementation that is monitoring link utilization determines that it
   is necessary.

   BOD decisions can also be based on the resources (e.g., physical
   port, B-channel, etc.) available to an implementation.  For example,
   an implementation might remove a link from a multilink bundle to
   answer an incoming voice call, or might add a link when a line
   becomes free due to the termination of a separate PPP call on another
   port.  An implementation MUST use an LCP Terminate-Request to remove
   a link due to a resource condition.

5.3.  BAP Packets

   All of the BAP Request and Indication packets require a Response
   packet in response before taking any action.

   An implementation MUST set a timer when sending a Request or
   Indication packet. The value of this timer SHOULD depend on the type
   and speed of the link or links in use.  Upon expiration of this
   timer, the implementation MUST retransmit the request or indication,
   with an identical identification number.  This procedure will insure
   that the peer receives the proper request or indication even if a
   packet is lost during transmission.  If a response packet is lost the
   peer will realize that this is not a new request or indication
   packet.



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


   If the number of retransmissions exceeds the number supported by the
   implementation for this packet, the implementation MAY take
   appropriate recovery action. For example, if no response to a Link-
   Drop-Query-Request is received after 2 retransmissions, an
   implementation MAY initiate dropping the link by sending an LCP
   Terminate-Request for that link.

   Since BAP packets help determine the amount of bandwidth available to
   an implementation, PPP SHOULD give them priority over other data
   packets when transmitting.  This will help insure the prompt addition
   and removal of links in a multilink bundle.  This is especially
   important when adding links to a bundle due to bandwidth constraints.

5.4.  Race Conditions

   In order to resolve race conditions, an implementation MUST implement
   the BACP Favored-Peer Configuration Option.

   A race condition can occur if both implementations send a Call-
   Request, Callback-Request or Link-Drop-Query-Request at the same
   time.  These race conditions should be solved as follows:

      If each implementation sends a Call-Request or Callback-Request at
      the same time, the implementation with the lowest BACP Favored-
      Peer Magic-Number value SHOULD be favored.

      If each implementation sends a Link-Drop-Query-Request at the same
      time, the same scheme SHOULD be used as for Call-Requests.

5.5.  BAP Datagram Format

   Description

      Before any BAP packets may be communicated, PPP MUST reach the
      Network-Layer Protocol phase, and BACP MUST reach the opened
      state.

      Exactly one BAP packet is encapsulated in the Information field of
      PPP Data Link Layer frames where the Protocol field indicates type
      hex c02d (Bandwidth Allocation Protocol).

      Because ISDN Terminal Adapters sometimes are used to do multilink
      with a non-multilink aware client, BAP datagrams MUST NOT be
      compressed or encrypted.  Otherwise, the ISDN TA may not be able
      to properly intercept BAP datagrams needed to control the
      multilink connection.  This refers to compression of the whole
      datagram; Address-and-Control-Field-Compression and Protocol-
      Field-Compression are allowed if properly negotiated.



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


      The maximum length of a BAP packet transmitted over a PPP link is
      the same as the maximum length of the Information field of a PPP
      data link layer frame.

      Bandwidth Allocation Protocol datagrams can be catagorized as
      either Request, Indication or Response packets.  Every Request and
      Indication datagram has a corresponding Response packet.  Request
      and Indication datagrams have a slightly different format from
      Response datagrams, as the Response datagrams include a Response
      Code octet.

      All of the BAP datagrams MUST be supported by an implementation.
      However, that does not mean an implementation must support all BAP
      datagram actions.  An implementation MAY send a Request-Rej to a
      Request that it does not implement.

   A summary of the Bandwidth Allocation Protocol datagram Request and
   Indication packet 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      |  Identifier   |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Data ...
   +-+-+-+-+-+-+-+-+

   A summary of the Bandwidth Allocation Protocol datagram Response
   packet 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      |  Identifier   |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Response Code |    Data ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type

      The Type field is one octet and identifies the type of BAP
      datagram packet.  Datagram types are defined as follows.  This
      field is coded in binary coded hexadecimal.






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


         01       Call-Request
         02       Call-Response
         03       Callback-Request
         04       Callback-Response
         05       Link-Drop-Query-Request
         06       Link-Drop-Query-Response
         07       Call-Status-Indication
         08       Call-Status-Response

      The various types of BAP datagrams are explained in the following
      sections.

   Identifier

      The Identifier field is one octet and is binary coded.  It aids in
      matching Requests and Indications with Responses.  Call-Status-
      Indication packets MUST use the same Identifier as was used by the
      original Call-Request or Callback-Request that was used to
      initiate the call.  All other Request or Indication packets MUST
      use a unique Identifier for each new Request or Indication.  All
      Response packets MUST use the same Identifier as the Identifier in
      the Request or Indication packet being responded to.  When re-
      transmitting a request or indication, the Identifier MUST be the
      same as the Identifier used on the previous transmission of the
      request or indication.

   Length

      The Length field is two octets and indicates the length of the
      packet including the Type, Identifier, Length and Options fields.
      It is binary encoded. Octets outside the range of the Length field
      should be treated as Data Link Layer padding and should be ignored
      on reception.

   Response Code

      The Response Code is only present in Response datagrams.  It is
      binary coded and can have the following values:

         00000000        Request-Ack
         00000001        Request-Nak
         00000010        Request-Rej
         00000011        Request-Full-Nak

      The Request-Ack Response Code is sent to indicate that the Request
      or Indication command is valid and was successfully received by an
      implementation. The Request-Nak Response Code is sent to indicate
      that the Request command was received, but an implementation does



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


      not want the requested action performed at this time.  If a
      Response containing a Request-Nak Response Code is received, the
      original Request MAY be retried after an implementation determines
      that sufficient time has elapsed.  The Request-Rej Response Code
      is sent to indicate that the Request command received by an
      implementation is not implemented (i.e., if reception of a
      particular request type is not supported by the peer.) The
      Request-Full-Nak Response Code is sent to indicate that the
      Request command was received, but an implementation does not want
      the requested action performed.  The Request-Full-Nak is used to
      indicate that an implementation has reached the maximum (for a
      Call- or Callback-Request) or the minimum (for a Link-Drop-Query-
      Request) bandwidth configured or available for this multilink
      bundle.  If a Response containing a Request-Full-Nak Response Code
      is received, the original Request SHOULD NOT be retried until the
      total bandwidth of the multilink bundle has changed.

   Data

      The Data field is variable in length, and will usually contain the
      list of zero or more BAP Options that the sender desires to
      transmit. The format of BAP Options is described in a later
      chapter.

5.5.1.  Call-Request

   Before originating a call to add another link to a multilink bundle,
   an implementation MUST transmit a Call-Request packet.  This will
   inform the receiver of the request to add another link to the bundle
   and give the receiver a chance to inform the implementation of the
   phone number of a free port that can be called.

   The options field MUST include the Link-Type option.  The options
   field MAY include the No-Phone-Number and/or the Reason options.

   Upon reception of a Call-Request, a Call-Response datagram MUST be
   transmitted.

5.5.2.  Call-Response

   An implementation MUST transmit a Call-Response datagram in response
   to a received Call-Request datagram.  If the Call-Request is
   acceptable, the Call-Response MUST have a Response Code of Request-
   Ack.  The Phone-Delta option MUST be included in a Call-Response
   packet with a Response Code of Request-Ack unless the Call-Request
   included the No-Phone-Number option. The options field MAY include
   the Reason and/or Link-Type options.




Richards & Smith            Standards Track                    [Page 12]