RFC 5578
PPP over Ethernet (PPPoE) Extensions for Credit Flow and Link Metrics
PPP over Ethernet (PPPoE) Extensions for Credit Flow and Link Metrics ✨
Okay bestie, here's the deal. This is RFC 5578, and it's an Independent Submission with Informational category, published February 2010 🎀 It's by B. Berry (Ed.), S. Ratliff, and E. Paradise from Cisco, T. Kaiser from Harris Corporation, and M. Adams from L3 Communications. It obsoletes RFC 4938, and its ISSN is 2070-1721. The whole vibe is adding optional extras to PPPoE so it works better on wobbly wireless links 📡
Abstract 🌸
This doc adds two optional extras to PPP over Ethernet (PPPoE). The first is a credit-based flow control mechanism, and the second is an optional Link Quality Metric report. These make PPPoE way more reliable over media where the bandwidth keeps changing and there's not much buffer space, like mobile point-to-point radio links 💅
Status of This Memo 🦋
Not an Internet Standards Track spec, just published for info 🤍
This is a contribution to the RFC Series, totally independent of any other RFC stream. The RFC Editor picked to publish it at their discretion and makes no statement about whether it's valuable for anyone to implement or deploy. Docs the RFC Editor approves for publication are not candidates for any level of Internet Standard, see Section 2 of RFC 5741.
For the current status, errata, and how to send feedback, check http:/www.rfc-editor.org/info/rfc5578.
Correction from me: the original link is http://www.rfc-editor.org/info/rfc5578.
IESG Note 🔥
Real talk, the PPP Extensions Working Group (PPPEXT) has reservations about whether this feature is actually desirable. They think it solves a general problem at the wrong layer, and it might have unpredictable interactions with higher and lower level protocols 🙈
The techniques here are meant for one specific deployment, where a PPP termination is separated from a radio termination by an Ethernet, and there's radio-side flow control for a slower PPP-only link to remote nodes. Implementors are better off avoiding split termination with inter-media protocol translation and just using standard Internet Protocol routing instead ✨
Copyright Notice 🌈
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http:trustee.ietf.org/license-info) in effect on the date of publication. Read those carefully, because they describe your rights and restrictions for this doc 📜
Table of Contents 🗂️
1. Introduction ....................................................3
2. Terminology .....................................................4
3. Overview of Protocol Extensions .................................5
3.1. TLVs .......................................................5
3.1.1. Credits TLV .........................................5
3.1.2. Metrics TLV .........................................6
3.1.3. Sequence Number TLV .................................7
3.1.4. Credit Scale Factor TLV .............................8
3.2. Discovery Stage Extensions .................................8
3.2.1. PPPoE Active Discovery Request (PADR) ...............9
3.2.2. PPPoE Active Discovery Session-Confirmation
(PADS) .............................................11
3.2.3. PPPoE Active Discovery Session-Grant (PADG) ........13
3.2.4. PPPoE Active Discovery Session-Credit
Response (PADC) ....................................15
3.2.5. PPPoE Active Discovery Quality (PADQ) ..............16
3.3. PPP Session Stage Extensions ..............................18
4. Credit Flow Considerations .....................................19
5. PADG and PADC Retransmission ...................................20
6. Other Considerations ...........................................20
7. IANA Considerations ............................................21
8. Security Considerations ........................................21
9. References .....................................................21
9.1. Normative References ......................................21
9.2. Informative References ....................................21
Appendix A. Examples of Session Credit Flows ......................221. Introduction 💖
PPP over Ethernet (PPPoE) [2] is the protocol for setting up and encapsulating sessions between Hosts (Clients) and traffic-access aggregators (Servers). It carries PPP [1] over real or emulated Ethernet. PPPoE works great when both session endpoints have similar bandwidth, forwarding, and buffering capabilities that don't change over time. But things get messy for apps with variable bandwidth and limited buffering, so this doc adds optional PPPoE extensions for credit-based session flow control and session-based link metric quality reports 🦋
These extensions are built for radio systems with point-to-point waveforms. Here's the picture: when the local Client (Radio) notices a remote Radio neighbor, it starts a PPPoE session with its local Server (router). The Radio also sets up a radio link connection with the remote Radio over the point-to-point RF (radio frequency) link, which is out of scope for this doc. The remote Radio is doing the same thing with its own local Server (router). The Radios tie the two PPPoE sessions and the point-to-point radio link protocol (RLP) together, and that creates a full data path 🛣️
Next, a PPP session gets set up through the PPP IP Control Protocol (IPCP), as described in RFC 1661. The router IP address is included in this IPCP exchange. Once the IPCP IP addresses are swapped, each router puts the remote IP address into its local routing table. The radio IP info does NOT go into the routing tables, just so we're clear 🙅♀️
|-----Local Neighbor-----| |-----Remote Neighbor----|
+--------+ +-------+ +-------+ +--------+
| Router |=======| Radio |{~~~~~~~~}| Radio |=======| Router |
| Server | | Client| | Client| | Server |
+--------+ +-------+ +-------+ +--------+
| | | | | |
|-PPPoE-| |----RLP---| |-PPPoE-|
| |
|-----------PPP IPCP (IP Address)---------|
| |
|-------------PPP Data Session-------------|
Figure 1: PPPoE NetworkThe capabilities of the RF links between RLP neighbors keep changing because of mobility, environmental conditions, and shifts in RF waveforms and encoding. To keep up, the Radio may periodically send Link Quality Metrics to the router. The router uses that link metric to update route costs and influence route selection. How that affects the routing protocols is out of scope for this doc 🧚
Fun fact, a PPPoE Client implementation is available at [3]. It's open source under GNU GPLv2 (General Public License) 💜
2. Terminology 🎀
- Access Concentrator: The RFC 2516 term for the Server. This document uses the terms Router or Server instead.
- BCN: Backward Credit Notification. The BCN is the number of remaining credits at the local node that were granted by the peer node. The local node uses these credits to send payload back to the peer node. BCN ranges from 0-65535.
- CDR: The Current Datarate.
- FCN: Forward Credit Notification. The FCN is the credits the local node is granting to the peer node. The peer node uses these granted credits to send payload back to the local node. FCN ranges from 0-65535.
- Gbit/s: gigabits (1,000,000,000) per second.
- Host: The RFC 2516 term for the Server. This document uses the terms Radio or Client.
- kbit/s: kilobits (1,000) per second.
- LCP: PPP Link Control Protocol, RFC 1661.
- Mbit/s: megabits (1,000,000) per second.
- MDR: The Maximum Datarate.
- NCP: PPP Network Control Protocol, RFC 1661.
- RLP: Radio Link Protocol.
- TAG: The RFC 2516 PPPoE synonym for TLV. This document uses TLV.
- Tbit/s: terabits (1,000,000,000,000) per second.
- TLV: Type-Length-Value.
3. Overview of Protocol Extensions 🧁
The extensions are made of optional TLVs plus enhanced and newly defined Discovery packets. The changes apply to both the Discovery Stage and the PPP Session Stage 🌟
3.1. TLVs 🦄
The new TLVs are listed in the table below:
TLV TLV
Value Description
=========================================
0x0106 Credits TLV
0x0107 Metrics TLV
0x0108 Sequence Number TLV
0x0109 Credit Scale Factor TLV3.1.1. Credits TLV 💸
This TLV carries the Forward Credit Notification (FCN) and the Backward Credit Notification (BCN). The Credits TLV is optional in the PADR (PPPoE Active Discovery Request) and PADS (PPPoE Active Discovery Session-Confirmation) packets, but required in the PADG (PPPoE Active Discovery Session Grant) and PADC (PPPoE Active Discovery Session-Credit) Discovery packets (ETHER_TYPE=8863) 🔥
The Credits TLV can also optionally be carried in the PPPoE data payload packet of the PPP Stage (ETHER_TYPE=8864) ✨
The FCN is the number of credits the local node is granting to the peer node. The BCN is the number of credits remaining at the local node that were granted by the peer node 🫶
Here's the Credits TLV 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Credits TLV = 0x0106 | TLV Length = 0x04 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FCN | BCN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+These fields are sent in network byte order. The same byte order is used everywhere else in the document's structures too 💅
3.1.2. Metrics TLV 📡
okay so the Metrics TLV is how you report the link-quality parameters 💅 and it is required with the PADQ (PPPoE Discovery Quality) Discovery packet. no skipping it, bestie 🫶
The Metrics TLV holds these fields:
- Resources 🔋 - a percentage, 0-100, representing the amount of remaining or available resources, such as battery power. If resources cannot be calculated, a value of 100 should be reported.
- Relative Link Quality (RLQ) 📶 - a non-dimensional number, 0-100, representing the relative link quality. A value of 100 represents a link of the highest quality. If the RLQ cannot be calculated, a value of 100 should be reported.
- Receive only 📥 - a bit that indicates whether the link is bi-directional or receive-only. A value of "1" indicates that the link is receive-only.
- Reserved 🫧 - reserved fields are zeroed unless otherwise specified.
- CD 🎀 - two bits that designate the units of the Current Datarate.
CD Scale: 00 == kbit/s (default)
01 == Mbit/s
10 == Gbit/s
11 == Tbit/s- MD 🎀 - two bits that designate the units of the Maximum Datarate.
MD Scale: 00 == kbit/s (default)
01 == Mbit/s
10 == Gbit/s
11 == Tbit/s- Current Datarate ⚡ - the Current Datarate, in un-scaled units per second, achieved on the RLP link. If the Radio makes no distinction between Maximum Datarate and Current Datarate, Current Datarate should equal the Maximum Datarate. When metrics are reported, the Current Datarate must be reported. The Current Datarate must be less than or equal to the Maximum Datarate.
- Latency ⏱️ - the transmission delay that a packet encounters as it is transmitted over the link. This is reported in absolute delay, milliseconds. If latency cannot be calculated, a value of 0 should be reported. The calculation of latency is Radio dependent. For example, the latency may be a running average calculated from the internal queuing.
- Maximum Datarate 🚀 - the maximum theoretical data rate, in un-scaled units per second, that the RLP link is capable of providing. When metrics are reported, the Maximum Datarate must be reported.
The Metrics TLV is shown below 👀
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Metrics TLV = 0x0107 | TLV Length = 0x0A |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | MD| CD|R| RLQ | Resources |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Latency (MS) | Current Datarate |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Datarate |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+3.1.3. Sequence Number TLV 🔢
this TLV carries a unique 16-bit sequence number so you can match a specific request with its response 🧚 the sequence number should start at zero and go up by one for each new request. for retransmitted packets, the same sequence number that was used in the previous packet transmission gets repeated, so it's giving consistency 💖 The PADG and PADC packets require the Sequence Number Tag.
The Sequence Number TLV is shown below ✨
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number TLV = 0x0108 | TLV Length = 0x02 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+3.1.4. Credit Scale Factor TLV 📏
this TLV holds the scale factor value that gets applied to the session credit calculations 🌸 the Credit Scale Factor TLV is optional with the PADR and PADS packets. once the session is established with specified scale factors, those scale factors are locked in for the entire session, no switching mid-call 🔒 the scale factor value represents the units that the local node grants to the remote node, and the remote node is responsible for maintaining the credit accounting relative to the data flow back to the local node.
the Credit Scale Factor TLV can be used to change from the default 64-byte credit unit during the PADR-PADS exchange. the credit scale factor value can range from 1 byte to 65535 bytes. a zero value is ignored and the default 64-byte unit remains set. the scale factor is set per each payload flow: peer-to-local and local-to-peer 🦋
The Credit Scale Factor TLV is shown below 💅
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Credit Scale Factor = 0x0109 | TLV Length = 0x02 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scale Factor Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+3.2. Discovery Stage Extensions 🌈
the PADR (PPPoE Active Discovery Request) and PADS (PPPoE Active Discovery Session-confirmation) packets get extended to include the optional Credits TLV and the Credit Scale Factor TLV 🎀 the PADG (PPPoE Active Discovery Session-Grant) packet, the PADC (PPPoE Active Discovery Session-Credit Response) packet, and the Quality packets are newly defined Discovery Stage packets, so they're brand new 🧚
Discovery
Packet Status
=======================================================
PADR Enhanced Optionally includes the Credits
TLV and the Credit Scale Factor
TLV
PADS Enhanced Optionally includes the Credits
TLV and the Credit Scale Factor
TLV
PADG New Includes the Credits TLV and the
Sequence Number TLV
PADC New Includes the Credits TLV and the
Sequence Number TLV
PADQ New Includes the Metrics TLV3.2.1. PPPoE Active Discovery Request (PADR) 💌
the PADR packet is extended to optionally contain a single Credits TLV, which tells everyone the Client wants credit flow control for this session 🫶 the Credits TLV carries the Forward Credit Notification (FCN) and the Backward Credit Notification (BCN) to be applied to the PPP Session Stage. the FCN provides the initial credits granted to the Server by the Client. the BCN value is set to 0, since the Client hasn't been granted any credits from the Server yet 🙈
the PADR packet is also enhanced to optionally contain a single Credit Scale Factor TLV, which defines the credit scale factor value. if the Credit Scale Factor TLV is omitted, the default 64-byte value is used for the session. when the Client includes the optional Credit Scale Factor TLV in the PADR, that credit scale factor value is applied to all credit grants associated with the Client credits that are granted to the Server 🌟
the Server must echo the Credit Scale Factor TLV in the PADS response to confirm the credit scaling session and to designate the Server credit scaling factor 🔥 this PADS Credit Scaling Factor TLV represents the scale factor value that is applied to all credits granted from the Server to the Client.
once the session is established during the PADR-PADS exchange, the credit scale factor value cannot be changed. no takesies backsies 💀
A Discovery PADR packet with the optional Credits TLV is shown below 🦋
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access_Concentrator_mac_addr |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Access_Concentrator_mac_addr(c)| Host_mac_addr |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Host_mac_addr (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ETHER_TYPE = 0x8863 | v = 1 | t = 1 | CODE = 0x19 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SESSION_ID = 0x1234 | LENGTH = 0x0C |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = 0x0101 | Metrics TLV Length = 0x00 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Credits TLV = 0x0106 | TLV Length = 0x04 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FCN | BCN = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+the credit units are expressed in the default 64-byte units 📦
A Discovery PADR packet with the optional Credits TLV and the optional Credit Scale Factor TLV is shown below 🌸
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access_Concentrator_mac_addr |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Access_Concentrator_mac_addr(c)| Host_mac_addr |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Host_mac_addr (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ETHER_TYPE = 0x8863 | v = 1 | t = 1 | CODE = 0x19 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SESSION_ID = 0x1234 | LENGTH = 0x12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = 0x0101 | TLV Length = 0x00 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Credits TLV = 0x0106 | TLV Length = 0x04 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FCN | BCN = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Credit Scale Factor = 0x0109 | TLV Length = 0x02 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| scale factor value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+the Credits TLV FCN value is expressed in units of the session's credit scale factor value 🧚💖
3.2.2. PPPoE Active Discovery Session-Confirmation (PADS) 💌
Okay so the Server PADS gets a glow-up 💅 It can optionally carry one single Credits TLV, which tells you the Forward Credit Notification (FCN) and the Backward Credit Notification (BCN) of the PPP Session Stage ✨
If the Client's PADR had a Credits TLV, then the Server PADS must indicate support for credit flow control by including a Credits TLV of its own 🫶 The FCN in the PADS Credits TLV is the number of credits the Client starts out with 🎀 The BCN is basically an echo of how many credits the Client had granted to the Server in the originating PADR 🦋
Exchanging Credits TLVs in the PADR and PADS means credit flow control is supported by both the Server and the Client for that PPP Session Stage 👑 It's binding, so it has to be followed for the entire duration of the PPP Session Stage 😭 Also, the session's credit binding has to be set up before any other credit indications get exchanged 🌸
The Server PADS should only include the Credits TLV in response to a Client PADR that had one. If the Server can't do credit flow, it should leave the Credits TLV out of its PADS response 🙈 And if the Client can't keep up with a credit-based session the Server can't support, the Client must terminate it 💀 A Credits TLV that shows up outside an established credit-based session must be ignored, so don't even look at it 🙅
The Server PADS is also allowed to optionally carry a single Credit Scale Factor TLV ✨ That's the thing that defines the credit scale unit value 🍓 If the Client PADR included a Credit Scale Factor TLV, the Server PADS must include one too. If the originating PADR didn't include a Credits TLV, the Credit Scale Factor TLV must be left out, and that means the 64-byte default gets used for the directional flow 🦋 This credit scale factor gets applied to the Server's grants to the Client 👑
Here's what a Discovery PADS packet with the optional Credits TLV looks like 🎀
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access_Concentrator_mac_addr |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Access_Concentrator_mac_addr(c)| Host_mac_addr |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Host_mac_addr (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ETHER_TYPE = 0x8863 | v = 1 | t = 1 | CODE = 0x65 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SESSION_ID = 0x1234 | LENGTH = 0x0C |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = 0x0101 | TLV Length = 0x00 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Credits TLV = 0x0106 | TLV Length = 0x04 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FCN | BCN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The BCN is expressed in the default 64-byte units 📏
Next up is a Discovery PADS packet with the optional Credits TLV and the optional Credit Scale Factor TLV both included 🌈
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access_Concentrator_mac_addr |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Access_Concentrator_mac_addr(c)| Host_mac_addr |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Host_mac_addr (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ETHER_TYPE = 0x8863 | v = 1 | t = 1 | CODE = 0x65 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SESSION_ID = 0x1234 | LENGTH = 0x12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = 0x0101 | TLV Length = 0x00 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Credits TLV = 0x0106 | TLV Length = 0x04 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FCN | BCN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Credit Scale Factor = 0x0109 | TLV Length = 0x02 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| scale factor value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The Credits TLV BCN value is expressed in units of the session scale factor value received in the PADR ✨
3.2.3. PPPoE Active Discovery Session-Grant (PADG) 🧚
The PPPoE Active Discovery Session-Grant (PADG) is a brand-new packet defined in this specification 🌸 The local node (Server or Client) may send a PADG at any time after the PADR/PADS exchange to grant incremental flow control credits to a peer 💜 The CODE field is set to 0x0A, and the SESSION_ID must be set to the unique value generated for this PPPoE Session 🔥
Each flow control credit stands for an amount of PPP payload bytes that can be sent or received 🧮 For example, if the default credit scale factor of 64 bytes is used and 128 bytes of PPP payload data are sent, then 2 credits get consumed. When you calculate credits to consume, you always round up 💖 So in that same example, if 130 bytes of PPP payload data were sent, 3 credits would've been consumed 🙈
When the peer gets a PADG packet, it adds the incremental credits to its working credit count and responds with a PPPoE Active Discovery Session-Credit Response (PADC) packet that shows the accumulation of the credits 🎀 The FCN and BCN values must be scaled by the value established during session establishment in the Credit Scale Factor TLV, or by the default 64-byte value, before processing ✨
The PADG packet must contain a single Credits TLV, indicating the Forward Credit Notification (FCN) and the Backward Credit Notification (BCN) of the PPPoE Session 🫶
The Credits TLV FCN is how many incremental credits the node is granting to the peer. A value from 1 to 0xffff is an incremental credit grant ✨ The peer must multiply the credit units by the credit scale factor and add the result to its accumulated transmit credit count. A value of 0x0000 is a NULL grant, which means there are no additional credits being granted 🌈
The Credits TLV BCN shows the remaining absolute credits the peer has granted to the local node 🦋 Once the local node runs out of BCN, it must stop sending payload packets 😭
Once a credit has been granted, it must be honored 👑 The largest number of incremental credits at any one time is 0xffff 💅
The PADG packet must contain a single Sequence Number TLV 🍓 This TLV carries a unique 16-bit sequence number so each request can be told apart 🧚 The sequence number should start at zero and go up by one for each new PADG. For retransmitted PADGs, the same sequence number from the previous transmission gets repeated 🔁
Here's a Discovery PADG packet with the Sequence Number and Credits TLVs 💖
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination_mac_addr |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination_mac_addr(c) | Source_mac_addr |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source mac_addr (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ETHER_TYPE = 0x8863 | v = 1 | t = 1 | CODE = 0x0A |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SESSION_ID = 0x1234 | LENGTH = 0x0E |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number TLV = 0x0108 | TLV Length = 0x02 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number | Credits TLV = 0x0106 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Length = 0x04 | FCN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BCN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+3.2.4. PPPoE Active Discovery Session-Credit Response (PADC) 🦋
The PPPoE Active Discovery Session-Credit Response (PADC) is another new packet defined in this specification 💅 A Server or Client must send a PADC in response to a PADG 🫶 The CODE field is set to 0x0B, and the SESSION_ID must be set to the unique value generated for this PPPoE session ✨
The PADC packet must contain a single Credits TLV, indicating the Forward Credit Notification (FCN) and the Backward Credit Notification (BCN) of the PPPoE session 🎀
The Credits TLV FCN represents the absolute credits still remaining that have been granted to the peer by the node 💖 The Credits TLV BCN represents the remaining absolute credits that have been granted to the local node from the peer 🌈 The FCN and BCN values must be scaled by the value established during session establishment in the Credit Scale Factor TLV, or by the default 64-byte value, before processing 🧮
The PADC packet must contain a single Sequence Number TLV 🍓 The sequence number must be the one associated with the PADG 🔢
Here's a Discovery PADC packet with the Sequence Number and Credits TLV 👑
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination_mac_addr |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination_mac_addr(c) | Source_mac_addr |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source mac_addr (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ETHER_TYPE = 0x8863 | v = 1 | t = 1 | CODE = 0x0B |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SESSION_ID = 0x1234 | LENGTH = 0x0E |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number TLV = 0x0108 | TLV Length = 0x02 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number | Credits TLV = 0x0106 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Length = 0x04 | FCN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BCN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The FCN and BCN values are expressed in the respective units defined by the Credit Scale Factor TLV, or in the 64-byte default 🌸
3.2.5. PPPoE Active Discovery Quality (PADQ) 📡✨
okay bestie, the PPPoE Active Discovery Quality (PADQ) is a brand new packet that this spec introduces 🦋 A Server or Client MAY send an optional PADQ at any time, either to ask for link-quality metrics or to report them 💅
When PPP [1] streams run over wireless links through radio modems, the quality of the RF link directly affects the throughput 📶 That's where PADQ comes in: the radio modem can use it to report RF link metrics. The CODE field is set to 0x0C, and the SESSION_ID MUST be set to the unique value generated for this PPPoE session 🔐
You can also use PADQ to query link metrics, which you do by setting the PADQ Metrics TLV Length to zero 🔍
A PADQ MUST carry a single Metrics TLV 🎀 When you process the data rates, the values MUST be converted using the indicated data rate units 🌸 This document enhances the Metrics TLV, as described below ✨
Here's what a Discovery PADQ packet with the required Metrics TLV looks like 👀
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access_Concentrator_mac_addr |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Access_Concentrator_mac_addr(c)| Host_mac_addr |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Host_mac_addr (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ETHER_TYPE = 0x8863 | v = 1 | t = 1 | CODE = 0x0C |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SESSION_ID = 0x1234 | LENGTH = 0x12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = 0x0101 | TLV Length = 0x00 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Metrics TLV = 0x0107 | TLV Length = 0x0A |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | MD| CD|R| RLQ | Resources |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Latency (MS) | Current Datarate |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Datarate |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The Maximum Datarate and the Current Datarate are expressed in units set by the MD and CD bits, respectively. 🧚
And here's a Discovery PADQ packet with a Metrics TLV Length=0, used to query 🌈
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access_Concentrator_mac_addr |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Access_Concentrator_mac_addr(c)| Host_mac_addr |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Host_mac_addr (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ETHER_TYPE = 0x8863 | v = 1 | t = 1 | CODE = 0x0C |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SESSION_ID = 0x1234 | LENGTH = 0x08 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = 0x0101 | TLV Length = 0x00 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Metrics TLV = 0x0107 | TLV Length = 0x00 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+3.3. PPP Session Stage Extensions 🎀
The PPP Session Stage Extensions define the optional use of the Credits TLV 💖 Using the Credits TLV in the PPP Session Stage is called an in-band credit grant 🫶
The first field after the PPP Session Stage LENGTH MUST be checked 👀 If its value equals the PPP Protocol identifier (0xc021), then normal packet (payload) processing happens 🙌 If the field after the PPP Session Stage LENGTH is not the PPP Protocol identifier (0xc021), then it's a TLV. In that case, the TLV length gets subtracted from the overall payload length 🧮
Here's a PPP LCP packet with an optional Credits TLV ✨
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access_Concentrator_mac_addr |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Access_Concentrator_mac_addr(c)| Host_mac_addr |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Host_mac_addr (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ETHER_TYPE = 0x8864 | v = 1 | t = 1 | CODE = 0x00 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SESSION_ID = 0x1234 | LENGTH = (payload) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Credits TLV = 0x0106 | TLV Length = 0x04 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FCN | BCN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PPP PROTOCOL = 0xc021 | PPP payload ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+4. Credit Flow Considerations 💸
For a given session, credit grants exchanged in the Discovery Stage (PADG-PADC) are called out-of-band 🫧 Credit grants exchanged in the PPP Session Stage are called in-band 🌸 Credit accounting only applies to packets sent in the PPP Session Stage 🧾
Out-of-band credit management happens through a periodic exchange of the PPPoE Active Discovery Session-Grant (PADG) and PPPoE Active Discovery Credit Response (PADC) packets 🔁
In-band credit management lets credits get granted little by little with each PPP Session Stage packet 🍓 These in-band incremental credit grants aren't explicitly acknowledged, but they show up in the in-band credit flow from the peer node 👀 This is the most efficient way to grant credits when traffic rates are high 🔥
Once they're agreed upon during the Discovery Stage, credit grants are REQUIRED to transmit packets in the PPP Session Stage 🫶 A node MUST grant credits to its peer before the peer can transmit packets to the granting node 🚦
Credits are granted incrementally in the forward direction. Locally, a node keeps track of the credits it has granted to a peer, plus the credits a peer has granted to it 🧠
Grants received from a peer get added to a local running credit counter 💜 The accumulated credits go down with each packet the node transmits to the peer. When the running counter reaches zero, the node MUST stop transmitting packets to the peer 🛑
To manage the credits a node has granted, the node keeps a running counter too 🧮 Every PPP Session Stage packet received from the peer decrements that counter. When it reaches zero, no more packets are expected 🙈 The node incrementally grants more credits to the peer to keep packets flowing 🦋 Packets that show up after the granted credits are used up get discarded 🗑️
5. PADG and PADC Retransmission 🔄
If a node doesn't receive a PADC packet in response to a PADG within a specified amount of time, it SHOULD transmit a new PADG packet with zero credits. It uses the same sequence number and doubles the waiting period 🫠 A PADC response with the matching sequence number tells the node whether the previously granted credits were accumulated 🔍 If they weren't, a PADG with credits and an incremented sequence number SHOULD be transmitted 💅 This process SHOULD be repeated until the granted credits are properly acknowledged, or as many times as desired ✨
If a node doesn't receive a PADQ metric packet in response to a query within a specified amount of time, it SHOULD resend the PADQ query packet and double the waiting period 📡 This can be repeated as many times as desired 🌈
6. Other Considerations 🧚
A node MAY autonomously generate PADQ metric packets 🦋 The rate of autonomously generated PADQ metric packets may need to be throttled so it doesn't overrun the peer 🚦
Sending and receiving PPPoE Discovery packets doesn't depend on credit counts 🫶 For example, a node MUST always be able to receive a PADG and send a PADC 💖
During normal operation, nodes may disagree about the number of credits 🤷♀️ These operational mismatches happen because of packets still in transit on the wire. Much bigger mismatches can happen if there are transmission errors 😭 To fix the bigger errors, the receiving node can use the BCN fields of the PADG and PADC packets, plus in-band credit grants from a peer, to reset the credit values of its peer 🔧
7. IANA Considerations 🏳️🌈
IANA has assigned the following PPPoE TLV Values, and this RFC is the reference for them ✨
TLV Value TLV Name Description Reference
----------- ------------------- ----------------- ---------
262 0x0106 Credits See the reference [RFC5578]
263 0x0107 Metrics See the reference [RFC5578]
264 0x0108 Sequence Number See the reference [RFC5578]
265 0x0109 Credit Scale Factor See the reference [RFC5578]IANA has also assigned the following PPPoE Code fields, and this RFC is the reference for them 💜
Code PPPoE Packet Name Description Reference
-------- ---------------------- ----------------- ---------
10 0x0a PADG, Session-Grant See the reference [RFC5578]
11 0x0b PADC, Session-Credit See the reference [RFC5578]
Response
12 0x0c PADQ, Quality See the reference [RFC5578]8. Security Considerations 🚨
This memo defines a mechanism for adding flow control to existing PPP over Ethernet (PPPoE) sessions. These extensions come after the existing PPPoE security mechanisms described in RFC 2516 [2]. It is REQUIRED that the Service TLV and Session ID always be validated prior to processing credits. Skipping this check would be a total disaster 💀
9. References 📚
9.1. Normative References
[1] Simpson, W., Ed., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[2] Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D., and R. Wheeler, "A Method for Transmitting PPP Over Ethernet (PPPoE)", RFC 2516, February 1999.
9.2. Informative References
[3] An open source (GPLv2) PPPoE Client implementation of RFC 5578, PPP Over Ethernet (PPPoE) Extensions for Credit Flow and Link Metrics, http://rfc4938.sourceforge.net/.
Appendix A. Examples of Session Credit Flows 🧚
okay bestie, this is the fun part 🦋 the examples! first up is the flow with the default 64-byte credit unit. read it top to bottom, and each arrow is one message going between the Server and the Client 💖
Server Client
====================================================================
<------------PADI-------------- Initiate
------------PADO--------------> Offer
<------------PADR-------------- Credits TLV:
FCN represents the initial
Client credit grant to the
Server in 64-byte units.
BCN is set to 0.
------------PADS--------------> Credits TLV:
FCN represents the initial
Server credit grant to the
Client in 64-byte units.
BCN represents an echo of
initial Client credits.
<==============================> Data w/ optional in-band
Credits TLV
<------------PADG-------------- Credits TLV: (out-of-band)
FCN represents an incremental
Client credit grant to the
Server, in 64-byte units.
BCN represents the remaining
Server credits that were granted
to the Client, in 64-byte units.
------------PADC--------------> Credits TLV: (out-of-band)
FCN represents an incremental
Server credit grant to the
Client, in 64-byte units.
BCN represents the remaining
Client credits that were granted
to the Server, in 64-byte units.
<==============================> Data w/ optional in-band Credits
TLV
<------------PADT--------------> Terminatenext up 👑 same vibe, but this time the Server and the Client each get their own credit scale factor units. the Credit Scale Factor TLV decides the units, so the story is the same, just with a different ruler 📏✨
Server Client
====================================================================
<------------PADI-------------- Initiate
------------PADO--------------> Offer
<------------PADR-------------- Credits TLV:
FCN represents the initial
Client credit grant to the
Server, in Credit Scale Factor
TLV units.
BCN is set to 0.
------------PADS--------------> Credits TLV:
FCN represents the initial
Server credit grant to the
Client, in Credit Scale Factor
TLV units.
BCN represents an echo of the
initial Client credits, in
Credit Scale Factor TLV units.
<==============================> Data w/ optional in-band Credits
TLV
<------------PADG-------------- Credits TLV: (out-of-band)
FCN represents an incremental
Client credit grant to the Server,
in Credit Scale Factor TLV units.
BCN represents the remaining
Server credits that were granted
to the Client, in Credit Scale
Factor TLV units.
------------PADC--------------> Credits TLV: (out-of-band)
FCN represents an incremental
Server credit grant to the Client,
in Credit Scale Factor TLV units.
BCN represents the remaining
Client credits that were granted
to the Server, in Credit Scale
Factor TLV units.
<==============================> Data w/ optional inband Credits
TLV
<------------PADT--------------> Terminatethat's the whole flow zoo, bestie 🌈 the PADG and PADC messages are the little credit top-ups that keep the conversation going, and the data just zooms along in between 🚀💅
Authors' Addresses 💌
these are the lovely humans who wrote it, with their Cisco and Harris and L-3 contact details 🫶
Bo Berry, Editor
Cisco
170 West Tasman Drive
San Jose, CA 95134
EMail: bberry@cisco.com
Stan Ratliff
Cisco
170 West Tasman Drive
San Jose, CA 95134
EMail: sratliff@cisco.com
Ed Paradise
Cisco
170 West Tasman Drive
San Jose, CA 95134
EMail: pdice@cisco.com
Tim Kaiser
Harris Corporation
Government Communications System Division
Mail Stop 25-11F
P.O. Box 37
Melbourne, FL 32902-0037
EMail: timothy.kaiser@harris.com
Michael D Adams
640 N 2200 W MS F1J12
Salt Lake City, Utah 84116
EMail: Michael.D.Adams@L-3com.comand that's a wrap on the whole RFC, bestie!! 🎀💜🌸
📦 where this page comes from
- ietf: rfc5578 2010-02
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms