[要約] RFC 4938は、PPP Over Ethernet（PPPoE）の拡張であり、クレジットフローとリンクメトリックスに関する情報を提供します。このRFCの目的は、PPPoEセッションの信用フローとリンクのパフォーマンスを向上させるための仕組みを提供することです。
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
クレジットフローとリンクメトリックのためのイーサネット（PPPOE）拡張機能
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）The IETF Trust（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.
PPP Over Ethernet（PPPOE）[2]は、PPP [1]のトラフィックアグリゲーター（アクセス濃縮器）間のセッションを確立およびカプセル化するためのプロトコルであり、実際のイーサネットまたはエミュレーションイーサネットを介して輸送します。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）セッションを確立し、トランスミッションシステムの関連アクセス濃縮器（Router）を使用して、各隣接に対応するPPPOEセッションを確立します。ラジオは、PPPOEセッションを対応するRLPセッションと論理的に関連付けます。
+--------+ +-------+ +-------+ +--------+
| 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.
上の図では、Access Concencoratorの観点から、それとホストラジオとの間の各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.
イーサネットペイロードバージョンフィールドは、0x01の値を保持します。クレジットフロー制御とリンク品質メトリックの拡張機能は、オプションであり、後方互換性があります。
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には2つの異なる段階があります。ディスカバリーステージとPPPセッションステージがあります。発見段階では、ホストはオプションでフロー制御されたPPPセッションステージを要求できます。Access Concentorがホストフロー制御要求を認めたら、すべての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）パケットの仕様は、オプションのクレジットタグタイプ長価値（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は、ホストによってAccess Concencoratorに付与された初期クレジットを提供します。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パケットは、オプションで単一のクレジットタグTLVを含むように拡張されており、PPPセッションステージのフォワードクレジット通知（FCN）と後方クレジット通知（BCN）を示します。
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クレジットタグ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.
アクセスコンセントレーターパッドは、クレジットを備えたホストPADRに応じてクレジットタグのみを搭載する必要があります。Access Concentorがクレジットフローをサポートしていない場合、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 Active Discovery Session-Grant（PADG）は、この仕様で定義された新しいパケットです。アクセスコンセントレーターまたはホストは、PADR/PADSの交換後、いつでもPADGを送信して、インクリメンタルフロー制御クレジットを付与できます。コードフィールドは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 Active Discovery-Credit（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パケットには、単一のクレジットタグTLVを含める必要があり、PPPセッションのフォワードクレジット通知（FCN）と後方クレジット通知（BCN）を示しています。
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の値は、増分クレジット助成金を表します。ピアは、これらのクレジットを蓄積された送信クレジットカウントに追加する必要があります。0x0000の値はヌル助成金を表します。つまり、付与される追加のクレジットはありません。
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ビットシーケンス番号を運ぶために使用されます。シーケンス番号はゼロに初期化し、新しいパッドごとに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 0x0B, and the SESSION_ID must be set to the unique value generated for this PPPoE session.
PPPOEアクティブディスカバリーセッションクレジット応答（PADC）は、この仕様で定義された新しいパケットです。アクセスコンセントレーターまたはホストは、PADGに応じてPADCを送信する必要があります。コードフィールドは0x0Bに設定されており、このPPPOEセッションで生成された一意の値にセッション_IDを設定する必要があります。
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パケットには、単一のクレジットタグTLVを含む必要があります。これは、PPPOEセッションのフォワードクレジット通知（FCN）と後方クレジット通知（BCN）、および他の数のタグタイプを示す必要があります。
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 Active Discovery Quality（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 Active Discovery Quality（PADQ）パケットは、RADIOモデムでRFリンクメトリックを報告するために使用できます。コードフィールドは0x0Cに設定されており、このPPPOEセッションで生成された一意の値にセッション_IDを設定する必要があります。
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.
受信 - リンクが双方向であるか受信しているかを示すビット。-1-の値は、リンクが受信のみであることを示します。
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.
現在のデータレート-1秒あたりのキロビット（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 Active Discovery Quality（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 Active Discovery Grant（PADG）およびPPPOE Active Discovery Credit（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バイトを表すため、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パケットを送信し、待機期間を2倍にする必要があります。関連するシーケンス番号を使用したPADC応答は、以前に付与されたクレジットが蓄積されたかどうかを示します。そうでない場合は、シーケンス番号を増やしたクレジットのあるパッジを送信する必要があります。このプロセスは、付与されたクレジットが適切に認められるか、何度も望ましいとおりに繰り返される必要があります。
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クエリパケットを再送信し、待機期間を2倍にする必要があります。これは、必要なだけ繰り返すことができます。
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]:
IANAは、[3]に記載されているように、次の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]:
IANAは、[3]に記載されているように、次の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 [2]で説明されているように、既存のPPPOEセキュリティメカニズムに続きます。クレジットを処理する前に、サービスタグとセッション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、パッド、および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応答にエコーされます。これにより、特定のPADC応答が特定の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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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:
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:
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:
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:
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.
著者は、ビリー・ムーン、フレッド・ベイカー、スタン・ラトリフ、エド・パラダイスからの影響力と貢献を認めたいと考えています。
Normative References
引用文献
[1] Simpson, W., Ed., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[1] Simpson、W.、ed。、「ポイントツーポイントプロトコル（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.、Carrel、D.、Simone、D。、およびR. Wheeler、「PPPを超える（PPPOE）を送信する方法」、RFC 2516、1999年2月。
[3] Arberg, P. and V. Mammoliti, "IANA Considerations for PPP over Ethernet (PPPoE)", RFC 4937, June 2007.
[3] Arberg、P。and V. Mammoliti、「イーサネット上のPPP（PPPOE）に関するIANAの考慮事項」、RFC 4937、2007年6月。
Authors' Addresses
著者のアドレス
Bo Berry Cisco 170 West Tasman Drive San Jose, CA 95134 USA EMail: bberry@cisco.com
Bo Berry Cisco 170 West Tasman Drive San Jose、CA 95134 USAメール：bberry@cisco.com
Howard Holgate Cisco 170 West Tasman Drive San Jose, CA 95134 USA EMail: hholgate@cisco.com
ハワード・ホルゲート・シスコ170ウェストタスマンドライブサンノゼ、カリフォルニア95134 USAメール：hholgate@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。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エディター機能の資金は現在、インターネット協会によって提供されています。