Internet-Draft
Network Working Group                                      B. Berry (Editor)
Intended status: Informational Berry, Ed.
Request for Comments: 5568                                    S. Ratliff
Obsoletes: 4938                                              E. Paradise
Expires: October 24, 2008
Category: Informational                                            Cisco
                                                                T.Kaiser
                                                               T. Kaiser
                                                      Harris Corporation
                                                                M. Adams
                                                       L3 Communications
                                                          April 24, 2008
                                                                May 2009

 PPP Over over Ethernet (PPPoE) Extensions for Credit Flow and Link Metrics

                    draft-bberry-rfc4938bis-00.txt

Status of this This Memo

   By submitting this Internet-Draft, each author represents that

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any
   applicable patent or other IPR claims kind.  Distribution of which he or she this
   memo is aware
   have been or will be disclosed, unlimited.

Copyright Notice

   Copyright (c) 2009 IETF Trust and any of which he or she becomes
   aware will be disclosed, 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 in accordance with Section 6 effect on the date of BCP 79.

   Internet-Drafts are working
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

IESG Note

   The PPP Extensions Working Group (PPPEXT) has reservations about the
   desirability of the Internet Engineering
   Task Force (IETF), its areas, feature described in this document.  In
   particular, it solves a general problem at an inappropriate layer and its working groups.  Note that
   other groups
   it may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts have unpredictable interactions with higher and lower level
   protocols.  The techniques described in this document are draft documents valid intended
   for use with a maximum of six
   months and may be updated, replaced, or obsoleted particular deployment technique that uses a PPP
   termination separated from a radio termination by other
   documents at any time.  It is inappropriate an Ethernet, and
   that has radio-side flow control for a slower PPP-only link to use Internet-Drafts
   as reference material or remote
   nodes.  Implementors are better advised 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). avoid split termination
   with inter-media protocol translation, and use standard Internet
   Protocol routing instead.

Abstract

   This document extends the Point-to-Point Protocol 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.

Table of Contents

   1.0

   1. Introduction .................................................2
   2.0 ....................................................3
   2. Terminology ..................................................3
   3.0 .....................................................4
   3. Overview of Protocol Extensions ..............................3
   3.1  TLVs..........................................................4 .................................5
      3.1. TLVs .......................................................5
           3.1.1. Credit Credits TLV .................................................5 .........................................5
           3.1.2. Metric Metrics TLV .................................................5 .........................................6
           3.1.3. Sequence Number TLV ........................................7 .................................7
           3.1.4. Credit Scale Factor TLV ....................................7
   3.2 .............................8
      3.2. Discovery Stage Extensions ...................................8 .................................8
           3.2.1. PPPoE Active Discovery Request (PADR) ......................8 ...............9
           3.2.2. PPPoE Active Discovery Session-confirmation Session-Confirmation
                  (PADS) ........10 .............................................11
           3.2.3. PPPoE Active Discovery Session-Grant (PADG) ...............12 ........13
           3.2.4. PPPoE Active Discovery Session-Credit
                  Response (PADC) .....14 ....................................15
           3.2.5. PPPoE Active Discovery Quality (PADQ) .....................15
   3.3 ..............16
      3.3. PPP Session Stage Extensions ................................17
   4.0 ..............................18
   4. Credit Flow Considerations ..................................18
   5.0 .....................................19
   5. PADG and PADC Retransmission ................................19
   6.0 ...................................20
   6. Other Considerations ........................................19
   7.0 ...........................................20
   7. IANA Considerations .........................................20
   8.0 ............................................21
   8. Security Considerations .....................................20
   9.0 ........................................21
   9. References ..................................................21
   10.0 .....................................................21
      9.1. Normative References ......................................21
      9.2. Informative References ....................................21
   Appendix ...................................................22

1.0 A. Examples of Session Credit Flows ......................22

