[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00 01 02 03 04 05 RFC 2125

PPP Working Group                                         Craig Richards
Internet Draft                                         Shiva Corporation
expires July 1996                                            Kevin Smith
                                             Ascend Communications, Inc.
                                                            January 1996


              The PPP Bandwidth Allocation Protocol (BAP)
          The PPP Bandwidth Allocation Control Protocol (BACP)
                     draft-ietf-pppext-bacp-00.txt


Status of this Memo

   This document is a submission to the Point-to-Point Protocol Working
   Group of the Internet Engineering Task Force (IETF).  Comments should
   be submitted to the ietf-ppp@merit.edu mailing list.

   Distribution of this memo is unlimited.

   Internet Drafts are working documents of the Internet Engineering
   Task Force (IETF), its Areas, and its Working Groups.  Note that
   other groups may also distribute working documents as Internet
   Drafts.

   Internet Drafts are draft documents valid for a maximum of six
   months.  Internet Drafts may be updated, replaced, or obsoleted by
   other documents at any time.  It is not appropriate to use Internet
   Drafts as reference material or to cite them other than as a
   ``working draft'' or ``work in progress.''

   Please check the 1id-abstracts.txt listing contained in the
   internet-drafts Shadow Directories on nic.ddn.mil, ds.internic.net,
   venera.isi.edu, nic.nordu.net, or munnari.oz.au to learn the current
   status of any Internet Draft.

Abstract

   This document proposes a method to manage the dynamic bandwidth
   allocation of implementations supporting the PPP multilink protocol
   [1].  This is done by defining the Bandwidth Allocation Protocol
   (BAP), as well as its associated control protocol, the Bandwidth
   Allocation Control Protocol (BACP).  BAP will manage the number of
   links in a multlink bundle.  This includes defining 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.




Richards & Smith           expires July 1996                    [Page i]

INTERNET DRAFT                  PPP BACP                    January 1996


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. Interoperable implementations of PPP multilink may have
   problems such as thrashing, when links are repeatedly brought up and
   torn down in a short amount of time.  BACP and BAP provide a means of
   solving problems associated with interoperable thrashing
   implementations, as well as providing a flexible yet robust way of
   managing bandwidth between 2 peers.  BAP does this by defining rules
   governing bandwidth on demand allocation and by defining Call-Control
   packets that co-ordinate the actual bandwidth allocation and de-
   allocation.  Phone numbers may be passed in the Call-Control packets
   to improve dynamic bandwidth decisions, as well as minimizing 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.

   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



Richards & Smith           expires July 1996                    [Page 1]

INTERNET DRAFT                  PPP BACP                    January 1996


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


   Description

      This option is used to declare a unique discriminator for the link
      that the option is sent over.  This option may be in an LCP
      configure request packet.    The link discriminator is used to
      differentiate the various links in a multilink bundle.  If this
      option is used, 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.

   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

      ?? for Link Discriminator option.

   Length

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




Richards & Smith           expires July 1996                    [Page 2]

INTERNET DRAFT                  PPP BACP                    January 1996


   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.

3.  BACP Packet Format

   BACP uses the same packet exchange mechanism as the Link Control
   Protocol [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 80?? (Bandwidth Allocation Control
         Protocol).

      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.




Richards & Smith           expires July 1996                    [Page 3]

INTERNET DRAFT                  PPP BACP                    January 1996


   Current values of BACP Configuration Options are assigned as follows:

      1     Datagrams-Supported
      2     Base-Phone-Number


4.1.  Datagrams-Supported

   Description

      This option is used to inform the peer of which Bandwidth
      Allocation Protocol datagrams this implementation supports.  This
      option MUST be included in every BACP Configure-Request packet.
      An implementation MUST NOT send its peer any packets which it does
      not support, as indicated by this option.  If an implementation
      receives a packet that it does not support, it MUST silently
      discard it.

      Since this configuration option is used to inform the peer, and
      can not be negotiated, an implementation SHOULD NOT transmit a
      Config-Nak or a Config-Rej in response to this configuration
      option.

   A summary of the Datagrams-Supported 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     |     Datagrams Supported       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Type

      1 for Datagrams-Supported.

   Length

      The Length field is one octet, and indicates the length of this
      BACP Option including the Type, Length and Datagrams Supported
      fields.

   Datagrams Supported

      The Datagrams Supported field is a bit mask.  It is 2 octets long.
      If a bit is set, it indicates support of both a Bandwidth
      Allocation Protocol Request or Indication datagram as well as the



Richards & Smith           expires July 1996                    [Page 4]

INTERNET DRAFT                  PPP BACP                    January 1996


      corresponding Response datagram.  Bit 0 of the Datagrams Supported
      field corresponds to bit 31 of the Datagrams-Supported Option as
      diagrammed above.

         Bit     Datagram Supported
         ---     ------------------
          0      Call-Request & Call-Response
          1      Callback-Request & Callback-Response
          2      Link-Drop-Request & Link-Drop-Response
          3      Link-Drop-Query-Request & Link-Drop-Query-Response
          4      Bundle-Drop-Request & Bundle-Drop-Response
          5      Link-Type-Request & Link-Type-Response
          6      Available-Link-Indication & Available-Link-Response
          7      Call-Fail-Indication & Call-Fail-Response

      If the Length field contains more bits than are defined by this
      specification, then any bits that are not defined should be
      ignored.  If the Length field is shorter than the number of bits
      defined, then the implementation should set all bits not received
      to 0.

4.2.  Base-Phone-Number

   Description

      This Configuration Option provides a way to inform the peer of an
      implementation's base phone number.  The base phone number can be
      used in conjunction with the unique-digits sub-option of the
      phone-number BAP option to create a valid phone number string to
      be dialed.  This option would be needed if an answering
      implementation wishes to make a callback call to initiate a
      subsequent link in a bundle.

      By default, the answerer's base phone number is the original
      number used to make the call that creates the first link in a
      multilink bundle, and the originator does not have a base phone
      number.  However, if a callback protocol is used during link
      establishment of the first link of a bundle, then the callback
      phone number would be the default base number for the originator's
      implementation.

      Since this configuration option is used to inform the peer, and
      can not be negotiated, an implementation SHOULD NOT transmit a
      Config-Nak or a Config-Rej in response to this configuration
      option.

   A summary of the Base-Phone-Number Option format is shown below.  The
   fields are transmitted from left to right.



Richards & Smith           expires July 1996                    [Page 5]

INTERNET DRAFT                  PPP BACP                    January 1996



    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     |     Base Phone Number...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Type

      2 for Base-Phone-Number.

   Length

      The Length field is one octet, and indicates the length of this
      BACP Option including the Type, Length and Base Phone Number
      fields.

   Base Phone Number

      The Base Phone Number field is an ASCII phone number string.  It
      will contain the complete set of digits that must be dialed by the
      calling implementation to reach the called implementation.  This
      might include a code to reach an outside line, long distance
      prefix, area code, country prefix and/or country code, as well as
      the phone number to be dialed.  It should be similar to the format
      of a phone number used when performing a callback connection.


5.  BAP Overview

5.1.  Link Management

   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 to
   answer the call for the new link.  The implementation receiving Call-
   and Callback-Requests must respond with the appropriate Request-Ack
   or Request-Nak Response Code.

5.2.  Bandwidth Management

   In order to discuss bandwidth management, it is first necessary to
   define some terms.  For the purposes of this specification, Bandwidth
   on Demand (BOD) is divided into 2 different types - throughput BOD
   and resource BOD. Throughput BOD refers to BOD decisions made based



Richards & Smith           expires July 1996                    [Page 6]

INTERNET DRAFT                  PPP BACP                    January 1996


   on the amount of data being sent, received or queued to be sent over
   a multilink bundle. An example of this is when a link is added to a
   bundle due to a large file being transferred across the bundle.
   Resource BOD refers to dynamic bandwidth decisions based on the
   equipment available to an implementation.  For example, a link might
   be removed from a multilink bundle to allow an incoming voice call to
   be answered, or a link might be added when a line becomes free due to
   the termination of a seperate PPP call on another port.  A system
   implementing BACP may be capable of implementing neither, one or both
   types of dynamic bandwidth management.

   Resource BOD support is an optional part of BAP.  An implementation
   does not have to locally make resource based BOD decisions as part of
   BAP.  However, any system implementing BAP must handle resource BOD
   management by its peer.  When links are removed due to resource BOD
   decisions, an implementation MUST use a Link-Drop-Request.  A Link-
   Drop-Request is used to inform the peer that the implementation is
   going to drop a link from the multilink bundle.  The peer MUST reply
   to this request with a Link-Drop-Response with the Response Code set
   to Request-Ack.  No other response is allowed.  The peer that decides
   to drop a link MAY choose to drop the link even if a Request-Ack has
   not been received.  This SHOULD only be done if there is a time
   critical quality to dropping the link.  An example of this is when
   there is an incoming call on a line in use by the multilink bundle,
   and the line must be dropped quickly before the incoming call goes
   away.

   Throughput BOD support is an optional part of BAP.  An implementation
   does not have to locally make throughput based BOD decisions as part
   of BAP.  However, any system implementing BAP must handle throughput
   BOD management by its peer.  When an implementation decides that it's
   time to remove a link due to a throughput BOD decision, an
   implementation MUST transmit a Link-Drop-Query-Request.  A Link-
   Drop-Query-Request is used to inquire if the peer agrees that it is
   okay to drop a link from the current multilink bundle.  When an
   implementation receives a Link-Drop-Query-Request, it MUST base its
   response on its transmit heuristics (unless it is not monitoring its
   transmit data, in which case it MUST accept the request to drop a
   link.) It MUST NOT base its response on its receive data heuristics.
   It MAY base its decision on its configuration, for example if the
   request would cause the number of active links to fall below the
   allowable minimum number of links configured for the active multilink
   bundle.  By making the decision to respond to a Link-Drop-Query-
   Request based on transmit heuristics only, BAP maximizes
   interoperability of various types of throughput BOD implementations.

   An implementation may monitor its transmit traffic, both transmit and
   receive traffic, or choose not to monitor traffic in either direction



Richards & Smith           expires July 1996                    [Page 7]

INTERNET DRAFT                  PPP BACP                    January 1996


   when implementing BACP.  It is recommended that server systems
   implement at least transmit monitoring, and that single-user dialin
   servers implement bi-directional monitoring.  This will allow clients
   implementations that require a minimum amount of end-user
   configuration in order to implement BOD successfully.

   The Bandwidth Allocation Protocol does not include an algorithm for
   determining when to add and remove links in a multilink bundle. It is
   not necessary to include such an algorithm in the protocol, and
   including it may limit the abilities of implementations to work
   optimally.  Leaving out the bandwidth on demand algorithm also
   improves chances for interoperability and makes the protocol more
   flexible.


6.  BAP Packets

   All of the BAP Request and Indication packets require a Response
   packet in response before taking any action, except the Link-Drop-
   Request packet.  The sender of the Link-Drop-Request packet is not
   required to receive a response to this packet before dropping a link,
   because there may be a time critical event depending on dropping the
   link.  However, when possible, the sender of a Link-Drop-Request
   packet SHOULD wait for a response before dropping the link.

   With the exception of the Link-Drop-Request packet, an implementation
   MUST set a timer when sending a request or indication packet. Upon
   expiration of this timer, the implementation MUST retransmit the same
   request or indication, with the identical identification number.
   This will insure that the peer receives the proper request or
   indication even if it is lost during transmission.  If a Response
   packet is lost, this retransmission scheme will insure that the
   original Request or Indication will be retransmitted with the same
   identification number, so the peer will realize that the response was
   lost, and that this is not a new request or indication packet.

   Since BAP packets help determine the amount of bandwidth available to
   an implementation, they SHOULD be given 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.

   A race condition can occur if both implementations send a Call-
   Request at the same time, or if both implementations send a Link-
   Drop-Request at the same time.  A race condition SHOULD be solved by
   favoring the implementation with the lowest username value.  If both
   implementations are using the same username, then the lowest
   Multilink Endpoint Discriminator SHOULD be favored.  This means that



Richards & Smith           expires July 1996                    [Page 8]

INTERNET DRAFT                  PPP BACP                    January 1996


   the favored peer's request should be acked by its peer, and the
   unfavored peer's request should be naked by the favored peer.

6.1.  BAP Datagram Format

   Description

      Before any BAP packets may be communicated, PPP must reach the
      Network-Layer Protocol phase, and the BA Control Protocol 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 00?? (Bandwidth Allocation Protocol).

      The maximum length of a BAP packet transmitted over a PPP links 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.

   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.










Richards & Smith           expires July 1996                    [Page 9]

INTERNET DRAFT                  PPP BACP                    January 1996



    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:


         00       Call-Request
         01       Call-Response
         02       Callback-Request
         03       Callback-Response
         04       Link-Drop-Request
         05       Link-Drop-Response
         06       Link-Drop-Query-Request
         07       Link-Drop-Query-Response
         08       Bundle-Drop-Request
         09       Bundle-Drop-Response
         0A       Link-Type-Request
         0B       Link-Type-Response
         0C       Available-Link-Indication
         0D       Available-Link-Response
         0E       Call-Failure-Indication
         0F       Call-Failure-Response

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

   Identifier

      The Identifier field is one octet and aids in matching Requests
      and Indications with Responses, as well as which links are added
      or removed.  Call-Failure-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 that failed. 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



Richards & Smith           expires July 1996                   [Page 10]

INTERNET DRAFT                  PPP BACP                    January 1996


      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.
      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 can
      have the following values:

         0        Request-Ack
         1        Request-Nak


   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.

6.1.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 peer of the intention to add another link to the bundle,
   and give the peer 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 Call-Add-Code
   options.

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

6.1.2.  Call-Response

   An implementation transmits a Call-Response datagram in response to a
   received Call-Request datagram.  If the Call-Request is acceptable,
   the Call-Response will have a Response Code set to Request-Ack,
   otherwise the Response Code will be Request-Nak.  The Phone-Number
   option MUST be included in a Call-Response packet with a Response
   Code of Request-Ack unless the Call-Request included the No-Phone-



Richards & Smith           expires July 1996                   [Page 11]

INTERNET DRAFT                  PPP BACP                    January 1996


   Number option.  The Nak-Code option MUST be included in a Call-
   Response packet with a Response Code of Request-Nak, and the Time-
   Until-Retry and Link-Types options MAY be included in such a packet.

6.1.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 peer of the intention to add
   another link to the bundle, and will also inform the peer of the
   number to be called.

   The options field MUST include the Link-Type and Phone-Number
   options.  The Call-Add-Code option MAY also be included.

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

6.1.4.  Callback-Response

   An implementation transmits a Callback-Response datagram in response
   to a received Callback-Request datagram.  If the Callback-Request is
   acceptable, the Callback-Response will have a Response Code of
   Request-Ack, otherwise the Response Code will be Request-Nak.  The
   Nak-Code option MUST be included in a Callback-Response packet with a
   Response Code of Request-Nak, and the Time-Until-Retry option MAY
   also be included in such a packet.

6.1.5.  Link-Drop-Request

   An implementation that requires that a link be removed from the
   current multilink bundle MUST transmit a Link-Drop-Request packet.
   This will usually be due to resource BOD decisions.  If an
   implementation wants to remove a link due to a throughput BOD
   decision, it MUST send a Link-Drop-Query-Request (see section below)
   The options field MUST include the Link-Type option and MAY include
   the Drop-Code option and MAY include the Link-Discriminator option.

   Upon reception of a Link-Drop-Request, a Link-Drop-Response datagram
   with a Response Code of Request-Ack MUST be transmitted. After the
   receipt of the Link-Drop-Response datagram, the transmitter of the
   Link-Drop-Request MUST initiate tear down of the indicated link by
   sending an LCP Terminate-Request packet.

   The Link-Drop-Request is the only BAP Request packet that does not
   require a response before an action is taken.  If there are time
   constaints, an implementation may go ahead and drop a link from the
   multilink bundle without receiving a response from its peer.



Richards & Smith           expires July 1996                   [Page 12]

INTERNET DRAFT                  PPP BACP                    January 1996


6.1.6.  Link-Drop-Response

   An implementation transmit a Link-Drop-Response datagram in response
   to a received Link-Drop-Request datagram.  The Response Code MUST be
   set to Request-Ack in this packet.

6.1.7.  Link-Drop-Query-Request

   An implementation that determines that a link is no longer needed
   based on a throughput BOD decision MUST transmit a Link-Drop-Query-
   Request packet.  The remote implementation will respond with a
   Response Code of Request-Ack if it agrees that there is too much
   bandwidth in the current multilink bundle based on a throughput BOD
   algorithm, or a Request-Nak if its own throughput BOD management
   determines that current load conditions warrent keeping all links of
   the bundle.  The options field MUST include the Link-Type option and
   MAY include the Drop-Code option and MAY include the Link-
   Discriminator option.

   Upon reception of a Link-Drop-Query-Request, a Link-Drop-Query-
   Response datagram MUST be transmitted.  After the receipt of a Link-
   Drop-Query-Request 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.

6.1.8.  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 determines, based on its BOD algoritm, that it would
   be acceptable to reduce the bandwidth of the multilink bundle, then
   the Response Code should be set to Request-Ack.  Otherwise, the
   Response Code should be set to Request-Nak.

   If the Response Code is Request-Nak, the Nak-Code option MUST be
   included, and the Time-Until-Retry option MAY be included.

6.1.9.  Bundle-Drop-Request

   An implementation that wishes to terminate a multilink bundle MAY
   transmit a Bundle-Drop-Request to its peer.  This packet indicates
   that the peer is going to terminate all the links in the current
   bundle.  This packet can be used instead of sending Link-Drop-
   Requests for each link in a multilink bundle.  The options field MAY
   include a Drop-Code option.

   Upon reception of a Bundle-Drop-Request, a Bundle-Drop-Response with
   a Response Code of Request-Ack MUST be transmitted. After the receipt



Richards & Smith           expires July 1996                   [Page 13]

INTERNET DRAFT                  PPP BACP                    January 1996


   of the Bundle-Drop-Response, the transmitter of the Bundle-Drop-
   Request MUST initiate tear down of all links in the bundle by sending
   an LCP Terminate-Request packet on each link.

6.1.10.  Bundle-Drop-Response

   An implementation transmits a Bundle-Drop-Response datagram in
   response to a received Bundle-Drop-Request datagram.  The Response
   Code MUST be set to Request-Ack in this packet.

6.1.11.  Link-Type-Request

   If an implementation desires to know which types of links its peer
   supports for the current multilink bundle, it MAY send a Link-Type-
   Request to its peer.

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

6.1.12.  Link-Type-Response

   An implementation transmits a Link-Type-Response datagram in response
   to a received Link-Type-Request datagram.  The Response Code MUST be
   set to Request-Ack in this packet.  The Link-Types option MUST be
   included in this datagram, so the peer will be informed of which link
   types this implementation supports.

6.1.13.  Available-Link-Indication

   Whenever an implementation transmits a Call-Response or a Callback-
   Response with the Response Code set to Request-Nak and the Nak Code
   set to "link not currently available", that implementation enters a
   link denied state.  While an implementation is in a link denied state
   and a link of the type previously requested becomes available, and if
   the implementation and its peer both support the Available-Link
   packets, then the implementation MUST send an Available-Link-
   Indication packet to the peer.  When an Available-Link-Indication
   packet is sent to the peer, the link denied state is cleared for that
   link type.  Each independent link type has an independent link denied
   state.

   When an implementation receives an Available-Link-Indication packet,
   it MUST transmit an Available-Link-Response packet in response so
   that the peer knows that the indication was received.  The Link-Type
   option MUST be included in the Available-Link-Indication datagram.






Richards & Smith           expires July 1996                   [Page 14]

INTERNET DRAFT                  PPP BACP                    January 1996


6.1.14.  Available-Link-Response

   An implementation transmits an Available-Link-Response datagram in
   response to a received Available-Link-Indication datagram.  The
   Response Code MUST be set to Request-Ack in this packet.

6.1.15.  Call-Failure-Indication

   After an implementation fails an attempt to add a link to a bundle as
   the result of a Call-Request or a Callback-Request, it MUST send a
   Call-Failure-Indication packet to its peer. The options field MUST
   include the Call-Failure-Code option to indicate why the call failed
   as well as whether or not the implementation will retry the call.
   The Link-Type option MAY be included and the Phone-Number option
   indicating the phone number of the attempted call MAY be included.

   Upon reception of a Call-Failure-Indication packet, an implementation
   MAY log the failure and reason code, and a Call-Failure-Response
   datagram MUST be transmitted.

6.1.16.  Call-Failure-Response

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


7.  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.

   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



Richards & Smith           expires July 1996                   [Page 15]

INTERNET DRAFT                  PPP BACP                    January 1996


      Datagram Option.  The following options are currently defined:

          0   Link-Type
          1   Link-Types
          2   Phone-Number
          3   No-Phone-Number-Needed
          4   Call-Add-Code
          5   Nak-Code
          6   Drop-Code
          7   Call-Failure-Code
          8   Time-Until-Retry
          9   Link-Discriminator


   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.

7.1.  Link-Type

   Description

      This option indicates the type of link supported for the operation
      being performed.  Exactly one bit MUST be set in the Link Type
      field.  This option MUST be included in all Bandwidth Allocation
      Protocol datagrams except Bundle-Drop- Request/Response and Link-
      Type- Request/Response datagrams.

   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 Type           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Type

      0 for Link-Type.



Richards & Smith           expires July 1996                   [Page 16]

INTERNET DRAFT                  PPP BACP                    January 1996


   Length

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

   Link Type

      The Link Type field is a bit mask.  It is 2 octets in length.  Bit
      0 of the Link Type field corresponds to bit 31 of the Link-Type
      BAP Option as described above.  If a bit is set, it indicates
      support of the corresponding link type:

         Bit     Link type
         ---     -------------
          0      Sync ISDN 64K
          1      Sync ISDN 56K
          2      Sync ISDN Data over voice
          3      V.120 on Sync ISDN 64K
          4      V.120 on Sync ISDN 56K
          5      V.120 on Sync ISDN Data over voice
          6      V.110 on Sync ISDN 64K
          7      V.110 on Sync ISDN 56K
          8      V.110 on Sync ISDN Data over voice
          9      ISDN PRI H0 Channel
         10      X.25
         11      Asynchronous analog modem
         12      Synchronous analog modem
         13      Analog modem over ISDN

      If the Length field contains more bits than are defined by this
      specification, then any bits that are not defined should be
      ignored.  If the Length field is shorter than the number of bits
      defined, then the implementation should set all bits not received
      to 0.

7.2.  Link-Types

   Description

      This option indicates the types of links capable of being
      supported in this multilink bundle.  This option has a similar
      format to the Link-Type option, except that the Link Type field is
      a bit mask instead on having exactly one bit set.

      This option MUST be included in the Link-Type-Response datagram.

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



Richards & Smith           expires July 1996                   [Page 17]

INTERNET DRAFT                  PPP BACP                    January 1996



    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 Types          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Type

      1 for Link-Types.

   Length

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

   Link Types

      The Link Types field is a bit mask.  It is 2 octets long. See the
      bit definitions in the previous section (Link-Type Option) for a
      definition of the bits in the Link Types field.  If a bit is set,
      it indicates support of the corresponding link type.

      If the Length field contains more bits than are defined by this
      specification, then any bits that are not defined should be
      ignored.  If the Length field is shorter than the number of bits
      defined, then the implementation should set all bits not received
      to 0.

7.3.  Phone-Number

   Description

      This option is used to transmit an implementation's phone number
      to its peer.  This phone number should be either the phone number
      of a hunt group for this device, or the specific phone number of a
      free port on this device.  If there are no free ports on this
      device, a Response with a Response Code of Request-Nak should be
      sent, and this option would not be used.

      Note that an implementation may include more than one Phone-Number
      option in a response.  This means that there is more than one
      phone number that can be used for the requested operation.

      The Phone-Number option MUST appear in a Callback-Request. It also
      MUST appear in a Call-Response if the Call-Request did not contain
      the No-Phone-Number option.  It MAY appear in the Call-Failure-



Richards & Smith           expires July 1996                   [Page 18]

INTERNET DRAFT                  PPP BACP                    January 1996


      Indication datagram.

   A summary of the Phone-Number 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

      2 for Phone-Number.

   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-Options Types are defined for the Phone-Number
      option.

          0    Unique Digits
          1    Phone Number
          2    Area Code
          3    Country Code
          4    Phone Number Sub Address


7.3.1.  Phone-Number Sub-Options

   Unique Digits

      This byte is a count of the number of unique digits in the phone
      number.  The Unique Digits byte indicates the number of rightmost
      digits of the complete phone number that are different from port
      to port on the given device.  (For example, if all phone numbers
      on a given device are 617/555-89XX, the Unique Digits byte is 2,
      if all phone numbers are 617/55X-XXXX, then the Unique Digits byte
      will be 5).  This field is required.

      The purpose of the unique digits sub-option is to aid the



Richards & Smith           expires July 1996                   [Page 19]

INTERNET DRAFT                  PPP BACP                    January 1996


      originating implementation in phone number parsing.  With this
      information, the implementation that originates a call does not
      have to know which combination of access codes, country codes,
      dialing codes, area codes and extension numbers are necessary.  It
      just takes the digits contained in the original phone number
      dialed, and replaces the rightmost unique digits with the
      rightmost unique digits of the new phone number. For example, if
      the original number dialed is 9,16175512345, and the new phone
      number has an area code of 617, a phone number of 5598765, and a
      unique digits value of 5, then the number to be dialed will be
      created by replacing the rightmost 5 digits of the original number
      (12345) with the rightmost 5 digits of the new number (98765),
      which results in a new phone number to be dialed of 9,16175598765.

   Phone Number

      This field is the phone number of the port that should be called
      by the peer.  It MUST NOT include the area code and country code
      fields IF they are defined in seperate sub-options.  This field is
      an ASCII string and only contains valid phone number digits. This
      field is required.

   Area Code

      This field is the area code of the port that should be called by
      the peer. This field is an ASCII string and only contains valid
      phone number digits. This field is optional.

   Country Code

      This field is the country code of the port that should be called
      by the peer. This field is an ASCII string and only contains valid
      phone number digits. This field is optional.

   Phone Number Sub Address

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

7.4.  No-Phone-Number-Needed

   Description

      The No-Phone-Number option is used to indicate that the calling
      peer is already configured with the phone number of its multilink
      peer.  This may be for security reasons, for configuration



Richards & Smith           expires July 1996                   [Page 20]

INTERNET DRAFT                  PPP BACP                    January 1996


      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

      3 for No-Phone-Number.

   Length

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

7.5.  Call-Add-Code

   Description

      This option is used to indicate the primary reason for requesting
      that a link be added to a bundle.  This option MAY be used in a
      Call-Request or a Callback-Request packet.

   A summary of the Call-Add-Code 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     |    Description
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    String (Optional)...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Type

      4 for Call-Add-Code.





Richards & Smith           expires July 1996                   [Page 21]

INTERNET DRAFT                  PPP BACP                    January 1996


   Length

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

   Reason

      The reason code byte can have the following values:

         0 - unlisted reason
         1 - link has been freed up
         2 - other resources freed up
         3 - transmit queue length exceeds limit
         4 - receive traffic exceeds limit
         5 - transmit traffic exceeds limit


   Description String

      The Description String field is optional.  If the length field
      indicates that the option continues past the Reason field, then
      the remaining octets in the option are the Description String.
      This is an ASCII string.  The content of the field is
      implementation dependent.  An implementation MAY ignore the
      Description String field.

7.6.  Nak-Code

   Description

      This option is used to transmit a Nak code to the peer. This
      option MUST be included in every Call-Response and Callback-
      Response with a Response Code of Request-Nak.

   A summary of the Nak-Code 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     |    Description
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    String (Optional)...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+






Richards & Smith           expires July 1996                   [Page 22]

INTERNET DRAFT                  PPP BACP                    January 1996


   Type

      5 for Nak-Code.

   Length

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

   Reason

      The reason code byte can have the following values:


         0 - unlisted reason
         1 - link not currently available
         2 - multilink bundle has reached its maximum capacity
         3 - invalid phone number
         4 - no resources
         5 - peer does not have sufficient privilege


   Description String

      The Description String field is optional.  If the length field
      indicates that the option continues past the Reason field, then
      the remaining octets in the option are the Description String.
      This is an ASCII string.  The content of the field is
      implementation dependent.  An implementation MAY ignore the
      Description String field.

7.7.  Drop-Code

   Description

      This option is used to indicate the primary reason for requesting
      that a link be removed from the bundle.  This option MAY be used
      in a Link-Drop-Request, Link-Drop-Query-Request or a Bundle-Drop-
      Request packet.

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








Richards & Smith           expires July 1996                   [Page 23]

INTERNET DRAFT                  PPP BACP                    January 1996



    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     |    Description
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    String (Optional)...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Type

      6 for Drop-Code.

   Length

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

   Reason

      The reason code byte can have the following values:

         0 - unlisted reason
         1 - incoming call
         2 - outgoing call
         3 - transmit data dropped below threshold
         4 - receive data dropped below threshold
         5 - transmit queue dropped below threshold
         6 - higher priority connection requested line
         7 - user initiated disconnect


   Description String

      The Description String field is optional.  If the length field
      indicates that the option continues past the Reason field, then
      the remaining octets in the option are the Description String.
      This is an ASCII string.  The content of the field is
      implementation dependent.  An implementation MAY ignore the
      Description String field.

7.8.  Call-Failure-Code

   Description

      This option is used to indicate the action that will be taken



Richards & Smith           expires July 1996                   [Page 24]

INTERNET DRAFT                  PPP BACP                    January 1996


      after a call failed, as well as a reason code for the failure.
      This option MUST be included in a Call-Failure-Indication packet.

   A summary of the Call-Failure-Code 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     |    Action     |    Reason     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Description String (Optional)...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Type

      7 for Call-Failure-Code.

   Length

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

   Action

      The Action octet indicates what action the calling implementation
      is taking after a failed call.

      The Action octet can have the following values:

         0 - No retry
         1 - Will retry same number
         2 - Will retry next number in list


   Reason

      The reason code byte can have the following values:

         0 - unlisted reason
         1 - no dial tone
         2 - no answer
         3 - no carrier
         4 - unable to negotiate LCP
         5 - unable to authenticate
         6 - call canceled



Richards & Smith           expires July 1996                   [Page 25]

INTERNET DRAFT                  PPP BACP                    January 1996


   Description String

      The Description String field is optional.  If the length field
      indicates that the option continues past the Reason field, then
      the remaining octets in the option are the Description String.
      This is an ASCII string.  The content of the field is
      implementation dependent.  An implementation MAY ignore the
      Description String field.

7.9.  Time-Until-Retry

   Description

      The Time-Until-Retry option MAY be used in Nak's of Call-Response,
      Callback-Response, and Link-Drop-Query-Response datagrams with the
      Response Code set to Request-Nak.  This option is used to inform
      the peer that the previous Request will not be accepted until the
      time indicated by the option.  This retry time only applies to the
      link type or types being requested.

   A summary of the Time-Until-Retry 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     |         Time (seconds)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
            Time (continued)       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Type

      8 for Time-Until-Retry.

   Length

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

   Time

      The Time field is 4 octets in length (network byte order), and
      indicates the time in seconds before the Request being Nak'd may
      be retried.





Richards & Smith           expires July 1996                   [Page 26]

INTERNET DRAFT                  PPP BACP                    January 1996


7.10.  Link-Discriminator

   Description

      The Link-Discriminator option MAY be used in a Link-Drop-Request
      or a Link-Drop-Query-Request datagram.  This option is used to
      inform the peer of which link will be dropped.  If the peer did
      not send the LCP Link Discriminator Configuration Option during
      the LCP link negotiation phase, then this option MUST NOT be sent.

   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

      9 for Time-Until-Retry.

   Length

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

   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 peer.
















Richards & Smith           expires July 1996                   [Page 27]

INTERNET DRAFT                  PPP BACP                    January 1996


Appendix


   List of BAP datagrams and associated options.

   datagram                      mandatory options          possible options
   --------                      -----------------          ----------------
   Call-Request                  Link-Type                  No-Phone-Number
                                                            Call-Add-Code
   Call-Response                                            Phone-Number
                                                            Nak-Code
                                                            Time-Until-Retry
                                                            Link-Types
   Callback-Request              Link-Type                  Phone-Number
                                                            Call-Add-Code
   Callback-Response                                        Nak-Code
                                                            Time-Until-Retry
                                                            Link-Types
   Link-Drop-Request             Link-Type                  Link-Discriminator
                                                            Drop-Code
   Link-Drop-Response
   Link-Drop-Query-Request       Link-Type                  Link-Discriminator
                                                            Drop-Code
   Link-Drop-Query-Response
   Bundle-Drop-Request                                      Drop-Code
   Bundle-Drop-Response
   Link-Type-Request
   Link-Type-Response            Link-Types
   Available-Link-Indication     Link-Type
   Available-Link-Response
   Call-Failure-Indication       Call-Failure-Code          Phone-Number
                                                            Link-Type
   Call-Failure-Response


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



Richards & Smith           expires July 1996                   [Page 28]

INTERNET DRAFT                  PPP BACP                    January 1996


   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.



References

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

   [2]   Sklower, Lloyd, McGregor & Carr, "The PPP Multilink Protocol",
         RFC 1717,  PPP Extensions Working Group, Work in Progress.

Chair's Address

   The working group can be contacted via the current chair:

      Fred Baker
      Cisco Systems
      519 Lado Drive
      Santa Barbara, California 93111
      VOICE   +1 408 526 4257
      FAX     +1 805 681-0115

      EMail: fbaker@cisco.com




Editors' Addresses

   Craig Richards
   Shiva Corporation
   63 Third Avenue
   Burlington, MA  01803
   VOICE   +1 617 270 8419
   FAX     +1 617 270 8599

   EMail: crich@shiva.com


   Kevin Smith
   Ascend Communications, Inc.



Richards & Smith           expires July 1996                   [Page 29]

INTERNET DRAFT                  PPP BACP                    January 1996


   1275 Harbor Bay Parkway
   Alameda, CA  94501
   CA

   EMail: kevin@ascend.com














































Richards & Smith           expires July 1996                   [Page 30]

INTERNET DRAFT                  PPP BACP                    January 1996


                           Table of Contents


     1.     Introduction ..........................................    1
        1.1       Specification of Requirements ...................    1
        1.2       Terminology .....................................    1

     2.     New LCP Configuration Option - Link Discriminator .....    2

     3.     BACP Packet Format ....................................    3

     4.     BACP Configuration Options ............................    3
        4.1       Datagrams-Supported .............................    4
        4.2       Base-Phone-Number ...............................    5

     5.     BAP Overview ..........................................    6
        5.1       Link Management .................................    6
        5.2       Bandwidth Management ............................    6

     6.     BAP Packets ...........................................    8
        6.1       BAP Datagram Format .............................    9
           6.1.1  Call-Request ....................................   11
           6.1.2  Call-Response ...................................   11
           6.1.3  Callback-Request ................................   12
           6.1.4  Callback-Response ...............................   12
           6.1.5  Link-Drop-Request ...............................   12
           6.1.6  Link-Drop-Response ..............................   13
           6.1.7  Link-Drop-Query-Request .........................   13
           6.1.8  Link-Drop-Query-Response ........................   13
           6.1.9  Bundle-Drop-Request .............................   13
           6.1.10 Bundle-Drop-Response ............................   14
           6.1.11 Link-Type-Request ...............................   14
           6.1.12 Link-Type-Response ..............................   14
           6.1.13 Available-Link-Indication .......................   14
           6.1.14 Available-Link-Response .........................   15
           6.1.15 Call-Failure-Indication .........................   15
           6.1.16 Call-Failure-Response ...........................   15

     7.     BAP Datagram Options ..................................   15
        7.1       Link-Type .......................................   16
        7.2       Link-Types ......................................   17
        7.3       Phone-Number ....................................   18
           7.3.1  Phone-Number Sub-Options ........................   19
        7.4       No-Phone-Number-Needed ..........................   20
        7.5       Call-Add-Code ...................................   21
        7.6       Nak-Code ........................................   22
        7.7       Drop-Code .......................................   23
        7.8       Call-Failure-Code ...............................   24



Richards & Smith           expires July 1996                   [Page ii]

INTERNET DRAFT                  PPP BACP                    January 1996


        7.9       Time-Until-Retry ................................   26
        7.10      Link-Discriminator ..............................   27

     Appendix - List of BAP datagrams and associated options ......   28

     ACKNOWLEDEMENTS ..............................................   28

     SECURITY CONSIDERATIONS ......................................   29

     REFERENCES ...................................................   29

     CHAIR'S ADDRESS ..............................................   29

     EDITORS'S ADDRESSES ..........................................   29





































Richards & Smith           expires July 1996                  [Page iii]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/