home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / rfc / rfc2125 < prev    next >
Text File  |  1997-03-31  |  49KB  |  1,348 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                     C. Richards
  8. Request for Comments: 2125                          Shiva Corporation
  9. Category: Standards Track                                    K. Smith
  10.                                           Ascend Communications, Inc.
  11.                                                            March 1997
  12.  
  13.  
  14.               The PPP Bandwidth Allocation Protocol (BAP)
  15.           The PPP Bandwidth Allocation Control Protocol (BACP)
  16.  
  17. Status of this Memo
  18.  
  19.    This document specifies an Internet standards track protocol for the
  20.    Internet community, and requests discussion and suggestions for
  21.    improvements.  Please refer to the current edition of the "Internet
  22.    Official Protocol Standards" (STD 1) for the standardization state
  23.    and status of this protocol.  Distribution of this memo is unlimited.
  24.  
  25. Abstract
  26.  
  27.    This document proposes a method to manage the dynamic bandwidth
  28.    allocation of implementations supporting the PPP multilink protocol
  29.    [2].  This is done by defining the Bandwidth Allocation Protocol
  30.    (BAP), as well as its associated control protocol, the Bandwidth
  31.    Allocation Control Protocol (BACP).  BAP can be used to manage the
  32.    number of links in a multilink bundle.  BAP defines datagrams to co-
  33.    ordinate adding and removing individual links in a multilink bundle,
  34.    as well as specifying which peer is responsible for which decisions
  35.    regarding managing bandwidth during a multilink connection.
  36.  
  37. Table of Contents
  38.  
  39.    1.     Introduction ..........................................    2
  40.       1.1       Specification of Requirements ...................    2
  41.       1.2       Terminology .....................................    3
  42.    2.     New LCP Configuration Option ..........................    3
  43.       2.1       Link Discriminator ..............................    3
  44.    3.     BACP Operation ........................................    4
  45.    4.     BACP Configuration Options ............................    5
  46.       4.1       Favored-Peer ....................................    5
  47.    5.     BAP Operation .........................................    7
  48.       5.1       Link Management .................................    7
  49.       5.2       Bandwidth Management ............................    8
  50.       5.3       BAP Packets .....................................    8
  51.       5.4       Race Conditions .................................    9
  52.       5.5       BAP Datagram Format .............................    9
  53.          5.5.1  Call-Request ....................................   12
  54.          5.5.2  Call-Response ...................................   12
  55.  
  56.  
  57.  
  58. Richards & Smith            Standards Track                     [Page 1]
  59.  
  60. RFC 2125                       PPP BACP                       March 1997
  61.  
  62.  
  63.          5.5.3  Callback-Request ................................   13
  64.          5.5.4  Callback-Response ...............................   13
  65.          5.5.5  Link-Drop-Query-Request .........................   13
  66.          5.5.6  Link-Drop-Query-Response ........................   13
  67.          5.5.7  Call-Status-Indication ..........................   14
  68.          5.5.8  Call-Status-Response ............................   14
  69.    6.     BAP Datagram Options ..................................   14
  70.       6.1       Link-Type .......................................   15
  71.       6.2       Phone-Delta .....................................   17
  72.          6.2.1  Phone-Delta Sub-Options .........................   18
  73.       6.3       No-Phone-Number-Needed ..........................   19
  74.       6.4       Reason ..........................................   20
  75.       6.5       Link-Discriminator ..............................   21
  76.       6.6       Call-Status .....................................   21
  77.    Appendix - List of BAP datagrams and associated fields .......   23
  78.    ACKNOWLEDEMENTS ..............................................   23
  79.    SECURITY CONSIDERATIONS ......................................   23
  80.    REFERENCES ...................................................   24
  81.    CHAIR'S ADDRESS ..............................................   24
  82.    EDITORS'S ADDRESSES ..........................................   24
  83.  
  84. 1.  Introduction
  85.  
  86.    As PPP multilink implementations become increasingly common, there is
  87.    a greater need for some conformity in how to manage bandwidth over
  88.    such links. BACP and BAP provide a flexible yet robust way of
  89.    managing bandwidth between 2 peers.  BAP does this by defining Call-
  90.    Control packets and a protocol that allows peers to co-ordinate the
  91.    actual bandwidth allocation and de-allocation.  Phone number deltas
  92.    may be passed in the Call-Control packets to minimize the end user's
  93.    configuration.
  94.  
  95. 1.1.  Specification of Requirements
  96.  
  97.    In this document, several words are used to signify the requirements
  98.    of the specification.  These words are often capitalized.
  99.  
  100.    MUST      This word, or the adjective "required", means that the
  101.              definition is an absolute requirement of the specification.
  102.  
  103.    MUST NOT  This phrase means that the definition is an absolute
  104.              prohibition of the specification.
  105.  
  106.    SHOULD    This word, or the adjective "recommended", means that there
  107.              may exist valid reasons in particular circumstances to
  108.              ignore this item, but the full implications must be
  109.              understood and carefully weighed before choosing a
  110.              different course.
  111.  
  112.  
  113.  
  114. Richards & Smith            Standards Track                     [Page 2]
  115.  
  116. RFC 2125                       PPP BACP                       March 1997
  117.  
  118.  
  119.    MAY       This word, or the adjective "optional", means that this
  120.              item is one of an allowed set of alternatives.  An
  121.              implementation which does not include this option MUST be
  122.              prepared to interoperate with another implementation which
  123.              does include the option.
  124.  
  125. 1.2.  Terminology
  126.  
  127.    This document frequently uses the following terms:
  128.  
  129.    peer      The other end of the point-to-point link
  130.  
  131.    silently discard
  132.          This means the implementation discards the packet without
  133.          further processing.  The implementation SHOULD provide the
  134.          capability of logging the error, including the contents of the
  135.          silently discarded packet, and SHOULD record the event in a
  136.          statistics counter.
  137.  
  138.    BOD (bandwidth on demand)
  139.          BOD refers to the ability of a system to allocate and remove
  140.          links in a multilink system to change the bandwidth of a
  141.          multilink bundle.  This may be done in response to changing
  142.          line conditions and it also may be done in response to changing
  143.          resource conditions.  In either case, changing bandwidth
  144.          dynamically during a multilink connection is referred to as
  145.          BOD.
  146.  
  147. 2.  New LCP Configuration Option
  148.  
  149.    Implementations MUST implement LCP as defined in [1].  LCP MUST be in
  150.    the Network-Layer Protocol phase before BACP can be negotiated.
  151.  
  152. 2.1.  Link Discriminator
  153.  
  154.    Description
  155.  
  156.       This LCP Configuration Option is used to declare a unique
  157.       discriminator for the link that the option is sent over.  This
  158.       option MUST be negotiated by LCP on every link.  BAP uses the link
  159.       discriminator to differentiate the various links in a multilink
  160.       bundle. Each link in a multilink bundle MUST have a unique
  161.       discriminator.  The discriminator is independent for each peer, so
  162.       each link may have 2 different LCP Link Discriminator values, one
  163.       for each peer. When the Link Discriminator is sent in a BAP
  164.       packet, the transmitter sends the Link Discriminator Option value
  165.       received from its peer in the peer's LCP Configure Request packet.
  166.  
  167.  
  168.  
  169.  
  170. Richards & Smith            Standards Track                     [Page 3]
  171.  
  172. RFC 2125                       PPP BACP                       March 1997
  173.  
  174.  
  175.    A summary of the Link Discriminator LCP Option format is shown below.
  176.    The fields are transmitted from left to right.
  177.  
  178.     0                   1                   2                   3
  179.     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
  180.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  181.    |     Type      |     Length    |       Link Discriminator      |
  182.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  183.  
  184.    Type
  185.  
  186.       23 for Link Discriminator option.
  187.  
  188.    Length
  189.  
  190.       4
  191.  
  192.    Link Discriminator
  193.  
  194.       The Link Discriminator field is 2 octets in Length, and it
  195.       contains a unique identifier used to indicate a particular link in
  196.       a multilink bundle.  The Link Discriminator for a link MUST be
  197.       unique among the Link Discriminators assigned by this endpoint for
  198.       this bundle.  The Link Discriminator MAY be assigned in a
  199.       sequential, monotonically increasing manner.
  200.  
  201. 3.  BACP Operation
  202.  
  203.    BACP uses the same packet exchange mechanism as the Link Control
  204.    Protocol defined in [1].  BACP packets MUST NOT be exchanged until
  205.    PPP has reached the Network-Layer Protocol phase.  BACP packets
  206.    received before this phase is reached should be silently discarded.
  207.  
  208.    BACP is negotiated once per multilink bundle.  If BACP is negotiated
  209.    on any of the links in a multilink bundle, it is opened for all of
  210.    the links in the bundle.
  211.  
  212.    The Bandwidth Allocation Control Protocol is exactly the same as the
  213.    Link Control Protocol [1] with the following exceptions:
  214.  
  215.       Data Link Layer Protocol Field
  216.  
  217.          Exactly one BACP packet is encapsulated in the Information
  218.          field of PPP Data Link Layer frames where the Protocol field
  219.          indicates Type hex c02b (Bandwidth Allocation Control
  220.          Protocol).
  221.  
  222.  
  223.  
  224.  
  225.  
  226. Richards & Smith            Standards Track                     [Page 4]
  227.  
  228. RFC 2125                       PPP BACP                       March 1997
  229.  
  230.  
  231.       Code field
  232.  
  233.          Only Codes 1 through 7 (Configure-Request, Configure-Ack,
  234.          Configure-Nak, Configure-Reject, Terminate-Request, Terminate-
  235.          Ack and Code-Reject) are used.  Other Codes should be treated
  236.          as unrecognized and should result in Code-Rejects.
  237.  
  238.    Configuration Option Types
  239.  
  240.          BACP has a distinct set of Configuration Options, which are
  241.          defined in the next section.
  242.  
  243. 4.  BACP Configuration Options
  244.  
  245.    BACP Configuration Options allow negotiation of desirable BACP
  246.    parameters.  These options are used in Config-Request, Config-Ack,
  247.    Config-Nak, and Config-Reject packets.  BACP uses the same
  248.    Configuration Option format defined for LCP [1], with a seperate set
  249.    of Options.
  250.  
  251.    Current values of BACP Configuration Options are assigned as follows:
  252.  
  253.       1     Favored-Peer
  254.  
  255. 4.1.  Favored-Peer
  256.  
  257.    Description
  258.  
  259.       This Configuration Option is used to determine which peer is
  260.       favored in the event of a race condition in which 2 peers
  261.       simultaneously transmit the same BAP request.  Each peer
  262.       negotiates a 4 octet magic number, which is successfully
  263.       negotiated when the 2 Magic-Numbers are different.  The favored
  264.       peer is the peer that transmits the lowest Magic-Number in its
  265.       Favored-Peer Configuration Option.
  266.  
  267.       The Favored-Peer Configuration Option MUST be implemented.
  268.  
  269.  
  270.  
  271.  
  272.  
  273.  
  274.  
  275.  
  276.  
  277.  
  278.  
  279.  
  280.  
  281.  
  282. Richards & Smith            Standards Track                     [Page 5]
  283.  
  284. RFC 2125                       PPP BACP                       March 1997
  285.  
  286.  
  287.       BACP will usually be negotiated after only one link of a multilink
  288.       bundle has reached the Network-Layer Protocol phase. In this
  289.       situation, it is acceptable for the peer that initiated the
  290.       connection to use a Magic-Number of 1, and the peer that responded
  291.       to the connection to use a Magic-Number of 0xFFFFFFFF.  If a
  292.       multilink bundle has been established with links that were
  293.       originated by each peer, or if it is not clear which peer has
  294.       initiated a link (on a leased line, for example), then a random
  295.       number MUST be used for the Magic-Number.  Refer to the
  296.       description of the LCP Magic-Number Configuration Option in [1]
  297.       for an explanation of how to create a useful random number.
  298.  
  299.       When a Configure-Request is received with a Favored-Peer
  300.       Configuration Option, the received Magic-Number is compared with
  301.       the Magic-Number of the last Configure-Request sent to the peer.
  302.       If the two Magic-Numbers are different, then the Favored-Peer
  303.       negotiation has been successful, and the Favored-Peer Option
  304.       SHOULD be acknowledged.  If the two Magic-Numbers are equal, a
  305.       Configure-Nak MUST be sent specifying a different Magic-Number
  306.       value.  A new Configure-Request SHOULD NOT be sent to the peer
  307.       until normal processing would cause it to be sent (that is, until
  308.       a Configure-Nak is received or the Restart timer runs out).
  309.  
  310.    A summary of the Favored-Peer Option format is shown below.  The
  311.    fields are transmitted from left to right.
  312.  
  313.     0                   1                   2                   3
  314.     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
  315.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  316.    |     Type      |    Length     |          Magic-Number
  317.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  318.          Magic-Number (cont)       |
  319.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  320.  
  321.    Type
  322.  
  323.       1 for Favored-Peer
  324.  
  325.    Length
  326.  
  327.       6
  328.  
  329.    Magic-Number
  330.  
  331.       The Magic-Number field is four octets, and indicates a number
  332.       which is very likely to be unique to one end of the link.  A
  333.       Magic-Number of zero is illegal and MUST always be Nak'd.
  334.  
  335.  
  336.  
  337.  
  338. Richards & Smith            Standards Track                     [Page 6]
  339.  
  340. RFC 2125                       PPP BACP                       March 1997
  341.  
  342.  
  343. 5.  BAP Operation
  344.  
  345. 5.1.  Link Management
  346.  
  347.    BAP defines packets, parameters and negotiation procedures to allow
  348.    two endpoints to negotiate gracefully adding and dropping links from
  349.    a multilink bundle.  An implementation can:
  350.  
  351.       o Request permission to add a Link to a bundle (Call-Request)
  352.  
  353.       o Request that the peer add a link to a bundle via a callback
  354.         (Callback-Request)
  355.  
  356.       o Negotiate with the peer to drop a link from a bundle (this
  357.         implies that the peer can refuse) (Link-Drop-Query-Request)
  358.  
  359.    After BACP reaches the opened state, either peer MAY request that
  360.    another link be added to the bundle by sending a BAP Call- or
  361.    Callback-Request packet.  A Call-Request packet is sent if the
  362.    implementation wishes to originate the call for the new link, and a
  363.    Callback-Request packet is sent if the implementation wishes its peer
  364.    to originate the call for the new link.  The implementation receiving
  365.    a Call- or Callback-Request MUST respond with a Call- or Callback-
  366.    Response with a valid Response Code.
  367.  
  368.    After BACP reaches the opened state, either peer MAY request that a
  369.    link be dropped from the bundle.  A BAP Link-Drop-Query-Request
  370.    packet is sent to the peer to negotiate dropping a link.  The peer
  371.    MUST respond with a Link-Drop-Query-Response.   If the peer is
  372.    agreeable to dropping the link the implementation MUST issue an LCP
  373.    Terminate-Request to initiate dropping the link.
  374.  
  375.    If an implementation wishes to force dropping a link without
  376.    negotiation, it should simply send an LCP Terminate-Request packet on
  377.    the link (without sending any BAP Link-Drop-Query-Request).
  378.  
  379.    After an LCP Terminate-Request is sent an implementation SHOULD stop
  380.    transmitting data packets on that link, but still continue to receive
  381.    and process data packets normally until receipt of a Terminate-Ack
  382.    from the peer.  The receiver of an LCP Terminate-Request SHOULD stop
  383.    transmitting packets before issuing the Terminate-Ack.  This
  384.    procedure will insure that no data is lost in either direction.
  385.  
  386.  
  387.  
  388.  
  389.  
  390.  
  391.  
  392.  
  393.  
  394. Richards & Smith            Standards Track                     [Page 7]
  395.  
  396. RFC 2125                       PPP BACP                       March 1997
  397.  
  398.  
  399. 5.2.  Bandwidth Management
  400.  
  401.    BAP allows two peer implementations to manage the bandwidth available
  402.    to the protocols using the multilink bundle by negotiating when to
  403.    add and drop links (See Link Management).  Use of the negotiation
  404.    features of BAP makes it unnecessary to require a 'common' algorithm
  405.    for determining when to add and remove links in a multilink bundle.
  406.  
  407.    BOD decisions can be based on link utilization.  A BAP implementation
  408.    may monitor its transmit traffic, both transmit and receive traffic,
  409.    or choose not to monitor traffic in either direction.  If a server
  410.    system implements bi-directional monitoring, it will allow BOD
  411.    operation with a client that does not monitor traffic in either
  412.    direction, which will minimize the end-user's configuration.  When an
  413.    implementation decides that it is time to remove a link due to
  414.    traffic monitoring, it MUST transmit a Link-Drop-Query-Request to
  415.    inquire if the peer agrees to drop a link from the current multilink
  416.    bundle.  When an implementation receives a Link-Drop-Query-Request,
  417.    it SHOULD base its response on the traffic it is monitoring.  It MUST
  418.    NOT base its response solely on its receive data heuristics.
  419.  
  420.    The operation of the Link-Drop-Query-Request and -Response datagrams
  421.    causes a link in a multilink bundle to be left up as long as either
  422.    implementation that is monitoring link utilization determines that it
  423.    is necessary.
  424.  
  425.    BOD decisions can also be based on the resources (e.g., physical
  426.    port, B-channel, etc.) available to an implementation.  For example,
  427.    an implementation might remove a link from a multilink bundle to
  428.    answer an incoming voice call, or might add a link when a line
  429.    becomes free due to the termination of a separate PPP call on another
  430.    port.  An implementation MUST use an LCP Terminate-Request to remove
  431.    a link due to a resource condition.
  432.  
  433. 5.3.  BAP Packets
  434.  
  435.    All of the BAP Request and Indication packets require a Response
  436.    packet in response before taking any action.
  437.  
  438.    An implementation MUST set a timer when sending a Request or
  439.    Indication packet. The value of this timer SHOULD depend on the type
  440.    and speed of the link or links in use.  Upon expiration of this
  441.    timer, the implementation MUST retransmit the request or indication,
  442.    with an identical identification number.  This procedure will insure
  443.    that the peer receives the proper request or indication even if a
  444.    packet is lost during transmission.  If a response packet is lost the
  445.    peer will realize that this is not a new request or indication
  446.    packet.
  447.  
  448.  
  449.  
  450. Richards & Smith            Standards Track                     [Page 8]
  451.  
  452. RFC 2125                       PPP BACP                       March 1997
  453.  
  454.  
  455.    If the number of retransmissions exceeds the number supported by the
  456.    implementation for this packet, the implementation MAY take
  457.    appropriate recovery action. For example, if no response to a Link-
  458.    Drop-Query-Request is received after 2 retransmissions, an
  459.    implementation MAY initiate dropping the link by sending an LCP
  460.    Terminate-Request for that link.
  461.  
  462.    Since BAP packets help determine the amount of bandwidth available to
  463.    an implementation, PPP SHOULD give them priority over other data
  464.    packets when transmitting.  This will help insure the prompt addition
  465.    and removal of links in a multilink bundle.  This is especially
  466.    important when adding links to a bundle due to bandwidth constraints.
  467.  
  468. 5.4.  Race Conditions
  469.  
  470.    In order to resolve race conditions, an implementation MUST implement
  471.    the BACP Favored-Peer Configuration Option.
  472.  
  473.    A race condition can occur if both implementations send a Call-
  474.    Request, Callback-Request or Link-Drop-Query-Request at the same
  475.    time.  These race conditions should be solved as follows:
  476.  
  477.       If each implementation sends a Call-Request or Callback-Request at
  478.       the same time, the implementation with the lowest BACP Favored-
  479.       Peer Magic-Number value SHOULD be favored.
  480.  
  481.       If each implementation sends a Link-Drop-Query-Request at the same
  482.       time, the same scheme SHOULD be used as for Call-Requests.
  483.  
  484. 5.5.  BAP Datagram Format
  485.  
  486.    Description
  487.  
  488.       Before any BAP packets may be communicated, PPP MUST reach the
  489.       Network-Layer Protocol phase, and BACP MUST reach the opened
  490.       state.
  491.  
  492.       Exactly one BAP packet is encapsulated in the Information field of
  493.       PPP Data Link Layer frames where the Protocol field indicates type
  494.       hex c02d (Bandwidth Allocation Protocol).
  495.  
  496.       Because ISDN Terminal Adapters sometimes are used to do multilink
  497.       with a non-multilink aware client, BAP datagrams MUST NOT be
  498.       compressed or encrypted.  Otherwise, the ISDN TA may not be able
  499.       to properly intercept BAP datagrams needed to control the
  500.       multilink connection.  This refers to compression of the whole
  501.       datagram; Address-and-Control-Field-Compression and Protocol-
  502.       Field-Compression are allowed if properly negotiated.
  503.  
  504.  
  505.  
  506. Richards & Smith            Standards Track                     [Page 9]
  507.  
  508. RFC 2125                       PPP BACP                       March 1997
  509.  
  510.  
  511.       The maximum length of a BAP packet transmitted over a PPP link is
  512.       the same as the maximum length of the Information field of a PPP
  513.       data link layer frame.
  514.  
  515.       Bandwidth Allocation Protocol datagrams can be catagorized as
  516.       either Request, Indication or Response packets.  Every Request and
  517.       Indication datagram has a corresponding Response packet.  Request
  518.       and Indication datagrams have a slightly different format from
  519.       Response datagrams, as the Response datagrams include a Response
  520.       Code octet.
  521.  
  522.       All of the BAP datagrams MUST be supported by an implementation.
  523.       However, that does not mean an implementation must support all BAP
  524.       datagram actions.  An implementation MAY send a Request-Rej to a
  525.       Request that it does not implement.
  526.  
  527.    A summary of the Bandwidth Allocation Protocol datagram Request and
  528.    Indication packet format is shown below.  The fields are transmitted
  529.    from left to right.
  530.  
  531.     0                   1                   2                   3
  532.     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
  533.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  534.    |     Type      |  Identifier   |            Length             |
  535.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  536.    |   Data ...
  537.    +-+-+-+-+-+-+-+-+
  538.  
  539.    A summary of the Bandwidth Allocation Protocol datagram Response
  540.    packet format is shown below.  The fields are transmitted from left
  541.    to right.
  542.  
  543.     0                   1                   2                   3
  544.     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
  545.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  546.    |     Type      |  Identifier   |            Length             |
  547.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  548.    | Response Code |    Data ...
  549.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  550.  
  551.    Type
  552.  
  553.       The Type field is one octet and identifies the type of BAP
  554.       datagram packet.  Datagram types are defined as follows.  This
  555.       field is coded in binary coded hexadecimal.
  556.  
  557.  
  558.  
  559.  
  560.  
  561.  
  562. Richards & Smith            Standards Track                    [Page 10]
  563.  
  564. RFC 2125                       PPP BACP                       March 1997
  565.  
  566.  
  567.          01       Call-Request
  568.          02       Call-Response
  569.          03       Callback-Request
  570.          04       Callback-Response
  571.          05       Link-Drop-Query-Request
  572.          06       Link-Drop-Query-Response
  573.          07       Call-Status-Indication
  574.          08       Call-Status-Response
  575.  
  576.       The various types of BAP datagrams are explained in the following
  577.       sections.
  578.  
  579.    Identifier
  580.  
  581.       The Identifier field is one octet and is binary coded.  It aids in
  582.       matching Requests and Indications with Responses.  Call-Status-
  583.       Indication packets MUST use the same Identifier as was used by the
  584.       original Call-Request or Callback-Request that was used to
  585.       initiate the call.  All other Request or Indication packets MUST
  586.       use a unique Identifier for each new Request or Indication.  All
  587.       Response packets MUST use the same Identifier as the Identifier in
  588.       the Request or Indication packet being responded to.  When re-
  589.       transmitting a request or indication, the Identifier MUST be the
  590.       same as the Identifier used on the previous transmission of the
  591.       request or indication.
  592.  
  593.    Length
  594.  
  595.       The Length field is two octets and indicates the length of the
  596.       packet including the Type, Identifier, Length and Options fields.
  597.       It is binary encoded. Octets outside the range of the Length field
  598.       should be treated as Data Link Layer padding and should be ignored
  599.       on reception.
  600.  
  601.    Response Code
  602.  
  603.       The Response Code is only present in Response datagrams.  It is
  604.       binary coded and can have the following values:
  605.  
  606.          00000000        Request-Ack
  607.          00000001        Request-Nak
  608.          00000010        Request-Rej
  609.          00000011        Request-Full-Nak
  610.  
  611.       The Request-Ack Response Code is sent to indicate that the Request
  612.       or Indication command is valid and was successfully received by an
  613.       implementation. The Request-Nak Response Code is sent to indicate
  614.       that the Request command was received, but an implementation does
  615.  
  616.  
  617.  
  618. Richards & Smith            Standards Track                    [Page 11]
  619.  
  620. RFC 2125                       PPP BACP                       March 1997
  621.  
  622.  
  623.       not want the requested action performed at this time.  If a
  624.       Response containing a Request-Nak Response Code is received, the
  625.       original Request MAY be retried after an implementation determines
  626.       that sufficient time has elapsed.  The Request-Rej Response Code
  627.       is sent to indicate that the Request command received by an
  628.       implementation is not implemented (i.e., if reception of a
  629.       particular request type is not supported by the peer.) The
  630.       Request-Full-Nak Response Code is sent to indicate that the
  631.       Request command was received, but an implementation does not want
  632.       the requested action performed.  The Request-Full-Nak is used to
  633.       indicate that an implementation has reached the maximum (for a
  634.       Call- or Callback-Request) or the minimum (for a Link-Drop-Query-
  635.       Request) bandwidth configured or available for this multilink
  636.       bundle.  If a Response containing a Request-Full-Nak Response Code
  637.       is received, the original Request SHOULD NOT be retried until the
  638.       total bandwidth of the multilink bundle has changed.
  639.  
  640.    Data
  641.  
  642.       The Data field is variable in length, and will usually contain the
  643.       list of zero or more BAP Options that the sender desires to
  644.       transmit. The format of BAP Options is described in a later
  645.       chapter.
  646.  
  647. 5.5.1.  Call-Request
  648.  
  649.    Before originating a call to add another link to a multilink bundle,
  650.    an implementation MUST transmit a Call-Request packet.  This will
  651.    inform the receiver of the request to add another link to the bundle
  652.    and give the receiver a chance to inform the implementation of the
  653.    phone number of a free port that can be called.
  654.  
  655.    The options field MUST include the Link-Type option.  The options
  656.    field MAY include the No-Phone-Number and/or the Reason options.
  657.  
  658.    Upon reception of a Call-Request, a Call-Response datagram MUST be
  659.    transmitted.
  660.  
  661. 5.5.2.  Call-Response
  662.  
  663.    An implementation MUST transmit a Call-Response datagram in response
  664.    to a received Call-Request datagram.  If the Call-Request is
  665.    acceptable, the Call-Response MUST have a Response Code of Request-
  666.    Ack.  The Phone-Delta option MUST be included in a Call-Response
  667.    packet with a Response Code of Request-Ack unless the Call-Request
  668.    included the No-Phone-Number option. The options field MAY include
  669.    the Reason and/or Link-Type options.
  670.  
  671.  
  672.  
  673.  
  674. Richards & Smith            Standards Track                    [Page 12]
  675.  
  676. RFC 2125                       PPP BACP                       March 1997
  677.  
  678.  
  679. 5.5.3.  Callback-Request
  680.  
  681.    An implementation that wants its peer to originate another link to
  682.    add to the multilink bundle MUST transmit a Callback-Request packet
  683.    to its peer.  This will inform the receiver of the request to add
  684.    another link to the bundle along with the number to be called.
  685.  
  686.    The options field MUST include the Link-Type and Phone-Delta options.
  687.    The Reason option MAY also be included.
  688.  
  689.    Upon reception of a Callback-Request, a Callback-Response datagram
  690.    MUST be transmitted.
  691.  
  692. 5.5.4.  Callback-Response
  693.  
  694.    An implementation MUST transmit a Callback-Response datagram in
  695.    response to a received Callback-Request datagram.  If the Callback-
  696.    Request is acceptable, the Callback-Response MUST have a Response
  697.    Code of Request-Ack.  A Callback-Response packet MAY include the
  698.    Link-Type option.
  699.  
  700. 5.5.5.  Link-Drop-Query-Request
  701.  
  702.    An implementation that determines that a link is no longer needed and
  703.    wishes to negotiate dropping it (e.g., based on a throughput BOD
  704.    decision), MUST transmit a Link-Drop-Query-Request packet. The
  705.    options field MUST include the Link-Discriminator option (containing
  706.    the receiver's Link-Discriminator), and MAY include the Reason
  707.    option.
  708.  
  709.    Upon reception of a Link-Drop-Query-Request, an implementation MUST
  710.    transmit a Link-Drop-Query-Response datagram.  The Response-Code will
  711.    be Request-Ack if it agrees to drop the link; if it does not agree to
  712.    drop the link the Response-Code will be Request-Nak or Request-Full-
  713.    Nak.  After the receipt of a Link-Drop-Query-Response with a Response
  714.    Code of Request-Ack, the transmitter of the Link-Drop-Query-Request
  715.    MUST initiate tear down of the indicated link by sending an LCP
  716.    Terminate-Request packet on the designated link.
  717.  
  718. 5.5.6.  Link-Drop-Query-Response
  719.  
  720.    An implementation transmits a Link-Drop-Query-Response datagram in
  721.    response to a received Link-Drop-Query-Request datagram.  If the
  722.    implementation agrees (e.g., based on its throughput BOD algorithm)
  723.    to reduce the bandwidth of the multilink bundle, then the Response
  724.    Code MUST be set to Request-Ack.
  725.  
  726.  
  727.  
  728.  
  729.  
  730. Richards & Smith            Standards Track                    [Page 13]
  731.  
  732. RFC 2125                       PPP BACP                       March 1997
  733.  
  734.  
  735.    The Reason option MAY be included in the Link-Drop-Query-Response
  736.    packet.
  737.  
  738.    The Link-Drop-Query-Request datagram MUST be supported, as well as
  739.    the underlying implementation to respond to it.  This means that a
  740.    Link-Drop-Query-Response with a Response Code of Request-Rej MUST NOT
  741.    be transmitted in response to a Link-Drop-Query-Request.
  742.  
  743. 5.5.7.  Call-Status-Indication
  744.  
  745.    After an implementation attempts to add a link to a bundle as the
  746.    result of a Call-Request or a Callback-Request, it MUST send a Call-
  747.    Status-Indication packet to its peer to indicate if the attempt to
  748.    add the link succeeded or failed.  One Indication MUST be sent for
  749.    each attempt made. For each Call-Status-Indication packet transmitted
  750.    with the Call-Status Option Action octet set to Retry, a subsequent
  751.    Call-Status-Indication packet MUST be sent to indicate the success or
  752.    failure of the retry.  The Call-Status option MUST be included to
  753.    inform the receiver of the status of the attempt to add a link and
  754.    the action the implementation will take in case of failure.  The
  755.    reason option MAY also be included in the Call-Status-Indication
  756.    packet.
  757.  
  758.    Upon reception of a Call-Status-Indication packet which indicates a
  759.    failure, an implementation may log the failure and reason code.  Upon
  760.    reception of any Call-Status-Indication packet, a Call-Status-
  761.    Response datagram MUST be transmitted.
  762.  
  763. 5.5.8.  Call-Status-Response
  764.  
  765.    An implementation transmits a Call-Status-Response datagram in
  766.    response to a received Call-Status-Indication datagram.  The Response
  767.    Code field MUST be set to Request-Ack in this packet.  The Reason
  768.    option MAY be included in this packet.
  769.  
  770. 6.  BAP Datagram Options
  771.  
  772.    BAP Datagram Options are used in various BAP packets.  Their use in
  773.    various packets is as defined below.  The format of these options
  774.    loosely follows the formatting conventions of LCP Configuration
  775.    Options.  When there are multiple BAP Options in one BAP packet, the
  776.    options MAY be transmitted in any order.
  777.  
  778.  
  779.  
  780.  
  781.  
  782.  
  783.  
  784.  
  785.  
  786. Richards & Smith            Standards Track                    [Page 14]
  787.  
  788. RFC 2125                       PPP BACP                       March 1997
  789.  
  790.  
  791.    A summary of the BAP Option format is shown below.  The fields are
  792.    transmitted from left to right.
  793.  
  794.     0                   1
  795.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9
  796.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  797.    |     Type      |    Length     |    Data ...
  798.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  799.  
  800.  
  801.    Type
  802.  
  803.       The type field is one octet, and indicates the type of the BAP
  804.       Datagram Option.  This field is binary coded Hexadecimal.  The
  805.       following options are currently defined:
  806.  
  807.          01   Link-Type
  808.          02   Phone-Delta
  809.          03   No-Phone-Number-Needed
  810.          04   Reason
  811.          05   Link-Discriminator
  812.          06   Call-Status
  813.  
  814.  
  815.    Length
  816.  
  817.       The Length field is one octet, and indicates the length of this
  818.       BAP Option including the Type, Length, and Data fields.
  819.  
  820.    Data
  821.  
  822.       The Data field is zero or more octets, and contains information
  823.       specific to the BAP Option.  The format and length of the Data
  824.       field is determined by the Type and Length fields.
  825.  
  826. 6.1.  Link-Type
  827.  
  828.    Description
  829.  
  830.       This option indicates the general type of link indicated for the
  831.       operation being performed.  This option does not indicate a
  832.       specific link type, rather it gives some general characteristics
  833.       of the desired link type.  This option MAY be used along with
  834.       other knowledge (i.e., the type of the other link(s) in the bundle
  835.       or user configuration) to determine the type of link desired to be
  836.       used in the operation.  It MUST be included in a Call- or
  837.       Callback-Request, and MAY be included in a Call- or Callback-
  838.       Response.
  839.  
  840.  
  841.  
  842. Richards & Smith            Standards Track                    [Page 15]
  843.  
  844. RFC 2125                       PPP BACP                       March 1997
  845.  
  846.  
  847.    A summary of the Link-Type BAP Option format is shown below.  The
  848.    fields are transmitted from left to right.
  849.  
  850.     0                   1                   2                   3
  851.     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
  852.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  853.    |     Type      |    Length     |       Link Speed (kbps)       |
  854.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  855.    |  Link Type    |
  856.    +-+-+-+-+-+-+-+-+
  857.  
  858.    Type
  859.  
  860.       01 for Link-Type.
  861.  
  862.    Length
  863.  
  864.       The Length field is one octet, and indicates the length of this
  865.       BAP Option including the Type, Length and Link Type fields.
  866.  
  867.    Link Speed
  868.  
  869.       The Link Speed field is 2 octets, and indicates the requested
  870.       speed of the desired link in kilobits per second.  This field is
  871.       coded as 2 binary coded hexadecimal octets, with the most
  872.       significant octet sent first.
  873.  
  874.    Link Type
  875.  
  876.       The Link Type field is a bit mask.  It is 1 octet in length.  Bit
  877.       0 of the Link Type field corresponds to bit 39 of the Link-Type
  878.       BAP Option as described above.  If a bit is set, it indicates
  879.       support of the corresponding link type.  If the link indicated is
  880.       different than the supported link types, no bit will be set.
  881.       Otherwise, at least one bit MUST be set.  If an implementation
  882.       supports more than one link type, more than one bit MAY be set.
  883.  
  884.          Bit     Link type
  885.          ---     -------------
  886.           0      ISDN
  887.           1      X.25
  888.           2      analog
  889.           3      switched digital (non-ISDN)
  890.           4      ISDN data over voice
  891.           5-7    reserved
  892.  
  893.       If the Length field contains more bits than are defined by this
  894.       specification, then any bits that are not defined should be
  895.  
  896.  
  897.  
  898. Richards & Smith            Standards Track                    [Page 16]
  899.  
  900. RFC 2125                       PPP BACP                       March 1997
  901.  
  902.  
  903.       ignored.  In order to allow for future expansion of this field, it
  904.       is important to properly support receiving a Link Type field
  905.       longer than what is defined by this specification.  If the Length
  906.       field is shorter than the number of bits defined, then the
  907.       implementation should set all bits not received to 0.
  908.  
  909. 6.2.  Phone-Delta
  910.  
  911.    Description
  912.  
  913.       The BAP Phone-Delta Option is used by an implementation to give
  914.       its peer the information needed to make a call.  Due to the
  915.       difficulty of determining which dialing prefixes (if any) are
  916.       necessary to dial a given phone number/national destination
  917.       code/country code combination, the phone number to be dialed will
  918.       be based on a previously known number.  This MAY be the original
  919.       number used to establish the first link of the multilink bundle, a
  920.       number configured by the user, the phone number used to make a
  921.       callback connection, or a number determined in some other way.
  922.       The Phone-Delta Option will consist of a Subscriber-Number Sub-
  923.       Option along with a Unique-Digits Sub-Option that indicates how
  924.       many of the digits of the Subscriber-Number are unique among the
  925.       ports in use, previously used, and to be used in the multilink
  926.       bundle.  There is also an optional Phone-Number-Sub-Address Sub-
  927.       Option.
  928.  
  929.       An implementation MAY include more than one Phone-Delta option in
  930.       a response.  This indicates that there is more than one phone
  931.       number that can be used for the requested operation.  The Phone-
  932.       Delta option MUST appear in a Callback-Request.  It also MUST
  933.       appear in a Call-Response with a Response Code set to Request-Ack
  934.       if the Call-Request did not contain the No-Phone-Number option.
  935.       It MAY be included in the Call-Status-Indication packet.
  936.  
  937.    A summary of the Phone-Delta BAP Option format is shown below.  The
  938.    fields are transmitted from left to right.
  939.  
  940.     0                   1                   2                   3
  941.     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
  942.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  943.    |     Type      |    Length     |Sub-Option Type| Sub-Option Len|
  944.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  945.    |  Sub-Option...
  946.    +-+-+-+-+-+-+-+-+
  947.  
  948.    Type
  949.  
  950.       02 for Phone-Delta.
  951.  
  952.  
  953.  
  954. Richards & Smith            Standards Track                    [Page 17]
  955.  
  956. RFC 2125                       PPP BACP                       March 1997
  957.  
  958.  
  959.    Length
  960.  
  961.       The Length field is one octet, and indicates the length of this
  962.       BAP Option including the Type, Length, and Sub-Option fields.
  963.  
  964.    Sub-Option Type
  965.  
  966.       The following Sub-Option Types are defined for the Phone-Delta
  967.       option.
  968.  
  969.           01   Unique-Digits
  970.           02   Subscriber-Number
  971.           03   Phone-Number-Sub-Address
  972.  
  973.    Sub-Option Length
  974.  
  975.       The Sub-Option Length field is one octet, and indicates the length
  976.       of this BAP Sub-Option including the Sub-Option Type, Sub-Option
  977.       Length, and Sub-Option fields.
  978.  
  979. 6.2.1.  Phone-Delta Sub-Options
  980.  
  981.    Unique-Digits
  982.  
  983.       The Unique-Digits Sub-Option field consists of one octet that is a
  984.       count of the number of rightmost digits of the Subscriber-Number
  985.       that are different from the set of phone numbers of the ports used
  986.       in this multilink connection.  (For example, if the first port of
  987.       a multilink bundle has a phone number of 123456789, and an
  988.       implementation wanted its peer to call a port with a phone number
  989.       of 123456888, the Unique-Digits octet would be 3.) If the Phone-
  990.       Number-Sub-Address Sub-Option is present, the Unique-Digits Sub-
  991.       Option MUST NOT include any of the Sub Address digits in its count
  992.       of different rightmost digits.
  993.  
  994.       This field is required.
  995.  
  996.    Subscriber-Number
  997.  
  998.       This field is the phone number of the port that should be called
  999.       by the peer. Any digits that precede the rightmost unique digits
  1000.       of the Subscriber-Number are provided for informational purposes
  1001.       only, and do not need to be included in this field.  This field is
  1002.       an ASCII string and MUST contain only ASCII characters indicating
  1003.       valid phone number digits.  This field is required.
  1004.  
  1005.  
  1006.  
  1007.  
  1008.  
  1009.  
  1010. Richards & Smith            Standards Track                    [Page 18]
  1011.  
  1012. RFC 2125                       PPP BACP                       March 1997
  1013.  
  1014.  
  1015.    Phone-Number-Sub-Address
  1016.  
  1017.       This field is the sub address of the port to be called by the
  1018.       peer.  This sub-option SHOULD only be used for an ISDN call. This
  1019.       field is an ASCII string and only contains valid phone number
  1020.       digits. This field is optional.
  1021.  
  1022. 6.3.  No-Phone-Number-Needed
  1023.  
  1024.    Description
  1025.  
  1026.       The No-Phone-Number option indicates that the calling
  1027.       implementation is already configured with the phone number of its
  1028.       multilink peer and the answering implementation MUST NOT include
  1029.       the Phone Number option in the response.  This may be for security
  1030.       reasons, for configuration reasons, or for any other reason.
  1031.  
  1032.       This option MAY be used in a Call-Request packet.
  1033.  
  1034.    A summary of the No-Phone-Number BAP Option format is shown below.
  1035.    The fields are transmitted from left to right.
  1036.  
  1037.     0                   1
  1038.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
  1039.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1040.    |     Type      |    Length     |
  1041.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1042.  
  1043.    Type
  1044.  
  1045.       03 for No-Phone-Number.
  1046.  
  1047.    Length
  1048.  
  1049.       2
  1050.  
  1051.  
  1052.  
  1053.  
  1054.  
  1055.  
  1056.  
  1057.  
  1058.  
  1059.  
  1060.  
  1061.  
  1062.  
  1063.  
  1064.  
  1065.  
  1066. Richards & Smith            Standards Track                    [Page 19]
  1067.  
  1068. RFC 2125                       PPP BACP                       March 1997
  1069.  
  1070.  
  1071. 6.4.  Reason
  1072.  
  1073.    Description
  1074.  
  1075.       This option is used to indicate a reason for the Request or
  1076.       Response.  It is meant to be used for informational purposes only.
  1077.       This option MAY be used in any BAP packet.
  1078.  
  1079.    A summary of the Reason BAP Option format is shown below.  The fields
  1080.    are transmitted from left to right.
  1081.  
  1082.     0                   1                   2                   3
  1083.     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
  1084.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1085.    |     Type      |    Length     |         Reason String...
  1086.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1087.  
  1088.    Type
  1089.  
  1090.       04 for Reason.
  1091.  
  1092.    Length
  1093.  
  1094.       The Length field is one octet, and indicates the length of this
  1095.       BAP Option including the Type, Length and Reason String fields.
  1096.  
  1097.    Reason String
  1098.  
  1099.       This is an ASCII string.  The content of the field is
  1100.       implementation dependent.  An implementation MAY ignore the Reason
  1101.       String field.
  1102.  
  1103.  
  1104.  
  1105.  
  1106.  
  1107.  
  1108.  
  1109.  
  1110.  
  1111.  
  1112.  
  1113.  
  1114.  
  1115.  
  1116.  
  1117.  
  1118.  
  1119.  
  1120.  
  1121.  
  1122. Richards & Smith            Standards Track                    [Page 20]
  1123.  
  1124. RFC 2125                       PPP BACP                       March 1997
  1125.  
  1126.  
  1127. 6.5.  Link-Discriminator
  1128.  
  1129.    Description
  1130.  
  1131.       The Link-Discriminator option MUST be used in a Link-Drop-Query-
  1132.       Request datagram.  This option is used to inform the receiver of a
  1133.       Link-Drop-Query-Request of which link will be dropped.
  1134.  
  1135.    A summary of the Link-Discriminator BAP Option format is shown below.
  1136.    The fields are transmitted from left to right.
  1137.  
  1138.     0                   1                   2                   3
  1139.     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
  1140.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1141.    |     Type      |    Length     |       Link Discriminator      |
  1142.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1143.  
  1144.    Type
  1145.  
  1146.       05 for Link-Discriminator
  1147.  
  1148.    Length
  1149.  
  1150.       4
  1151.  
  1152.    Link Discriminator
  1153.  
  1154.       The Link Discriminator field is 2 octets in length.  It contains
  1155.       the Link Discriminator that was contained in the LCP Link-
  1156.       Discriminator Configuration Option sent by the receiver of the
  1157.       packet containing the Link Discriminator.
  1158.  
  1159. 6.6.  Call-Status
  1160.  
  1161.    Description
  1162.  
  1163.       The Call-Status option MUST be used in a Call-Status-Indication
  1164.       datagram.  This option is used to inform the receiver of the
  1165.       Call-Status-Indication datagram of the status of the completed
  1166.       call attempt, as well as a possible action that will be taken (if
  1167.       the call failed).
  1168.  
  1169.  
  1170.  
  1171.  
  1172.  
  1173.  
  1174.  
  1175.  
  1176.  
  1177.  
  1178. Richards & Smith            Standards Track                    [Page 21]
  1179.  
  1180. RFC 2125                       PPP BACP                       March 1997
  1181.  
  1182.  
  1183.    A summary of the Call-Status BAP Option format is shown below.  The
  1184.    fields are transmitted from left to right.
  1185.  
  1186.     0                   1                   2                   3
  1187.     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
  1188.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1189.    |     Type      |    Length     |     Status    |     Action    |
  1190.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1191.  
  1192.    Type
  1193.  
  1194.       06 for Call-Status.
  1195.  
  1196.    Length
  1197.  
  1198.       4
  1199.  
  1200.    Status
  1201.  
  1202.       The Status field is 1 octet in length.  If the call was
  1203.       successful, the value MUST be set to 0.  A non-zero value
  1204.       indicates a call failure.  A value of 255 indicates a non-specific
  1205.       failure, and a more specific call status MAY be indicated by using
  1206.       the same number as the Q.931 cause value (i.e., 1 is unassigned
  1207.       number, 17 is user busy, etc.)
  1208.  
  1209.    Action
  1210.  
  1211.    The Action octet indicates what action the calling implementation is
  1212.    taking after a failed call.  If the call was sucessful, the Action
  1213.    octet MUST be set to 0.
  1214.  
  1215.    The Action octet can have the following values:
  1216.  
  1217.       0 - No retry
  1218.       1 - Retry
  1219.  
  1220.  
  1221.  
  1222.  
  1223.  
  1224.  
  1225.  
  1226.  
  1227.  
  1228.  
  1229.  
  1230.  
  1231.  
  1232.  
  1233.  
  1234. Richards & Smith            Standards Track                    [Page 22]
  1235.  
  1236. RFC 2125                       PPP BACP                       March 1997
  1237.  
  1238.  
  1239. Appendix
  1240.  
  1241. List of BAP datagrams and associated fields.
  1242.  
  1243. datagram                      mandatory fields           allowed options
  1244. --------                      -----------------          ---------------
  1245. Call-Request                  Link-Type                  No-Phone-Number
  1246. Call-Response                                            Phone-Delta
  1247.                                                          Link-Type
  1248. Callback-Request              Link-Type
  1249.                               Phone-Delta
  1250. Callback-Response                                        Link-Type
  1251. Link-Drop-Query-Request       Link-Discriminator
  1252. Link-Drop-Query-Response
  1253. Call-Status-Indication        Call-Status                Phone-Delta
  1254. Call-Status-Response
  1255.  
  1256.    The Reason option is allowed to be included with any BAP datagram.
  1257.  
  1258. History of BACP
  1259.  
  1260.    The first version of BACP was written by Craig Richards of Shiva
  1261.    Corporation.  This version was enhanced and improved by the MPCP
  1262.    Working Group, a collaborative effort of 3Com, Ascend, Bay Networks,
  1263.    Cisco, Microsoft, Shiva, US Robotics and Xylogics.
  1264.  
  1265. Acknowledgements
  1266.  
  1267.    Kevin Smith of Ascend for his contributions based on his work on the
  1268.    MP+ Specification.  Gerry Meyer and Robert Myhill of Shiva for their
  1269.    early comments and improvements.  Andy Nicholson of Microsoft for his
  1270.    improvements to the bandwidth management scheme.  Dana Blair and Andy
  1271.    Valencia of Cisco, Cheng Chen and Dan Brennan of 3Com for their good
  1272.    ideas as part of the MPCP Working Group. All of the members of the
  1273.    MPCP working group for their ability to work with their competitors
  1274.    with enthusiasm to produce a better protocol for the industry.
  1275.  
  1276. Security Considerations
  1277.  
  1278.    Security issues are not discussed in this memo.
  1279.  
  1280.  
  1281.  
  1282.  
  1283.  
  1284.  
  1285.  
  1286.  
  1287.  
  1288.  
  1289.  
  1290. Richards & Smith            Standards Track                    [Page 23]
  1291.  
  1292. RFC 2125                       PPP BACP                       March 1997
  1293.  
  1294.  
  1295. References
  1296.  
  1297. [1]   Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD
  1298.       51, RFC 1661, Daydreamer, July 1994.
  1299.  
  1300. [2]   Sklower, Lloyd, McGregor, Carr & Coradetti, "The PPP Multilink
  1301.       Protocol", RFC 1990,  University of California, Berkeley, Lloyd
  1302.       Internetworking, Newbridge Networks Corporation, Sidewalk
  1303.       Software, August 1996.
  1304.  
  1305. Chair's Address
  1306.  
  1307.    The working group can be contacted via the current chair:
  1308.  
  1309.       Karl Fox
  1310.       Ascend Communications
  1311.       3518 Riverside Drive, Suite 101
  1312.       Columbus, Ohio  43221
  1313.  
  1314.       (614)451-1883
  1315.  
  1316.       EMail: karl@ascend.com
  1317.  
  1318. Editors' Addresses
  1319.  
  1320.       Craig Richards
  1321.       Shiva Corporation
  1322.       28 Crosby Drive
  1323.       Bedford, MA  01730
  1324.       VOICE   +1 617 270 8419
  1325.       FAX     +1 617 270 8599
  1326.  
  1327.       EMail: crich@us.shiva.com
  1328.  
  1329.  
  1330.       Kevin Smith
  1331.       Ascend Communications, Inc.
  1332.       1275 Harbor Bay Parkway
  1333.       Alameda, CA  94501
  1334.       CA
  1335.  
  1336.       EMail: kevin@ascend.com
  1337.  
  1338.  
  1339.  
  1340.  
  1341.  
  1342.  
  1343.  
  1344.  
  1345.  
  1346. Richards & Smith            Standards Track                    [Page 24]
  1347.  
  1348.