Network Working Group B. Berry
Request for Comments: 4938 H. Holgate
Category: Informational Cisco Systems,Inc.
June 2007
PPP Over Ethernet (PPPoE) Extensions
for Credit Flow and Link Metrics
Status of This Memo
このメモのステータス
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（2007）。
IESG Note
IESG注意
The PPP Extensions Working Group (PPPEXT) has reservations about the desirability of the feature described in this document. In particular, it solves a general problem at an inappropriate layer and it may have unpredictable interactions with higher and lower level protocols. The techniques described in this document are intended for use with a particular deployment technique that uses a PPP termination separated from a radio termination by an Ethernet, and that has radio-side flow control for a slower PPP-only link to remote nodes. Implementors are better advised to avoid split termination with inter-media protocol translation, and use standard Internet Protocol routing instead.
PPP拡張ワーキンググループ（PPPEXT）は、この文書で説明する機能の望ましさについての予約を持っています。特に、不適切な層で一般的な問題を解決し、それがより高い及びより低いレベルのプロトコルとの予測できない相互作用を有することができます。この文書に記載された技術は、イーサネットによって無線終端から分離PPP終端を使用して特定のデプロイメント技術で使用するために意図され、それがリモートノードに遅いPPPのみのリンクのための無線側のフロー制御を有します。実装者は、より優れたメディア間のプロトコル変換と分割終端を避け、代わりに標準のインターネット・プロトコル・ルーティングを使用することをお勧めします。
Abstract
抽象
This document extends the Point-to-Point over Ethernet (PPPoE) Protocol with a credit-based flow control mechanism and Link Quality Metric report. This optional extension should improve the performance of PPPoE over media with variable bandwidth and limited buffering, such as mobile radio links.
この文書では、クレジットベースのフロー制御機構とリンク品質メトリックレポートとポイント・ツー・ポイント・オーバー・イーサネット（PPPoEの）プロトコルを拡張します。このオプションの拡張は、モバイル無線リンクのような可変帯域幅と限られたバッファリング、とメディア上にPPPoEのパフォーマンスを向上させる必要があります。
Table of Contents
目次
1. Introduction ....................................................2
2. Payload .........................................................3
3. Overview of Protocol Extensions .................................3
4. Discovery Stage .................................................3
4.1. PPPoE Active Discovery Request (PADR) ......................4
4.2. PPPoE Active Discovery Session-confirmation (PADS) .........4
4.3. PPPoE Active Discovery Session-Grant (PADG) ................5
4.4. PPPoE Active Discovery Session-Credit Response (PADC) ......5
4.5. PPPoE Active Discovery Quality (PADQ) ......................6
5. PPP Session Stage ...............................................7
6. Credit Flow Considerations ......................................7
7. PADG and PADC Retransmission ....................................8
8. Other Considerations ............................................9
9. IANA Considerations .............................................9
10. Security Considerations ........................................9
Appendix A: Tag Values.............................................10
Appendix B: Example Message Formats................................11
Acknowledgements...................................................15
Normative References...............................................15
PPP over Ethernet (PPPoE) [2] is a protocol for establishing and encapsulating sessions between hosts and traffic aggregators (Access Concentrators) for PPP [1] transport over real or emulated Ethernet. PPPoE works well when both session endpoints have similar bandwidth, forwarding, and buffering capabilities that do not vary over time. However, it is insufficient for applications with variable bandwidth and limited buffering (for example, mobile radio links). This document addresses this problem by suggesting an extension to PPPoE to support credit-based session flow control and session-based link metric exchanges.
イーサネット（PPPoEの）上のPPP [2]実数またはエミュレートされたイーサネット上の[1]トランスポートを確立し、PPPのためのホストとトラフィック・アグリゲータ（アクセスコンセントレータ）との間のセッションをカプセル化するためのプロトコルです。両方のセッションエンドポイントが経時的に変化していない同様の帯域幅、転送、および緩衝能力を持っているとき、PPPoEはよく働きます。しかし、可変帯域幅及び限られたバッファ（例えば、移動無線リンク）を持つアプリケーションには不十分です。この文書では、クレジットベースのセッションフロー制御およびセッションベースのリンクメトリックの交流を支援するためのPPPoEの拡張を示唆することによって、この問題に対処しています。
The diagram below illustrates the problem that this extension is intended to solve, for the case of a radio link. Here PPPoE sessions are used between access concentrators (routers) and radio transmission systems that are shown as radio neighbors. Each radio transmission system establishes point-to-point Radio Link Protocol (RLP) sessions with its neighbors and establishes a corresponding PPPoE session for each neighbor with the transmission system's associated access concentrator (router). The radio logically associates the PPPoE session with the corresponding RLP session.
以下の図は、この拡張は、無線リンクの場合について、解決することを意図している問題を示しています。ここでPPPoEセッションは、アクセスコンセントレータ（ルータ）と無線ネイバーとして示されている無線伝送システムの間で使用されています。各無線伝送システムは、そのネイバーとポイント・ツー・ポイント無線リンクプロトコル（RLP）セッションを確立し、伝送システムの関連するアクセス・コンセントレータ（ルータ）と各隣接のための対応するPPPoEセッションを確立します。ラジオは、論理的に対応するRLPセッションでPPPoEセッションを関連付けます。
+--------+ +-------+ +-------+ +--------+
| Access | | Host | | Host | | Access |
| Conc. |=======| Radio |~~~~~~~| Radio |=======| Conc. |
+--------+ +-------+ +-------+ +--------+
| | | | | |
|-PPPoE-| |--RLP--| |-PPPoE-|
| |
|-------------PPP Session---------------|
Figure 1. PPPoE Network
図1. PPPoEのネットワーク
The capabilities of the RF links between RLP neighbors may vary over time due to mobility and environmental conditions. In many instances, the Host Radio has limited buffering capability to handle capacity changes in the RLP sessions. To limit buffering in the Host Radio, the PPPoE credit flow control mechanism provides dynamic buffering feedback to the access concentrator.
RLPのネイバー間のRFリンクの機能は、移動性および環境条件による経時的に変化することがあります。多くの場合、ホストラジオはRLPセッションで容量の変化を処理するために、限られたバッファリング機能を持っています。ホスト無線でバッファリングを制限するために、PPPoEのクレジットフロー制御機構は、アクセスコンセントレータへの動的緩衝フィードバックを提供します。
In the diagram above, from the access concentrator's perspective, each PPPoE session between it and the Host Radio represent a connection to a remote routable peer. For efficient routing, the local Host Radio uses the link metric mechanism to dynamically update the access concentrator route cost of the associated link.
上記の図では、アクセスコンセントレータの観点から、それとホストラジオ間の各PPPoEセッションは、リモートルーティング可能なピアへの接続を表します。効率的なルーティングのために、ローカルホストラジオ動的関連するリンクのアクセスコンセントレータ経路コストを更新するためのリンクメトリックメカニズムを使用します。
While the example shows an RF-based application, the extensions are applicable to other media.
例では、RFベースのアプリケーションを示しているが、拡張は、他のメディアにも適用可能です。
The Ethernet payload version field retains its value of 0x01. The extensions for credit flow control and link quality metrics are optional and backward compatible.
イーサネットペイロードのバージョンフィールドは0×01の値は保持されます。クレジットフロー制御およびリンク品質メトリクスのための拡張機能はオプションと下位互換性があります。
PPPoE has two distinct stages. There is a Discovery Stage and a PPP Session Stage. During the Discovery Stage, the Host can optionally request a flow controlled PPP Session Stage. Once the Access Concentrator acknowledges the Host flow control request, all PPP Session Stage traffic must be flow controlled.
PPPoEは、二つの異なる段階があります。ディスカバリーステージとPPPセッションステージがあります。ディスカバリー段階で、ホストは、必要に応じてPPPセッションステージ制御された流れを要求することができます。アクセスコンセントレータがホストのフロー制御要求を承認すると、すべてのPPPセッションステージのトラフィックが流れに制御されなければなりません。
The packet exchange of the Discovery Stage is unchanged by this specification. The specifications of the Session Request (PADR) and the Session Confirmation (PADS) packets are extended to include the optional Credit Tag Type-Length-Value (TLV).
ディスカバリーステージのパケット交換は、この仕様によって変更されません。セッション要求（PADR）の仕様およびセッションの確認（PADS）パケットは、オプションのクレジットタグのType-Length-Value（TLV）を含むように拡張されています。
In addition, the optional Credit Grant (PADG) packet, the Credit Response (PADC) packet, and the Link Quality Metric (PADQ) packets are introduced.
また、オプションのクレジット・グラント（PADG）パケット、クレジット応答（PADC）パケット、およびリンク品質メトリック（PADQ）パケットが導入されています。
The PADR packet is extended to optionally contain a single Credit Tag TLV, indicating that the Host requests credit flow control for this session. The Credit Tag contains the Forward Credit Notification (FCN) and the Backward Credit Notification (BCN) to be applied to the PPP Session Stage. The FCN provides the initial credits granted to the Access Concentrator by the Host. The BCN value is set to 0.
PADRパケットは、必要に応じてホストがこのセッションのためのクレジットフロー制御を要求していることを示す、単一のクレジットタグTLVを含むように拡張されます。クレジットタグは、PPPセッションステージに適用されるフォワードクレジット通知（FCN）と後方クレジット通知（BCN）が含まれています。 FCNは、ホストによってアクセスコンセントレータに与えられた最初のクレジットを提供します。 BCNの値が0に設定されています。
An example packet is shown in Appendix B.
例えば、パケットは、付録Bに示されています
The PADS packet is extended to optionally contain a single Credit Tag TLV, indicating the Forward Credit Notification (FCN) and the Backward Credit Notification (BCN) of the PPP Session Stage.
PADSパケットは、必要に応じて転送クレジット通知（FCN）とPPPセッションステージの後方へのクレジット通知（BCN）を示す、単一のクレジットタグTLVを含むように拡張されます。
If the PADR contained a Credit Tag, then the Access Concentrator PADS packet indicates support for credit flow control by including a Credit Tag. The PADS Credit Tag FCN represents the number of credits being initially granted to the Host. The Credit Tag BCN is an echo of the number of credits that the Host had granted to the Access Concentrator in the previous PADR packet.
PADRは、クレジットタグが含まれている場合、アクセスコンセントレータPADSパケットは、クレジットタグを含めることで、クレジットフロー制御のサポートを示します。 PADSクレジットタグFCNは最初のホストに付与されたクレジットの数を表します。クレジットタグBCNは、ホストが前のPADRパケットにアクセスコンセントレータに付与されたクレジットの数のエコーです。
Exchange of the Credit Tag TLV in the PADR and PADS indicates that credit flow control is supported by both the Access Concentrator and the Host for the designated PPP Session Stage. This is binding and must be followed for the entire duration of the PPP Session Stage. A session's credit binding must be established prior to any other credit indications can be exchanged.
PADRとPADSでクレジットタグTLVの交換は信用フロー制御は、アクセスコンセントレータと指定されたPPPセッションステージのためのホストの両方でサポートされていることを示しています。これは、結合され、PPPセッションステージの全期間のために従わなければなりません。セッション・バインディングの信用は他の信用の適応症を交換することができる前に確立されなければなりません。
The Access Concentrator PADS should only carry the Credit Tag in response to a Host PADR with Credits. If the Access Concentrator does not support credit flow, it should not include the Credit Tag in its PADS response. The Host must terminate a credit-based session that cannot be supported by the Access Concentrator. Credit Tags transmitted outside an established credit based session must be ignored.
アクセスコンセントレータPADSはクレジットでホストPADRに応じてクレジットタグを運ぶ必要があります。アクセスコンセントレータは、信用の流れをサポートしていない場合、それはそのPADS応答にクレジットタグを含めるべきではありません。ホストがアクセスコンセントレータでサポートすることはできませんクレジットベースのセッションを終了する必要があります。設立されたクレジットベースのセッション外送信クレジットタグは無視されなければなりません。
An example packet is shown in Appendix B.
例えば、パケットは、付録Bに示されています
The PPPoE Active Discovery Session-Grant (PADG) is a new packet defined in this specification. An Access Concentrator or Host MAY send a PADG at any time after the PADR/PADS exchange to grant incremental flow control credits. The CODE field is set to 0x0A and the SESSION_ID must be set to the unique value generated for this PPPoE Session.
PPPoEのアクティブディスカバリセッション・グラント（PADG）は、この仕様で定義された新しいパケットです。アクセスコンセントレータまたはホストは、インクリメンタルフロー制御クレジットを付与するPADR / PADS交換した後、任意の時点でPADGを送信することができます。 CODEフィールドには、0x0Aのに設定され、SESSION_IDは、このPPPoEのセッションのために生成される一意の値に設定する必要があります。
The peer may then transmit data until the credits are exhausted.
クレジットが使い果たされるまで、ピアは、データを送信することができます。
When the peer receives a PADG packet, it adds the incremental credits to its working credit count and responds with a PPPoE Active Discovery Session-Credit (PADC) packet indicating the accumulated credits.
ピアはPADGパケットを受信すると、その作業のクレジット数に増分クレジットを追加し、蓄積されたクレジットを示すのPPPoEアクティブディスカバリーセッション・クレジット（PADC）パケットで応答します。
The PADG packet must contain a single Credit Tag TLV, indicating the Forward Credit Notification (FCN) and the Backward Credit Notification (BCN) of the PPP Session.
PADGパケットを転送するクレジット通知（FCN）とPPPセッションの後方クレジット通知（BCN）を示す、一つのクレジットタグTLVが含まれている必要があります。
The Credit Tag FCN indicates the number of incremental credits being granted to the peer by the node. A value between 1 and 0xffff represents an incremental credit grant. The peer must add these credits to its accumulated transmit credit count. A value of 0x0000 represents a NULL grant, meaning that there are no additional credits being granted.
クレジットタグFCNはノードによって、ピアに付与された増分クレジットの数を示します。 1と0xFFFFの間の値が増分クレジット許可を表します。ピアは、その蓄積された送信クレジット・カウントにこれらのクレジットを追加する必要があります。 0000の値が付与されている追加のクレジットが存在しないことを意味し、NULL許可を表します。
The Credit Tag BCN indicates the remaining absolute credits that have been granted by the peer to the node.
クレジットタグBCNは、ノードにピアによって付与されている残りの絶対クレジットを示します。
Once a credit has been granted, it must be honored. The largest number of outstanding credits at any time is 0xffff.
クレジットが付与されていたら、それは尊重されなければなりません。いつでも優れたクレジットの最大数が0xffffのです。
The PADG packet must contain a single Sequence Number Tag TLV. This tag is used to carry a unique 16-bit sequence number to uniquely identify each request. The sequence number should be initialized to zero and incremented by one for each new PADG. For retransmitted PADGs, the same sequence number that was used in the previous packet transmission is repeated.
PADGパケットは、単一のシーケンス番号タグTLVが含まれている必要があります。このタグは、一意の要求を識別するためのユニークな16ビットのシーケンス番号を運ぶために使用されます。シーケンス番号はゼロに初期化し、それぞれの新しいPADGに1つずつインクリメントされなければなりません。再送PADGsため、前のパケットの送信に用いたのと同じシーケンス番号が繰り返されます。
An example packet is shown in Appendix B.
例えば、パケットは、付録Bに示されています
The PPPoE Active Discovery Session-Credit Response (PADC) is a new packet defined in this specification. An Access Concentrator or Host must send a PADC in response to a PADG. The CODE field is set to
PPPoEのアクティブディスカバリセッションクレジット応答（PADC）は、この仕様で定義された新しいパケットです。アクセスコンセントレータまたはホストはPADGに応じてPADCを送信する必要があります。 CODEフィールドがに設定されています
0x0B, and the SESSION_ID must be set to the unique value generated for this PPPoE session.
0x0Bの、そしてSESSION_IDは、このPPPoEセッションのために生成されたユニークな値に設定する必要があります。
The PADC packet must contain a single Credit Tag TLV, indicating the Forward Credit Notification (FCN) and the Backward Credit Notification (BCN) of the PPPoE session, and any number of other Tag types.
PADCパケットが転送クレジット通知（FCN）及びPPPoEセッションの後方へのクレジット通知（BCN）、および他のタグタイプの任意の数を示す、単一のクレジットタグTLVを含んでいなければなりません。
The Credit Tag FCN represents the absolute credits remaining that have been granted to the peer by the node. The Credit Tag BCN represents the remaining absolute credits that have been granted to the node from the peer.
クレジットタグFCNはノードによって、ピアに付与されている残りの絶対クレジットを表します。クレジットタグBCNは、ピアからのノードに付与されている残りの絶対クレジットを表します。
The PADC packet must contain a single Sequence Number Tag. The sequence number must be the sequence number associated with the PADG.
PADCパケットは、単一のシーケンス番号のタグが含まれている必要があります。シーケンス番号はPADGに関連付けられたシーケンス番号でなければなりません。
An example packet is shown in Appendix B.
例えば、パケットは、付録Bに示されています
The PPPoE Active Discovery Quality (PADQ) is a new packet defined in this specification. An Access Concentrator or Host may send an optional PADQ at any time to query or report link quality metrics.
PPPoEのアクティブディスカバリ品質（PADQ）は、この仕様で定義された新しいパケットです。アクセスコンセントレータまたはホストを照会したり、リンク品質メトリックを報告するために、いつでも、オプションPADQを送信することができます。
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.
送信するときPPP [1]無線モデムを介して無線リンクを介してストリーム、RFリンクの品質は直接スループットに影響を与えます。 PPPoEのアクティブディスカバリ品質（PADQ）パケットは、RFリンクメトリックを報告するために無線モデムで使用することができます。 CODEフィールドは0x0Cのに設定され、SESSION_IDは、このPPPoEセッションのために生成されたユニークな値に設定する必要があります。
The PADQ must carry a single Metric Tag TYPE, which contains the following fields:
PADQは、次のフィールドを含む単一のメトリックタグタイプを運ぶ必要があります。
Receive only - a bit that indicates whether the link is bi-
directional or receive only. A value of -1- indicates that the
link is receive-only.
Maximum data rate - the maximum theoretical data rate, in kilobits per second (kbps), that the Host link is capable of providing. When metrics are reported, the maximum data rate must be reported.
最大データレート - 理論上の最大データレート、秒（kbps）あたりのキロビットで、ホストリンクが提供することが可能であること。メトリックが報告されている場合は、最大データレートが報告されなければなりません。
Current data rate - the current data rate, in kilobits per second (kbps), achieved on the Host link. If there is no distinction between maximum data rate and current data rate, current data rate should equal to the maximum data rate.
現在のデータレート - 現在のデータレートは、毎秒キロビット（kbps単位）で、ホストのリンクを実現しました。最大データレートと現在のデータレートとの間に区別が存在しない場合、現在のデータレートが最大データレートに等しくなければなりません。
Latency - the transmission delay that a packet encounters as it is transmitted over the Host link. This is reported in absolute delay, milliseconds. If latency cannot be calculated, a value of 0 should be reported.
待ち時間 - それはホストのリンクを介して送信されるパケットが発生した伝送遅延。これは絶対遅延、ミリ秒単位で報告されます。待ち時間が計算できない場合は、0の値が報告されるべきです。
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.
リソース - パーセント、0-100、例えばバッテリ電源として残るか、利用可能なリソースの量を表します。資源が計算できない場合は、100の値が報告されるべきです。
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.
相対リンク品質（RLQ） - 相対リンク品質を表す無次元数、0-100、。 100の値は、最高品質のリンクを表しています。 RLQが計算できない場合は、100の値が報告されるべきです。
The PPPoE Active Discovery Quality (PADQ) packet can be used to query link metrics by setting the PADQ Metric Tag Length to zero.
PPPoEのアクティブディスカバリ品質（PADQ）パケットがゼロにPADQメトリックタグの長さを設定することにより、リンクメトリックを照会するために使用することができます。
An example packet is shown in Appendix B.
例えば、パケットは、付録Bに示されています
This specification defines the optional use of TLV Tags in the PPP Session Stage. The first field following the PPP Session Stage LENGTH must be checked. If the value is equal to the PPP Protocol identifier (0xc021), then normal packet (payload) processing occurs. When the field following the PPP Session Stage LENGTH is not the PPP Protocol identifier (0xc021), a TLV is assumed. In this case, the Tag length is subtracted from the overall payload length.
この仕様は、PPPセッションステージにおけるTLVタグの任意の使用を定義します。 PPPセッションステージの長さを以下の最初のフィールドをチェックする必要があります。値はPPPプロトコル識別子（0xc021）に等しい場合、正常パケット（ペイロード）の処理が起こります。 PPPセッションステージの長さを以下のフィールドは、PPPプロトコル識別子（0xc021）でない場合は、TLVが想定されます。この場合、タグの長さは、全体のペイロード長から減算されます。
The Credit Tag is the only optional TLV permitted in the PPP Session Stage. The Credit Tag TLV is used to support in-band flow control.
クレジットタグは、PPPセッションステージで許可のみ、オプションのTLVです。クレジットタグTLVは、帯域内フロー制御をサポートするために使用されます。
A PPP Session Stage packet with Credits is shown in Appendix B.
クレジットでのPPPセッションステージパケットは付録Bに示されています
For a given session, credit grants exchanged in the Discovery Stage, PADG-PADC, are referred to as out-of-band. Credit grants exchanged in the PPP Session Stage are referred to as in-band. Credit processing is only applied to the packets transmitted in the PPP Session Stage.
特定のセッションのために、信用補助金はPADG-PADC、ディスカバリーステージで交換、アウトオブバンドと呼ばれています。 PPPセッションステージで交換信用補助金は、インバンドと呼ばれています。クレジット処理は、PPPセッションステージに送信されるパケットにのみ適用されます。
Out-of-band credit management is handled by periodic exchange of the PPPoE Active Discovery Grant (PADG) and PPPoE Active Discovery Credit (PADC) packets.
アウトオブバンドの与信管理は、PPPoEのアクティブディスカバリーグラント（PADG）およびPPPoEアクティブディスカバリークレジット（PADC）パケットの定期的な交換によって処理されます。
In-band credit management allows credits to be incrementally granted with each PPP Session Stage packet. These in-band incremental credit grants are not explicitly unacknowledged. However, they are reflected in the in-band credit flow from the peer node. This offers the greatest credit granting efficiency when traffic rates are high.
インバンド与信管理は、クレジットが漸増各PPPセッションステージのパケットを付与することができます。これらの帯域内の増分信用補助金は、明示的に認められていないではありません。しかし、それらは、ピア・ノードからのインバンド信用フローに反映されます。これは、トラフィックレートが高い最大の信用供与の効率を提供しています。
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.
ディスカバリーステージの間に合意したら、信用補助金は、PPPセッションステージでパケットを送信するために必要とされています。ピアが許可ノードにパケットを送信する前に、ノードは、そのピアにクレジットを付与しなければなりません。
Credits are granted incrementally in the forward direction. Locally, a node manages the credits that it has granted to a peer, as well as the credits that a peer has granted to it.
クレジットは順方向に漸増的に付与されます。ローカルで、ノードは、ピアに付与されたクレジットだけでなく、相手がそれに付与されたクレジットを管理します。
Grants received from a peer are added to a local running credit counter. The accumulated credits are decremented with each packet the node transmits to the peer. When the running counter reaches zero, the node stops transmitting packets to the peer. The values of the PADC are not simply an echo of the PADG. They represent the current internal FCN/BCN values of that node.
ピアから受け取った補助金は、地元のランニングのクレジットカウンタに加算されます。蓄積されたクレジットは、ノードがピアに送信する各パケットにデクリメントされます。ランニングカウンタがゼロに達すると、ノードは、ピアにパケットの送信を停止します。 PADCの値は、単にPADGのエコーではありません。彼らは、そのノードの現在の内部FCN / BCN値を表します。
To manage the credits that a node has granted, the node maintains a running counter. With each PPP Session Stage packet received from the peer, the running counter is decremented. When the running counter reaches zero, no additional packets are expected. The node incrementally grants more credits to the peer to maintain packet flow. Packets received when granted credits that have been exhausted are discarded.
ノードが与えたクレジットを管理するには、ノードが実行されているカウンタを維持します。各PPPセッションステージパケットがピアから受信すると、実行中のカウンタがデクリメントされます。ランニングカウンタがゼロに達すると、追加のパケットが期待されていません。ノードは、インクリメンタルパケットフローを維持するために、ピアにクレジットを付与します。破棄され尽くされているクレジットを付与されたとき、パケットを受信しました。
The largest possible credit limit is 0x0ffff. If an incremental credit grant causes the accumulated count to exceed this value, the max value is used.
可能な限り最大の信用限度は0x0ffffです。インクリメンタルクレジットグラントがこの値を超えて累積カウントが発生した場合は、最大値が使用されます。
One unit of credit represents 64-bytes, so a grant of 4 credits translates to 256 bytes.
クレジットの1つの単位は、64バイトを表し、SO 4つのクレジットの許可は256バイトに変換します。
When a node does not receive a PADC packet in response to a PADG within a specified amount of time, it should transmit a new PADG packet with zero credits, using the same sequence number and double the waiting period. A PADC response with the associated sequence number will indicate whether or not the previously granted credits were accumulated. If they were not, a PADG with credits, with an incremented sequence number, should be transmitted. This process should be repeated until granted credits are properly acknowledged or as many times as desired.
ノードが指定した時間内にPADGに応じてPADCパケットを受信しない場合は、同じシーケンス番号を使用して、ゼロクレジットで新しいPADGパケットを送信し、待機期間を倍にする必要があります。関連するシーケンス番号とPADC応答が以前に付与されたクレジットが蓄積されたかどうかを示します。彼らがいなかった場合は、クレジットとPADGは、インクリメントされたシーケンス番号と、送信されなければなりません。必要に応じて付与されたクレジットが適切に認めたり何度でもされるまで、このプロセスが繰り返されるべきです。
When a node does not receive a PADQ metric packet within a specified amount of time, it should resend the PADQ query packet and double the waiting period. This can be repeated as many times as desired.
ノードが指定した時間内にPADQメトリックパケットを受信しない場合は、PADQ問い合わせパケットを再送し、待機期間を倍にする必要があります。必要に応じて、これは何度でも繰り返すことができます。
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.
ノードが自律的にPADQメトリックパケットを生成することができます。ピアをオーバーランしないように自律的に生成PADQメトリックパケットのレートが絞られる必要があり得ます。
The sending and receiving of PPPoE control packets are independent of credit counts. For example, a node must always be able to receive a PADG and send a PADC.
送信およびPPPoE制御パケットの受信クレジット数とは無関係です。例えば、ノードは常にPADGを受け取り、PADCを送ることができなければなりません。
During normal operation, nodes may disagree about the number of credits. Operational credit mismatches would occur due to packets in transit on the wire. Much larger credit mismatches can occur if there are transmission errors. To correct these larger errors, the BCN fields of the PADG and PADC packets and in-band credit grants from a peer should be used by the receiving node to set the credit values of its peer.
通常動作時には、ノードは、クレジットの数については同意しないことがあります。オペレーショナル信用のミスマッチは、ワイヤ上の輸送中のパケットのために発生します。伝送エラーがある場合、非常に大きな信用の不一致が発生する可能性があります。これらの大きなエラーを修正するために、ピアからPADGとPADCパケットと帯域内のクレジット付与のBCNフィールドは、ピアのクレジット値を設定するために、受信ノードによって使用されるべきです。
IANA has assigned the following PPPoE TAG Values as noted in [3]:
[3]で述べたようにIANAは、次のPPPoEタグ値を割り当てました。
TAG Value TAG Name Tag Description Reference
----------- ------------------- --------------------- ---------
262 0x0106 Credits See the reference [RFC4938]
263 0x0107 Metrics See the reference [RFC4938]
264 0x0108 Sequence Number See the reference [RFC4938]
IANA has assigned the following PPPoE Code fields as noted in [3]:
[3]で述べたようにIANAは、次のPPPoEコードフィールドを割り当てました。
Code PPPoE Packet Name Description Reference
-------- ----------------------------- ----------------- ---------
10 0x0a PADG, Session-Grant See the reference [RFC4938]
11 0x0b PADC, Session-Credit Response See the reference [RFC4938]
12 0x0c PADQ, Quality See the reference [RFC4938]
This memo defines a mechanism for adding flow control to the existing PPP Over Ethernet (PPPoE) sessions. These extensions are subsequent to the existing PPPoE security mechanisms as described in RFC 2516 [2]. It is required that the Service Tag and Session ID always be validated prior to processing credits.
このメモは、既存のPPPオーバーイーサネット（PPPoEの）セッションにフロー制御を追加するためのメカニズムを定義します。これらの拡張は、RFC 2516に記載されているように、既存のPPPoEセキュリティ機構に続いている[2]。サービスタグとセッションIDは、常に前処理クレジットに検証する必要があります。
Appendix A: Tag Values
付録A：タグ値
Feature Tag_Types and Tag_Values
フィーチャーTag_TypesとTag_Values
0x0106 Credits
0x0106クレジット
This tag contains the Forward Credit Notification (FCN) and the Backward Credit Notification (BCN). The Credit Tag TLV is OPTIONAL with the PADR, PADS, and the PPPoE data payload packet (ETHER_TYPE=8864).
このタグは、フォワードクレジット通知（FCN）と後方クレジット通知（BCN）が含まれています。クレジットタグTLVはPADR、PADS、およびPPPoEデータペイロードパケット（ETHER_TYPE = 8864）と、任意です。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag Type = 0x0106 | Tag Length=0x04 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FCN | BCN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0x0107 Metrics
0x0107メトリック
This tag is used to report the link quality and performance. The Metrics Tag TLV contains the Receive Only indicator, Resource status, Latency, Relative Link Quality (RLQ), Current data rate, and Maximum data rate. The Metrics TLV is required by the PADQ packet.
このタグは、リンク品質とパフォーマンスを報告するために使用されます。メトリックタグTLVは受信のみインジケータ、リソース状況、待ち時間、相対リンク品質（RLQ）、現在のデータ・レート、および最大データレートが含まれています。メトリックTLVはPADQパケットによって必要とされます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag Type = 0x0107 | Tag Length=0x0A |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |R| RLQ | Resource |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Latency (MS) | Current Datarate (kbps) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Datarate (kbps) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0x0108 Sequence Number
0x0108シーケンス番号
This tag is used to carry a unique 16-bit sequence number in order to identify a specific request and the associated response. The sequence number should be initialized to zero and incremented by one for each new request. For retransmitted packets, the same sequence number that was used in the previous packet transmission is repeated. The PADG and PADC packets require the Sequence Number Tag.
このタグは、特定の要求および関連する応答を識別するためにユニークな16ビットのシーケンス番号を運ぶために使用されます。シーケンス番号はゼロに初期化し、それぞれの新しい要求に1つずつインクリメントされなければなりません。再送パケットは、以前のパケットの送信に使用されたのと同じシーケンス番号が繰り返されます。 PADGとPADCパケットは、シーケンス番号のタグが必要です。
For example, the sequence number sent in the PADG request is echoed in the PADC response. This ties a specific PADC response to a specific PADG request.
例えば、PADG要求で送信されたシーケンス番号がPADC応答にエコーされます。これは、特定のPADG要求に固有のPADC応答を結び付けます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag Type = 0x0108 | Tag Length=0x02 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Appendix B: Example Message Formats
付録B：例メッセージ形式
A PADR packet with OPTIONAL Credit Tag Type 0x0106:
オプションクレジットタグタイプ0x0106とPADRパケット：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access_Concentrator_mac_addr |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Access_Concentrator_mac_addr(c)| Host_mac_addr |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Host_mac_addr (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ETHER_TYPE = 0x8863 | v = 1 | t = 1 | CODE = 0x19 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SESSION_ID = 0x1234 | LENGTH = 0x0C |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag Type = 0x0101 | Tag Length=0x00 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag Type = 0x0106 | Tag Length=0x04 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FCN | BCN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A PADS packet with OPTIONAL Credit Tag Type 0x0106:
オプションクレジットタグタイプ0x0106とPADSパケット：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access_Concentrator_mac_addr |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Access_Concentrator_mac_addr(c)| Host_mac_addr |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Host_mac_addr (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ETHER_TYPE = 0x8863 | v = 1 | t = 1 | CODE = 0x65 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SESSION_ID = 0x1234 | LENGTH = 0x0C |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag Type = 0x0101 | Tag Length=0x00 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag Type = 0x0106 | Tag Length=0x04 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FCN | BCN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A PADG packet with Credit Tag Type 0x0106:
クレジットタグタイプ0x0106とPADGパケット：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination_mac_addr |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination_mac_addr(c) | Source_mac_addr |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source mac_addr (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ETHER_TYPE = 0x8863 | v = 1 | t = 1 | CODE = 0x0A |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SESSION_ID = 0x1234 | LENGTH = 0x0E |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag Type = 0x0108 | Tag Length=0x02 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number | Tag Type = 0x0106 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag Length=0x04 | FCN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BCN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A PADC packet with Credit Tag Type 0x0106:
クレジットタグタイプ0x0106とPADCパケット：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination_mac_addr |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination_mac_addr(c) | Source_mac_addr |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source mac_addr (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ETHER_TYPE = 0x8863 | v = 1 | t = 1 | CODE = 0x0B |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SESSION_ID = 0x1234 | LENGTH = 0x0E |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag Type = 0x0108 | Tag Length=0x02 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number | Tag Type = 0x0106 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag Length=0x04 | FCN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BCN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A PADQ packet to query for the link metrics: This is indicated by the Metric Tag Length=0.
PADQパケットは、リンクメトリックを照会するには：これは、メトリックタグの長さ= 0で示されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access_Concentrator_mac_addr |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Access_Concentrator_mac_addr(c)| Host_mac_addr |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Host_mac_addr (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ETHER_TYPE = 0x8863 | v = 1 | t = 1 | CODE = 0x0C |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SESSION_ID = 0x1234 | LENGTH = 0x08 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag Type = 0x0101 | Tag Length=0x00 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag Type = 0x0107 | Tag Length=0x00 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A PADQ packet with Metric Tag Type 0x0107:
メトリックタグタイプ0x0107とPADQパケット：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access_Concentrator_mac_addr |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Access_Concentrator_mac_addr(c)| Host_mac_addr |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Host_mac_addr (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ETHER_TYPE = 0x8863 | v = 1 | t = 1 | CODE = 0x0C |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SESSION_ID = 0x1234 | LENGTH = 0x12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag Type = 0x0101 | Tag Length=0x00 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag Type = 0x0107 | Tag Length=0x0A |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |R| RLQ | Resource |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Latency (MS) | Current Datarate (kbps) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Datarate (kbps) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A PPP LCP packet with optional Credit Tag Type 0x0106:
オプションのクレジットタグタイプ0x0106でPPP LCPパケット：
While the PPP protocol value is shown (0xc021), the PPP payload is left to the reader. This is a packet from the Host to the Access Concentrator.
PPPプロトコル値（0xc021）が示されているが、PPPペイロードは読者に任されています。これは、アクセスコンセントレータへのホストからのパケットです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access_Concentrator_mac_addr |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Access_Concentrator_mac_addr(c)| Host_mac_addr |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Host_mac_addr (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ETHER_TYPE = 0x8864 | v = 1 | t = 1 | CODE = 0x00 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SESSION_ID = 0x1234 | LENGTH = (payload) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag Type = 0x0106 | Tag Length=0x04 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FCN | BCN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PPP PROTOCOL = 0xc021 | PPP payload ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Acknowledgements
謝辞
The authors would like to acknowledge the influence and contributions from Billy Moon, Fred Baker, Stan Ratliff, and Ed Paradise.
著者はビリー・ムーン、フレッド・ベイカー、スタンRatliff、とエド・パラダイスからの影響と貢献を認めたいと思います。
Normative References
引用規格
[1] Simpson, W., Ed., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[1]シンプソン、W.、編、 "ポイントツーポイントプロトコル（PPP）"、STD 51、RFC 1661、1994年7月。
[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.
[2] Mamakos、L.、Lidlの、K.、Evarts、J.、カレル、D.、シモン、D.、およびR.ウィーラー、 "PPPオーバーイーサネット（PPPoEを）送信するための方法"、RFC 2516年2月1999。
[3] Arberg, P. and V. Mammoliti, "IANA Considerations for PPP over Ethernet (PPPoE)", RFC 4937, June 2007.
[3]アーベルク、P.およびV. Mammoliti、 "イーサネット上のPPPのためのIANAの考慮事項（PPPoEの）"、RFC 4937、2007年6月。
Authors' Addresses
著者のアドレス
Bo Berry Cisco 170 West Tasman Drive San Jose, CA 95134 USA EMail: bberry@cisco.com
ボー・ベリーのCisco 170西タスマン・ドライブサンノゼ、CA 95134 USA電子メール：bberry@cisco.com
Howard Holgate Cisco 170 West Tasman Drive San Jose, CA 95134 USA EMail: hholgate@cisco.com
ハワードホルゲートシスコ170西タスマン・ドライブサンノゼ、CA 95134 USA電子メール：hholgate@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（2007）。
This document is subject to the rights, licenses and restrictions contained in BCP 78 and at www.rfc-editor.org/copyright.html, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に及びwww.rfc-editor.org/copyright.htmlに含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
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.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78および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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンライン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.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。