rfc2125.txt

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

RFC 2125                       PPP BACP                       March 1997


   Phone-Number-Sub-Address

      This field is the sub address of the port to be called by the
      peer.  This sub-option SHOULD only be used for an ISDN call. This
      field is an ASCII string and only contains valid phone number
      digits. This field is optional.

6.3.  No-Phone-Number-Needed

   Description

      The No-Phone-Number option indicates that the calling
      implementation is already configured with the phone number of its
      multilink peer and the answering implementation MUST NOT include
      the Phone Number option in the response.  This may be for security
      reasons, for configuration reasons, or for any other reason.

      This option MAY be used in a Call-Request packet.

   A summary of the No-Phone-Number 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type

      03 for No-Phone-Number.

   Length

      2
















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


6.4.  Reason

   Description

      This option is used to indicate a reason for the Request or
      Response.  It is meant to be used for informational purposes only.
      This option MAY be used in any BAP packet.

   A summary of the Reason 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     |         Reason String...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type

      04 for Reason.

   Length

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

   Reason String

      This is an ASCII string.  The content of the field is
      implementation dependent.  An implementation MAY ignore the Reason
      String field.




















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


6.5.  Link-Discriminator

   Description

      The Link-Discriminator option MUST be used in a Link-Drop-Query-
      Request datagram.  This option is used to inform the receiver of a
      Link-Drop-Query-Request of which link will be dropped.

   A summary of the Link-Discriminator 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 Discriminator      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type

      05 for Link-Discriminator

   Length

      4

   Link Discriminator

      The Link Discriminator field is 2 octets in length.  It contains
      the Link Discriminator that was contained in the LCP Link-
      Discriminator Configuration Option sent by the receiver of the
      packet containing the Link Discriminator.

6.6.  Call-Status

   Description

      The Call-Status option MUST be used in a Call-Status-Indication
      datagram.  This option is used to inform the receiver of the
      Call-Status-Indication datagram of the status of the completed
      call attempt, as well as a possible action that will be taken (if
      the call failed).










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


   A summary of the Call-Status 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     |     Status    |     Action    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type

      06 for Call-Status.

   Length

      4

   Status

      The Status field is 1 octet in length.  If the call was
      successful, the value MUST be set to 0.  A non-zero value
      indicates a call failure.  A value of 255 indicates a non-specific
      failure, and a more specific call status MAY be indicated by using
      the same number as the Q.931 cause value (i.e., 1 is unassigned
      number, 17 is user busy, etc.)

   Action

   The Action octet indicates what action the calling implementation is
   taking after a failed call.  If the call was sucessful, the Action
   octet MUST be set to 0.

   The Action octet can have the following values:

      0 - No retry
      1 - Retry















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


Appendix

List of BAP datagrams and associated fields.

datagram                      mandatory fields           allowed options
--------                      -----------------          ---------------
Call-Request                  Link-Type                  No-Phone-Number
Call-Response                                            Phone-Delta
                                                         Link-Type
Callback-Request              Link-Type
                              Phone-Delta
Callback-Response                                        Link-Type
Link-Drop-Query-Request       Link-Discriminator
Link-Drop-Query-Response
Call-Status-Indication        Call-Status                Phone-Delta
Call-Status-Response

   The Reason option is allowed to be included with any BAP datagram.

History of BACP

   The first version of BACP was written by Craig Richards of Shiva
   Corporation.  This version was enhanced and improved by the MPCP
   Working Group, a collaborative effort of 3Com, Ascend, Bay Networks,
   Cisco, Microsoft, Shiva, US Robotics and Xylogics.

Acknowledgements

   Kevin Smith of Ascend for his contributions based on his work on the
   MP+ Specification.  Gerry Meyer and Robert Myhill of Shiva for their
   early comments and improvements.  Andy Nicholson of Microsoft for his
   improvements to the bandwidth management scheme.  Dana Blair and Andy
   Valencia of Cisco, Cheng Chen and Dan Brennan of 3Com for their good
   ideas as part of the MPCP Working Group. All of the members of the
   MPCP working group for their ability to work with their competitors
   with enthusiasm to produce a better protocol for the industry.

Security Considerations

   Security issues are not discussed in this memo.











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


References

[1]   Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD
      51, RFC 1661, Daydreamer, July 1994.

[2]   Sklower, Lloyd, McGregor, Carr & Coradetti, "The PPP Multilink
      Protocol", RFC 1990,  University of California, Berkeley, Lloyd
      Internetworking, Newbridge Networks Corporation, Sidewalk
      Software, August 1996.

Chair's Address

   The working group can be contacted via the current chair:

      Karl Fox
      Ascend Communications
      3518 Riverside Drive, Suite 101
      Columbus, Ohio  43221

      [phone]

      EMail: [e-mail]

Editors' Addresses

      Craig Richards
      Shiva Corporation
      28 Crosby Drive
      Bedford, MA  01730
      VOICE   [phone]
      FAX     [phone]

      EMail: [e-mail]


      Kevin Smith
      Ascend Communications, Inc.
      1275 Harbor Bay Parkway
      Alameda, CA  94501
      CA

      EMail: [e-mail]









Richards & Smith            Standards Track                    [Page 24]