GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc2125

Network Working Group C. Richards Request for Comments: 2125 Shiva Corporation Category: Standards Track K. Smith

                                        Ascend Communications, Inc.
                                                         March 1997
            The PPP Bandwidth Allocation Protocol (BAP)
        The PPP Bandwidth Allocation Control Protocol (BACP)

Status of this Memo

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

Abstract

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

Table of Contents

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

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

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

1. Introduction

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

1.1. Specification of Requirements

 In this document, several words are used to signify the requirements
 of the specification.  These words are often capitalized.
 MUST      This word, or the adjective "required", means that the
           definition is an absolute requirement of the specification.
 MUST NOT  This phrase means that the definition is an absolute
           prohibition of the specification.
 SHOULD    This word, or the adjective "recommended", means that there
           may exist valid reasons in particular circumstances to
           ignore this item, but the full implications must be
           understood and carefully weighed before choosing a
           different course.

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

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

1.2. Terminology

 This document frequently uses the following terms:
 peer      The other end of the point-to-point link
 silently discard
       This means the implementation discards the packet without
       further processing.  The implementation SHOULD provide the
       capability of logging the error, including the contents of the
       silently discarded packet, and SHOULD record the event in a
       statistics counter.
 BOD (bandwidth on demand)
       BOD refers to the ability of a system to allocate and remove
       links in a multilink system to change the bandwidth of a
       multilink bundle.  This may be done in response to changing
       line conditions and it also may be done in response to changing
       resource conditions.  In either case, changing bandwidth
       dynamically during a multilink connection is referred to as
       BOD.

2. New LCP Configuration Option

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

2.1. Link Discriminator

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

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

 A summary of the Link Discriminator LCP Option format is shown below.
 The fields are transmitted from left to right.
  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |     Type      |     Length    |       Link Discriminator      |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 Type
    23 for Link Discriminator option.
 Length
    4
 Link Discriminator
    The Link Discriminator field is 2 octets in Length, and it
    contains a unique identifier used to indicate a particular link in
    a multilink bundle.  The Link Discriminator for a link MUST be
    unique among the Link Discriminators assigned by this endpoint for
    this bundle.  The Link Discriminator MAY be assigned in a
    sequential, monotonically increasing manner.

3. BACP Operation

 BACP uses the same packet exchange mechanism as the Link Control
 Protocol defined in [1].  BACP packets MUST NOT be exchanged until
 PPP has reached the Network-Layer Protocol phase.  BACP packets
 received before this phase is reached should be silently discarded.
 BACP is negotiated once per multilink bundle.  If BACP is negotiated
 on any of the links in a multilink bundle, it is opened for all of
 the links in the bundle.
 The Bandwidth Allocation Control Protocol is exactly the same as the
 Link Control Protocol [1] with the following exceptions:
    Data Link Layer Protocol Field
       Exactly one BACP packet is encapsulated in the Information
       field of PPP Data Link Layer frames where the Protocol field
       indicates Type hex c02b (Bandwidth Allocation Control
       Protocol).

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

    Code field
       Only Codes 1 through 7 (Configure-Request, Configure-Ack,
       Configure-Nak, Configure-Reject, Terminate-Request, Terminate-
       Ack and Code-Reject) are used.  Other Codes should be treated
       as unrecognized and should result in Code-Rejects.
 Configuration Option Types
       BACP has a distinct set of Configuration Options, which are
       defined in the next section.

4. BACP Configuration Options

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

4.1. Favored-Peer

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

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

    BACP will usually be negotiated after only one link of a multilink
    bundle has reached the Network-Layer Protocol phase. In this
    situation, it is acceptable for the peer that initiated the
    connection to use a Magic-Number of 1, and the peer that responded
    to the connection to use a Magic-Number of 0xFFFFFFFF.  If a
    multilink bundle has been established with links that were
    originated by each peer, or if it is not clear which peer has
    initiated a link (on a leased line, for example), then a random
    number MUST be used for the Magic-Number.  Refer to the
    description of the LCP Magic-Number Configuration Option in [1]
    for an explanation of how to create a useful random number.
    When a Configure-Request is received with a Favored-Peer
    Configuration Option, the received Magic-Number is compared with
    the Magic-Number of the last Configure-Request sent to the peer.
    If the two Magic-Numbers are different, then the Favored-Peer
    negotiation has been successful, and the Favored-Peer Option
    SHOULD be acknowledged.  If the two Magic-Numbers are equal, a
    Configure-Nak MUST be sent specifying a different Magic-Number
    value.  A new Configure-Request SHOULD NOT be sent to the peer
    until normal processing would cause it to be sent (that is, until
    a Configure-Nak is received or the Restart timer runs out).
 A summary of the Favored-Peer Option format is shown below.  The
 fields are transmitted from left to right.
  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |     Type      |    Length     |          Magic-Number
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       Magic-Number (cont)       |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 Type
    1 for Favored-Peer
 Length
    6
 Magic-Number
    The Magic-Number field is four octets, and indicates a number
    which is very likely to be unique to one end of the link.  A
    Magic-Number of zero is illegal and MUST always be Nak'd.

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] 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] 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
    (614)451-1883
    EMail: karl@ascend.com

Editors' Addresses

    Craig Richards
    Shiva Corporation
    28 Crosby Drive
    Bedford, MA  01730
    VOICE   +1 617 270 8419
    FAX     +1 617 270 8599
    EMail: crich@us.shiva.com
    Kevin Smith
    Ascend Communications, Inc.
    1275 Harbor Bay Parkway
    Alameda, CA  94501
    CA
    EMail: kevin@ascend.com

Richards & Smith Standards Track [Page 24]

/data/webs/external/dokuwiki/data/pages/rfc/rfc2125.txt · Last modified: 1997/03/28 22:32 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki