diff options
Diffstat (limited to 'doc/rfc/rfc4938.txt')
| -rw-r--r-- | doc/rfc/rfc4938.txt | 955 |
1 files changed, 955 insertions, 0 deletions
diff --git a/doc/rfc/rfc4938.txt b/doc/rfc/rfc4938.txt new file mode 100644 index 0000000..3e852d1 --- /dev/null +++ b/doc/rfc/rfc4938.txt @@ -0,0 +1,955 @@ + + + + + + +Network Working Group B. Berry +Request for Comments: 4938 H. Holgate +Category: Informational Cisco Systems,Inc. + June 2007 + + + PPP Over Ethernet (PPPoE) Extensions + for Credit Flow and Link Metrics + +Status of This Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The IETF Trust (2007). + +IESG Note + + The PPP Extensions Working Group (PPPEXT) has reservations about the + desirability of the feature described in this document. In + particular, it solves a general problem at an inappropriate layer and + it may have unpredictable interactions with higher and lower level + protocols. The techniques described in this document are intended + for use with a particular deployment technique that uses a PPP + termination separated from a radio termination by an Ethernet, and + that has radio-side flow control for a slower PPP-only link to remote + nodes. Implementors are better advised to avoid split termination + with inter-media protocol translation, and use standard Internet + Protocol routing instead. + +Abstract + + This document extends the Point-to-Point over Ethernet (PPPoE) + Protocol with a credit-based flow control mechanism and Link Quality + Metric report. This optional extension should improve the + performance of PPPoE over media with variable bandwidth and limited + buffering, such as mobile radio links. + + + + + + + + + + + +Berry & Holgate Informational [Page 1] + +RFC 4938 PPPoE with Credit Flow and Metrics June 2007 + + +Table of Contents + + 1. Introduction ....................................................2 + 2. Payload .........................................................3 + 3. Overview of Protocol Extensions .................................3 + 4. Discovery Stage .................................................3 + 4.1. PPPoE Active Discovery Request (PADR) ......................4 + 4.2. PPPoE Active Discovery Session-confirmation (PADS) .........4 + 4.3. PPPoE Active Discovery Session-Grant (PADG) ................5 + 4.4. PPPoE Active Discovery Session-Credit Response (PADC) ......5 + 4.5. PPPoE Active Discovery Quality (PADQ) ......................6 + 5. PPP Session Stage ...............................................7 + 6. Credit Flow Considerations ......................................7 + 7. PADG and PADC Retransmission ....................................8 + 8. Other Considerations ............................................9 + 9. IANA Considerations .............................................9 + 10. Security Considerations ........................................9 + Appendix A: Tag Values.............................................10 + Appendix B: Example Message Formats................................11 + Acknowledgements...................................................15 + Normative References...............................................15 + +1. Introduction + + PPP over Ethernet (PPPoE) [2] is a protocol for establishing and + encapsulating sessions between hosts and traffic aggregators (Access + Concentrators) for PPP [1] transport over real or emulated Ethernet. + PPPoE works well when both session endpoints have similar bandwidth, + forwarding, and buffering capabilities that do not vary over time. + However, it is insufficient for applications with variable bandwidth + and limited buffering (for example, mobile radio links). This + document addresses this problem by suggesting an extension to PPPoE + to support credit-based session flow control and session-based link + metric exchanges. + + The diagram below illustrates the problem that this extension is + intended to solve, for the case of a radio link. Here PPPoE sessions + are used between access concentrators (routers) and radio + transmission systems that are shown as radio neighbors. Each radio + transmission system establishes point-to-point Radio Link Protocol + (RLP) sessions with its neighbors and establishes a corresponding + PPPoE session for each neighbor with the transmission system's + associated access concentrator (router). The radio logically + associates the PPPoE session with the corresponding RLP session. + + + + + + + +Berry & Holgate Informational [Page 2] + +RFC 4938 PPPoE with Credit Flow and Metrics June 2007 + + + +--------+ +-------+ +-------+ +--------+ + | Access | | Host | | Host | | Access | + | Conc. |=======| Radio |~~~~~~~| Radio |=======| Conc. | + +--------+ +-------+ +-------+ +--------+ + | | | | | | + |-PPPoE-| |--RLP--| |-PPPoE-| + | | + |-------------PPP Session---------------| + + Figure 1. PPPoE Network + + The capabilities of the RF links between RLP neighbors may vary over + time due to mobility and environmental conditions. In many + instances, the Host Radio has limited buffering capability to handle + capacity changes in the RLP sessions. To limit buffering in the Host + Radio, the PPPoE credit flow control mechanism provides dynamic + buffering feedback to the access concentrator. + + In the diagram above, from the access concentrator's perspective, + each PPPoE session between it and the Host Radio represent a + connection to a remote routable peer. For efficient routing, the + local Host Radio uses the link metric mechanism to dynamically update + the access concentrator route cost of the associated link. + + While the example shows an RF-based application, the extensions are + applicable to other media. + +2. Payload + + The Ethernet payload version field retains its value of 0x01. The + extensions for credit flow control and link quality metrics are + optional and backward compatible. + +3. Overview of Protocol Extensions + + PPPoE has two distinct stages. There is a Discovery Stage and a PPP + Session Stage. During the Discovery Stage, the Host can optionally + request a flow controlled PPP Session Stage. Once the Access + Concentrator acknowledges the Host flow control request, all PPP + Session Stage traffic must be flow controlled. + +4. Discovery Stage + + The packet exchange of the Discovery Stage is unchanged by this + specification. The specifications of the Session Request (PADR) and + the Session Confirmation (PADS) packets are extended to include the + optional Credit Tag Type-Length-Value (TLV). + + + + +Berry & Holgate Informational [Page 3] + +RFC 4938 PPPoE with Credit Flow and Metrics June 2007 + + + In addition, the optional Credit Grant (PADG) packet, the Credit + Response (PADC) packet, and the Link Quality Metric (PADQ) packets + are introduced. + +4.1. PPPoE Active Discovery Request (PADR) + + The PADR packet is extended to optionally contain a single Credit Tag + TLV, indicating that the Host requests credit flow control for this + session. The Credit Tag contains 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 Access Concentrator by the Host. The BCN value is set to 0. + + An example packet is shown in Appendix B. + +4.2. PPPoE Active Discovery Session-confirmation (PADS) + + The PADS packet is extended to optionally contain a single Credit Tag + TLV, indicating the Forward Credit Notification (FCN) and the + Backward Credit Notification (BCN) of the PPP Session Stage. + + If the PADR contained a Credit Tag, then the Access Concentrator PADS + packet indicates support for credit flow control by including a + Credit Tag. The PADS Credit Tag FCN represents the number of credits + being initially granted to the Host. The Credit Tag BCN is an echo + of the number of credits that the Host had granted to the Access + Concentrator in the previous PADR packet. + + Exchange of the Credit Tag TLV in the PADR and PADS indicates that + credit flow control is supported by both the Access Concentrator and + the Host for the designated PPP Session Stage. This is binding and + must be followed for the entire duration of the PPP Session Stage. A + session's credit binding must be established prior to any other + credit indications can be exchanged. + + The Access Concentrator PADS should only carry the Credit Tag in + response to a Host PADR with Credits. If the Access Concentrator + does not support credit flow, it should not include the Credit Tag in + its PADS response. The Host must terminate a credit-based session + that cannot be supported by the Access Concentrator. Credit Tags + transmitted outside an established credit based session must be + ignored. + + An example packet is shown in Appendix B. + + + + + + + +Berry & Holgate Informational [Page 4] + +RFC 4938 PPPoE with Credit Flow and Metrics June 2007 + + +4.3. PPPoE Active Discovery Session-Grant (PADG) + + The PPPoE Active Discovery Session-Grant (PADG) is a new packet + defined in this specification. An Access Concentrator or Host MAY + send a PADG at any time after the PADR/PADS exchange to grant + incremental flow control credits. The CODE field is set to 0x0A and + the SESSION_ID must be set to the unique value generated for this + PPPoE Session. + + The peer may then transmit data until the credits are exhausted. + + When the peer receives a PADG packet, it adds the incremental credits + to its working credit count and responds with a PPPoE Active + Discovery Session-Credit (PADC) packet indicating the accumulated + credits. + + The PADG packet must contain a single Credit Tag TLV, indicating the + Forward Credit Notification (FCN) and the Backward Credit + Notification (BCN) of the PPP Session. + + The Credit Tag FCN indicates the number of incremental credits being + granted to the peer by the node. A value between 1 and 0xffff + represents an incremental credit grant. The peer must add these + credits to its accumulated transmit credit count. A value of 0x0000 + represents a NULL grant, meaning that there are no additional credits + being granted. + + The Credit Tag BCN indicates the remaining absolute credits that have + been granted by the peer to the node. + + Once a credit has been granted, it must be honored. The largest + number of outstanding credits at any time is 0xffff. + + + The PADG packet must contain a single Sequence Number Tag TLV. This + tag is used to carry a unique 16-bit sequence number to uniquely + identify each request. The sequence number should be initialized to + zero and incremented by one for each new PADG. For retransmitted + PADGs, the same sequence number that was used in the previous packet + transmission is repeated. + + An example packet is shown in Appendix B. + +4.4. PPPoE Active Discovery Session-Credit Response (PADC) + + The PPPoE Active Discovery Session-Credit Response (PADC) is a new + packet defined in this specification. An Access Concentrator or Host + must send a PADC in response to a PADG. The CODE field is set to + + + +Berry & Holgate Informational [Page 5] + +RFC 4938 PPPoE with Credit Flow and Metrics June 2007 + + + 0x0B, and the SESSION_ID must be set to the unique value generated + for this PPPoE session. + + The PADC packet must contain a single Credit Tag TLV, indicating the + Forward Credit Notification (FCN) and the Backward Credit + Notification (BCN) of the PPPoE session, and any number of other Tag + types. + + The Credit Tag FCN represents the absolute credits remaining that + have been granted to the peer by the node. The Credit Tag BCN + represents the remaining absolute credits that have been granted to + the node from the peer. + + The PADC packet must contain a single Sequence Number Tag. The + sequence number must be the sequence number associated with the PADG. + + An example packet is shown in Appendix B. + +4.5. PPPoE Active Discovery Quality (PADQ) + + The PPPoE Active Discovery Quality (PADQ) is a new packet defined in + this specification. An Access Concentrator or Host may send an + optional PADQ at any time to query or report link quality metrics. + + When transmitting PPP [1] streams over wireless links through radio + modems, the quality of the RF link directly affects the throughput. + The PPPoE Active Discovery Quality (PADQ) packet can be used by the + radio modem 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. + + The PADQ must carry a single Metric Tag TYPE, which contains the + following fields: + + 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. + + Maximum data rate - the maximum theoretical data rate, in + kilobits per second (kbps), that the Host link is capable of + providing. When metrics are reported, the maximum data rate must + be reported. + + Current data rate - the current data rate, in kilobits per second + (kbps), achieved on the Host link. If there is no distinction + between maximum data rate and current data rate, current data + rate should equal to the maximum data rate. + + + + +Berry & Holgate Informational [Page 6] + +RFC 4938 PPPoE with Credit Flow and Metrics June 2007 + + + Latency - the transmission delay that a packet encounters as it + is transmitted over the Host link. This is reported in absolute + delay, milliseconds. If latency cannot be calculated, a value of + 0 should be reported. + + 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. + + The PPPoE Active Discovery Quality (PADQ) packet can be used to query + link metrics by setting the PADQ Metric Tag Length to zero. + + An example packet is shown in Appendix B. + +5. PPP Session Stage + + This specification defines the optional use of TLV Tags in the PPP + Session Stage. The first field following the PPP Session Stage + LENGTH must be checked. If the value is equal to the PPP Protocol + identifier (0xc021), then normal packet (payload) processing occurs. + When the field following the PPP Session Stage LENGTH is not the PPP + Protocol identifier (0xc021), a TLV is assumed. In this case, the + Tag length is subtracted from the overall payload length. + + The Credit Tag is the only optional TLV permitted in the PPP Session + Stage. The Credit Tag TLV is used to support in-band flow control. + + A PPP Session Stage packet with Credits is shown in Appendix B. + +6. Credit Flow Considerations + + For a given session, credit grants exchanged in the Discovery Stage, + PADG-PADC, are referred to as out-of-band. Credit grants exchanged + in the PPP Session Stage are referred to as in-band. Credit + processing is only applied to the packets transmitted in the PPP + Session Stage. + + Out-of-band credit management is handled by periodic exchange of the + PPPoE Active Discovery Grant (PADG) and PPPoE Active Discovery Credit + (PADC) packets. + + + + + +Berry & Holgate Informational [Page 7] + +RFC 4938 PPPoE with Credit Flow and Metrics June 2007 + + + In-band credit management allows credits to be incrementally granted + with each PPP Session Stage packet. These in-band incremental credit + grants are not explicitly unacknowledged. However, they are + reflected in the in-band credit flow from the peer node. This offers + the greatest credit granting efficiency when traffic rates are high. + + Once 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 manages the credits that it has granted to a peer, as well as + the credits that a peer has granted to it. + + Grants received from a peer are added to a local running credit + counter. The accumulated credits are decremented with each packet + the node transmits to the peer. When the running counter reaches + zero, the node stops transmitting packets to the peer. The values of + the PADC are not simply an echo of the PADG. They represent the + current internal FCN/BCN values of that node. + + To manage the credits that a node has granted, the node maintains a + running counter. With each PPP Session Stage packet received from + the peer, the running counter is decremented. When the running + counter reaches zero, no additional packets are expected. The node + incrementally grants more credits to the peer to maintain packet + flow. Packets received when granted credits that have been exhausted + are discarded. + + The largest possible credit limit is 0x0ffff. If an incremental + credit grant causes the accumulated count to exceed this value, the + max value is used. + + One unit of credit represents 64-bytes, so a grant of 4 credits + translates to 256 bytes. + +7. PADG and PADC Retransmission + + When a node does not 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, using the same sequence number and double + the waiting period. A PADC response with the associated sequence + number will indicate whether or not the previously granted credits + were accumulated. If they were not, a PADG with credits, with an + incremented sequence number, should be transmitted. This process + should be repeated until granted credits are properly acknowledged or + as many times as desired. + + + +Berry & Holgate Informational [Page 8] + +RFC 4938 PPPoE with Credit Flow and Metrics June 2007 + + + When a node does not receive a PADQ metric packet 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. + +8. Other Considerations + + A node may autonomously generate PADQ metric packets. The rate of + autonomously generated PADQ metric packets may need to be throttled + so as not to overrun the peer. + + The sending and receiving of PPPoE control packets are independent of + 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. Operational credit mismatches would occur due to packets in + transit on the wire. Much larger credit mismatches can occur if + there are transmission errors. To correct these larger errors, the + BCN fields of the PADG and PADC packets and in-band credit grants + from a peer should be used by the receiving node to set the credit + values of its peer. + +9. IANA Considerations + + IANA has assigned the following PPPoE TAG Values as noted in [3]: + + TAG Value TAG Name Tag Description Reference + ----------- ------------------- --------------------- --------- + 262 0x0106 Credits See the reference [RFC4938] + 263 0x0107 Metrics See the reference [RFC4938] + 264 0x0108 Sequence Number See the reference [RFC4938] + + IANA has assigned the following PPPoE Code fields as noted in [3]: + + Code PPPoE Packet Name Description Reference + -------- ----------------------------- ----------------- --------- + 10 0x0a PADG, Session-Grant See the reference [RFC4938] + 11 0x0b PADC, Session-Credit Response See the reference [RFC4938] + 12 0x0c PADQ, Quality See the reference [RFC4938] + +10. Security Considerations + + This memo defines a mechanism for adding flow control to the existing + PPP Over Ethernet (PPPoE) sessions. These extensions are subsequent + to the existing PPPoE security mechanisms as described in RFC 2516 + [2]. It is required that the Service Tag and Session ID always be + validated prior to processing credits. + + + + +Berry & Holgate Informational [Page 9] + +RFC 4938 PPPoE with Credit Flow and Metrics June 2007 + + +Appendix A: Tag Values + + Feature Tag_Types and Tag_Values + + 0x0106 Credits + + This tag contains the Forward Credit Notification (FCN) and the + Backward Credit Notification (BCN). The Credit Tag TLV is OPTIONAL + with the PADR, PADS, and the PPPoE data payload packet + (ETHER_TYPE=8864). + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Tag Type = 0x0106 | Tag Length=0x04 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | FCN | BCN | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + 0x0107 Metrics + + This tag is used to report the link quality and performance. The + Metrics Tag TLV contains the Receive Only indicator, Resource status, + Latency, Relative Link Quality (RLQ), Current data rate, and Maximum + data rate. The Metrics TLV is required by the PADQ packet. + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Tag Type = 0x0107 | Tag Length=0x0A | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Reserved |R| RLQ | Resource | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Latency (MS) | Current Datarate (kbps) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Maximum Datarate (kbps) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + 0x0108 Sequence Number + + This tag is used to carry a unique 16-bit sequence number in order to + identify a specific request and the associated response. The + sequence number should be initialized to zero and incremented by one + for each new request. For retransmitted packets, the same sequence + number that was used in the previous packet transmission is repeated. + The PADG and PADC packets require the Sequence Number Tag. + + + + + +Berry & Holgate Informational [Page 10] + +RFC 4938 PPPoE with Credit Flow and Metrics June 2007 + + + For example, the sequence number sent in the PADG request is echoed + in the PADC response. This ties a specific PADC response to a + specific PADG request. + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Tag Type = 0x0108 | Tag Length=0x02 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Sequence Number | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +Appendix B: Example Message Formats + + A PADR packet with OPTIONAL Credit Tag Type 0x0106: + + 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 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Tag Type = 0x0101 | Tag Length=0x00 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Tag Type = 0x0106 | Tag Length=0x04 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | FCN | BCN | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + + + + + + + + + + + + + + +Berry & Holgate Informational [Page 11] + +RFC 4938 PPPoE with Credit Flow and Metrics June 2007 + + + A PADS packet with OPTIONAL Credit Tag Type 0x0106: + + 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 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Tag Type = 0x0101 | Tag Length=0x00 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Tag Type = 0x0106 | Tag Length=0x04 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | FCN | BCN | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + A PADG packet with Credit Tag Type 0x0106: + + 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 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Tag Type = 0x0108 | Tag Length=0x02 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Sequence Number | Tag Type = 0x0106 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Tag Length=0x04 | FCN | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | BCN | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + + + +Berry & Holgate Informational [Page 12] + +RFC 4938 PPPoE with Credit Flow and Metrics June 2007 + + + A PADC packet with Credit Tag Type 0x0106: + + 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 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Tag Type = 0x0108 | Tag Length=0x02 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Sequence Number | Tag Type = 0x0106 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Tag Length=0x04 | FCN | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | BCN | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + A PADQ packet to query for the link metrics: This is indicated by + the Metric Tag Length=0. + + 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 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Tag Type = 0x0101 | Tag Length=0x00 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Tag Type = 0x0107 | Tag Length=0x00 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + + + + +Berry & Holgate Informational [Page 13] + +RFC 4938 PPPoE with Credit Flow and Metrics June 2007 + + + A PADQ packet with Metric Tag Type 0x0107: + + 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 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Tag Type = 0x0101 | Tag Length=0x00 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Tag Type = 0x0107 | Tag Length=0x0A | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Reserved |R| RLQ | Resource | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Latency (MS) | Current Datarate (kbps) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Maximum Datarate (kbps) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + + + + + + + + + + + + + + + + + + + + + + + + +Berry & Holgate Informational [Page 14] + +RFC 4938 PPPoE with Credit Flow and Metrics June 2007 + + + A PPP LCP packet with optional Credit Tag Type 0x0106: + + While the PPP protocol value is shown (0xc021), the PPP payload is + left to the reader. This is a packet from the Host to the Access + Concentrator. + + 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) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Tag Type = 0x0106 | Tag Length=0x04 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | FCN | BCN | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | PPP PROTOCOL = 0xc021 | PPP payload ~ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +Acknowledgements + + The authors would like to acknowledge the influence and contributions + from Billy Moon, Fred Baker, Stan Ratliff, and Ed Paradise. + +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. + + [3] Arberg, P. and V. Mammoliti, "IANA Considerations for PPP over + Ethernet (PPPoE)", RFC 4937, June 2007. + + + + + + + + + +Berry & Holgate Informational [Page 15] + +RFC 4938 PPPoE with Credit Flow and Metrics June 2007 + + +Authors' Addresses + + Bo Berry + Cisco + 170 West Tasman Drive + San Jose, CA 95134 + USA + EMail: bberry@cisco.com + + + Howard Holgate + Cisco + 170 West Tasman Drive + San Jose, CA 95134 + USA + EMail: hholgate@cisco.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Berry & Holgate Informational [Page 16] + +RFC 4938 PPPoE with Credit Flow and Metrics June 2007 + + +Full Copyright Statement + + Copyright (C) The IETF Trust (2007). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78 and at www.rfc-editor.org/copyright.html, and + except as set forth therein, the authors retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND + THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS + OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF + THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + +Berry & Holgate Informational [Page 17] + |