idnits 2.17.1 draft-ietf-pppext-bacp-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 3 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** The abstract seems to contain references ([2]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 66: '... MUST This word, or the adjecti...' RFC 2119 keyword, line 69: '... MUST NOT This phrase means that th...' RFC 2119 keyword, line 72: '... SHOULD This word, or the adjecti...' RFC 2119 keyword, line 78: '... MAY This word, or the adjecti...' RFC 2119 keyword, line 80: '...h does not include this option MUST be...' (98 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 1996) is 10024 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. '1' Summary: 12 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PPP Working Group Craig Richards 3 Internet Draft Shiva Corporation 4 expires May 1997 Kevin Smith 5 Ascend Communications, Inc. 6 November 1996 8 The PPP Bandwidth Allocation Protocol (BAP) 9 The PPP Bandwidth Allocation Control Protocol (BACP) 10 draft-ietf-pppext-bacp-05.txt 12 Status of this Memo 14 This document is a submission to the Point-to-Point Protocol Working 15 Group of the Internet Engineering Task Force (IETF). Comments should 16 be submitted to the ietf-ppp@merit.edu mailing list. 18 Distribution of this memo is unlimited. 20 Internet Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its Areas, and its Working Groups. Note that 22 other groups may also distribute working documents as Internet 23 Drafts. 25 Internet Drafts are draft documents valid for a maximum of six 26 months. Internet Drafts may be updated, replaced, or obsoleted by 27 other documents at any time. It is not appropriate to use Internet 28 Drafts as reference material or to cite them other than as a 29 ``working draft'' or ``work in progress.'' 31 Please check the 1id-abstracts.txt listing contained in the 32 internet-drafts Shadow Directories on nic.ddn.mil, ds.internic.net, 33 venera.isi.edu, nic.nordu.net, or munnari.oz.au to learn the current 34 status of any Internet Draft. 36 Abstract 38 This document proposes a method to manage the dynamic bandwidth 39 allocation of implementations supporting the PPP multilink protocol 40 [2]. This is done by defining the Bandwidth Allocation Protocol 41 (BAP), as well as its associated control protocol, the Bandwidth 42 Allocation Control Protocol (BACP). BAP can be used to manage the 43 number of links in a multilink bundle. BAP defines datagrams to co- 44 ordinate adding and removing individual links in a multilink bundle, 45 as well as specifying which peer is responsible for which decisions 46 regarding managing bandwidth during a multilink connection. 48 RFC DRAFT PPP BACP November 1996 50 1. Introduction 52 As PPP multilink implementations become increasingly common, there is 53 a greater need for some conformity in how to manage bandwidth over 54 such links. BACP and BAP provide a flexible yet robust way of 55 managing bandwidth between 2 peers. BAP does this by defining Call- 56 Control packets and a protocol that allows peers to co-ordinate the 57 actual bandwidth allocation and de-allocation. Phone number deltas 58 may be passed in the Call-Control packets to minimize the end user's 59 configuration. 61 1.1. Specification of Requirements 63 In this document, several words are used to signify the requirements 64 of the specification. These words are often capitalized. 66 MUST This word, or the adjective "required", means that the 67 definition is an absolute requirement of the specification. 69 MUST NOT This phrase means that the definition is an absolute 70 prohibition of the specification. 72 SHOULD This word, or the adjective "recommended", means that there 73 may exist valid reasons in particular circumstances to 74 ignore this item, but the full implications must be 75 understood and carefully weighed before choosing a 76 different course. 78 MAY This word, or the adjective "optional", means that this 79 item is one of an allowed set of alternatives. An 80 implementation which does not include this option MUST be 81 prepared to interoperate with another implementation which 82 does include the option. 84 1.2. Terminology 86 This document frequently uses the following terms: 88 peer The other end of the point-to-point link 90 silently discard 91 This means the implementation discards the packet without 92 further processing. The implementation SHOULD provide the 93 capability of logging the error, including the contents of 94 the silently discarded packet, and SHOULD record the event 95 in a statistics counter. 97 BOD (bandwidth on demand) 99 RFC DRAFT PPP BACP November 1996 101 BOD refers to the ability of a system to allocate and 102 remove links in a multilink system to change the bandwidth 103 of a multilink bundle. This may be done in response to 104 changing line conditions and it also may be done in 105 response to changing resource conditions. In either case, 106 changing bandwidth dynamically during a multilink 107 connection is referred to as BOD. 109 2. New LCP Configuration Option 111 Implementations MUST implement LCP as defined in [1]. LCP MUST be in 112 the Network-Layer Protocol phase before BACP can be negotiated. 114 2.1. Link Discriminator 116 Description 118 This LCP Configuration Option is used to declare a unique 119 discriminator for the link that the option is sent over. This 120 option MUST be negotiated by LCP on every link. BAP uses the link 121 discriminator to differentiate the various links in a multilink 122 bundle. Each link in a multilink bundle MUST have a unique 123 discriminator. The discriminator is independent for each peer, so 124 each link may have 2 different LCP Link Discriminator values, one 125 for each peer. When the Link Discriminator is sent in a BAP 126 packet, the transmitter sends the Link Discriminator Option value 127 received from its peer in the peer's LCP Configure Request packet. 129 A summary of the Link Discriminator LCP Option format is shown below. 130 The fields are transmitted from left to right. 132 0 1 2 3 133 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 134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 135 | Type | Length | Link Discriminator | 136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 138 Type 140 23 for Link Discriminator option. 142 Length 144 4 146 RFC DRAFT PPP BACP November 1996 148 Link Discriminator 150 The Link Discriminator field is 2 octets in Length, and it 151 contains a unique identifier used to indicate a particular link in 152 a multilink bundle. The Link Discriminator for a link MUST be 153 unique among the Link Discriminators assigned by this endpoint for 154 this bundle. The Link Discriminator MAY be assigned in a 155 sequential, monotonically increasing manner. 157 3. BACP Operation 159 BACP uses the same packet exchange mechanism as the Link Control 160 Protocol defined in [1]. BACP packets MUST NOT be exchanged until 161 PPP has reached the Network-Layer Protocol phase. BACP packets 162 received before this phase is reached should be silently discarded. 164 BACP is negotiated once per multilink bundle. If BACP is negotiated 165 on any of the links in a multilink bundle, it is opened for all of 166 the links in the bundle. 168 The Bandwidth Allocation Control Protocol is exactly the same as the 169 Link Control Protocol [1] with the following exceptions: 171 Data Link Layer Protocol Field 173 Exactly one BACP packet is encapsulated in the Information 174 field of PPP Data Link Layer frames where the Protocol field 175 indicates Type hex 8071 (Bandwidth Allocation Control 176 Protocol). 178 Code field 180 Only Codes 1 through 7 (Configure-Request, Configure-Ack, 181 Configure-Nak, Configure-Reject, Terminate-Request, Terminate- 182 Ack and Code-Reject) are used. Other Codes should be treated 183 as unrecognized and should result in Code-Rejects. 185 Configuration Option Types 187 BACP has a distinct set of Configuration Options, which are 188 defined in the next section. 190 4. BACP Configuration Options 192 BACP Configuration Options allow negotiation of desirable BACP 193 parameters. These options are used in Config-Request, Config-Ack, 194 Config-Nak, and Config-Reject packets. BACP uses the same 196 RFC DRAFT PPP BACP November 1996 198 Configuration Option format defined for LCP [1], with a seperate set 199 of Options. 201 Current values of BACP Configuration Options are assigned as follows: 203 1 Favored-Peer 205 4.1. Favored-Peer 207 Description 209 This Configuration Option is used to determine which peer is 210 favored in the event of a race condition in which 2 peers 211 simultaneously transmit the same BAP request. Each peer 212 negotiates a 4 octet magic number, which is successfully 213 negotiated when the 2 Magic-Numbers are different. The favored 214 peer is the peer that transmits the lowest Magic-Number in its 215 Favored-Peer Configuration Option. 217 The Favored-Peer Configuration Option MUST be implemented. 219 BACP will usually be negotiated after only one link of a multilink 220 bundle has reached the Network-Layer Protocol phase. In this 221 situation, it is acceptable for the peer that initiated the 222 connection to use a Magic-Number of 1, and the peer that responded 223 to the connection to use a Magic-Number of 0xFFFFFFFF. If a 224 multilink bundle has been established with links that were 225 originated by each peer, or if it is not clear which peer has 226 initiated a link (on a leased line, for example), then a random 227 number MUST be used for the Magic-Number. Refer to the 228 description of the LCP Magic-Number Configuration Option in [1] 229 for an explanation of how to create a useful random number. 231 When a Configure-Request is received with a Favored-Peer 232 Configuration Option, the received Magic-Number is compared with 233 the Magic-Number of the last Configure-Request sent to the peer. 234 If the two Magic-Numbers are different, then the Favored-Peer 235 negotiation has been successful, and the Favored-Peer Option 236 SHOULD be acknowledged. If the two Magic-Numbers are equal, a 237 Configure-Nak MUST be sent specifying a different Magic-Number 238 value. A new Configure-Request SHOULD NOT be sent to the peer 239 until normal processing would cause it to be sent (that is, until 240 a Configure-Nak is received or the Restart timer runs out). 242 A summary of the Favored-Peer Option format is shown below. The 243 fields are transmitted from left to right. 245 RFC DRAFT PPP BACP November 1996 247 0 1 2 3 248 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 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 | Type | Length | Magic-Number 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 Magic-Number (cont) | 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 Type 257 1 for Favored-Peer 259 Length 261 6 263 Magic-Number 265 The Magic-Number field is four octets, and indicates a number 266 which is very likely to be unique to one end of the link. A 267 Magic-Number of zero is illegal and MUST always be Nak'd. 269 5. BAP Operation 271 5.1. Link Management 273 BAP defines packets, parameters and negotiation procedures to allow 274 two endpoints to negotiate gracefully adding and dropping links from 275 a multilink bundle. An implementation can: 277 o Request permission to add a Link to a bundle (Call-Request) 279 o Request that the peer add a link to a bundle via a callback 280 (Callback-Request) 282 o Negotiate with the peer to drop a link from a bundle (this 283 implies that the peer can refuse) (Link-Drop-Query-Request) 285 After BACP reaches the opened state, either peer MAY request that 286 another link be added to the bundle by sending a BAP Call- or 287 Callback-Request packet. A Call-Request packet is sent if the 288 implementation wishes to originate the call for the new link, and a 289 Callback-Request packet is sent if the implementation wishes its peer 290 to originate the call for the new link. The implementation receiving 291 a Call- or Callback-Request MUST respond with a Call- or Callback- 293 RFC DRAFT PPP BACP November 1996 295 Response with a valid Response Code. 297 After BACP reaches the opened state, either peer MAY request that a 298 link be dropped from the bundle. A BAP Link-Drop-Query-Request 299 packet is sent to the peer to negotiate dropping a link. The peer 300 MUST respond with a Link-Drop-Query-Response. If the peer is 301 agreeable to dropping the link the implementation MUST issue an LCP 302 Terminate-Request to initiate dropping the link. 304 If an implementation wishes to force dropping a link without 305 negotiation, it should simply send an LCP Terminate-Request packet on 306 the link (without sending any BAP Link-Drop-Query-Request). 308 After an LCP Terminate-Request is sent an implementation SHOULD stop 309 transmitting data packets on that link, but still continue to receive 310 and process data packets normally until receipt of a Terminate-Ack 311 from the peer. The receiver of an LCP Terminate-Request SHOULD stop 312 transmitting packets before issuing the Terminate-Ack. This 313 procedure will insure that no data is lost in either direction. 315 5.2. Bandwidth Management 317 BAP allows two peer implementations to manage the bandwidth available 318 to the protocols using the multilink bundle by negotiating when to 319 add and drop links (See Link Management). Use of the negotiation 320 features of BAP makes it unnecessary to require a 'common' algorithm 321 for determining when to add and remove links in a multilink bundle. 323 BOD decisions can be based on link utilization. A BAP implementation 324 may monitor its transmit traffic, both transmit and receive traffic, 325 or choose not to monitor traffic in either direction. If a server 326 system implements bi-directional monitoring, it will allow BOD 327 operation with a client that does not monitor traffic in either 328 direction, which will minimize the end-user's configuration. When an 329 implementation decides that it is time to remove a link due to 330 traffic monitoring, it MUST transmit a Link-Drop-Query-Request to 331 inquire if the peer agrees to drop a link from the current multilink 332 bundle. When an implementation receives a Link-Drop-Query-Request, 333 it SHOULD base its response on the traffic it is monitoring. It MUST 334 NOT base its response solely on its receive data heuristics. 336 The operation of the Link-Drop-Query-Request and -Response datagrams 337 causes a link in a multilink bundle to be left up as long as either 338 implementation that is monitoring link utilization determines that it 339 is necessary. 341 BOD decisions can also be based on the resources (e.g., physical 342 port, B-channel, etc.) available to an implementation. For example, 344 RFC DRAFT PPP BACP November 1996 346 an implementation might remove a link from a multilink bundle to 347 answer an incoming voice call, or might add a link when a line 348 becomes free due to the termination of a separate PPP call on another 349 port. An implementation MUST use an LCP Terminate-Request to remove 350 a link due to a resource condition. 352 5.3. BAP Packets 354 All of the BAP Request and Indication packets require a Response 355 packet in response before taking any action. 357 An implementation MUST set a timer when sending a Request or 358 Indication packet. The value of this timer SHOULD depend on the type 359 and speed of the link or links in use. Upon expiration of this 360 timer, the implementation MUST retransmit the request or indication, 361 with an identical identification number. This procedure will insure 362 that the peer receives the proper request or indication even if a 363 packet is lost during transmission. If a response packet is lost the 364 peer will realize that this is not a new request or indication 365 packet. 367 If the number of retransmissions exceeds the number supported by the 368 implementation for this packet, the implementation MAY take 369 appropriate recovery action. For example, if no response to a Link- 370 Drop-Query-Request is received after 2 retransmissions, an 371 implementation MAY initiate dropping the link by sending an LCP 372 Terminate-Request for that link. 374 Since BAP packets help determine the amount of bandwidth available to 375 an implementation, PPP SHOULD give them priority over other data 376 packets when transmitting. This will help insure the prompt addition 377 and removal of links in a multilink bundle. This is especially 378 important when adding links to a bundle due to bandwidth constraints. 380 5.4. Race Conditions 382 In order to resolve race conditions, an implementation MUST implement 383 the BACP Favored-Peer Configuration Option. 385 A race condition can occur if both implementations send a Call- 386 Request, Callback-Request or Link-Drop-Query-Request at the same 387 time. These race conditions should be solved as follows: 389 If each implementation sends a Call-Request or Callback-Request at 390 the same time, the implementation with the lowest BACP Favored- 391 Peer Magic-Number value SHOULD be favored. 393 RFC DRAFT PPP BACP November 1996 395 If each implementation sends a Link-Drop-Query-Request at the same 396 time, the same scheme SHOULD be used as for Call-Requests. 398 5.5. BAP Datagram Format 400 Description 402 Before any BAP packets may be communicated, PPP MUST reach the 403 Network-Layer Protocol phase, and BACP MUST reach the opened 404 state. 406 Exactly one BAP packet is encapsulated in the Information field of 407 PPP Data Link Layer frames where the Protocol field indicates type 408 hex 0071 (Bandwidth Allocation Protocol). 410 Because ISDN Terminal Adapters sometimes are used to do multilink 411 with a non-multilink aware client, BAP datagrams MUST NOT be 412 compressed or encrypted. Otherwise, the ISDN TA may not be able 413 to properly intercept BAP datagrams needed to control the 414 multilink connection. This refers to compression of the whole 415 datagram; Address-and-Control-Field-Compression and Protocol- 416 Field-Compression are allowed if properly negotiated. 418 The maximum length of a BAP packet transmitted over a PPP link is 419 the same as the maximum length of the Information field of a PPP 420 data link layer frame. 422 Bandwidth Allocation Protocol datagrams can be catagorized as 423 either Request, Indication or Response packets. Every Request and 424 Indication datagram has a corresponding Response packet. Request 425 and Indication datagrams have a slightly different format from 426 Response datagrams, as the Response datagrams include a Response 427 Code octet. 429 All of the BAP datagrams MUST be supported by an implementation. 430 However, that does not mean an implementation must support all BAP 431 datagram actions. An implementation MAY send a Request-Rej to a 432 Request that it does not implement. 434 A summary of the Bandwidth Allocation Protocol datagram Request and 435 Indication packet format is shown below. The fields are transmitted 436 from left to right. 438 RFC DRAFT PPP BACP November 1996 440 0 1 2 3 441 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 442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 443 | Type | Identifier | Length | 444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 445 | Data ... 446 +-+-+-+-+-+-+-+-+ 448 A summary of the Bandwidth Allocation Protocol datagram Response 449 packet format is shown below. The fields are transmitted from left 450 to right. 452 0 1 2 3 453 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 454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 455 | Type | Identifier | Length | 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 457 | Response Code | Data ... 458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 460 Type 462 The Type field is one octet and identifies the type of BAP 463 datagram packet. Datagram types are defined as follows. This 464 field is coded in binary coded hexadecimal. 466 01 Call-Request 467 02 Call-Response 468 03 Callback-Request 469 04 Callback-Response 470 05 Link-Drop-Query-Request 471 06 Link-Drop-Query-Response 472 07 Call-Status-Indication 473 08 Call-Status-Response 475 The various types of BAP datagrams are explained in the following 476 sections. 478 Identifier 480 The Identifier field is one octet and is binary coded. It aids in 481 matching Requests and Indications with Responses. Call-Status- 482 Indication packets MUST use the same Identifier as was used by the 483 original Call-Request or Callback-Request that was used to 484 initiate the call. All other Request or Indication packets MUST 486 RFC DRAFT PPP BACP November 1996 488 use a unique Identifier for each new Request or Indication. All 489 Response packets MUST use the same Identifier as the Identifier in 490 the Request or Indication packet being responded to. When re- 491 transmitting a request or indication, the Identifier MUST be the 492 same as the Identifier used on the previous transmission of the 493 request or indication. 495 Length 497 The Length field is two octets and indicates the length of the 498 packet including the Type, Identifier, Length and Options fields. 499 It is binary encoded. Octets outside the range of the Length field 500 should be treated as Data Link Layer padding and should be ignored 501 on reception. 503 Response Code 505 The Response Code is only present in Response datagrams. It is 506 binary coded and can have the following values: 508 00000000 Request-Ack 509 00000001 Request-Nak 510 00000010 Request-Rej 511 00000011 Request-Full-Nak 513 The Request-Ack Response Code is sent to indicate that the Request 514 or Indication command is valid and was successfully received by an 515 implementation. The Request-Nak Response Code is sent to indicate 516 that the Request command was received, but an implementation does 517 not want the requested action performed at this time. If a 518 Response containing a Request-Nak Response Code is received, the 519 original Request MAY be retried after an implementation determines 520 that sufficient time has elapsed. The Request-Rej Response Code 521 is sent to indicate that the Request command received by an 522 implementation is not implemented (i.e., if reception of a 523 particular request type is not supported by the peer.) The 524 Request-Full-Nak Response Code is sent to indicate that the 525 Request command was received, but an implementation does not want 526 the requested action performed. The Request-Full-Nak is used to 527 indicate that an implementation has reached the maximum (for a 528 Call- or Callback-Request) or the minimum (for a Link-Drop-Query- 529 Request) bandwidth configured or available for this multilink 530 bundle. If a Response containing a Request-Full-Nak Response Code 531 is received, the original Request SHOULD NOT be retried until the 532 total bandwidth of the multilink bundle has changed. 534 RFC DRAFT PPP BACP November 1996 536 Data 538 The Data field is variable in length, and will usually contain the 539 list of zero or more BAP Options that the sender desires to 540 transmit. The format of BAP Options is described in a later 541 chapter. 543 5.5.1. Call-Request 545 Before originating a call to add another link to a multilink bundle, 546 an implementation MUST transmit a Call-Request packet. This will 547 inform the receiver of the request to add another link to the bundle 548 and give the receiver a chance to inform the implementation of the 549 phone number of a free port that can be called. 551 The options field MUST include the Link-Type option. The options 552 field MAY include the No-Phone-Number and/or the Reason options. 554 Upon reception of a Call-Request, a Call-Response datagram MUST be 555 transmitted. 557 5.5.2. Call-Response 559 An implementation MUST transmit a Call-Response datagram in response 560 to a received Call-Request datagram. If the Call-Request is 561 acceptable, the Call-Response MUST have a Response Code of Request- 562 Ack. The Phone-Delta option MUST be included in a Call-Response 563 packet with a Response Code of Request-Ack unless the Call-Request 564 included the No-Phone-Number option. The options field MAY include 565 the Reason and/or Link-Type options. 567 5.5.3. Callback-Request 569 An implementation that wants its peer to originate another link to 570 add to the multilink bundle MUST transmit a Callback-Request packet 571 to its peer. This will inform the receiver of the request to add 572 another link to the bundle along with the number to be called. 574 The options field MUST include the Link-Type and Phone-Delta options. 575 The Reason option MAY also be included. 577 Upon reception of a Callback-Request, a Callback-Response datagram 578 MUST be transmitted. 580 5.5.4. Callback-Response 582 An implementation MUST transmit a Callback-Response datagram in 583 response to a received Callback-Request datagram. If the Callback- 585 RFC DRAFT PPP BACP November 1996 587 Request is acceptable, the Callback-Response MUST have a Response 588 Code of Request-Ack. A Callback-Response packet MAY include the 589 Link-Type option. 591 5.5.5. Link-Drop-Query-Request 593 An implementation that determines that a link is no longer needed and 594 wishes to negotiate dropping it (e.g., based on a throughput BOD 595 decision), MUST transmit a Link-Drop-Query-Request packet. The 596 options field MUST include the Link-Discriminator option (containing 597 the receiver's Link-Discriminator), and MAY include the Reason 598 option. 600 Upon reception of a Link-Drop-Query-Request, an implementation MUST 601 transmit a Link-Drop-Query-Response datagram. The Response-Code will 602 be Request-Ack if it agrees to drop the link; if it does not agree to 603 drop the link the Response-Code will be Request-Nak or Request-Full- 604 Nak. After the receipt of a Link-Drop-Query-Response with a Response 605 Code of Request-Ack, the transmitter of the Link-Drop-Query-Request 606 MUST initiate tear down of the indicated link by sending an LCP 607 Terminate-Request packet on the designated link. 609 5.5.6. Link-Drop-Query-Response 611 An implementation transmits a Link-Drop-Query-Response datagram in 612 response to a received Link-Drop-Query-Request datagram. If the 613 implementation agrees (e.g., based on its throughput BOD algorithm) 614 to reduce the bandwidth of the multilink bundle, then the Response 615 Code MUST be set to Request-Ack. 617 The Reason option MAY be included in the Link-Drop-Query-Response 618 packet. 620 The Link-Drop-Query-Request datagram MUST be supported, as well as 621 the underlying implementation to respond to it. This means that a 622 Link-Drop-Query-Response with a Response Code of Request-Rej MUST NOT 623 be transmitted in response to a Link-Drop-Query-Request. 625 5.5.7. Call-Status-Indication 627 After an implementation attempts to add a link to a bundle as the 628 result of a Call-Request or a Callback-Request, it MUST send a Call- 629 Status-Indication packet to its peer to indicate if the attempt to 630 add the link succeeded or failed. One Indication MUST be sent for 631 each attempt made. For each Call-Status-Indication packet transmitted 632 with the Call-Status Option Action octet set to Retry, a subsequent 633 Call-Status-Indication packet MUST be sent to indicate the success or 634 failure of the retry. The Call-Status option MUST be included to 636 RFC DRAFT PPP BACP November 1996 638 inform the receiver of the status of the attempt to add a link and 639 the action the implementation will take in case of failure. The 640 reason option MAY also be included in the Call-Status-Indication 641 packet. 643 Upon reception of a Call-Status-Indication packet which indicates a 644 failure, an implementation may log the failure and reason code. Upon 645 reception of any Call-Status-Indication packet, a Call-Status- 646 Response datagram MUST be transmitted. 648 5.5.8. Call-Status-Response 650 An implementation transmits a Call-Status-Response datagram in 651 response to a received Call-Status-Indication datagram. The Response 652 Code field MUST be set to Request-Ack in this packet. The Reason 653 option MAY be included in this packet. 655 6. BAP Datagram Options 657 BAP Datagram Options are used in various BAP packets. Their use in 658 various packets is as defined below. The format of these options 659 loosely follows the formatting conventions of LCP Configuration 660 Options. When there are multiple BAP Options in one BAP packet, the 661 options MAY be transmitted in any order. 663 A summary of the BAP Option format is shown below. The fields are 664 transmitted from left to right. 666 0 1 667 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 668 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 669 | Type | Length | Data ... 670 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 672 Type 674 The type field is one octet, and indicates the type of the BAP 675 Datagram Option. This field is binary coded Hexadecimal. The 676 following options are currently defined: 678 RFC DRAFT PPP BACP November 1996 680 01 Link-Type 681 02 Phone-Delta 682 03 No-Phone-Number-Needed 683 04 Reason 684 05 Link-Discriminator 685 06 Call-Status 687 Length 689 The Length field is one octet, and indicates the length of this 690 BAP Option including the Type, Length, and Data fields. 692 Data 694 The Data field is zero or more octets, and contains information 695 specific to the BAP Option. The format and length of the Data 696 field is determined by the Type and Length fields. 698 6.1. Link-Type 700 Description 702 This option indicates the general type of link indicated for the 703 operation being performed. This option does not indicate a 704 specific link type, rather it gives some general characteristics 705 of the desired link type. This option MAY be used along with 706 other knowledge (i.e., the type of the other link(s) in the bundle 707 or user configuration) to determine the type of link desired to be 708 used in the operation. It MUST be included in a Call- or 709 Callback-Request, and MAY be included in a Call- or Callback- 710 Response. 712 A summary of the Link-Type BAP Option format is shown below. The 713 fields are transmitted from left to right. 715 0 1 2 3 716 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 717 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 718 | Type | Length | Link Speed (kbps) | 719 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 720 | Link Type | 721 +-+-+-+-+-+-+-+-+ 723 RFC DRAFT PPP BACP November 1996 725 Type 727 01 for Link-Type. 729 Length 731 The Length field is one octet, and indicates the length of this 732 BAP Option including the Type, Length and Link Type fields. 734 Link Speed 736 The Link Speed field is 2 octets, and indicates the requested 737 speed of the desired link in kilobits per second. This field is 738 coded as 2 binary coded hexadecimal octets, with the most 739 significant octet sent first. 741 Link Type 743 The Link Type field is a bit mask. It is 1 octet in length. Bit 744 0 of the Link Type field corresponds to bit 39 of the Link-Type 745 BAP Option as described above. If a bit is set, it indicates 746 support of the corresponding link type. If the link indicated is 747 different than the supported link types, no bit will be set. 748 Otherwise, at least one bit MUST be set. If an implementation 749 supports more than one link type, more than one bit MAY be set. 751 Bit Link type 752 --- ------------- 753 0 ISDN 754 1 X.25 755 2 analog 756 3 switched digital (non-ISDN) 757 4 ISDN data over voice 758 5-7 reserved 760 If the Length field contains more bits than are defined by this 761 specification, then any bits that are not defined should be 762 ignored. In order to allow for future expansion of this field, it 763 is important to properly support receiving a Link Type field 764 longer than what is defined by this specification. If the Length 765 field is shorter than the number of bits defined, then the 766 implementation should set all bits not received to 0. 768 6.2. Phone-Delta 770 Description 772 The BAP Phone-Delta Option is used by an implementation to give 774 RFC DRAFT PPP BACP November 1996 776 its peer the information needed to make a call. Due to the 777 difficulty of determining which dialing prefixes (if any) are 778 necessary to dial a given phone number/national destination 779 code/country code combination, the phone number to be dialed will 780 be based on a previously known number. This MAY be the original 781 number used to establish the first link of the multilink bundle, a 782 number configured by the user, the phone number used to make a 783 callback connection, or a number determined in some other way. 784 The Phone-Delta Option will consist of a Subscriber-Number Sub- 785 Option along with a Unique-Digits Sub-Option that indicates how 786 many of the digits of the Subscriber-Number are unique among the 787 ports in use, previously used, and to be used in the multilink 788 bundle. There is also an optional Phone-Number-Sub-Address Sub- 789 Option. 791 An implementation MAY include more than one Phone-Delta option in 792 a response. This indicates that there is more than one phone 793 number that can be used for the requested operation. The Phone- 794 Delta option MUST appear in a Callback-Request. It also MUST 795 appear in a Call-Response with a Response Code set to Request-Ack 796 if the Call-Request did not contain the No-Phone-Number option. 797 It MAY be included in the Call-Status-Indication packet. 799 A summary of the Phone-Delta BAP Option format is shown below. The 800 fields are transmitted from left to right. 802 0 1 2 3 803 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 804 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 805 | Type | Length |Sub-Option Type| Sub-Option Len| 806 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 807 | Sub-Option... 808 +-+-+-+-+-+-+-+-+ 810 Type 812 02 for Phone-Delta. 814 Length 816 The Length field is one octet, and indicates the length of this 817 BAP Option including the Type, Length, and Sub-Option fields. 819 Sub-Option Type 821 The following Sub-Option Types are defined for the Phone-Delta 822 option. 824 RFC DRAFT PPP BACP November 1996 826 01 Unique-Digits 827 02 Subscriber-Number 828 03 Phone-Number-Sub-Address 830 Sub-Option Length 832 The Sub-Option Length field is one octet, and indicates the length 833 of this BAP Sub-Option including the Sub-Option Type, Sub-Option 834 Length, and Sub-Option fields. 836 6.2.1. Phone-Delta Sub-Options 838 Unique-Digits 840 The Unique-Digits Sub-Option field consists of one octet that is a 841 count of the number of rightmost digits of the Subscriber-Number 842 that are different from the set of phone numbers of the ports used 843 in this multilink connection. (For example, if the first port of 844 a multilink bundle has a phone number of 123456789, and an 845 implementation wanted its peer to call a port with a phone number 846 of 123456888, the Unique-Digits octet would be 3.) If the Phone- 847 Number-Sub-Address Sub-Option is present, the Unique-Digits Sub- 848 Option MUST NOT include any of the Sub Address digits in its count 849 of different rightmost digits. 851 This field is required. 853 Subscriber-Number 855 This field is the phone number of the port that should be called 856 by the peer. Any digits that precede the rightmost unique digits 857 of the Subscriber-Number are provided for informational purposes 858 only, and do not need to be included in this field. This field is 859 an ASCII string and MUST contain only ASCII characters indicating 860 valid phone number digits. This field is required. 862 Phone-Number-Sub-Address 864 This field is the sub address of the port to be called by the 865 peer. This sub-option SHOULD only be used for an ISDN call. This 866 field is an ASCII string and only contains valid phone number 867 digits. This field is optional. 869 6.3. No-Phone-Number-Needed 870 RFC DRAFT PPP BACP November 1996 872 Description 874 The No-Phone-Number option indicates that the calling 875 implementation is already configured with the phone number of its 876 multilink peer and the answering implementation MUST NOT include 877 the Phone Number option in the response. This may be for security 878 reasons, for configuration reasons, or for any other reason. 880 This option MAY be used in a Call-Request packet. 882 A summary of the No-Phone-Number BAP Option format is shown below. 883 The fields are transmitted from left to right. 885 0 1 886 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 887 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 888 | Type | Length | 889 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 891 Type 893 03 for No-Phone-Number. 895 Length 897 2 899 6.4. Reason 901 Description 903 This option is used to indicate a reason for the Request or 904 Response. It is meant to be used for informational purposes only. 905 This option MAY be used in any BAP packet. 907 A summary of the Reason BAP Option format is shown below. The fields 908 are transmitted from left to right. 910 0 1 2 3 911 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 912 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 913 | Type | Length | Reason String... 914 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 916 RFC DRAFT PPP BACP November 1996 918 Type 920 04 for Reason. 922 Length 924 The Length field is one octet, and indicates the length of this 925 BAP Option including the Type, Length and Reason String fields. 927 Reason String 929 This is an ASCII string. The content of the field is 930 implementation dependent. An implementation MAY ignore the Reason 931 String field. 933 6.5. Link-Discriminator 935 Description 937 The Link-Discriminator option MUST be used in a Link-Drop-Query- 938 Request datagram. This option is used to inform the receiver of a 939 Link-Drop-Query-Request of which link will be dropped. 941 A summary of the Link-Discriminator BAP Option format is shown below. 942 The fields are transmitted from left to right. 944 0 1 2 3 945 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 946 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 947 | Type | Length | Link Discriminator | 948 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 950 Type 952 05 for Link-Discriminator 954 Length 956 4 958 Link Discriminator 960 The Link Discriminator field is 2 octets in length. It contains 961 the Link Discriminator that was contained in the LCP Link- 962 Discriminator Configuration Option sent by the receiver of the 963 packet containing the Link Discriminator. 965 RFC DRAFT PPP BACP November 1996 967 6.6. Call-Status 969 Description 971 The Call-Status option MUST be used in a Call-Status-Indication 972 datagram. This option is used to inform the receiver of the 973 Call-Status-Indication datagram of the status of the completed 974 call attempt, as well as a possible action that will be taken (if 975 the call failed). 977 A summary of the Call-Status BAP Option format is shown below. The 978 fields are transmitted from left to right. 980 0 1 2 3 981 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 982 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 983 | Type | Length | Status | Action | 984 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 986 Type 988 06 for Call-Status. 990 Length 992 4 994 Status 996 The Status field is 1 octet in length. If the call was 997 successful, the value MUST be set to 0. A non-zero value 998 indicates a call failure. A value of 255 indicates a non-specific 999 failure, and a more specific call status MAY be indicated by using 1000 the same number as the Q.931 cause value (i.e., 1 is unassigned 1001 number, 17 is user busy, etc.) 1003 Action 1005 The Action octet indicates what action the calling implementation is 1006 taking after a failed call. If the call was sucessful, the Action 1007 octet MUST be set to 0. 1009 The Action octet can have the following values: 1011 0 - No retry 1012 1 - Retry 1014 RFC DRAFT PPP BACP November 1996 1016 Appendix 1018 List of BAP datagrams and associated fields. 1020 datagram mandatory fields allowed options 1021 -------- ----------------- --------------- 1022 Call-Request Link-Type No-Phone-Number 1023 Call-Response Phone-Delta 1024 Link-Type 1025 Callback-Request Link-Type 1026 Phone-Delta 1027 Callback-Response Link-Type 1028 Link-Drop-Query-Request Link-Discriminator 1029 Link-Drop-Query-Response 1030 Call-Status-Indication Call-Status Phone-Delta 1031 Call-Status-Response 1033 The Reason option is allowed to be included with any BAP datagram. 1035 History of BACP 1037 The first version of BACP was written by Craig Richards of Shiva 1038 Corporation. This version was enhanced and improved by the MPCP 1039 Working Group, a collaborative effort of 3Com, Ascend, Bay Networks, 1040 Cisco, Microsoft, Shiva, US Robotics and Xylogics. 1042 Acknowledgements 1044 Kevin Smith of Ascend for his contributions based on his work on the 1045 MP+ Specification. Gerry Meyer and Robert Myhill of Shiva for their 1046 early comments and improvements. Andy Nicholson of Microsoft for his 1047 improvements to the bandwidth management scheme. Dana Blair and Andy 1048 Valencia of Cisco, Cheng Chen and Dan Brennan of 3Com for their good 1049 ideas as part of the MPCP Working Group. All of the members of the 1050 MPCP working group for their ability to work with their competitors 1051 with enthusiasm to produce a better protocol for the industry. 1053 Security Considerations 1055 Security issues are not discussed in this memo. 1057 References 1059 [1] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD 1061 RFC DRAFT PPP BACP November 1996 1063 51, RFC 1661, Daydreamer, July 1994. 1065 [2] Sklower, Lloyd, McGregor, Carr & Coradetti, "The PPP Multilink 1066 Protocol", RFC 1990, University of California, Berkeley, Lloyd 1067 Internetworking, Newbridge Networks Corporation, Sidewalk 1068 Software, August 1996. 1070 Chair's Address 1072 The working group can be contacted via the current chair: 1074 Karl Fox 1075 Ascend Communications 1076 3518 Riverside Drive, Suite 101 1077 Columbus, Ohio 43221 1079 (614)451-1883 1081 EMail: karl@ascend.com 1083 Editors' Addresses 1085 Craig Richards 1086 Shiva Corporation 1087 28 Crosby Drive 1088 Bedford, MA 01730 1089 VOICE +1 617 270 8419 1090 FAX +1 617 270 8599 1092 EMail: crich@us.shiva.com 1094 Kevin Smith 1095 Ascend Communications, Inc. 1096 1275 Harbor Bay Parkway 1097 Alameda, CA 94501 1098 CA 1100 EMail: kevin@ascend.com 1102 RFC DRAFT PPP BACP November 1996 1104 Table of Contents 1106 1. Introduction .......................................... 1 1107 1.1 Specification of Requirements ................... 1 1108 1.2 Terminology ..................................... 1 1110 2. New LCP Configuration Option .......................... 2 1111 2.1 Link Discriminator .............................. 2 1113 3. BACP Operation ........................................ 3 1115 4. BACP Configuration Options ............................ 3 1116 4.1 Favored-Peer .................................... 4 1118 5. BAP Operation ......................................... 5 1119 5.1 Link Management ................................. 5 1120 5.2 Bandwidth Management ............................ 6 1121 5.3 BAP Packets ..................................... 7 1122 5.4 Race Conditions ................................. 7 1123 5.5 BAP Datagram Format ............................. 8 1124 5.5.1 Call-Request .................................... 11 1125 5.5.2 Call-Response ................................... 11 1126 5.5.3 Callback-Request ................................ 11 1127 5.5.4 Callback-Response ............................... 11 1128 5.5.5 Link-Drop-Query-Request ......................... 12 1129 5.5.6 Link-Drop-Query-Response ........................ 12 1130 5.5.7 Call-Status-Indication .......................... 12 1131 5.5.8 Call-Status-Response ............................ 13 1133 6. BAP Datagram Options .................................. 13 1134 6.1 Link-Type ....................................... 14 1135 6.2 Phone-Delta ..................................... 15 1136 6.2.1 Phone-Delta Sub-Options ......................... 17 1137 6.3 No-Phone-Number-Needed .......................... 17 1138 6.4 Reason .......................................... 18 1139 6.5 Link-Discriminator .............................. 19 1140 6.6 Call-Status ..................................... 20 1142 Appendix - List of BAP datagrams and associated fields ....... 21 1144 ACKNOWLEDEMENTS .............................................. 21 1146 SECURITY CONSIDERATIONS ...................................... 21 1148 REFERENCES ................................................... 21 1150 CHAIR'S ADDRESS .............................................. 22 1152 RFC DRAFT PPP BACP November 1996 1154 EDITORS'S ADDRESSES .......................................... 22