PPP over Ethernet (PPPoE) Extensions for Credit Flow and Link Metrics
draft-bberry-rfc4938bis-00
This document is an Internet-Draft (I-D) that has been submitted to the Independent Submission stream.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
The information below is for an old version of the document that is already published as an RFC.
| Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 5578.
|
|
|---|---|---|---|
| Authors | Stan Ratliff , Bo Berry, Tim Kaiser , Ed Paradise , Mike D. Adams | ||
| Last updated | 2021-04-06 (Latest revision 2008-04-24) | ||
| RFC stream | Independent Submission | ||
| Intended RFC status | Informational | ||
| Formats | |||
| Stream | ISE state | (None) | |
| Consensus boilerplate | Unknown | ||
| Document shepherd | (None) | ||
| IESG | IESG state | Became RFC 5578 (Informational) | |
| Action Holders |
(None)
|
||
| Telechat date | (None) | ||
| Responsible AD | Jari Arkko | ||
| Send notices to | rfc-editor@rfc-editor.org |
draft-bberry-rfc4938bis-00
Internet-Draft B. Berry (Editor)
Intended status: Informational S. Ratliff
Obsoletes: 4938 E. Paradise
Expires: October 24, 2008 Cisco
T.Kaiser
Harris Corporation
M. Adams
L3 Communications
April 24, 2008
PPP Over Ethernet (PPPoE) Extensions
for Credit Flow and Link Metrics
draft-bberry-rfc4938bis-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts
as reference material or to cite them other than as "work in
progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Abstract
This document extends the Point-to-Point over Ethernet (PPPoE)
Protocol 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.
Berry, et. al. Expires October 24, 2008 [Page 1]
Internet-Draft PPPoE with Credit Flow and Metrics April 2008
Table of Contents
1.0 Introduction .................................................2
2.0 Terminology ..................................................3
3.0 Overview of Protocol Extensions ..............................3
3.1 TLVs..........................................................4
3.1.1. Credit TLV .................................................5
3.1.2. Metric TLV .................................................5
3.1.3. Sequence Number TLV ........................................7
3.1.4. Credit Scale Factor TLV ....................................7
3.2 Discovery Stage Extensions ...................................8
3.2.1. PPPoE Active Discovery Request (PADR) ......................8
3.2.2. PPPoE Active Discovery Session-confirmation (PADS) ........10
3.2.3. PPPoE Active Discovery Session-Grant (PADG) ...............12
3.2.4. PPPoE Active Discovery Session-Credit Response (PADC) .....14
3.2.5. PPPoE Active Discovery Quality (PADQ) .....................15
3.3 PPP Session Stage Extensions ................................17
4.0 Credit Flow Considerations ..................................18
5.0 PADG and PADC Retransmission ................................19
6.0 Other Considerations ........................................19
7.0 IANA Considerations .........................................20
8.0 Security Considerations .....................................20
9.0 References ..................................................21
10.0 Appendix ...................................................22
1.0 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 link (which is beyond the scope of this
document). The remote radio is also establishing a PPPoE session
Berry, et. al. Expires October 24, 2008 [Page 2]
Internet-Draft PPPoE with Credit Flow and Metrics April 2008
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
The capabilities of the RF links between RLP neighbors will vary
over time due to mobility, changes in the RF waveforms and encoding
as well as environmental conditions. 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.
An open source (GPLv2) pppoe client implementation can be found
at [4].
2.0 Terminology
Access Concentrator
The RFC 2516 term used to describe the server. This
document uses the terms Router or Server.
BCN Backward Credit Notification, The BCN represent the
local node remaining credits that were granted from
the peer node. The local node uses these credits
to transmit payload back to the peer node. BCN
ranges from 0-65535.
CDR Current Data rate
Berry, et. al. Expires October 24, 2008 [Page 3]
Internet-Draft PPPoE with Credit Flow and Metrics April 2008
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.
gbps 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.
kbps kilobits (1,000) per second
LCP PPP Link Control Protocol, RFC 1661
mbps megabits (1,000,000) per second
MDR Maximum Data rate
NCP PPP Network Control Protocol, RFC 1661
RLP Radio Link Protocol
TAG Is the RFC 2516 PPPoE Synonym for TLV. This document
uses TLV.
tbps terabits (1,000,000,000,000) per second
TLV Type-Length-Value
3.0 Overview of Protocol Extensions
The extensions consist of optional TLVs, 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 Credit TLV
0x0107 Metric TLV
0x0108 Sequence Number TLV
0x0109 Credit Scale Factor TLV
Berry, et. al. Expires October 24, 2008 [Page 4]
Internet-Draft PPPoE with Credit Flow and Metrics April 2008
3.1.1 Credit TLV
This TLV contains the Forward Credit Notification (FCN) and the
Backward Credit Notification (BCN). The Credit TLV is optional
with the PADR and PADS and required in the PADG and PADC Discovery
Packets (ETHER_TYPE=8863).
The Credit 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 Credit 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 TLV = 0x0106 | TLV Length = 0x04 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FCN | BCN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.1.2 Metric TLV
The Metric TLV is used to report the link quality parameters. The
Metric TLV is required with the PADQ Discovery Packet.
The Metric 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.
Berry, et. al. Expires October 24, 2008 [Page 5]
Internet-Draft PPPoE with Credit Flow and Metrics April 2008
CD - Two bits that designate the units of the current data rate.
CD Scale: 00 == kbps (default)
01 == mbps
10 == gbps
11 == tbps
MD - Two bits that designate the units of the maximum data rate.
MD Scale: 00 == kbps (default)
01 == mbps
10 == gbps
11 == tbps
Current data rate - the current data rate, in un scaled units
per second, achieved on the RLP link. If the radio makes no
distinction between maximum data rate and current data rate,
current data rate should equal the maximum data rate. When
metrics are reported, the current data rate must be reported.
The current data rate must be less than or equal to the maximum
data rate.
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 data rate - 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 data rate
must be reported.
The Metric 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Metric TLV = 0x0107 | TLV Length = 0x0A |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | MD| CD|R| RLQ | Resources |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Latency (MS) | Current Datarate |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Datarate |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Berry, et. al. Expires October 24, 2008 [Page 6]
Internet-Draft PPPoE with Credit Flow and Metrics April 2008
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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, 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Berry, et. al. Expires October 24, 2008 [Page 7]
Internet-Draft PPPoE with Credit Flow and Metrics April 2008
3.2 Discovery Stage Extensions
The specifications of the Session Request (PADR) and the Session
Confirmation (PADS) packets are extended to include the optional
Credit TLV and the Credit Scale Factor TLV. The Credit Grant (PADG)
packet, the Grant Confirmation (PADC) packet and the Quality packet
are newly defined Discovery Stage Packets.
Discovery
Packet Status
=======================================================
PADR Enhanced Optionally includes the Credit
TLV and the Credit Scale Factor
TLV
PADS Enhanced Optionally includes the Credit
TLV and the Credit Scale Factor
TLV
PADG New Includes the Credit TLV and the
Sequence Number TLV
PADC New Includes the Credit TLV and the
Sequence Number TLV
PADQ New Includes the Metric TLV
3.2.1 PPPoE Active Discovery Request (PADR)
The PADR packet is extended to optionally contain a single Credit
TLV, indicating that the Client requests credit flow control for
this session. The Credit 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.
Berry, et. al. Expires October 24, 2008 [Page 8]
Internet-Draft PPPoE with Credit Flow and Metrics April 2008
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 can not be changed.
A Discovery PADR packet with optional Credit 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 | Metric TLV Length = 0x00 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Credit TLV = 0x0106 | TLV Length = 0x04 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FCN | BCN = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The credit units are expressed in the default 64-byte units.
Berry, et. al. Expires October 24, 2008 [Page 9]
Internet-Draft PPPoE with Credit Flow and Metrics April 2008
A Discovery PADR packet with the optional Credit 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 = 0x0C |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = 0x0101 | TLV Length = 0x00 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Credit TLV = 0x0106 | TLV Length = 0x04 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FCN | BCN = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Credit Scale Factor = 0x0109 | TLV Length = 0x02 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| scale factor value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Credit TLV FCN value is expressed in units of the session
credit scale factor value.
3.2.2 PPPoE Active Discovery Session-confirmation (PADS)
The Server PADS is extended to optionally contain a single Credit
TLV, indicating the Forward Credit Notification (FCN) and the
Backward Credit Notification (BCN) of the PPP Session Stage.
If the Client PADR contained a Credit TLV, then the Server PADS
must indicate support for credit flow control by including
a Credit TLV. The PADS Credit TLV FCN represents the number of
credits initially granted to the Client. The Credit 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 Credit 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
Berry, et. al. Expires October 24, 2008 [Page 10]
Internet-Draft PPPoE with Credit Flow and Metrics April 2008
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 Server PADS should only include the Credit TLV in response to
a Client PADR which included the Credit TLV. If the Server does
not support credit flow, it should not include the Credit TLV in
its PADS response. The Client must terminate a credit-based session
that cannot be supported by the Server. A Credit 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 Credit 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 Credit 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Credit TLV = 0x0106 | TLV Length = 0x04 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FCN | BCN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The BCN is expressed in the default 64-byte units.
Berry, et. al. Expires October 24, 2008 [Page 11]
Internet-Draft PPPoE with Credit Flow and Metrics April 2008
A Discovery PADS packet with the optional Credit 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 = 0x0C |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = 0x0101 | TLV Length = 0x00 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Credit TLV = 0x0106 | TLV Length = 0x04 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FCN | BCN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Credit Scale Factor = 0x0109 | TLV Length = 0x02 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| scale factor value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Credit 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 is 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 was sent, 3 credits would have been consumed.
Berry, et. al. Expires October 24, 2008 [Page 12]
Internet-Draft PPPoE with Credit Flow and Metrics April 2008
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
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 Credit TLV, indicating
the Forward Credit Notification (FCN) and the Backward Credit
Notification (BCN) of the PPPoE Session.
The Credit 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 credits 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 Credit Tag 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
tag is used to carry a unique 16-bit sequence number to uniquely
to identify each request. The sequence number should be
initialized 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. Expires October 24, 2008 [Page 13]
Internet-Draft PPPoE with Credit Flow and Metrics April 2008
A Discovery PADG packet with the Sequence Number and Credit 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 | Credit 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 Credit Tag TLV, indicating
the Forward Credit Notification (FCN) and the Backward Credit
Notification (BCN) of the PPPoE session.
The Credit TLV FCN represents the absolute credits remaining that
have been granted to the peer by the node. The Credit 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 Tag.The
sequence number must be the sequence number associated with the
PADG.
Berry, et. al. Expires October 24, 2008 [Page 14]
Internet-Draft PPPoE with Credit Flow and Metrics April 2008
A Discovery PADC packet with the Sequence Number and Credit 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 | Credit 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 Metric Tag Length to zero.
The PADQ must carry a single Metric TLV. When processing the
data rates, the values must be converted using the indicated
data rate units. This document enhances the Metric Tag as
described below.
Berry, et. al. Expires October 24, 2008 [Page 15]
Internet-Draft PPPoE with Credit Flow and Metrics April 2008
The PPPoE Active Discovery Quality (PADQ) packet can be used to
query link metrics by setting the PADQ Metric Tag Length to zero.
A Discovery PADQ packet with the required Metric 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Metric 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. Expires October 24, 2008 [Page 16]
Internet-Draft PPPoE with Credit Flow and Metrics April 2008
A Discovery PADQ packet with a Metric TLV Length=0 to query for
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Metric TLV = 0x0107 | TLV Length = 0x00 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.3 PPP Session Stage Extensions
The PPP Session Stage Extensions define the optional use of Credit
TLV. Use of the Credit 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. Expires October 24, 2008 [Page 17]
Internet-Draft PPPoE with Credit Flow and Metrics April 2008
A PPP LCP packet with optional Credit 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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Credit TLV = 0x0106 | TLV Length = 0x04 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FCN | BCN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PPP PROTOCOL = 0xc021 | PPP payload ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.0 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 Grant (PADG) and PPPoE Active Discovery
Credit (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.
Berry, et. al. Expires October 24, 2008 [Page 18]
Internet-Draft PPPoE with Credit Flow and Metrics April 2008
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 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.0 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.
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.0 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.
Berry, et. al. Expires October 24, 2008 [Page 19]
Internet-Draft PPPoE with Credit Flow and Metrics April 2008
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.
7.0 IANA Considerations
IANA has assigned the following PPPoE TLV Values as noted in [3]:
TLV Value TLV Name Description Reference
----------- ------------------- ----------------- ---------
262 0x0106 Credits See the reference [RFC4938bis]
263 0x0107 Metrics See the reference [RFC4938bis]
264 0x0108 Sequence Number See the reference [RFC4938bis]
265 0x0109 Credit Scale Factor See the reference [RFC4938bis]
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 [RFC4938bis]
11 0x0b PADC, Session-Credit See the reference [RFC4938bis]
Response
12 0x0c PADQ, Quality See the reference [RFC4938bis]
8.0 Security Considerations
This memo defines a mechanism for adding flow control to the
existingPPP 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.0 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.
Berry, et. al. Expires October 24, 2008 [Page 20]
Internet-Draft PPPoE with Credit Flow and Metrics April 2008
[3] Arberg, P. and V. Mammoliti, "IANA Considerations for PPP over
Ethernet (PPPoE)", RFC 4937, June 2007.
9.2 Informative References
[4] An open source (GPLv2) pppoe client implementation of
RFC4938bis, PPP Over Ethernet (PPPoE) Extensions for Credit
Flow and Link Metrics,
http://rfc4938.sourceforge.net/
Berry, et. al. Expires October 24, 2008 [Page 21]
Internet-Draft PPPoE with Credit Flow and Metrics April 2008
10.0 Appendix
Session Credit Flow with the default 64-byte credit unit.
Server Client
======================================================================
<------------PADI-------------- Initiate
------------PADO--------------> Offer
<------------PADR-------------- Credit TLV:
FCN represents the initial
client credit grant to the
server in 64-byte units.
BCN is set to 0.
------------PADS--------------> Credit 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 inband
Credit TLV
<------------PADG-------------- Credit 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--------------> Credit 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 inband Credit
TLV
<------------PADT--------------> Terminate
Berry, et. al. Expires October 24, 2008 [Page 22]
Internet-Draft PPPoE with Credit Flow and Metrics April 2008
Session Credit Flow with specific credit scale factor units for
the Server and the Client.
Server Client
======================================================================
<------------PADI-------------- Initiate
------------PADO--------------> Offer
<------------PADR-------------- Credit TLV:
FCN represents the initial
client credit grant to the
server, in Credit Scale Factor
TLV units.
BCN is set to 0.
------------PADS--------------> Credit 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 inband Credit
TLV
<------------PADG-------------- Credit 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--------------> Credit 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 Credit
TLV
<------------PADT--------------> Terminate
Berry, et. al. Expires October 24, 2008 [Page 23]
Internet-Draft PPPoE with Credit Flow and Metrics April 2008
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
Mike D Adams
640 N 2200 W MS F1J12
Salt Lake City, Utah 84116
801 594-2367
EMail: Michael.D.Adams@L-3com.com
Berry, et. al. Expires October 24, 2008 [Page 24]
Internet-Draft PPPoE with Credit Flow and Metrics April 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, 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, et. al. Expires October 24, 2008 [Page 25]