1.  Introduction

   PPP over Ethernet (PPPoE) [2] is a protocol for establishing and
   encapsulating sessions between hosts (clients) Hosts (Clients) and traffic access traffic-access
   aggregators (servers) (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) Client
   (Radio) detects the presence of a remote radio Radio neighbor, it initiates
   a PPPoE session with its local server Server (router).  The radio Radio also
   establishes a radio link connection with the remote radio Radio over the
   point-to-point RF (radio frequency) link (which is beyond the scope
   of this document).  The remote radio Radio is also establishing a PPPoE
   session with its local server Server (router).  The radios Radios associate the two
   PPPoE sessions and the point-to-point radio link protocol (RLP) (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. 1: PPPoE Network
   The capabilities of the RF links between RLP neighbors will vary over
   time due to mobility, mobility and environmental conditions as well as changes
   in the RF waveforms and encoding
   as well as environmental conditions. encoding.  To reflect these dynamic changes,
   the radio 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

   A PPPoE Client implementation can be found at [4].

2.0 [3].  It is open source
   (GNU GPLv2 -- General Public License).

2.  Terminology

   Access Concentrator
            The RFC 2516 term used to describe the server. Server.  This
            document uses the terms Router or Server. Server instead.

   BCN      Backward Credit Notification, Notification.  The BCN represent represents the
             local node number
            of remaining credits at the local node that were granted from
             the 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 Data rate 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.

    gbps

   Gbit/s   gigabits (1,000,000,000) per second second.

   Host     The RFC 2516 term used to describe the server. Server.  This
            document uses the terms Radio or Client.

    kbps

   kbit/s   kilobits (1,000) per second second.

   LCP      PPP Link Control Protocol, RFC 1661

    mbps 1661.

   Mbit/s   megabits (1,000,000) per second second.

   MDR      The Maximum Data rate Datarate.

   NCP      PPP Network Control Protocol, RFC 1661 1661.

   RLP      Radio Link Protocol Protocol.

   TAG      Is the      The RFC 2516 PPPoE Synonym synonym for TLV.  This document uses TLV.

    tbps

   Tbit/s   terabits (1,000,000,000,000) per second second.

   TLV      Type-Length-Value

3.0      Type-Length-Value.

3.  Overview of Protocol Extensions

   The extensions consist of optional TLVs, 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

3.1.  TLVs

   The new TLVs are listed in the table below:

           TLV      TLV
           Value    Description
           =========================================
           0x0106   Credit   Credits TLV
           0x0107   Metric   Metrics TLV
           0x0108   Sequence Number TLV
           0x0109   Credit Scale Factor TLV

3.1.1   Credit

3.1.1.  Credits TLV

   This TLV contains the Forward Credit Notification (FCN) and the
   Backward Credit Notification (BCN).  The Credit 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
   Packets
   Session-Credit) Discovery packets (ETHER_TYPE=8863).

   The Credit 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 Credit 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Credit    Credits TLV = 0x0106       |       TLV Length = 0x04       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              FCN              |              BCN              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3.1.2   Metric
   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 Metric Metrics TLV is used to report the link quality link-quality parameters.  The
   Metric
   Metrics TLV is required with the PADQ (PPPoE Discovery Quality)
   Discovery Packet. packet.

   The Metric 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. receive-only.  A value of -1- "1" indicates that the
      link is receive-only.

      Reserved - Reserved reserved fields are zeroed unless otherwise specified.

      CD - Two two bits that designate the units of the current data rate. Current Datarate.

               CD Scale:  00 == kbps kbit/s (default)
                          01 == mbps Mbit/s
                          10 == gbps Gbit/s
                          11 == tbps Tbit/s

      MD - Two two bits that designate the units of the maximum data rate. Maximum Datarate.

               MD Scale:  00 == kbps kbit/s (default)
                          01 == mbps Mbit/s
                          10 == gbps Gbit/s
                          11 == tbps Tbit/s

      Current data rate Datarate - the current data rate, Current Datarate, in un scaled un-scaled units per
      second, achieved on the RLP link.  If the radio Radio makes no
      distinction between maximum data rate Maximum Datarate and current data rate,
       current data rate Current Datarate, Current
      Datarate should equal the maximum data rate. Maximum Datarate.  When metrics are
      reported, the current data rate Current Datarate must be reported.  The current data rate Current
      Datarate must be less than or equal to the maximum
       data rate. Maximum Datarate.

      Latency - the transmission delay that a packet encounters as it is
      transmitted over the link.  This is reported in absolute delay,
      milliseconds.  If latency cannot be calculated, a value of 0
      should be reported.  The calculation of latency is radio Radio
      dependent.  For example, the latency may be a running average
      calculated from the internal queuing.

      Maximum data rate Datarate - the maximum theoretical data rate, in
       un scaled un-scaled
      units per second, that the RLP link is capable of providing.  When
      metrics are reported, the maximum data rate Maximum Datarate must be reported.

   The Metric 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Metric     Metrics TLV = 0x0107      |       TLV Length = 0x0A       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Reserved        | MD| CD|R|      RLQ      |    Resources  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Latency (MS)          |   Current Datarate            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Maximum Datarate           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3.1.3

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

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, 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 1 byte to 65535-bytes. 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

