RFC 2125
The PPP Bandwidth Allocation Protocol (BAP) / The PPP Bandwidth Allocation Control Protocol (BACP)
RFC 2125 🎀 The PPP Bandwidth Allocation Protocol (BAP) and The PPP Bandwidth Allocation Control Protocol (BACP)
Okay bestie, the basics first 💅 This is RFC 2125, published in March 1997 under the Network Working Group. It's a Standards Track doc, written by C. Richards (Shiva Corporation) and K. Smith (Ascend Communications, Inc.). It doesn't obsolete or update any other RFCs. 🦋
Status of this Memo ✨
This document is an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements. For the standardization state and status of this protocol, check the current edition of "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited. 🌸
Abstract 🧚
So this doc proposes a way to manage dynamic bandwidth allocation in implementations that support the PPP multilink protocol [2]. It does that by defining the Bandwidth Allocation Protocol (BAP), plus its control protocol, the Bandwidth Allocation Control Protocol (BACP) 💜. BAP can manage how many links are in a multilink bundle. It defines datagrams for coordinating the adding and removing of individual links, and it says which peer is responsible for which bandwidth decisions during a multilink connection. Iconic 👑
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
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 .......................................... 241. Introduction ✨
Okay so PPP multilink setups are getting super common, which means we need a bit more conformity in how bandwidth gets managed over those links 🫶 BACP and BAP give you a flexible yet robust way to manage bandwidth between 2 peers. BAP does this with Call-Control packets and a protocol that lets peers coordinate the actual allocation and de-allocation of bandwidth. Phone number deltas can be passed in those Call-Control packets too, so the end user's configuration stays minimal. Lowkey genius 🧠
1.1. Specification of Requirements 💖
In this document, a few words signal the requirements of the specification. They're usually capitalized, so watch for them 👀
- MUST: This word, or the adjective "required", means the definition is an absolute requirement of the specification.
- MUST NOT: This phrase means the definition is an absolute prohibition of the specification.
- SHOULD: This word, or the adjective "recommended", means there may be valid reasons in particular circumstances to ignore this item. The full implications still have to be understood and carefully weighed before picking a different course. Think before you skip it, bestie 🙈
- MAY: This word, or the adjective "optional", means this item is one of an allowed set of alternatives. An implementation that doesn't include this option MUST be prepared to interoperate with another implementation that does include it. Be nice to your optional-feature friends 🌈
1.2. Terminology 🦋
This document uses the following terms a lot:
- peer: The other end of the point-to-point link.
- silently discard: The implementation throws the packet away without further processing. It SHOULD be able to log the error, including the contents of the silently discarded packet, and SHOULD record the event in a statistics counter. 📝
- BOD (bandwidth on demand): BOD is the ability of a system to allocate and remove links in a multilink system to change the bandwidth of a multilink bundle. This can happen in response to changing line conditions, changing resource conditions, or both. Changing bandwidth dynamically during a multilink connection is called 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. No skipping ahead, babe 💅
2.1. Link Discriminator 💜
Description
This LCP Configuration Option declares a unique discriminator for the link it's sent over. This option MUST be negotiated by LCP on every link. BAP uses the link discriminator to tell apart the different 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 it received from its peer in the peer's LCP Configure Request packet. Ngl this part is a lot, but you've got this ✨
Here's a quick look at the Link Discriminator LCP Option format. The fields go 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 the Link Discriminator option.
Length
4
Link Discriminator
The Link Discriminator field is 2 octets long and holds a unique identifier that points to a particular link in a multilink bundle. The Link Discriminator for a link MUST be unique among the Link Discriminators this endpoint assigns for this bundle. The Link Discriminator MAY be assigned in a sequential, monotonically increasing manner. Sequential is an option, not a must 🍭
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 that phase is reached should be silently discarded.
BACP is negotiated once per multilink bundle. If BACP is negotiated on any link in a multilink bundle, it's opened for all of the links in the bundle. One and done, iconic 👑
The Bandwidth Allocation Control Protocol is exactly the same as the Link Control Protocol [1], with these 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). 📦
Code field
Only Codes 1 through 7 are used: Configure-Request, Configure-Ack, Configure-Nak, Configure-Reject, Terminate-Request, Terminate-Ack and Code-Reject. Other Codes should be treated as unrecognized and should result in Code-Rejects. Not you sending random codes 💀
Configuration Option Types
BACP has its own distinct set of Configuration Options, which are defined in the next section.
4. BACP Configuration Options 🌸
BACP Configuration Options let peers negotiate the BACP parameters they want. 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], but with a separate set of Options. Same format, different menu 🍓
The current values of BACP Configuration Options are assigned as follows:
1 Favored-Peer4.1. Favored-Peer 💖
Description 🎀
okay bestie, so this option is how two peers figure out who gets to be the favored one 👑 when they both accidentally send the same BAP request at the exact same moment (a race condition, iykyk 💀). Each peer negotiates a 4 octet magic number, and it only counts as successfully negotiated when the two Magic-Numbers are different ✨. The favored peer is whoever transmits the lowest Magic-Number in its Favored-Peer Configuration Option.
The Favored-Peer Configuration Option MUST be implemented. 💅
BACP usually gets negotiated after only one link of a multilink bundle has reached the Network-Layer Protocol phase 🧚. In that situation, it's totally fine for the peer that started the connection to use a Magic-Number of 1, and the peer that answered to use a Magic-Number of 0xFFFFFFFF. But if a bundle has links originated by each peer, or it's just not clear which peer started a link (like on a leased line, for example 🙈), then a random number MUST be used for the Magic-Number. Check out the LCP Magic-Number Configuration Option description in [1] for how to make a useful random number 🌈.
When a Configure-Request comes in with a Favored-Peer Configuration Option, the received Magic-Number gets compared with the Magic-Number of the last Configure-Request sent to that peer. If the two are different, the Favored-Peer negotiation has worked 🎉 and the Favored-Peer Option SHOULD be acknowledged. If the two 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 send it anyway (so, until a Configure-Nak is received or the Restart timer runs out) ⏰.
The summary of the Favored-Peer Option format is below, and the fields go out 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 is 1, which means Favored-Peer.
Length is 6.
Magic-Number is four octets long and holds a number that's very likely to be unique to one end of the link. A Magic-Number of zero is illegal and MUST always be Nak'd. Zero is a no-go, periodt 🙅♀️.
5. BAP Operation 🦋
5.1. Link Management
BAP defines packets, parameters and negotiation procedures so two endpoints can negotiate adding and dropping links from a multilink bundle super gracefully ✨. An implementation can:
- Request permission to add a link to a bundle (
Call-Request) - Ask the peer to add a link to a bundle via a callback (
Callback-Request) - Negotiate with the peer to drop a link from a bundle (this means the peer can say no) (
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 is sent if the implementation wants to originate the call for the new link, and a Callback-Request is sent if it wants its peer to originate the call instead. The implementation receiving a Call- or Callback-Request MUST respond with a Call- or Callback-Response that has a valid Response Code 💌.
After BACP reaches the opened state, either peer MAY also 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 start dropping it 👋.
If an implementation wants to force a link to drop without negotiating, 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 it still keeps receiving and processing data packets normally until it gets a Terminate-Ack from the peer 🫶. The receiver of an LCP Terminate-Request SHOULD stop transmitting packets before it issues the Terminate-Ack. This procedure makes sure no data gets lost in either direction 🌸.
5.2. Bandwidth Management
BAP lets two peer implementations manage the bandwidth available to the protocols using the multilink bundle by negotiating when to add and drop links (see Link Management) 🌈. Using BAP's negotiation features means you don't have to require a 'common' algorithm for deciding when to add and remove links in a multilink bundle. Major relief, honestly 😮💨.
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 doesn't monitor traffic in either direction, which keeps the end-user's configuration minimal 🍓. When an implementation decides it's time to remove a link because of traffic monitoring, it MUST transmit a Link-Drop-Query-Request to ask whether 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's monitoring. It MUST NOT base its response solely on its receive data heuristics 🙅♀️.
The Link-Drop-Query-Request and -Response datagrams work together so a link in a multilink bundle stays up for as long as either implementation that's monitoring link utilization decides it's needed ⭐.
BOD decisions can also be based on the resources available to an implementation (e.g., physical port, B-channel, etc.) 🔌. For example, an implementation might remove a link from a multilink bundle to answer an incoming voice call, or it might add a link when a line becomes free because a separate PPP call on another port ended 📱. 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 before the implementation takes 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 ⏱️. When the timer expires, the implementation MUST retransmit the request or indication, with an identical identification number. This makes sure the peer gets the proper request or indication even if a packet gets lost in transit 🫶. If a response packet is lost, the peer will realize this isn't a new request or indication packet.
If the number of retransmissions goes over the number the implementation supports for this packet, the implementation MAY take appropriate recovery action 🛠️. For example, if no response to a Link-Drop-Query-Request comes back after 2 retransmissions, an implementation MAY start dropping the link by sending an LCP Terminate-Request for that link.
Since BAP packets help decide how much bandwidth an implementation has available, PPP SHOULD give them priority over other data packets when transmitting 🚀. This helps make sure links get added and removed promptly in a multilink bundle. It's especially important when adding links to a bundle because of bandwidth constraints 💜.
5.4. Race Conditions
To resolve race conditions, an implementation MUST implement the BACP Favored-Peer Configuration Option 👑.
A race condition can happen 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 💖
okay so before any BAP packets can be sent, PPP MUST reach the Network-Layer Protocol phase, and BACP MUST reach the opened state. no skipping ahead, bestie 🙅♀️
Exactly one BAP packet rides inside the Information field of a PPP Data Link Layer frame whose Protocol field is hex c02d (Bandwidth Allocation Protocol) 🎀
Some ISDN Terminal Adapters are used to do multilink with a client that isn't multilink aware, so BAP datagrams MUST NOT be compressed or encrypted 😭 If they were, the ISDN TA might not be able to catch the BAP datagrams it needs to control the multilink connection. This is about compressing the whole datagram. Address-and-Control-Field-Compression and Protocol-Field-Compression are fine, as long as they've been properly negotiated ✨
The maximum length of a BAP packet sent over a PPP link is the same as the maximum length of the Information field of a PPP data link layer frame.
BAP datagrams come in three flavors: Request, Indication, or Response packets. Every Request and Indication datagram has a matching Response packet 🦋 Request and Indication datagrams look a little different from Response datagrams, because Responses carry a Response Code octet.
All of the BAP datagrams MUST be supported by an implementation. That doesn't mean an implementation has to support every BAP datagram action, though 🙈 An implementation MAY send a Request-Rej to a Request that it does not implement.
Here's the summary of the Request and Indication packet format. The fields go 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 ...
+-+-+-+-+-+-+-+-+And here's the Response packet format, also 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 tells you what kind of BAP datagram you're looking at. It's binary coded hexadecimal, and the types are:
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-ResponseEach type gets its own section below, so keep scrolling ✨
Identifier 🔖
The Identifier field is one octet, binary coded, and it's what matches Requests and Indications with their Responses. Call-Status-Indication packets MUST use the same Identifier as the original Call-Request or Callback-Request that started the call. Every other Request or Indication packet MUST use a unique Identifier for each new Request or Indication. All Response packets MUST use the same Identifier as the Request or Indication they're answering. When you re-transmit a request or indication, the Identifier MUST be the same as the one used on the previous transmission.
Length 📏
The Length field is two octets, binary encoded, and it tells you the length of the packet including the Type, Identifier, Length, and Options fields. Octets outside the range of the Length field should be treated as Data Link Layer padding and should be ignored on reception.
Response Code 🎯
The Response Code only shows up in Response datagrams. It's binary coded and can be one of these:
00000000 Request-Ack
00000001 Request-Nak
00000010 Request-Rej
00000011 Request-Full-NakRequest-Ack means the Request or Indication command was valid and got received successfully by an implementation. Request-Nak means the Request was received, but the implementation doesn't want the requested action performed at this time. If you get a Response with a Request-Nak, the original Request MAY be retried once an implementation decides enough time has passed. Request-Rej means the Request it received isn't implemented (so the peer doesn't support that request type). Request-Full-Nak means the Request was received, but the implementation doesn't want the action performed either. It's used when an implementation has hit the maximum (for a Call- or Callback-Request) or the minimum (for a Link-Drop-Query-Request) bandwidth that's configured or available for this multilink bundle. If you get a Response with a Request-Full-Nak, 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 usually holds the list of zero or more BAP Options the sender wants to transmit. The format of BAP Options is covered in a later chapter.
5.5.1. Call-Request 📞
Before an implementation originates a call to add another link to a multilink bundle, it MUST transmit a Call-Request packet. This tells the receiver that you want to add a link to the bundle, and it gives the receiver a chance to tell you 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.
When a Call-Request is received, 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.
5.5.3. Callback-Request 🔁
If an implementation wants its peer to originate another link to add to the multilink bundle, it MUST transmit a Callback-Request packet to its peer. This tells the receiver you want a link added and gives them the number to call.
The options field MUST include the Link-Type and Phone-Delta options. The Reason option MAY also be included.
When a Callback-Request is received, 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 👋
If an implementation decides a link isn't needed anymore and wants to negotiate dropping it (for example, based on a throughput BOD decision), it 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.
When a Link-Drop-Query-Request is received, 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 doesn't agree, the Response Code will be Request-Nak or Request-Full-Nak. Once the transmitter of the Link-Drop-Query-Request gets a Link-Drop-Query-Response with a Response Code of Request-Ack, it 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 (for example, based on its throughput BOD algorithm) to reduce the bandwidth of the multilink bundle, then the Response Code MUST be set to Request-Ack.
The Reason option MAY be included in the Link-Drop-Query-Response packet.
The Link-Drop-Query-Request datagram MUST be supported, along with the underlying implementation needed to respond to it. That means a Link-Drop-Query-Response with a Response Code of Request-Rej MUST NOT be transmitted in response to a Link-Drop-Query-Request. No Request-Rej for this one, periodt 💅
5.5.7. Call-Status-Indication 📣
After an implementation tries to add a link to a bundle because of a Call-Request or a Callback-Request, it MUST send a Call-Status-Indication packet to its peer to say whether the attempt succeeded or failed. One Indication MUST be sent for each attempt made. For each Call-Status-Indication packet sent with the Call-Status Option Action octet set to Retry, a subsequent Call-Status-Indication packet MUST be sent to report the success or failure of the retry. The Call-Status option MUST be included so the receiver knows the status of the attempt to add a link and what the implementation will do if it fails. The reason option MAY also be included in the Call-Status-Indication packet.
When a Call-Status-Indication packet arrives that indicates a failure, an implementation may log the failure and reason code. When any Call-Status-Indication packet is received, 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 ✨
okay so BAP Datagram Options are the little add-ons that show up inside various BAP packets 🎀 each packet uses them in its own specific way, which I'll walk through below. The formatting is kinda modeled on LCP Configuration Options (so if you've seen those, you'll recognize the vibe 💜). And when a single BAP packet has more than one BAP Option, they MAY be sent in any order 🦋
Here's the general shape of a BAP Option. Fields go left to right, obviously 💅
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 tells you which kind of BAP Datagram Option you're looking at 🌸 It's binary coded hexadecimal. These are the ones defined right now:
01 Link-Type
02 Phone-Delta
03 No-Phone-Number-Needed
04 Reason
05 Link-Discriminator
06 Call-StatusLength
Also one octet. It's the length of the whole BAP Option, counting the Type, Length, and Data fields too 📏
Data
Zero or more octets with info specific to that option. The Type and Length fields decide what the Data field looks like and how long it is ✨
6.1. Link-Type
Description
This option says what general kind of link the operation is after. It doesn't name one exact link type, it just gives some general vibes about the link you want 🦋 It MAY be used together with other stuff you know (like what type of the other links are in the bundle, or what the user configured) to figure out which link to actually use. It MUST be included in a Call- or Callback-Request, and it MAY be included in a Call- or Callback-Response 💖
Here's how the Link-Type option is laid out, 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
One octet. It's the length of this BAP Option, counting the Type, Length and Link Type fields 📏
Link Speed
This is 2 octets and it's the speed you're requesting for the link, in kilobits per second. It's coded as 2 binary coded hexadecimal octets, and the most significant octet gets sent first 🚀
Link Type
The Link Type field is a bit mask, and it's 1 octet long. Bit 0 of the Link Type field lines up with bit 39 of the Link-Type BAP Option as shown above 🧚 If a bit is set, that means support for the matching link type. If the link you want isn't one of the supported link types, then no bits get 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 reservedIf the Length field has more bits in it than this spec defines, then any undefined bits should be ignored 🙈 Future-proofing is a whole thing here, so it's really important to properly handle receiving a Link Type field that's longer than what's defined here 🌈 And if the Length field is shorter than the number of bits defined, the implementation should set all the bits it didn't receive to 0 🍓
6.2. Phone-Delta
Description
The BAP Phone-Delta Option is how one implementation hands its peer the info it needs to make a call 📞 Figuring out which dialing prefixes (if any) you need to reach a given phone number, national destination code, and country code combo is honestly a nightmare 💀 So the number to dial gets based on a number that's already known. That MAY be the original number used to set up the first link of the multilink bundle, a number the user configured, the phone number used to make a callback connection, or a number figured out some other way 🔥 The Phone-Delta Option has a Subscriber-Number Sub-Option plus a Unique-Digits Sub-Option. The Unique-Digits one says how many of the Subscriber-Number's digits are unique across the ports in use, previously used, and to be used in the multilink bundle. There's also an optional Phone-Number-Sub-Address Sub-Option 🦋
An implementation MAY include more than one Phone-Delta option in a response, which means there's more than one phone number that works for the operation you asked for 👑 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 💜
Here's the layout:
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 🌸
Length
One octet. It's the length of this BAP Option, counting the Type, Length, and Sub-Option fields 📏
Sub-Option Type
These are the Sub-Option Types defined for the Phone-Delta option:
01 Unique-Digits
02 Subscriber-Number
03 Phone-Number-Sub-AddressSub-Option Length
One octet. It's the length of this BAP Sub-Option, counting 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 is one octet that counts how many of the rightmost digits of the Subscriber-Number are different from the phone numbers of the ports used in this multilink connection 🔢 For example, say the first port of a multilink bundle has the phone number 123456789, and the implementation wants its peer to call a port with the number 123456888. Then 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 is the phone number of the port that the peer should call 📱 Any digits in front of the rightmost unique digits of the Subscriber-Number are only there for information, so they don't need to be included in this field. It's an ASCII string and MUST contain only ASCII characters that indicate valid phone number digits 🔥 This field is required.
Phone-Number-Sub-Address
This is the sub address of the port the peer should call 🌈 This sub-option SHOULD only be used for an ISDN call. It's 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 tells you the calling implementation already has its multilink peer's phone number configured, and the answering implementation MUST NOT include the Phone Number option in the response 🙈 This might be for security reasons, for configuration reasons, or any other reason at all 🔐
This option MAY be used in a Call-Request packet 💖
Here's the layout, 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 ✨
6.4. Reason
Description
This option tells you a reason for the Request or Response 💬 It's only for informational purposes, so nothing depends on it. This option MAY be used in any BAP packet 🌸
Here's the layout, 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
One octet. It's the length of this BAP Option, counting the Type, Length and Reason String fields 📏
Reason String
This is an ASCII string, and what goes in it is up to the implementation 🧚 An implementation MAY ignore the Reason String field 🙃
6.5. Link-Discriminator
Description
The Link-Discriminator option MUST be used in a Link-Drop-Query-Request datagram 🔥 It tells the receiver of a Link-Drop-Query-Request which link is about to get dropped 💅
Here's the layout, 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 long. It holds the Link Discriminator that came in the LCP Link-Discriminator Configuration Option sent by the receiver of the packet that contains the Link Discriminator 💜
6.6. Call-Status 💖
Description
Okay so the Call-Status option MUST be used in a Call-Status-Indication datagram 📞✨ It tells whoever gets the Call-Status-Indication how the completed call attempt went, plus what action is gonna happen next if the call failed. Main character info, fr 💅
Here's the Call-Status BAP Option layout 🦋 Fields get sent 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 is the Type for Call-Status 🎀
Length
It's 4 🌸
Status
Status is 1 octet long 🍓 If the call was successful, the value MUST be set to 0 ✅ Anything non-zero means the call failed 😭 A value of 255 means a non-specific failure. A more specific call status MAY be indicated by using the same number as the Q.931 cause value, so 1 is unassigned number, 17 is user busy, etc. 📟
Action
The Action octet tells you what the calling implementation does after a failed call 🧚 If the call was successful, the Action octet MUST be set to 0, no notes 💅
The Action octet can have these values:
0 - No retry1 - Retry
Appendix ✨
List of BAP datagrams and associated fields 📋 This is the whole cast, bestie 👑
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-ResponseThe Reason option is allowed to be included with any BAP datagram 🫶 Like, any of them. No exceptions, periodt 💜
History of BACP 🦋
The first version of BACP was written by Craig Richards of Shiva Corporation 🌈 Then the MPCP Working Group, a collab between 3Com, Ascend, Bay Networks, Cisco, Microsoft, Shiva, US Robotics and Xylogics, glowed it up and made it even better 🔥
Acknowledgements 🙌
Shoutout to Kevin Smith of Ascend for his contributions, based on his work on the MP+ Specification 💖 Gerry Meyer and Robert Myhill of Shiva gave early comments and improvements 🎀 Andy Nicholson of Microsoft improved the bandwidth management scheme 📈 Dana Blair and Andy Valencia of Cisco, plus Cheng Chen and Dan Brennan of 3Com, brought good ideas as part of the MPCP Working Group 🧚 And to every member of the MPCP working group: you worked with your competitors with so much enthusiasm to make a better protocol for the industry. Iconic behaviour 👑🫶
Security Considerations 💀
Security issues are not discussed in this memo. 😱 Read that again, bestie. This doc does not cover them. Please go think about your threat model before you ship anything built on this, no cap 🙈
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.comEditors' 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📦 where this page comes from
- ietf: rfc2125 1997-03
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms