GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc5578

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.
  1. ———–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.
  1. ———–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.
  1. ———–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.
  1. ———–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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc5578.txt · Last modified: 2010/02/02 02:09 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki