diff options
Diffstat (limited to 'doc/rfc/rfc2125.txt')
| -rw-r--r-- | doc/rfc/rfc2125.txt | 1347 |
1 files changed, 1347 insertions, 0 deletions
diff --git a/doc/rfc/rfc2125.txt b/doc/rfc/rfc2125.txt new file mode 100644 index 0000000..12abd07 --- /dev/null +++ b/doc/rfc/rfc2125.txt @@ -0,0 +1,1347 @@ + + + + + + +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] + |