3.2.  Discovery Stage Extensions

   The specifications of the Session PPPoE Active Discovery Request (PADR) and
   the Session
   Confirmation PPPoE Active Discovery Session-confirmation (PADS) packets are
   extended to include the optional
   Credit Credits TLV and the Credit Scale
   Factor TLV.  The Credit Grant PPPoE Active Discovery Session-Grant (PADG) packet,
   the Grant Confirmation (PADC) packet PPPoE Active Discovery Session-Credit Response (PADC), and the
   Quality packet packets are newly defined Discovery Stage Packets. packets.

           Discovery
           Packet                 Status
           =======================================================
           PADR        Enhanced   Optionally includes the Credit Credits
                                  TLV and the Credit Scale Factor
                                  TLV

           PADS        Enhanced   Optionally includes the Credit Credits
                                  TLV and the Credit Scale Factor
                                  TLV

           PADG        New        Includes the Credit Credits TLV and the
                                  Sequence Number TLV

           PADC        New        Includes the Credit Credits TLV and the
                                  Sequence Number TLV

           PADQ        New        Includes the Metric Metrics TLV

3.2.1

3.2.1.  PPPoE Active Discovery Request (PADR)

   The PADR packet is extended to optionally contain a single Credit Credits
   TLV, indicating that the Client requests credit flow control for this
   session.  The Credit 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 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 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 Client credits that are granted to the server. 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 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 cannot be changed.

   A Discovery PADR packet with the optional Credit 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       |  Metric  Metrics TLV Length = 0x00    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Credit   Credits TLV = 0x0106        |      TLV Length = 0x04        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              FCN              |              BCN = 0          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The credit units are expressed in the default 64-byte units.

   A Discovery PADR packet with the optional Credit 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 = 0x0C 0x12            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       TLV Type = 0x0101       |        TLV Length = 0x00      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Credit     Credits TLV = 0x0106      |       TLV Length = 0x04       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              FCN              |             BCN = 0           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Credit Scale Factor = 0x0109  |       TLV Length = 0x02       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       scale factor value      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Credit Credits TLV FCN value is expressed in units of the session session's
   credit scale factor value.

3.2.2

3.2.2.  PPPoE Active Discovery Session-confirmation Session-Confirmation (PADS)

   The Server PADS is extended to optionally contain a single Credit 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 Credit Credits TLV, then the Server PADS must
   indicate support for credit flow control by including a Credit Credits TLV.
   The PADS Credit Credits TLV FCN represents the number of credits initially
   granted to the Client.  The Credit 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 Credit 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
   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 being exchanged.

   The Server PADS should only include the Credit Credits TLV in response to a
   Client PADR which that included the Credit Credits TLV.  If the Server does not
   support credit flow, it should not include the Credit Credits TLV in its
   PADS response.  The Client must terminate a credit-based session that
   cannot be supported by the Server.  A Credit Credits TLV transmitted outside
   an established credit based 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 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 Credit 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       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Credit   Credits TLV = 0x0106        |       TLV Length = 0x04       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              FCN              |              BCN              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The BCN is expressed in the default 64-byte units.

   A Discovery PADS packet with the optional Credit 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 = 0x0C 0x12            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       TLV Type = 0x0101       |       TLV Length = 0x00       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Credit    Credits TLV = 0x0106       |        TLV Length = 0x04      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              FCN              |              BCN              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Credit Scale Factor = 0x0109 |       TLV Length = 0x02       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      scale factor value       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Credit Credits TLV BCN value is expressed in units of the session scale
   factor value received in the PADR.

