RFC4938 日本語訳
4938 PPP Over Ethernet (PPPoE) Extensions for Credit Flow and LinkMetrics. B. Berry, H. Holgate. June 2007. (Format: TXT=38288 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group B. Berry
Request for Comments: 4938 H. Holgate
Category: Informational Cisco Systems,Inc.
June 2007
コメントを求めるワーキンググループB.ベリー要求をネットワークでつないでください: 4938時間Holgateカテゴリ: 情報のシスコシステムズ、株式会社2007年6月
PPP Over Ethernet (PPPoE) Extensions
for Credit Flow and Link Metrics
クレジット流動とリンク測定基準のためのイーサネット(PPPoE)拡大の上のppp
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).
IETFが信じる著作権(C)(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 Extensions作業部会(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)プロトコルの上でクレジットベースのフロー制御メカニズムとLink Quality MetricレポートでPointからポイントを広げています。 この任意の拡大はメディアの上で可変帯域幅と限られたバッファリングでPPPoEの性能を向上させるべきです、移動無線リンクなどのように。
Berry & Holgate Informational [Page 1] RFC 4938 PPPoE with Credit Flow and Metrics June 2007
クレジット流動があるベリーとHolgateの情報[1ページ]のRFC4938PPPoEと測定基準2007年6月
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
1. 序論…2 2. 有効搭載量…3 3. プロトコル拡大の概観…3 4. 発見ステージ…3 4.1. PPPoEの活発な発見要求(PADR)…4 4.2. PPPoEの活発な発見セッション確認(パッド)…4 4.3. PPPoEのアクティブな発見セッション交付金(PADG)…5 4.4. PPPoEの活発な発見セッションクレジット応答(PADC)…5 4.5. PPPoEのアクティブな発見品質(PADQ)…6 5. pppセッションステージ…7 6. 流れ問題を掛けてください…7 7. PADGとPADC Retransmission…8 8. 他の問題…9 9. IANA問題…9 10. セキュリティ問題…9 付録A: 値にタグ付けをしてください…10 付録B: 例のメッセージ・フォーマット…11の承認…15 標準の参照…15
1. Introduction
1. 序論
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)[2]の上のPPPはPPP[1]のためのホストと交通アグリゲータ(アクセスConcentrators)とのセッションが本当の、または、見習われたイーサネットの上で輸送する設立と要約のためのプロトコルです。 両方のセッション終点に同様の帯域幅があるとき、時間がたつにつれて異ならない能力を進めて、バッファリングして、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セッションはアクセス集中装置(ルータ)とラジオ隣人として見せられるラジオ伝動装置の間で使用されます。 それぞれのラジオ伝動装置は、隣人と共に二地点間Radio Linkプロトコル(RLP)セッションを確立して、各隣人のために伝動装置の関連アクセス集中装置(ルータ)で対応するPPPoEセッションを確立します。 ラジオは対応するRLPセッションとのPPPoEセッションを論理的に関連づけます。
Berry & Holgate Informational [Page 2] RFC 4938 PPPoE with Credit Flow and Metrics June 2007
クレジット流動があるベリーとHolgateの情報[2ページ]のRFC4938PPPoEと測定基準2007年6月
+--------+ +-------+ +-------+ +--------+
| Access | | Host | | Host | | Access |
| Conc. |=======| Radio |~~~~~~~| Radio |=======| Conc. |
+--------+ +-------+ +-------+ +--------+
| | | | | |
|-PPPoE-| |--RLP--| |-PPPoE-|
| |
|-------------PPP Session---------------|
+--------+ +-------+ +-------+ +--------+ | アクセス| | ホスト| | ホスト| | アクセス| | Conc。 |=======| ラジオ|~~~~~~~| ラジオ|=======| Conc。 | +--------+ +-------+ +-------+ +--------+ | | | | | | |-PPPoE| |--RLP--| |-PPPoE| | | |-------------pppセッション---------------|
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リンクの能力は時間がたつにつれて、移動性と環境条件のため異なるかもしれません。 多くの例では、Host Radioは、RLPセッションのときに能力をバッファリングするのをハンドル容量変化に制限しました。 Host Radioでのバッファリングを制限するために、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.
アクセス集中装置の見解からのそれとHost RadioとのそれぞれのPPPoEセッションを超えたダイヤグラムで、リモート発送可能同輩に接続の代理をしてください。 効率的なルーティングのために、地方のHost Radioはダイナミックに関連リンクのアクセス集中装置ルート費用をアップデートするリンクのメートル法のメカニズムを使用します。
While the example shows an RF-based application, the extensions are applicable to other media.
例はRFベースのアプリケーションを示していますが、拡大は他のメディアに適切です。
2. Payload
2. 有効搭載量
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の値を保有します。 クレジットフロー制御とリンク品質測定基準のための拡大は後方に任意です。互換性がある。
3. Overview of Protocol Extensions
3. プロトコル拡大の概観
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つの異なったステージがあります。 ディスカバリーStageとPPP Session Stageがあります。 ディスカバリーStageの間、Hostは、流れがPPP Session Stageを制御したよう任意に要求できます。 Access ConcentratorがいったんHostフロー制御要求を承諾すると、すべてのPPP Session Stage交通は制御された流れであるに違いありません。
4. Discovery Stage
4. 発見ステージ
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).
ディスカバリーStageのパケット交換はこの仕様で変わりがありません。 Session Request(PADR)の仕様とSession Confirmation(PADS)パケットは、任意のCredit Tag Type長さの価値(TLV)を含むように広げられます。
Berry & Holgate Informational [Page 3] RFC 4938 PPPoE with Credit Flow and Metrics June 2007
クレジット流動があるベリーとHolgateの情報[3ページ]のRFC4938PPPoEと測定基準2007年6月
In addition, the optional Credit Grant (PADG) packet, the Credit Response (PADC) packet, and the Link Quality Metric (PADQ) packets are introduced.
さらに、任意のCreditグラント(PADG)パケット、Credit Response(PADC)パケット、およびLink Quality Metric(PADQ)パケットを導入します。
4.1. PPPoE Active Discovery Request (PADR)
4.1. PPPoEの活発な発見要求(PADR)
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パケットは任意に独身のCredit Tag TLVを含むように広げられます、Hostがこのセッションのためのクレジットフロー制御を要求するのを示して。 Credit TagはPPP Session Stageに適用されるべきForward Credit Notification(FCN)とBackward Credit Notification(BCN)を含んでいます。 FCNはHostによってAccess Concentratorに与えられた初期のクレジットを提供します。 BCN値は0に設定されます。
An example packet is shown in Appendix B.
例のパケットはAppendix Bで見せられます。
4.2. PPPoE Active Discovery Session-confirmation (PADS)
4.2. PPPoEの活発な発見セッション確認(パッド)
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パケットは任意に独身のCredit Tag TLVを含むように広げられます、Forward Credit Notification(FCN)とPPP Session StageのBackward Credit Notification(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がCredit Tagを含んだなら、Access Concentrator PADSパケットは、Credit Tagを含んでいることによって、クレジットフロー制御のサポートを示します。 PADS Credit Tag FCNは初めはHostに与えられるクレジットの数を表します。 Credit Tag BCNはHostが前のPADRパケットのAccess Concentratorに与えたクレジットの数のエコーです。
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のCredit Tag TLVの交換は、クレジットフロー制御が指定されたPPP Session StageのためにAccess ConcentratorとHostの両方によって支持されるのを示します。 これを拘束力があって、PPP Session Stageの全体の持続時間のために続かなければなりません。 セッションのクレジット結合はいかなる他のクレジットの前にも設立されて、指摘を交換できるということであるに違いありません。
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.
Access Concentrator PADSはCreditsとHost PADRに対応してCredit Tagを運ぶだけであるはずです。 Access Concentratorがクレジット流動を支持しないなら、それはPADS応答にCredit Tagを含むべきではありません。 HostはAccess Concentratorが支持できないクレジットベースのセッションを終えなければなりません。 確立したクレジットベースのセッションのときに伝えられたクレジットTagsを無視しなければなりません。
An example packet is shown in Appendix B.
例のパケットはAppendix Bで見せられます。
Berry & Holgate Informational [Page 4] RFC 4938 PPPoE with Credit Flow and Metrics June 2007
クレジット流動があるベリーとHolgateの情報[4ページ]のRFC4938PPPoEと測定基準2007年6月
4.3. PPPoE Active Discovery Session-Grant (PADG)
4.3. PPPoEのアクティブな発見セッション交付金(PADG)
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ディスカバリーSession-交付金(PADG)はこの仕様に基づき定義された新しいパケットです。 Access ConcentratorかHostが、PADR/PADS交換の後にいつでも、増加のフロー制御クレジットを与えるためにPADGを送るかもしれません。 CODE分野は0x0Aに設定されます、そして、このPPPoE Sessionのために発生するユニークな値にSESSION_IDを設定しなければなりません。
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ディスカバリーSession-クレジット(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パケットは独身のCredit Tag TLVを含まなければなりません、Forward Credit Notification(FCN)とPPP SessionのBackward Credit Notification(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.
Credit Tag FCNはノードによって同輩に与えられる増加のクレジットの数を示します。 1と0xffffの間の値は増加のクレジット交付金を表します。 それは蓄積されました。同輩がこれらのクレジットを加えなければならない、クレジットカウントを伝えてください。 与えられるどんな追加クレジットもないことを意味して、0×0000の値はNULL交付金を表します。
The Credit Tag BCN indicates the remaining absolute credits that have been granted by the peer to the node.
Credit Tag 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パケットは独身のSequence Number Tag TLVを含まなければなりません。 このタグは、唯一各要求を特定するためにユニークな16ビットの一連番号を運ぶのに使用されます。 一連番号は、それぞれの新しいPADGのためにゼロに初期化されて、1つ増加されるべきです。 再送されたPADGsに関しては、前のパケット伝送で使用されたのと同じ一連番号は繰り返されます。
An example packet is shown in Appendix B.
例のパケットはAppendix Bで見せられます。
4.4. PPPoE Active Discovery Session-Credit Response (PADC)
4.4. PPPoEの活発な発見セッションクレジット応答(PADC)
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 ActiveディスカバリーSession-クレジットResponse(PADC)はこの仕様に基づき定義された新しいパケットです。 Access ConcentratorかHostがPADGに対応してPADCを送らなければなりません。 CODE分野は設定されます。
Berry & Holgate Informational [Page 5] RFC 4938 PPPoE with Credit Flow and Metrics June 2007
クレジット流動があるベリーとHolgateの情報[5ページ]のRFC4938PPPoEと測定基準2007年6月
0x0B, and the SESSION_ID must be set to the unique value generated for this PPPoE session.
0x0B、およびIDがこのPPPoEのために発生するユニークな値へのセットがセッションであったならそうしなければならないSESSION_。
The PADC packet must contain a single Credit Tag TLV, indicating the Forward Credit Notification (FCN) and the Backward Credit Notification (BCN) of the PPPoE session, and any number of other Tag types.
Forward Credit Notification(FCN)とPPPoEセッションのBackward Credit Notification(BCN)を示して、PADCパケットは独身のCredit Tag TLVを含まなければなりません、そして、他のいろいろなTagがタイプします。
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.
Credit Tag FCNはノードによって同輩に与えられた絶対クレジットの残りを表します。 Credit Tag BCNは同輩からノードに与えられた残っている絶対クレジットを表します。
The PADC packet must contain a single Sequence Number Tag. The sequence number must be the sequence number associated with the PADG.
PADCパケットは独身のSequence Number Tagを含まなければなりません。 一連番号はPADGに関連している一連番号であるに違いありません。
An example packet is shown in Appendix B.
例のパケットはAppendix Bで見せられます。
4.5. PPPoE Active Discovery Quality (PADQ)
4.5. PPPoEのアクティブな発見品質(PADQ)
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ディスカバリーQuality(PADQ)はこの仕様に基づき定義された新しいパケットです。 Access ConcentratorかHostが質問する何時でもレポートリンクの任意の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ディスカバリーQuality(PADQ)パケットはラジオモデムによって使用されて、RFが測定基準をリンクすると報告できます。 CODE分野は0x0Cに設定されます、そして、このPPPoEセッションのために発生するユニークな値にSESSION_IDを設定しなければなりません。
The PADQ must carry a single Metric Tag TYPE, which contains the following fields:
PADQは独身のMetric Tag TYPEを運ばなければなりません:(Metric Tag TYPEは以下の分野を含みます)。
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.
それを単に、少し受けてください。リンクが2方向上であるか、または受信専用であるかを示します。 -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.
最大のデータ信号速度--2番目の(キロビット毎秒)あたりのキロビットにおけるHostがリンクする最大の理論上のデータ信号速度は提供できます。 測定基準が報告されるとき、最大のデータ信号速度を報告しなければなりません。
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.
現在のデータ信号速度--キロビットにおけるHostで達成された2番目の(キロビット毎秒)あたりの現在のデータ信号速度に、リンクしてください。 最大のデータ信号速度と現在のデータ信号速度の間には、区別が全くなければ、現在のデータ信号速度は最大のデータ信号速度と等しくあるべきです。
Berry & Holgate Informational [Page 6] RFC 4938 PPPoE with Credit Flow and Metrics June 2007
クレジット流動があるベリーとHolgateの情報[6ページ]のRFC4938PPPoEと測定基準2007年6月
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.
潜在--パケットがそれとして遭遇するトランスミッション遅れはHostリンクの上に伝えられます。 これは絶対遅延、ミリセカンドで報告されます。 潜在について計算できないなら、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.
親類Link Quality(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.
ゼロにPADQ Metric Tag Lengthを設定することによってリンク測定基準について質問するのにPPPoE ActiveディスカバリーQuality(PADQ)パケットを使用できます。
An example packet is shown in Appendix B.
例のパケットはAppendix Bで見せられます。
5. PPP Session Stage
5. pppセッションステージ
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 Session StageにおけるTLV Tagsの任意の使用を定義します。 PPP Session Stage LENGTHに続く最初の分野をチェックしなければなりません。 値がPPPプロトコル識別子(0xc021)と等しいなら、通常のパケット(ペイロード)処理は起こります。 PPP Session Stage LENGTHに続く分野がPPPプロトコル識別子(0xc021)でないときに、TLVは想定されます。 この場合、Tagの長さは総合的なペイロード長から引き算されます。
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.
Credit TagはPPP Session Stageで受入れられた唯一の任意のTLVです。 Credit Tag TLVは、バンドにおけるフロー制御を支持するのに使用されます。
A PPP Session Stage packet with Credits is shown in Appendix B.
CreditsがあるPPP Session StageパケットはAppendix Bで見せられます。
6. Credit Flow Considerations
6. クレジット流れ問題
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.
与えられたセッションについて、バンドの外にStage(PADG-PADC)が呼ばれるディスカバリーで交換された交付金を掛けてください。 PPP Session Stageで交換されたクレジット交付金はバンドのように参照されます。 クレジット処理はPPP Session Stageで伝えられたパケットに適用されるだけです。
Out-of-band credit management is handled by periodic exchange of the PPPoE Active Discovery Grant (PADG) and PPPoE Active Discovery Credit (PADC) packets.
バンドの外では、クレジット管理はPPPoE Active Discoveryグラント(PADG)とPPPoE ActiveディスカバリーCredit(PADC)パケットの周期的な交換で扱われます。
Berry & Holgate Informational [Page 7] RFC 4938 PPPoE with Credit Flow and Metrics June 2007
クレジット流動があるベリーとHolgateの情報[7ページ]のRFC4938PPPoEと測定基準2007年6月
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 Session Stageパケットと共に増加して与えるためにつけで売ります。 バンドにおけるこれらの増加のクレジット交付金は明らかに認められなくはありません。 しかしながら、それらは同輩ノードからのバンドでのクレジット流動に反映されます。 交通率が高いときに、これは最大級の信用供与効率を提供します。
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.
ディスカバリーStageの間、いったん同意されると、クレジット交付金が、PPP Session Stageでパケットを伝えるのに必要です。 同輩が与えるノードにパケットを伝えることができる前にノードは同輩に借款を供与しなければなりません。
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 Session Stageパケットを受け取っていて、走行カウンタは減少します。 走行カウンタがゼロに達するとき、どんな追加パケットも予想されません。 ノードは、パケット流動を維持するために、より多くのクレジットを同輩に増加して与えます。 消耗したクレジットを与えるとき受け取るパケットは捨てられます。
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バイトに翻訳されます。
7. PADG and PADC Retransmission
7. PADGとPADC Retransmission
When a node does not receive a PADC packet in response to a PADG within a specified amount of time, it should transmit a new PADG packet with zero credits, using the same sequence number and double the waiting period. A PADC response with the associated sequence number will indicate whether or not the previously granted credits were accumulated. If they were not, a PADG with credits, with an incremented sequence number, should be transmitted. This process should be repeated until granted credits are properly acknowledged or as many times as desired.
ノードが指定された時間以内のPADGに対応してPADCパケットを受けないとき、それはクレジットがなくて、同じ一連番号を使用して、待ちの期間の二重で新しいPADGパケットを伝えるべきです。 関連一連番号があるPADC応答は、以前に与えられたクレジットが蓄積されたかどうかを示すでしょう。 彼らがいないなら、クレジット、増加している一連番号があるPADGは伝えられるでしょうに。 与えられたクレジットが適切に承認されているか、または多くの倍必要になるまで、この過程は繰り返されるべきです。
Berry & Holgate Informational [Page 8] RFC 4938 PPPoE with Credit Flow and Metrics June 2007
クレジット流動があるベリーとHolgateの情報[8ページ]のRFC4938PPPoEと測定基準2007年6月
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質問パケットを再送して、待ちの期間を倍にするべきです。 必要な同じくらい何回もこれを繰り返すことができます。
8. Other Considerations
8. 他の問題
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分野は受信ノードによって使用されて、同輩のクレジット値を設定するべきです。
9. IANA Considerations
9. IANA問題
IANA has assigned the following PPPoE TAG Values as noted in [3]:
IANAは[3]に述べられるように以下のPPPoE TAG Valuesを割り当てました:
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]
タグ値のタグ名札記述参照----------- ------------------- --------------------- --------- 262 0×0106クレジットSee参照[RFC4938]263 0×0107Metrics See参照[RFC4938]264 0×0108Sequence Number Seeは参照です。[RFC4938]
IANA has assigned the following PPPoE Code fields as noted in [3]:
IANAは[3]に述べられるように以下のPPPoE Code分野を割り当てました:
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]
コードPPPoEパケット名前記述参照-------- ----------------------------- ----------------- --------- 10 0x0a PADG、See参照[RFC4938]11 0x0b PADC、Session-クレジットResponse See参照[RFC4938]12 0x0c PADQ、Quality Seeに参照をSession承諾してください。[RFC4938]
10. Security Considerations
10. セキュリティ問題
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 Overイーサネット(PPPoE)セッションにフロー制御を加えるためにメカニズムを定義します。 これらの拡大はRFC2516[2]で説明されるように既存のPPPoEセキュリティー対策にその後です。 Service TagとSession IDが処理クレジットの前にいつも有効にされるのが必要です。
Berry & Holgate Informational [Page 9] RFC 4938 PPPoE with Credit Flow and Metrics June 2007
クレジット流動があるベリーとHolgateの情報[9ページ]のRFC4938PPPoEと測定基準2007年6月
Appendix A: Tag Values
付録A: タグ値
Feature Tag_Types and Tag_Values
特徴タグ_タイプとタグ_値
0x0106 Credits
0×0106クレジット
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).
このタグはForward Credit Notification(FCN)とBackward Credit Notification(BCN)を含んでいます。 Credit Tag TLVはPADR、PADS、およびPPPoEデータペイロードパケット(ETHER_TYPE=8864)があるOPTIONALです。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タグタイプ=0x0106| タグの長さ=0×04| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FCN| BCN| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0x0107 Metrics
0×0107の測定基準
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.
このタグは、リンク品質と性能を報告するのに使用されます。 Metrics Tag TLVはReceive Onlyインディケータ、Resource状態、Latency、Relative Link Quality(RLQ)、Currentデータ信号速度、およびMaximumデータ信号速度を含んでいます。 Metrics 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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タグタイプ=0x0107| タグの長さは0x0Aと等しいです。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 予約されます。|R| RLQ| リソース| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 潜在(MS)| 現在のDatarate(キロビット毎秒)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 最大のDatarate(キロビット毎秒)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0x0108 Sequence Number
0×0108一連番号
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パケットはSequence Number Tagを必要とします。
Berry & Holgate Informational [Page 10] RFC 4938 PPPoE with Credit Flow and Metrics June 2007
クレジット流動があるベリーとHolgateの情報[10ページ]のRFC4938PPPoEと測定基準2007年6月
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タグタイプ=0x0108| タグの長さ=0×02| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 一連番号| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Appendix B: Example Message Formats
付録B: 例のメッセージ・フォーマット
A PADR packet with OPTIONAL Credit Tag Type 0x0106:
OPTIONAL Credit Tag Type0x0106がある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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | _アクセス_集中装置mac_addr| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |_アクセス_集中装置mac_addr(c)| _mac_addrを接待してください。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ホスト_mac_addr(cont)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | エーテル_は=0x8863をタイプします。| =1に対して| t=1| コード=0x19| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | セッション_ID=0x1234| 長さは0x0Cと等しいです。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タグタイプ=0x0101| タグの長さ=0×00| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タグタイプ=0x0106| タグの長さ=0×04| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FCN| BCN| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Berry & Holgate Informational [Page 11] RFC 4938 PPPoE with Credit Flow and Metrics June 2007
クレジット流動があるベリーとHolgateの情報[11ページ]のRFC4938PPPoEと測定基準2007年6月
A PADS packet with OPTIONAL Credit Tag Type 0x0106:
OPTIONAL Credit Tag Type0x0106がある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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | _アクセス_集中装置mac_addr| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |_アクセス_集中装置mac_addr(c)| _mac_addrを接待してください。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ホスト_mac_addr(cont)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | エーテル_は=0x8863をタイプします。| =1に対して| t=1| コード=0x65| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | セッション_ID=0x1234| 長さは0x0Cと等しいです。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タグタイプ=0x0101| タグの長さ=0×00| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タグタイプ=0x0106| タグの長さ=0×04| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FCN| BCN| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A PADG packet with Credit Tag Type 0x0106:
Credit Tag Type0x0106がある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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 目的地_mac_addr| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 目的地_mac_addr(c)| ソース_mac_addr| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ソースmac_addr(cont)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | エーテル_は=0x8863をタイプします。| =1に対して| t=1| コードは0x0Aと等しいです。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | セッション_ID=0x1234| 長さは0x0Eと等しいです。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タグタイプ=0x0108| タグの長さ=0×02| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 一連番号| タグタイプ=0x0106| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タグの長さ=0×04| FCN| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BCN| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Berry & Holgate Informational [Page 12] RFC 4938 PPPoE with Credit Flow and Metrics June 2007
クレジット流動があるベリーとHolgateの情報[12ページ]のRFC4938PPPoEと測定基準2007年6月
A PADC packet with Credit Tag Type 0x0106:
Credit Tag Type0x0106がある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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 目的地_mac_addr| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 目的地_mac_addr(c)| ソース_mac_addr| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ソースmac_addr(cont)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | エーテル_は=0x8863をタイプします。| =1に対して| t=1| コードは0x0Bと等しいです。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | セッション_ID=0x1234| 長さは0x0Eと等しいです。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タグタイプ=0x0108| タグの長さ=0×02| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 一連番号| タグタイプ=0x0106| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タグの長さ=0×04| FCN| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BCN| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A PADQ packet to query for the link metrics: This is indicated by the Metric Tag Length=0.
リンク測定基準のために質問するPADQパケット: これはMetric Tag Length=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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | _アクセス_集中装置mac_addr| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |_アクセス_集中装置mac_addr(c)| _mac_addrを接待してください。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ホスト_mac_addr(cont)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | エーテル_は=0x8863をタイプします。| =1に対して| t=1| コードは0x0Cと等しいです。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | セッション_ID=0x1234| 長さ=0×08| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タグタイプ=0x0101| タグの長さ=0×00| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タグタイプ=0x0107| タグの長さ=0×00| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Berry & Holgate Informational [Page 13] RFC 4938 PPPoE with Credit Flow and Metrics June 2007
クレジット流動があるベリーとHolgateの情報[13ページ]のRFC4938PPPoEと測定基準2007年6月
A PADQ packet with Metric Tag Type 0x0107:
Metric Tag Type0x0107がある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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | _アクセス_集中装置mac_addr| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |_アクセス_集中装置mac_addr(c)| _mac_addrを接待してください。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ホスト_mac_addr(cont)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | エーテル_は=0x8863をタイプします。| =1に対して| t=1| コードは0x0Cと等しいです。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | セッション_ID=0x1234| 長さ=0×12| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タグタイプ=0x0101| タグの長さ=0×00| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タグタイプ=0x0107| タグの長さは0x0Aと等しいです。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 予約されます。|R| RLQ| リソース| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 潜在(MS)| 現在のDatarate(キロビット毎秒)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 最大のDatarate(キロビット毎秒)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Berry & Holgate Informational [Page 14] RFC 4938 PPPoE with Credit Flow and Metrics June 2007
クレジット流動があるベリーとHolgateの情報[14ページ]のRFC4938PPPoEと測定基準2007年6月
A PPP LCP packet with optional Credit Tag Type 0x0106:
任意のCredit Tag Type0x0106がある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.
(0xc021)はPPPプロトコル価値に示されますが、PPPペイロードは読者に任せます。 HostからAccess Concentratorまでこれはパケットです。
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 ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | _アクセス_集中装置mac_addr| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |_アクセス_集中装置mac_addr(c)| _mac_addrを接待してください。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ホスト_mac_addr(cont)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | エーテル_は=0x8864をタイプします。| =1に対して| t=1| コード=0x00| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | セッション_ID=0x1234| 長さの=(ペイロード)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タグタイプ=0x0106| タグの長さ=0×04| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FCN| BCN| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | pppプロトコル=0xc021| PPPペイロード~+++++++++++++++++++++++++++++++
Acknowledgements
承認
The authors would like to acknowledge the influence and contributions from Billy Moon, Fred Baker, Stan Ratliff, and Ed Paradise.
作者はビリーMoon、フレッド・ベイカー、スタン・ラトリフ、およびエドParadiseから影響と貢献を承諾したがっています。
Normative References
引用規格
[1] Simpson, W., Ed., "The Point-to-Point Protocol (PPP)", STD 51,
RFC 1661, July 1994.
[1] シンプソン、W.、エド、「二地点間プロトコル(ppp)」、STD51、RFC1661、7月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.
[2]Mamakos、L.、Lidl、K.、エバーツ、J.、個人閲覧室、D.、シモン、D.、およびR.ウィーラー、「イーサネットの上にpppを伝えるための方法(PPPoE)」、RFC2516(1999年2月)。
[3] Arberg, P. and V. Mammoliti, "IANA Considerations for PPP over
Ethernet (PPPoE)", RFC 4937, June 2007.
[3]Arberg、P.、および「イーサネット(PPPoE)の上のpppのためのIANA問題」、RFC4937、2007年6月対Mammoliti
Berry & Holgate Informational [Page 15] RFC 4938 PPPoE with Credit Flow and Metrics June 2007
クレジット流動があるベリーとHolgateの情報[15ページ]のRFC4938PPPoEと測定基準2007年6月
Authors' Addresses
作者のアドレス
Bo Berry Cisco 170 West Tasman Drive San Jose, CA 95134 USA EMail: bberry@cisco.com
西タスマン・Drive棒ベリーコクチマス170カリフォルニア95134サンノゼ(米国)はメールされます: bberry@cisco.com
Howard Holgate Cisco 170 West Tasman Drive San Jose, CA 95134 USA EMail: hholgate@cisco.com
西タスマン・DriveハワードHolgateシスコ170カリフォルニア95134サンノゼ(米国)はメールされます: hholgate@cisco.com
Berry & Holgate Informational [Page 16] RFC 4938 PPPoE with Credit Flow and Metrics June 2007
クレジット流動があるベリーとHolgateの情報[16ページ]のRFC4938PPPoEと測定基準2007年6月
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(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.
このドキュメントはBCP78と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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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機能のための基金は現在、インターネット協会によって提供されます。
Berry & Holgate Informational [Page 17]
ベリーとHolgate情報です。[17ページ]
一覧
スポンサーリンク
