rfc2125.txt

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


RFC 2125                       PPP BACP                       March 1997


5.5.3.  Callback-Request

   An implementation that wants its peer to originate another link to
   add to the multilink bundle MUST transmit a Callback-Request packet
   to its peer.  This will inform the receiver of the request to add
   another link to the bundle along with the number to be called.

   The options field MUST include the Link-Type and Phone-Delta options.
   The Reason option MAY also be included.

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

5.5.4.  Callback-Response

   An implementation MUST transmit a Callback-Response datagram in
   response to a received Callback-Request datagram.  If the Callback-
   Request is acceptable, the Callback-Response MUST have a Response
   Code of Request-Ack.  A Callback-Response packet MAY include the
   Link-Type option.

5.5.5.  Link-Drop-Query-Request

   An implementation that determines that a link is no longer needed and
   wishes to negotiate dropping it (e.g., based on a throughput BOD
   decision), MUST transmit a Link-Drop-Query-Request packet. The
   options field MUST include the Link-Discriminator option (containing
   the receiver's Link-Discriminator), and MAY include the Reason
   option.

   Upon reception of a Link-Drop-Query-Request, an implementation MUST
   transmit a Link-Drop-Query-Response datagram.  The Response-Code will
   be Request-Ack if it agrees to drop the link; if it does not agree to
   drop the link the Response-Code will be Request-Nak or Request-Full-
   Nak.  After the receipt of a Link-Drop-Query-Response with a Response
   Code of Request-Ack, the transmitter of the Link-Drop-Query-Request
   MUST initiate tear down of the indicated link by sending an LCP
   Terminate-Request packet on the designated link.

5.5.6.  Link-Drop-Query-Response

   An implementation transmits a Link-Drop-Query-Response datagram in
   response to a received Link-Drop-Query-Request datagram.  If the
   implementation agrees (e.g., based on its throughput BOD algorithm)
   to reduce the bandwidth of the multilink bundle, then the Response
   Code MUST be set to Request-Ack.





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


   The Reason option MAY be included in the Link-Drop-Query-Response
   packet.

   The Link-Drop-Query-Request datagram MUST be supported, as well as
   the underlying implementation to respond to it.  This means that a
   Link-Drop-Query-Response with a Response Code of Request-Rej MUST NOT
   be transmitted in response to a Link-Drop-Query-Request.

5.5.7.  Call-Status-Indication

   After an implementation attempts to add a link to a bundle as the
   result of a Call-Request or a Callback-Request, it MUST send a Call-
   Status-Indication packet to its peer to indicate if the attempt to
   add the link succeeded or failed.  One Indication MUST be sent for
   each attempt made. For each Call-Status-Indication packet transmitted
   with the Call-Status Option Action octet set to Retry, a subsequent
   Call-Status-Indication packet MUST be sent to indicate the success or
   failure of the retry.  The Call-Status option MUST be included to
   inform the receiver of the status of the attempt to add a link and
   the action the implementation will take in case of failure.  The
   reason option MAY also be included in the Call-Status-Indication
   packet.

   Upon reception of a Call-Status-Indication packet which indicates a
   failure, an implementation may log the failure and reason code.  Upon
   reception of any Call-Status-Indication packet, a Call-Status-
   Response datagram MUST be transmitted.

5.5.8.  Call-Status-Response

   An implementation transmits a Call-Status-Response datagram in
   response to a received Call-Status-Indication datagram.  The Response
   Code field MUST be set to Request-Ack in this packet.  The Reason
   option MAY be included in this packet.

6.  BAP Datagram Options

   BAP Datagram Options are used in various BAP packets.  Their use in
   various packets is as defined below.  The format of these options
   loosely follows the formatting conventions of LCP Configuration
   Options.  When there are multiple BAP Options in one BAP packet, the
   options MAY be transmitted in any order.









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


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

    0                   1
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |    Data ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Type

      The type field is one octet, and indicates the type of the BAP
      Datagram Option.  This field is binary coded Hexadecimal.  The
      following options are currently defined:

         01   Link-Type
         02   Phone-Delta
         03   No-Phone-Number-Needed
         04   Reason
         05   Link-Discriminator
         06   Call-Status


   Length

      The Length field is one octet, and indicates the length of this
      BAP Option including the Type, Length, and Data fields.

   Data

      The Data field is zero or more octets, and contains information
      specific to the BAP Option.  The format and length of the Data
      field is determined by the Type and Length fields.

6.1.  Link-Type

   Description

      This option indicates the general type of link indicated for the
      operation being performed.  This option does not indicate a
      specific link type, rather it gives some general characteristics
      of the desired link type.  This option MAY be used along with
      other knowledge (i.e., the type of the other link(s) in the bundle
      or user configuration) to determine the type of link desired to be
      used in the operation.  It MUST be included in a Call- or
      Callback-Request, and MAY be included in a Call- or Callback-
      Response.



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


   A summary of the Link-Type BAP 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 Speed (kbps)       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Link Type    |
   +-+-+-+-+-+-+-+-+

   Type

      01 for Link-Type.

   Length

      The Length field is one octet, and indicates the length of this
      BAP Option including the Type, Length and Link Type fields.

   Link Speed

      The Link Speed field is 2 octets, and indicates the requested
      speed of the desired link in kilobits per second.  This field is
      coded as 2 binary coded hexadecimal octets, with the most
      significant octet sent first.

   Link Type

      The Link Type field is a bit mask.  It is 1 octet in length.  Bit
      0 of the Link Type field corresponds to bit 39 of the Link-Type
      BAP Option as described above.  If a bit is set, it indicates
      support of the corresponding link type.  If the link indicated is
      different than the supported link types, no bit will be set.
      Otherwise, at least one bit MUST be set.  If an implementation
      supports more than one link type, more than one bit MAY be set.

         Bit     Link type
         ---     -------------
          0      ISDN
          1      X.25
          2      analog
          3      switched digital (non-ISDN)
          4      ISDN data over voice
          5-7    reserved

      If the Length field contains more bits than are defined by this
      specification, then any bits that are not defined should be



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


      ignored.  In order to allow for future expansion of this field, it
      is important to properly support receiving a Link Type field
      longer than what is defined by this specification.  If the Length
      field is shorter than the number of bits defined, then the
      implementation should set all bits not received to 0.

6.2.  Phone-Delta

   Description

      The BAP Phone-Delta Option is used by an implementation to give
      its peer the information needed to make a call.  Due to the
      difficulty of determining which dialing prefixes (if any) are
      necessary to dial a given phone number/national destination
      code/country code combination, the phone number to be dialed will
      be based on a previously known number.  This MAY be the original
      number used to establish the first link of the multilink bundle, a
      number configured by the user, the phone number used to make a
      callback connection, or a number determined in some other way.
      The Phone-Delta Option will consist of a Subscriber-Number Sub-
      Option along with a Unique-Digits Sub-Option that indicates how
      many of the digits of the Subscriber-Number are unique among the
      ports in use, previously used, and to be used in the multilink
      bundle.  There is also an optional Phone-Number-Sub-Address Sub-
      Option.

      An implementation MAY include more than one Phone-Delta option in
      a response.  This indicates that there is more than one phone
      number that can be used for the requested operation.  The Phone-
      Delta option MUST appear in a Callback-Request.  It also MUST
      appear in a Call-Response with a Response Code set to Request-Ack
      if the Call-Request did not contain the No-Phone-Number option.
      It MAY be included in the Call-Status-Indication packet.

   A summary of the Phone-Delta BAP 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     |Sub-Option Type| Sub-Option Len|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Sub-Option...
   +-+-+-+-+-+-+-+-+

   Type

      02 for Phone-Delta.



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


   Length

      The Length field is one octet, and indicates the length of this
      BAP Option including the Type, Length, and Sub-Option fields.

   Sub-Option Type

      The following Sub-Option Types are defined for the Phone-Delta
      option.

          01   Unique-Digits
          02   Subscriber-Number
          03   Phone-Number-Sub-Address

   Sub-Option Length

      The Sub-Option Length field is one octet, and indicates the length
      of this BAP Sub-Option including the Sub-Option Type, Sub-Option
      Length, and Sub-Option fields.

6.2.1.  Phone-Delta Sub-Options

   Unique-Digits

      The Unique-Digits Sub-Option field consists of one octet that is a
      count of the number of rightmost digits of the Subscriber-Number
      that are different from the set of phone numbers of the ports used
      in this multilink connection.  (For example, if the first port of
      a multilink bundle has a phone number of 123456789, and an
      implementation wanted its peer to call a port with a phone number
      of 123456888, the Unique-Digits octet would be 3.) If the Phone-
      Number-Sub-Address Sub-Option is present, the Unique-Digits Sub-
      Option MUST NOT include any of the Sub Address digits in its count
      of different rightmost digits.

      This field is required.

   Subscriber-Number

      This field is the phone number of the port that should be called
      by the peer. Any digits that precede the rightmost unique digits
      of the Subscriber-Number are provided for informational purposes
      only, and do not need to be included in this field.  This field is
      an ASCII string and MUST contain only ASCII characters indicating
      valid phone number digits.  This field is required.






Richards & Smith            Standards Track                    [Page 18]