3.2.3

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 64 bytes is used, and 128 bytes of PPP payload
   data is are sent, then 2 credits would be consumed.  When calculating
   credits to consume, all credit calculations must be rounded up. If  If,
   in the previous example example, 130 bytes of PPP payload data was were sent, 3
   credits would have been consumed.

   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 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 Credits TLV, indicating the
   Forward Credit Notification (FCN) and the Backward Credit
   Notification (BCN) of the PPPoE Session.

   The Credit 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 credits
   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 Credit Tag 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
   tag TLV
   is used to carry a unique 16-bit sequence number to uniquely
   to 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.

   A Discovery PADG packet with the Sequence Number and Credit 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         |     Credit     Credits TLV = 0x0106      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       TLV Length = 0x04       |               FCN             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              BCN              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3.2.4

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 Credits TLV, indicating the
   Forward Credit Notification (FCN) and the Backward Credit
   Notification (BCN) of the PPPoE session.

   The Credit Credits TLV FCN represents the absolute credits remaining that
   have been granted to the peer by the node.  The Credit 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 Tag.The TLV.  The
   sequence number must be the sequence number associated with the PADG.

   A Discovery PADC packet with the Sequence Number and Credit Credits TLV is
   shown below. 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     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

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 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 Metrics TLV Length to zero.

   The PADQ must carry a single Metric Metrics TLV.  When processing the data
   rates, the values must be converted using the indicated data rate
   units.  This document enhances the Metric Tag Metrics TLV as described below.

   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 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      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Metric    Metrics TLV = 0x0107       |        TLV Length = 0x0A      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Reserved      | MD| CD|R|      RLQ      |    Resources  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Latency (MS)          |        Current Datarate       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Maximum Datarate       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The maximum datarate Maximum Datarate and the current datarate Current Datarate are expressed in units
   determined by the MD and CD bits, respectively.

   A Discovery PADQ packet with a Metric Metrics 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     Metrics TLV = 0x0107      |       TLV Length = 0x00       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3.3

3.3.  PPP Session Stage Extensions

   The PPP Session Stage Extensions define the optional use of Credit Credits
   TLV.  Use of the Credit 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.

   A PPP LCP packet with optional Credit 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)       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Credit     Credits TLV = 0x0106      |       TLV Length = 0x04       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              FCN              |              BCN              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    PPP PROTOCOL = 0xc021      |        PPP payload           ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

4.0

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 Grant 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 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, peer before the peer can transmit packets to the
   granting node.

   Credits are granted incrementally in the forward direction.  Locally,
   a node manages the credits that it has granted to a peer, as well as
   the credits that a peer has granted to it.

   Grants received from a peer are added to a local running credit
   counter.  The accumulated credits are decremented with each packet
   the node transmits to the peer.  When the running counter reaches
   zero, the node 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

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 double 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, with credits and an
   incremented sequence number, 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

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.

7.0

7.  IANA Considerations

   IANA has assigned the following PPPoE TLV Values for which this RFC
   serves as noted in [3]: the reference:

   TLV Value     TLV Name             Description         Reference
   -----------   -------------------  -----------------   ---------
   262  0x0106   Credits              See the reference   [RFC4938bis]   [RFC5568]
   263  0x0107   Metrics              See the reference   [RFC4938bis]   [RFC5568]
   264  0x0108   Sequence Number      See the reference   [RFC4938bis]   [RFC5568]
   265  0x0109   Credit Scale Factor  See the reference   [RFC4938bis]   [RFC5568]

   IANA has assigned the following PPPoE Code fields for which this RFC
   serves as noted in [3]: the reference:

   Code      PPPoE Packet Name        Description         Reference
   --------  ----------------------   -----------------   ---------
   10  0x0a  PADG, Session-Grant      See the reference   [RFC4938bis]   [RFC5568]
   11  0x0b  PADC, Session-Credit     See the reference   [RFC4938bis]   [RFC5568]
                    Response
   12  0x0c  PADQ, Quality            See the reference   [RFC4938bis]

8.0   [RFC5568]

