diff options
Diffstat (limited to 'doc/rfc/rfc5578.txt')
| -rw-r--r-- | doc/rfc/rfc5578.txt | 1347 |
1 files changed, 1347 insertions, 0 deletions
diff --git a/doc/rfc/rfc5578.txt b/doc/rfc/rfc5578.txt new file mode 100644 index 0000000..eb7b873 --- /dev/null +++ b/doc/rfc/rfc5578.txt @@ -0,0 +1,1347 @@ + + + + + + +Independent Submission B. Berry, Ed. +Request for Comments: 5578 S. Ratliff +Obsoletes: 4938 E. Paradise +Category: Informational Cisco +ISSN: 2070-1721 T. Kaiser + Harris Corporation + M. Adams + L3 Communications + February 2010 + + + PPP over Ethernet (PPPoE) Extensions for Credit Flow and Link Metrics + +Abstract + + This document extends the Point-to-Point Protocol over Ethernet + (PPPoE) with an optional credit-based flow control mechanism and an + optional Link Quality Metric report. These optional extensions + improve the performance of PPPoE over media with variable bandwidth + and limited buffering, such as mobile point-to-point radio links. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for informational purposes. + + This is a contribution to the RFC Series, independently of any other + RFC stream. The RFC Editor has chosen to publish this document at + its discretion and makes no statement about its value for + implementation or deployment. Documents approved for publication by + the RFC Editor are not a candidate for any level of Internet + Standard; see Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc5578. + +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 + + + + +Berry, et al. Informational [Page 1] + +RFC 5578 PPPoE with Credit Flow and Metrics February 2010 + + + nodes. Implementors are better advised to avoid split termination + with inter-media protocol translation, and use 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 of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. + +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 ......................22 + + + + + + + +Berry, et al. Informational [Page 2] + +RFC 5578 PPPoE with Credit Flow and Metrics February 2010 + + +1. Introduction + + PPP over Ethernet (PPPoE) [2] is a protocol for establishing and + encapsulating sessions between Hosts (Clients) and traffic-access + aggregators (Servers) 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, improvements can be made for applications with + variable bandwidth and limited buffering. This document addresses + these improvements with optional extensions to PPPoE that support + credit-based session flow control and session-based link metric + quality reports. + + These extensions are designed to support radio systems that exhibit + point-to-point waveforms. The diagram below is used to illustrate + the improvement that these extensions address. When the local Client + (Radio) detects the presence of a remote Radio neighbor, it initiates + a PPPoE session with its local Server (router). The Radio also + establishes a radio link connection with the remote Radio over the + point-to-point RF (radio frequency) link (which is beyond the scope + of this document). The remote Radio is also establishing a PPPoE + session with its local Server (router). The Radios associate the two + PPPoE sessions and the point-to-point radio link protocol (RLP), + creating a complete data path. Now a PPP session is established via + the PPP IP Control Protocol (IPCP) as described in RFC 1661. + Included in this IPCP exchange is the router IP address. With the + exchange of the IPCP IP addresses, each router inserts the remote IP + address into its local routing tables. Note that the radio IP + information is not inserted into the routing tables. + + |-----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 Network + + + + + + +Berry, et al. Informational [Page 3] + +RFC 5578 PPPoE with Credit Flow and Metrics February 2010 + + + The capabilities of the RF links between RLP neighbors will vary over + time due to mobility and environmental conditions as well as changes + in the RF waveforms and encoding. To reflect these dynamic changes, + the Radio may periodically generate Link Quality Metrics to the + router. The router uses the link metric to update route costs and + influence route selection. The influence upon the routing protocols + is beyond the scope of this document. + + A PPPoE Client implementation can be found at [3]. It is open source + (GNU GPLv2 -- General Public License). + +2. Terminology + + Access Concentrator + The RFC 2516 term used to describe the Server. This + document uses the terms Router or Server instead. + + BCN Backward Credit Notification. The BCN represents the number + of remaining credits at the local node that were granted by + peer node. The local node uses these credits to transmit + payload back to the peer node. BCN ranges from 0-65535. + + CDR The Current Datarate. + + FCN Forward Credit Notification. The FCN represents the credits + that the local node is granting to the peer node. The peer + node uses these granted credits to transmit 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 used to describe 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. + + + + +Berry, et al. Informational [Page 4] + +RFC 5578 PPPoE with Credit Flow and Metrics February 2010 + + + Tbit/s terabits (1,000,000,000,000) per second. + + TLV Type-Length-Value. + +3. Overview of Protocol Extensions + + The extensions consist of optional TLVs as well as enhanced and newly + defined Discovery packets. The enhancements are applied to 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 TLV + +3.1.1. Credits TLV + + This TLV contains the Forward Credit Notification (FCN) and the + Backward Credit Notification (BCN). The Credits TLV is optional with + the PADR (PPPoE Active Discovery Request) and PADS (PPPoE Active + Discovery Session-Confirmation) and required in the PADG (PPPoE + Active Discovery Session Grant) and PADC (PPPoE Active Discovery + Session-Credit) Discovery packets (ETHER_TYPE=8863). + + The Credits TLV is optionally carried in the PPPoE data payload + packet of the PPP Stage (ETHER_TYPE=8864). + + The FCN represents the number of credits being granted by the local + node to the peer node. The BCN represents the number of credits + remaining at the local node that were granted by the peer node. + + The 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Credits TLV = 0x0106 | TLV Length = 0x04 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | FCN | BCN | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + + +Berry, et al. Informational [Page 5] + +RFC 5578 PPPoE with Credit Flow and Metrics February 2010 + + + These fields are transmitted in network byte order. The same byte + order is used throughout the document in other structures as well. + +3.1.2. Metrics TLV + + The Metrics TLV is used to report the link-quality parameters. The + Metrics TLV is required with the PADQ (PPPoE Discovery Quality) + Discovery packet. + + The Metrics TLV contains the following 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. + + + + + +Berry, et al. Informational [Page 6] + +RFC 5578 PPPoE with Credit Flow and Metrics February 2010 + + + 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 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. + + 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 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + + + + + + +Berry, et al. Informational [Page 7] + +RFC 5578 PPPoE with Credit Flow and Metrics February 2010 + + +3.1.4. Credit Scale Factor TLV + + This TLV contains the scale factor value that is to be 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, the scale factors are set for the entire + session. The scale factor value represents the units that the local + node grants to the remote node. 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 specifications of the PPPoE Active Discovery Request (PADR) and + the PPPoE Active Discovery Session-confirmation (PADS) packets are + extended to include the optional Credits TLV and the Credit Scale + Factor TLV. The PPPoE Active Discovery Session-Grant (PADG) packet, + the PPPoE Active Discovery Session-Credit Response (PADC), and the + Quality packets are newly defined Discovery Stage packets. + + + + + + + + + + + + + + + + +Berry, et al. Informational [Page 8] + +RFC 5578 PPPoE with Credit Flow and Metrics February 2010 + + + 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 TLV + +3.2.1. PPPoE Active Discovery Request (PADR) + + The PADR packet is extended to optionally contain a single Credits + TLV, indicating that the Client requests credit flow control for this + session. The Credits TLV 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 Server by the Client. The BCN value is set to 0, as the Client + has not yet been granted credits from the Server. + + The PADR packet is enhanced to optionally contain a single Credit + Scale Factor TLV. The Credit Scale Factor TLV 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, this + 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. + + + + + + +Berry, et al. Informational [Page 9] + +RFC 5578 PPPoE with Credit Flow and Metrics February 2010 + + + 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. + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Berry, et al. Informational [Page 10] + +RFC 5578 PPPoE with Credit Flow and Metrics February 2010 + + + 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) + + The Server PADS is extended to optionally contain a single Credits + TLV, indicating the Forward Credit Notification (FCN) and the + Backward Credit Notification (BCN) of the PPP Session Stage. + + If the Client PADR contained a Credits TLV, then the Server PADS must + indicate support for credit flow control by including a Credits TLV. + The PADS Credits TLV FCN represents the number of credits initially + granted to the Client. The Credits TLV BCN is an echo of the number + of credits that the Client had granted to the Server in the + originating PADR packet. + + Exchange of the Credits TLV in the PADR and PADS indicates that + credit flow control is supported by both the Server and the Client + for the designated PPP Session Stage. This is binding and must be + + + + + +Berry, et al. Informational [Page 11] + +RFC 5578 PPPoE with Credit Flow and Metrics February 2010 + + + followed for the entire duration of the PPP Session Stage. A + session's credit binding must be established prior to any other + credit indications being exchanged. + + The Server PADS should only include the Credits TLV in response to a + Client PADR that included the Credits TLV. If the Server does not + support credit flow, it should not include the Credits TLV in its + PADS response. The Client must terminate a credit-based session that + cannot be supported by the Server. A Credits TLV transmitted outside + an established credit-based session must be ignored. + + The Server PADS is enhanced to optionally contain a single Credit + Scale Factor TLV. The Credit Scale Factor TLV defines the credit + scale unit value. The Credit Scale Factor TLV must be included if it + was included in the Client PADR. If the Credits TLV was not included + in the originating PADR, it must be omitted, indicating that the + 64-byte default is used for the directional flow. This credit scale + factor is applied to Server grants to the Client. + + A Discovery PADS 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 = 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. + + + + + + + + + +Berry, et al. Informational [Page 12] + +RFC 5578 PPPoE with Credit Flow and Metrics February 2010 + + + A Discovery PADS 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 = 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 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 corresponds to the 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 would be consumed. When calculating + credits to consume, all credit calculations must be rounded up. If, + in the previous example, 130 bytes of PPP payload data were sent, 3 + credits would have been consumed. + + + + + +Berry, et al. Informational [Page 13] + +RFC 5578 PPPoE with Credit Flow and Metrics February 2010 + + + 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 Response (PADC) packet, indicating 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 prior to 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 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 multiply the + credit units by the credit scale factor and 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 Credits TLV BCN indicates the remaining absolute credits that + have been granted by the peer to the local node. When the local node + exhausts the BCN, it must stop transmitting payload packets. + + Once a credit has been granted, it must be honored. The largest + number of incremental credits at any time is 0xffff. + + The PADG packet must contain a single Sequence Number TLV. This TLV + is used to carry a unique 16-bit sequence number to uniquely identify + each request. The sequence number should be initialized at 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. + + + + + + + + + + + + + + + + + + + +Berry, et al. Informational [Page 14] + +RFC 5578 PPPoE with Credit Flow and Metrics February 2010 + + + A Discovery PADG packet with the Sequence Number and Credits TLVs 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 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 a 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 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 prior to processing. + + The PADC packet must contain a single Sequence Number TLV. The + sequence number must be the sequence number associated with the PADG. + + + + + +Berry, et al. Informational [Page 15] + +RFC 5578 PPPoE with Credit Flow and Metrics February 2010 + + + A Discovery PADC packet with the Sequence Number and 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 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 the 64-byte default. + +3.2.5. PPPoE Active Discovery Quality (PADQ) + + The PPPoE Active Discovery Quality (PADQ) is a new packet defined in + this specification. An Server or Client 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 PPPoE Active Discovery Quality (PADQ) packet can be used to query + link metrics by setting the PADQ Metrics TLV Length to zero. + + The PADQ must carry a single Metrics TLV. When processing the data + rates, the values must be converted using the indicated data rate + units. This document enhances the Metrics TLV as described below. + + + + +Berry, et al. Informational [Page 16] + +RFC 5578 PPPoE with Credit Flow and Metrics February 2010 + + + A Discovery PADQ packet with the required 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 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 + determined by the MD and CD bits, respectively. + + + + + + + + + + + + + + + + + + + + + + + +Berry, et al. Informational [Page 17] + +RFC 5578 PPPoE with Credit Flow and Metrics February 2010 + + + A Discovery PADQ packet with a Metrics TLV Length=0 to query 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 = 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 Credits + TLV. Use of the Credits TLV in the PPP Session Stage is referred to + as an in-band credit grant. + + 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 TLV length + is subtracted from the overall payload length. + + + + + + + + + + + + + + + + + + +Berry, et al. Informational [Page 18] + +RFC 5578 PPPoE with Credit Flow and Metrics February 2010 + + + A PPP LCP packet with 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 = 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 referred to as out-of-band. Credit grants exchanged + in the PPP Session Stage are referred to as in-band. Credit + accounting 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 Session-Grant (PADG) and PPPoE Active + Discovery Credit Response (PADC) packets. + + 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 acknowledged. 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. + + + +Berry, et al. Informational [Page 19] + +RFC 5578 PPPoE with Credit Flow and Metrics February 2010 + + + 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 must stop transmitting packets to the peer. + + 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 have been exhausted are + discarded. + +5. 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 doubling + 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 and an + incremented sequence number should be transmitted. This process + should be repeated until granted credits are properly acknowledged or + as many times as desired. + + When a node does not 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 as not to overrun the peer. + + The sending and receiving of PPPoE Discovery 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 can be used by the receiving node to reset the credit + values of its peer. + + + + +Berry, et al. Informational [Page 20] + +RFC 5578 PPPoE with Credit Flow and Metrics February 2010 + + +7. IANA Considerations + + IANA has assigned the following PPPoE TLV Values for which this RFC + serves as the reference: + + 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 assigned the following PPPoE Code fields for which this RFC + serves as the reference: + + 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 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 TLV and Session ID always be + validated prior to processing credits. + +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/. + + + + + +Berry, et al. Informational [Page 21] + +RFC 5578 PPPoE with Credit Flow and Metrics February 2010 + + +Appendix A. Examples of Session Credit Flows + + Session Credit Flow with the default 64-byte credit unit. + + 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--------------> Terminate + + Session Credit Flow with specific credit scale factor units for the + Server and the Client. + + + +Berry, et al. Informational [Page 22] + +RFC 5578 PPPoE with Credit Flow and Metrics February 2010 + + + 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--------------> Terminate + + + + + +Berry, et al. Informational [Page 23] + +RFC 5578 PPPoE with Credit Flow and Metrics February 2010 + + +Authors' Addresses + + 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.com + + + + + + + + + + + + + + + + + + + +Berry, et al. Informational [Page 24] + |