8.  Security Considerations

   This memo defines a mechanism for adding flow control to the
   existingPPP Over 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.0

9.  References

9.1

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.

   [3] Arberg, P. and V. Mammoliti, "IANA Considerations for PPP over
       Ethernet (PPPoE)", RFC 4937, June 2007.

9.2

9.2.  Informative References

   [4]

   [3] An open source (GPLv2) pppoe client PPPoE Client implementation of
       RFC4938bis, RFC 5568,
       PPP Over Ethernet (PPPoE) Extensions for Credit Flow and Link
       Metrics,
       http://rfc4938.sourceforge.net/

10.0 http://rfc4938.sourceforge.net/.

Appendix A.  Examples of Session Credit Flows

   Session Credit Flow with the default 64-byte credit unit.

   Server                    Client
 ======================================================================
   ====================================================================
   <------------PADI--------------    Initiate
    ------------PADO-------------->   Offer

   <------------PADR--------------    Credit    Credits TLV:
                                      FCN represents the initial
                                      client
                                      Client credit grant to the
                                      server
                                      Server in 64-byte units.
                                      BCN is set to 0.

    ------------PADS-------------->   Credit   Credits TLV:
                                      FCN represents the initial
                                      server
                                      Server credit grant to the
                                      client
                                      Client in 64-byte units.
                                      BCN represents an echo of
                                      initial client Client credits.

   <==============================>   Data w/ optional inband
                                      Credit in-band
                                      Credits TLV

   <------------PADG--------------    Credit    Credits TLV: (out-of-band)
                                      FCN represents an incremental
                                      client
                                      Client credit grant to the
                                      server,
                                      Server, in 64-byte units.
                                      BCN represents the remaining
                                      server
                                      Server credits that were granted
                                      to the client, Client, in 64-byte units.

    ------------PADC-------------->   Credit   Credits TLV: (out-of-band)
                                      FCN represents an incremental
                                      server
                                      Server credit grant to the
                                      client,
                                      Client, in 64-byte units.
                                      BCN represents the remaining
                                      client
                                      Client credits that were granted
                                      to the server, Server, in 64-byte units.

   <==============================>   Data w/ optional inband Credit in-band Credits
                                      TLV

   <------------PADT-------------->   Terminate

   Session Credit Flow with specific credit scale factor units for the
   Server and the Client.

   Server                    Client
 ======================================================================
   ====================================================================
   <------------PADI--------------    Initiate
    ------------PADO-------------->   Offer

   <------------PADR--------------    Credit    Credits TLV:
                                      FCN represents the initial
                                      client
                                      Client credit grant to the
                                      server,
                                      Server, in Credit Scale Factor
                                      TLV units.
                                      BCN is set to 0.

    ------------PADS-------------->   Credit   Credits TLV:
                                      FCN represents the initial
                                      server
                                      Server credit grant to the
                                      client,
                                      Client, in Credit Scale Factor
                                      TLV units.
                                      BCN represents an echo of the
                                      initial client Client credits, in
                                      Credit Scale Factor TLV units.

   <==============================>   Data w/ optional inband Credit in-band Credits
                                      TLV

   <------------PADG--------------    Credit    Credits TLV: (out-of-band)
                                      FCN represents an incremental
                                      client
                                      Client credit grant to the server, Server,
                                      in Credit Scale Factor TLV units.
                                      BCN represents the remaining
                                      server
                                      Server credits that were granted
                                      to the client, Client, in Credit Scale
                                      Factor TLV units.

    ------------PADC-------------->   Credit   Credits TLV: (out-of-band)
                                      FCN represents an incremental
                                      server
                                      Server credit grant to the client, Client,
                                      in Credit Scale Factor TLV units.
                                      BCN represents the remaining
                                      client
                                      Client credits that were granted
                                      to the server, Server, in Credit Scale
                                      Factor TLV units.

   <==============================>   Data w/ optional inband Credit Credits
                                      TLV

   <------------PADT-------------->   Terminate

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

   Michael D Adams
   640 N 2200 W MS F1J12
   Salt Lake City, Utah 84116
   801 594-2367
   EMail: Michael.D.Adams@L-3com.com

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.