RFC4719 日本語訳
4719 Transport of Ethernet Frames over Layer 2 Tunneling ProtocolVersion 3 (L2TPv3). R. Aggarwal, Ed., M. Townsley, Ed., M. DosSantos, Ed.. November 2006. (Format: TXT=30764 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group R. Aggarwal, Ed.
Request for Comments: 4719 Juniper Networks
Category: Standards Track M. Townsley, Ed.
M. Dos Santos, Ed.
Cisco Systems
November 2006
ワーキンググループR.Aggarwal、エドをネットワークでつないでください。コメントのために以下を要求してください。 4719年の杜松はカテゴリをネットワークでつなぎます: エド標準化過程M.Townsley、エドM.ドス・サントス、シスコシステムズ2006年11月
Transport of Ethernet Frames over
Layer 2 Tunneling Protocol Version 3 (L2TPv3)
層2のトンネリングプロトコルバージョン3の上のイーサネットフレームの輸送(L2TPv3)
Status of This Memo
このメモの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The IETF Trust (2006).
IETFが信じる著作権(C)(2006)。
Abstract
要約
This document describes the transport of Ethernet frames over the Layer 2 Tunneling Protocol, Version 3 (L2TPv3). This includes the transport of Ethernet port-to-port frames as well as the transport of Ethernet VLAN frames. The mechanism described in this document can be used in the creation of Pseudowires to transport Ethernet frames over an IP network.
バージョン3(L2TPv3)、このドキュメントはLayer2Tunnelingプロトコルの上でイーサネットフレームの輸送について説明します。 これはイーサネットVLANフレームの輸送と同様に移植するイーサネットポートフレームの輸送を含んでいます。 IPネットワークの上でイーサネットフレームを輸送するのにPseudowiresの創造に本書では説明されたメカニズムは使用できます。
Aggarwal, et al. Standards Track [Page 1] RFC 4719 Transport of Ethernet Frames over L2TPv3 November 2006
Aggarwal、他 L2TPv3 November 2006の上のイーサネットフレームの標準化過程[1ページ]RFC4719輸送
Table of Contents
目次
1. Introduction ....................................................2
1.1. Specification of Requirements ..............................2
1.2. Abbreviations ..............................................3
1.3. L2TPv3 Control Message Types ...............................3
1.4. Requirements ...............................................3
2. PW Establishment ................................................4
2.1. LCCE-LCCE Control Connection Establishment .................4
2.2. PW Session Establishment ...................................4
2.3. PW Session Monitoring ......................................6
3. Packet Processing ...............................................7
3.1. Encapsulation .............................................7
3.2. Sequencing ................................................7
3.3. MTU Handling ..............................................7
4. Applicability Statement .........................................8
5. Congestion Control .............................................10
6. Security Considerations ........................................10
7. IANA Considerations ............................................11
8. Contributors ...................................................11
9. Acknowledgements ...............................................11
10. References ....................................................12
10.1. Normative References .....................................12
10.2. Informative References ...................................12
1. 序論…2 1.1. 要件の仕様…2 1.2. 略語…3 1.3. L2TPv3はメッセージタイプを監督します…3 1.4. 要件…3 2. PW設立…4 2.1. LCCE-LCCEはコネクション確立を制御します…4 2.2. PWセッション設立…4 2.3. PWセッションモニター…6 3. パケット処理…7 3.1. カプセル化…7 3.2. 配列します。7 3.3. MTU取り扱い…7 4. 適用性声明…8 5. 混雑コントロール…10 6. セキュリティ問題…10 7. IANA問題…11 8. 貢献者…11 9. 承認…11 10. 参照…12 10.1. 標準の参照…12 10.2. 有益な参照…12
1. Introduction
1. 序論
The Layer 2 Tunneling Protocol, Version 3 (L2TPv3) can be used as a control protocol and for data encapsulation to set up Pseudowires (PWs) for transporting layer 2 Packet Data Units across an IP network [RFC3931]. This document describes the transport of Ethernet frames over L2TPv3 including the PW establishment and data encapsulation.
Layer2Tunnelingプロトコル、制御プロトコルとして使用できて、Pseudowires(PWs)にセットするデータカプセル化のためにIPの向こう側に層2のPacket Data Unitsを輸送するバージョン3(L2TPv3)が[RFC3931]をネットワークでつなぎます。 PW設立とデータカプセル化を含んでいて、このドキュメントはL2TPv3の上でイーサネットフレームの輸送について説明します。
The term "Ethernet" in this document is used with the intention to include all such protocols that are reasonably similar in their packet format to IEEE 802.3 [802.3], including variants or extensions that may or may not necessarily be sanctioned by the IEEE (including such frames as jumbo frames, etc.). The term "VLAN" in this document is used with the intention to include all virtual LAN tagging protocols such as IEEE 802.1Q [802.1Q], 802.1ad [802.1ad], etc.
「イーサネット」という用語はそれらのパケット・フォーマットにおいて合理的にIEEE802.3[802.3]と同様のそのようなすべてのプロトコルを含んでいるという意志と共に本書では使用されます、必ずIEEEによって認可されるかもしれない異形か拡大を含んでいて(ジャンボなフレームなどのようなフレームを含んでいて)。 "VLAN"という用語はIEEE 802.1Q[802.1Q]、802.1ad[802.1ad]などのすべてのバーチャルLANタグ付けプロトコルを含んでいるという意志と共に本書では使用されます。
1.1. Specification of Requirements
1.1. 要件の仕様
In this document, several words are used to signify the requirements of the specification. These words are often capitalized. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本書では、いくつかの単語が、仕様の要件を意味するのに使用されます。 これらの単語はしばしば大文字で書かれます。 キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?
Aggarwal, et al. Standards Track [Page 2] RFC 4719 Transport of Ethernet Frames over L2TPv3 November 2006
Aggarwal、他 L2TPv3 November 2006の上のイーサネットフレームの標準化過程[2ページ]RFC4719輸送
1.2. Abbreviations
1.2. 略語
AC Attachment Circuit (see [RFC3985]) CE Customer Edge (Typically also the L2TPv3 Remote System) LCCE L2TP Control Connection Endpoint (see [RFC3931]) NSP Native Service Processing (see [RFC3985]) PE Provider Edge (Typically also the LCCE) (see [RFC3985]) PSN Packet Switched Network (see [RFC3985]) PW Pseudowire (see [RFC3985]) PWE3 Pseudowire Emulation Edge to Edge (Working Group)
Edgeへの交流Attachment Circuit([RFC3985]を見る)CE Customer Edge(通常L2TPv3 Remote Systemも)LCCE L2TP Control Connection Endpoint([RFC3931]を見る)のNSPのネイティブのService Processing([RFC3985]を見る)PE Provider Edge(通常LCCEも)([RFC3985]を見る)PSN Packet Switched Network([RFC3985]を見る)PW Pseudowire([RFC3985]を見る)PWE3 Pseudowire Emulation Edge(作業部会)
1.3. L2TPv3 Control Message Types
1.3. L2TPv3コントロールメッセージタイプ
Relevant L2TPv3 control message types (see [RFC3931]) are listed for reference.
関連L2TPv3コントロールメッセージタイプ([RFC3931]を見る)は参照のために記載されています。
SCCRQ L2TPv3 Start-Control-Connection-Request control message SCCRP L2TPv3 Start-Control-Connection-Reply control message SCCCN L2TPv3 Start-Control-Connection-Connected control message StopCCN L2TPv3 Stop-Control-Connection-Notification control message ICRQ L2TPv3 Incoming-Call-Request control message ICRP L2TPv3 Incoming-Call-Reply control message ICCN L2TPv3 Incoming-Call-Connected control message OCRQ L2TPv3 Outgoing-Call-Request control message OCRP L2TPv3 Outgoing-Call-Reply control message OCCN L2TPv3 Outgoing-Call-Connected control message CDN L2TPv3 Call-Disconnect-Notify control message SLI L2TPv3 Set-Link-Info control message
SCCRQ L2TPv3 Startコントロール接続要求制御メッセージSCCRP L2TPv3 Startコントロール接続回答コントロールSCCCN L2TPv3 Startコントロール接続が接続しているメッセージのStopCCN L2TPv3 Stopコントロール接続通知コントロールメッセージICRQ L2TPv3 Incoming呼び出し要求コントロールコントロールメッセージメッセージICRP L2TPv3; 分離が通知するCDN L2TPv3 CallがメッセージSLI L2TPv3 Setリンクインフォメーションコントロールメッセージを制御するという接続された入って来る呼び出し回答コントロールメッセージICCN L2TPv3 Incoming呼び出しコントロールメッセージOCRQ L2TPv3 Outgoing呼び出し要求コントロールメッセージOCRP L2TPv3 Outgoing呼び出し回答コントロールメッセージ接続されたOCCN L2TPv3 Outgoing呼び出しコントロールメッセージ
1.4. Requirements
1.4. 要件
An Ethernet PW emulates a single Ethernet link between exactly two endpoints. The following figure depicts the PW termination relative to the NSP and PSN tunnel within an LCCE [RFC3985]. The Ethernet interface may be connected to one or more Remote Systems (an L2TPv3 Remote System is referred to as Customer Edge (CE) in this and associated PWE3 documents). The LCCE may or may not be a PE.
イーサネットPWはちょうど2つの終点の間の単一のイーサネットリンクを見習います。 以下の図はLCCE[RFC3985]の中にNSPとPSNトンネルに比例してPW終了について表現します。 イーサネットインタフェースは1Remote Systemsに接続されるかもしれません(L2TPv3 Remote Systemはこれと関連PWE3ドキュメントにCustomer Edge(CE)と呼ばれます)。 LCCEはPEであるかもしれません。
+---------------------------------------+
| LCCE |
+-+ +-----+ +------+ +------+ +-+
|P| | | |PW ter| | PSN | |P|
Ethernet <==>|h|<=>| NSP |<=>|minati|<=>|Tunnel|<=>|h|<==> PSN
Interface |y| | | |on | | | |y|
+-+ +-----+ +------+ +------+ +-+
| |
+---------------------------------------+
Figure 1: PW termination
+---------------------------------------+ | LCCE| +-+ +-----+ +------+ +------+ +-+ |P| | | |PW ter| | PSN| |P| イーサネット<=>|h|<=>| NSP|<=>|minati|<=>|トンネル|<=>|h|<=>PSNインタフェース|y| | | |オン| | | |y| +-+ +-----+ +------+ +------+ +-+ | | +---------------------------------------+ 図1: PW終了
Aggarwal, et al. Standards Track [Page 3] RFC 4719 Transport of Ethernet Frames over L2TPv3 November 2006
Aggarwal、他 L2TPv3 November 2006の上のイーサネットフレームの標準化過程[3ページ]RFC4719輸送
The PW termination point receives untagged (also referred to as 'raw') or tagged Ethernet frames and delivers them unaltered to the PW termination point on the remote LCCE. Hence, it can provide untagged or tagged Ethernet link emulation service.
ポイントが受けるPW終了は、リモートLCCEのPW終了ポイントに非変更されていた状態で非タグ付けをしたか(また、'生'に言及されます)、イーサネットフレームにタグ付けをして、またはそれらを渡します。 したがって、それは非タグ付けをされたかタグ付けをされたイーサネットリンクエミュレーションサービスを提供できます。
The "NSP" function includes packet processing needed to translate the Ethernet frames that arrive at the CE-LCCE interface to/from the Ethernet frames that are applied to the PW termination point. Such functions may include stripping, overwriting, or adding VLAN tags. The NSP functionality can be used in conjunction with local provisioning to provide heterogeneous services where the CE-LCCE encapsulations at the two ends may be different.
Ce-LCCEインタフェースに届くイーサネットフレームをPW終了ポイントに適用されるイーサネットフレームからの/に翻訳するのが必要であることで、"NSP"機能はパケット処理を含んでいます。 そのような機能は、VLANタグを剥取るか、上書きするか、または加えるのを含むかもしれません。 2つの終わりのCE-LCCEカプセル化が異なるかもしれないところに異種のサービスを提供するのに地方の食糧を供給することに関連してNSPの機能性を使用できます。
The physical layer between the CE and LCCE, and any adaptation (NSP) functions between it and the PW termination, are outside of the scope of PWE3 and are not defined here.
CEとLCCEの間の物理的な層、およびそれとPW終了の間のどんな適合(NSP)機能も、PWE3の範囲の外にあって、ここで定義されません。
2. PW Establishment
2. PW設立
With L2TPv3 as the tunneling protocol, Ethernet PWs are L2TPv3 sessions. An L2TP Control Connection has to be set up first between the two LCCEs. Individual PWs can then be established as L2TP sessions.
トンネリングプロトコルとしてのL2TPv3と共に、イーサネットPWsはL2TPv3セッションです。 L2TP Control Connectionは最初に、2LCCEsの間でセットアップされなければなりません。 そして、L2TPセッションと個々のPWsが書き立てられることができます。
2.1. LCCE-LCCE Control Connection Establishment
2.1. LCCE-LCCEコントロールコネクション確立
The two LCCEs that wish to set up Ethernet PWs MUST establish an L2TP Control Connection first as described in [RFC3931]. Hence, an Ethernet PW Type must be included in the Pseudowire Capabilities List as defined in [RFC3931]. The type of PW can be either "Ethernet port" or "Ethernet VLAN". This indicates that the Control Connection can support the establishment of Ethernet PWs. Note that there are two Ethernet PW Types required. For connecting an Ethernet port to another Ethernet port, the PW Type MUST be "Ethernet port"; for connecting an Ethernet VLAN to another Ethernet VLAN, the PW Type MUST be "Ethernet VLAN".
イーサネットPWsをセットアップしたがっている2LCCEsが最初に、[RFC3931]で説明されるようにL2TP Control Connectionを設立しなければなりません。 したがって、[RFC3931]で定義されるようにPseudowire Capabilities ListにイーサネットPW Typeを含まなければなりません。 PWのタイプは、「イーサネットポート」か「イーサネットVLAN」のどちらかであることができます。 これは、Control ConnectionがイーサネットPWsの設立を支持できるのを示します。 PW Typesが必要とした2つのイーサネットがあることに注意してください。 別のイーサネットポートにイーサネットポートをつなげるために、PW Typeは「イーサネットポート」でなければなりません。 別のイーサネットVLANにイーサネットVLANを接続するために、PW Typeは「イーサネットVLAN」でなければなりません。
2.2. PW Session Establishment
2.2. PWセッション設立
The provisioning of an Ethernet port or Ethernet VLAN and its association with a PW triggers the establishment of an L2TP session via the standard Incoming Call three-way handshake described in Section 3.4.1 of [RFC3931].
PWとのイーサネットポートかイーサネットVLANとその協会の食糧を供給するのは.1セクション3.4[RFC3931]で説明された標準のIncoming Call3方向ハンドシェイクでL2TPセッションの設立の引き金となります。
Aggarwal, et al. Standards Track [Page 4] RFC 4719 Transport of Ethernet Frames over L2TPv3 November 2006
Aggarwal、他 L2TPv3 November 2006の上のイーサネットフレームの標準化過程[4ページ]RFC4719輸送
Note that an L2TP Outgoing Call is essentially a method of controlling the originating point of a Switched Virtual Circuit (SVC), allowing it to be established from any reachable L2TP-enabled device able to perform outgoing calls. The Outgoing Call model and its corresponding OCRQ, OCRP, and OCCN control messages are mainly used within the dial arena with L2TPv2 today and has not been found applicable for PW applications yet.
L2TP Outgoing Callが本質的にはSwitched Virtual Circuit(SVC)の由来している先を制御する方法であることに注意してください、それが発信電話を実行できるどんな届いているL2TPによって可能にされた装置からも設立されるのを許容して。 今日、L2TPv2と共にダイヤルアリーナの中で主に使用されて、PWアプリケーションに、Outgoing Callモデル、対応するOCRQ、OCRP、およびOCCNコントロールメッセージが適切であることがまだわかっていません。
The following are the signaling elements needed for the Ethernet PW establishment:
↓これはイーサネットPW設立に必要であるシグナリング要素です:
a) Pseudowire Type: The type of a Pseudowire can be either "Ethernet
port" or "Ethernet VLAN". Each LCCE signals its Pseudowire type
in the Pseudowire Type AVP [RFC3931]. The assigned values for
"Ethernet port" and "Ethernet VLAN" Pseudowire types are captured
in the "IANA Considerations" of this document. The Pseudowire
Type AVP MUST be present in the ICRQ.
a) Pseudowireはタイプします: Pseudowireのタイプは、「イーサネットポート」か「イーサネットVLAN」のどちらかであることができます。 各LCCEはPseudowire Type AVP[RFC3931]のPseudowireタイプに合図します。 このドキュメントの「IANA問題」で「イーサネットポート」と「イーサネットVLAN」Pseudowireタイプのための割り当てられた値を得ます。 Pseudowire Type AVPはICRQに存在していなければなりません。
b) Pseudowire ID: Each PW is associated with a Pseudowire ID. The
two LCCEs of a PW have the same Pseudowire ID for it. The Remote
End Identifier AVP [RFC3931] is used to convey the Pseudowire ID.
The Remote End Identifier AVP MUST be present in the ICRQ in order
for the remote LCCE to determine the PW to associate the L2TP
session with. An implementation MUST support a Remote End
Identifier of four octets known to both LCCEs either by manual
configuration or some other means. Additional Remote End
Identifier formats that MAY be supported are outside the scope of
this document.
b) Pseudowire ID: それぞれのPWはPseudowire IDに関連しています。 PWの2LCCEsには、それのための同じPseudowire IDがあります。 Remote End Identifier AVP[RFC3931]は、Pseudowire IDを運ぶのに使用されます。 リモートLCCEが、PWがL2TPセッションを関連づけることを決定するように、Remote End Identifier AVPはICRQに存在していなければなりません。 実現は両方のLCCEsにおいて手動の構成かある他の手段によって知られていた4つの八重奏のRemote End Identifierを支持しなければなりません。 このドキュメントの範囲の外に支持されるかもしれない追加Remote End Identifier形式があります。
c) The Circuit Status AVP [RFC3931] MUST be included in ICRQ and ICRP
to indicate the circuit status of the Ethernet port or Ethernet
VLAN. For ICRQ and ICRP, the Circuit Status AVP MUST indicate
that the circuit status is for a new circuit (refer to N bit in
Section 2.3.3). An implementation MAY send an ICRQ or ICRP before
an Ethernet interface is ACTIVE, as long as the Circuit Status AVP
(refer to A bit in Section 2.3.3) in the ICRQ or ICRP reflects the
correct status of the Ethernet port or Ethernet VLAN link. A
subsequent circuit status change of the Ethernet port or Ethernet
VLAN MUST be conveyed in the Circuit Status AVP in ICCN or SLI
control messages. For ICCN and SLI (refer to Section 2.3.2), the
Circuit Status AVP MUST indicate that the circuit status is for an
existing circuit (refer to N bit in Section 2.3.3) and reflect the
current status of the link (refer to A bit in Section 2.3.3).
c) イーサネットポートかイーサネットVLANのサーキット状態を示すために、ICRQとICRPにCircuit Status AVP[RFC3931]を含まなければなりません。 ICRQとICRPに関しては、Circuit Status AVPは、新しいサーキットにはサーキット状態がいるのを示さなければなりません(セクション2.3.3でNビットを参照してください)。 イーサネットインタフェースがACTIVEになる前に実現はICRQかICRPを送るかもしれません、ICRQかICRPのCircuit Status AVP(セクション2.3.3で噛み付いたAについて言及する)がイーサネットポートかイーサネットVLANリンクの正しい状態を反映する限り。 その後のサーキット状態は運ばれたコネがICCNのCircuit Status AVPかSLIコントロールメッセージであったならイーサネットポートかイーサネットVLAN MUSTを変えます。 ICCNとSLI(セクション2.3.2について言及する)に関しては、Circuit Status AVPは既存のサーキット(セクション2.3.3でNビットについて言及する)にはサーキット状態がいるのを示して、リンクの現在の状態を反映しなければなりません(セクション2.3.3で噛み付いたAを参照してください)。
Aggarwal, et al. Standards Track [Page 5] RFC 4719 Transport of Ethernet Frames over L2TPv3 November 2006
Aggarwal、他 L2TPv3 November 2006の上のイーサネットフレームの標準化過程[5ページ]RFC4719輸送
2.3. PW Session Monitoring
2.3. PWセッションモニター
2.3.1. Control Connection Keep-alive
2.3.1. 接続が生かすコントロール
The working status of a PW is reflected by the state of the L2TPv3 session. If the corresponding L2TPv3 session is down, the PW associated with it MUST be shut down. The Control Connection keep- alive mechanism of L2TPv3 can serve as a link status monitoring mechanism for the set of PWs associated with a Control Connection.
PWの働く状態はL2TPv3セッションの州によって反映されます。 対応するL2TPv3セッションが下がっているなら、それに関連しているPWを止めなければなりません。 L2TPv3の生きているControl Connection生活費メカニズムはControl Connectionに関連しているPWsのセットのためのリンク状態監視メカニズムとして機能できます。
2.3.2. SLI Message
2.3.2. SLIメッセージ
In addition to the Control Connection keep-alive mechanism of L2TPv3, Ethernet PW over L2TP makes use of the Set-Link-Info (SLI) control message defined in [RFC3931]. The SLI message is used to signal Ethernet link status notifications between LCCEs. This can be useful to indicate Ethernet interface state changes without bringing down the L2TP session. Note that change in the Ethernet interface state will trigger an SLI message for each PW associated with that Ethernet interface. This may be one Ethernet port PW or more than one Ethernet VLAN PW. The SLI message MUST be sent any time there is a status change of any values identified in the Circuit Status AVP. The only exception to this is the initial ICRQ, ICRP, and CDN messages that establish and tear down the L2TP session itself. The SLI message may be sent from either LCCE at any time after the first ICRQ is sent (and perhaps before an ICRP is received, requiring the peer to perform a reverse Session ID lookup).
Control Connectionに加えて、L2TPv3(L2TPの上のPWが[RFC3931]で定義されたSetリンクインフォメーション(SLI)コントロールメッセージの使用をするイーサネット)のメカニズムを生かしてください。 SLIメッセージは、LCCEsの間のイーサネットリンク状態通知に合図するのに使用されます。 これは、L2TPセッションを降ろさないでイーサネット界面準位変化を示すために役に立つ場合があります。 イーサネット界面準位の変化がそのイーサネットインタフェースに関連しているそれぞれのPWへのSLIメッセージの引き金となることに注意してください。 これは、1イーサネットポートPWか1イーサネットVLAN PWであるかもしれません。 Circuit Status AVPで特定されたどんな値の状態変化もある何時でもSLIメッセージを送らなければなりません。 これへの唯一の例外が、L2TPセッション自体を確立して、取りこわす初期のICRQと、ICRPと、CDNメッセージです。 最初のICRQを送った(同輩が逆のSession IDルックアップを実行するのが必要であることで、ICRPが恐らく受け取られている前に)後にいつでも、LCCEからSLIメッセージを送るかもしれません。
2.3.3. Use of Circuit Status AVP for Ethernet
2.3.3. サーキット状態AVPのイーサネットの使用
Ethernet PW reports circuit status with the Circuit Status AVP defined in [RFC3931]. For reference, this AVP is shown below:
Circuit Status AVPが[RFC3931]で定義されている状態で、イーサネットPWはサーキット状態を報告します。 参照において、このAVPは以下で見せられます:
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |N|A|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 予約されます。|N|A| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Value is a 16-bit mask with the two least significant bits defined and the remaining bits reserved for future use. Reserved bits MUST be set to 0 when sending and ignored upon receipt.
Valueは2つの最下位ビットが定義されて、残っているビットが今後の使用のために予約されている16ビットのマスクです。 予約されたビットを発信するとき、0に設定されて、領収書で無視しなければなりません。
The A (Active) bit indicates whether the Ethernet interface is ACTIVE (1) or INACTIVE (0).
A(アクティブ)のビットは、イーサネットインタフェースがACTIVE(1)かそれともINACTIVE(0)であるかを示します。
The N (New) bit indicates whether the circuit status is for a new (1) Ethernet circuit or an existing (0) Ethernet circuit.
(新しい)のNビットは、新しい(1)イーサネットサーキットか存在(0)イーサネットサーキットにはサーキット状態がいるかを示します。
Aggarwal, et al. Standards Track [Page 6] RFC 4719 Transport of Ethernet Frames over L2TPv3 November 2006
Aggarwal、他 L2TPv3 November 2006の上のイーサネットフレームの標準化過程[6ページ]RFC4719輸送
3. Packet Processing
3. パケット処理
3.1. Encapsulation
3.1. カプセル化
The encapsulation described in this section refers to the functionality performed by the PW termination point depicted in Figure 1, unless otherwise indicated.
このセクションで説明されたカプセル化は図1に表現されたPW終了ポイントによって実行された機能性を示します、別の方法で示されない場合。
The entire Ethernet frame, without the preamble or frame check sequence (FCS), is encapsulated in L2TPv3 and is sent as a single packet by the ingress LCCE. This is done regardless of whether or not a VLAN tag is present in the Ethernet frame. For Ethernet port- to-port mode, the remote LCCE simply decapsulates the L2TP payload and sends it out on the appropriate interface without modifying the Ethernet header. For Ethernet VLAN-to-VLAN mode, the remote LCCE MAY rewrite the VLAN tag. As described in Section 1, the VLAN tag modification is an NSP function.
全体のイーサネットフレームは、L2TPv3で序文もフレームチェックシーケンス(FCS)なしで要約されて、単一のパケットとしてイングレスLCCEによって送られます。 VLANタグが存在しているかどうかにかかわらずイーサネットフレームでこれをします。 イーサネットポートポートへのモードのために、イーサネットヘッダーを変更しないで、リモートLCCEは単にL2TPペイロードをdecapsulatesして、適切なインタフェースにそれを出します。 イーサネットVLANからVLANへのモードのために、リモートLCCE MAYはVLANタグを書き直します。 セクション1で説明されるように、VLANタグ変更はNSP機能です。
The Ethernet PW over L2TP is homogeneous with respect to packet encapsulation, i.e., both ends of the PW are either untagged or tagged. The Ethernet PW can still be used to provide heterogeneous services using NSP functionality at the ingress and/or egress LCCE. The definition of such NSP functionality is outside the scope of this document.
L2TPの上のイーサネットPWがパケットカプセル化に関して均質である、すなわち、PWの両端は、非タグ付けをされるか、またはタグ付けをされます。 イングレス、そして/または、出口LCCEでNSPの機能性を使用することで異種のサービスを提供するのにまだイーサネットPWを使用できます。 このドキュメントの範囲の外にそのようなNSPの機能性の定義があります。
The maximum length of the Ethernet frame carried as the PW payload is irrelevant as far as the PW is concerned. If anything, that value would only be relevant when quantifying the faithfulness of the emulation.
PWに関する限り、PWペイロードが無関係であるので、イーサネットフレームの最大の長さは運ばれました。 エミュレーションの忠実を定量化するときだけ、どちらかと言えば、その値は関連しているでしょう。
3.2. Sequencing
3.2. 配列
Data packet sequencing MAY be enabled for Ethernet PWs. The sequencing mechanisms described in [RFC3931] MUST be used for signaling sequencing support.
データパケット順序制御はイーサネットPWsのために可能にされるかもしれません。 シグナリング配列サポートに[RFC3931]で説明された配列メカニズムを使用しなければなりません。
3.3. MTU Handling
3.3. MTU取り扱い
With L2TPv3 as the tunneling protocol, the IP packet resulting from the encapsulation is M + N bytes longer than the Ethernet frame without the preamble or FCS. Here M is the length of the IP header along with associated options and extension headers, and the value of N depends on the following fields:
トンネリングプロトコルとしてのL2TPv3と共に、カプセル化から生じるIPパケットがイーサネットフレームよりM+Nバイト長い間、序文もFCSなしであります。 ここで、Mは関連オプションと拡張ヘッダーに伴うIPヘッダーの長さです、そして、Nの値を以下のフィールドに依存します:
Aggarwal, et al. Standards Track [Page 7] RFC 4719 Transport of Ethernet Frames over L2TPv3 November 2006
Aggarwal、他 L2TPv3 November 2006の上のイーサネットフレームの標準化過程[7ページ]RFC4719輸送
L2TP Session Header:
Flags, Ver, Res - 4 octets (L2TPv3 over UDP only)
Session ID - 4 octets
Cookie Size - 0, 4, or 8 octets
L2-Specific Sublayer - 0 or 4 octets (i.e., using sequencing)
L2TPセッションヘッダー: 旗、Ver、Res----4八重奏Cookie Size--0、4、または8つの八重奏の4つの八重奏(UDPだけの上のL2TPv3)のSession IDのL2特有のSublayer--0か4つの八重奏(すなわち、配列を使用します)
Hence the range for N in octets is:
N = 4-16, for L2TPv3 data messages over IP;
N = 16-28, for L2TPv3 data messages over UDP;
(N does not include the IP header).
したがって、八重奏におけるNのための範囲は以下の通りです。 NはL2TPv3データメッセージのためにIPの上で4-16と等しいです。 NはUDPの上のL2TPv3データメッセージのために16-28と等しいです。 (NはIPヘッダーを含んでいません。)
Fragmentation in the PSN can occur when using Ethernet over L2TP, unless proper configuration and management of MTU sizes are in place between the Customer Edge (CE) router and Provider Edge (PE) router, and across the PSN. This is not specific only to Ethernet over L2TPv3, and the base L2TPv3 specification [RFC3931] provides general recommendations with respect to fragmentation and reassembly in Section 4.1.4. "PWE3 Fragmentation and Reassembly" [RFC4623] expounds on this topic, including a fragmentation and reassembly mechanism within L2TP itself in the event that no other option is available. Implementations MUST follow these guidelines with respect to fragmentation and reassembly.
L2TPの上でイーサネットを使用するとき、PSNでの断片化は起こることができます、MTUサイズの適切な構成と管理がCustomer Edge(CE)ルータとProvider Edge(PE)ルータの間とPSNのむこうに適所にない場合。 これはL2TPv3の上のイーサネットだけに特定ではありません、そして、ベースL2TPv3仕様[RFC3931]は断片化と再アセンブリに関してセクション4.1.4に一般的な推薦を提供します。 どんな別の選択肢も利用可能でない場合、「PWE3 FragmentationとReassembly」[RFC4623]はL2TP自身の中で断片化を含むこの話題に再アセンブリにメカニズムを述べます。 実現は、断片化に関してこれらのガイドラインに従って、再アセンブリされなければなりません。
4. Applicability Statement
4. 適用性証明
The Ethernet PW emulation allows a service provider to offer a "port-to-port"-based Ethernet service across an IP Packet Switched Network (PSN), while the Ethernet VLAN PW emulation allows an "VLAN- to-VLAN"-based Ethernet service across an IP Packet Switched Network (PSN).
サービスプロバイダーはIP Packet Switched Network(PSN)の向こう側にイーサネットPWエミュレーションで「移植するポート」ベースのイーサネットサービスを提供できます、とエミュレーションが許容するイーサネットVLAN PWがゆったり過ごす、「VLAN VLANに、」 ベースのイーサネットはIPの向こう側にPacket Switched Network(PSN)を調整します。
The Ethernet or Ethernet VLAN PW emulation has the following characteristics in relationship to the respective native service:
イーサネットかイーサネットVLAN PWエミュレーションには、それぞれのネイティブのサービスとの関係における以下の特性があります:
o Ethernet PW connects two Ethernet port ACs, and Ethernet VLAN PW
connects two Ethernet VLAN ACs, which both support bi-directional
transport of variable-length Ethernet frames. The ingress LCCE
strips the preamble and FCS from the Ethernet frame and transports
the frame in its entirety across the PW. This is done regardless
of the presence of the VLAN tag in the frame. The egress LCCE
receives the Ethernet frame from the PW and regenerates the
preamble and FCS before forwarding the frame to the attached
Remote System (see Section 3.1). Since FCS is not being
transported across either Ethernet or Ethernet VLAN PWs, payload
integrity transparency may be lost. To achieve payload integrity
transparency on Ethernet or Ethernet VLAN PWs using L2TP over IP
or L2TP over UDP/IP, the L2TPv3 session can utilize IPsec as
specified in Section 4.1.3 of [RFC3931].
o イーサネットPWは2イーサネットポートACsを接続します、そして、イーサネットVLAN PWは2イーサネットVLAN ACsを接続します。(ともに、VLAN ACsは可変長のイーサネットフレームの双方向の輸送を支持します)。 イングレスLCCEはイーサネットフレームから序文とFCSを剥取って、PWの向こう側にフレームを全体として輸送します。 フレームでのVLANタグの存在にかかわらずこれをします。 出口LCCEはPWからイーサネットフレームを受けて、付属Remote Systemにフレームを送る前に、序文とFCSを作り直します(セクション3.1を見てください)。 FCSがイーサネットかイーサネットのどちらかVLAN PWsの向こう側に輸送されていないので、ペイロード保全透明は失われるかもしれません。 イーサネットかイーサネットVLAN PWsでUDP/IPの上でIPかL2TPの上でL2TPを使用することでペイロード保全透明を達成するために、L2TPv3セッションは.3セクション4.1[RFC3931]の指定されるとしてのIPsecを利用できます。
Aggarwal, et al. Standards Track [Page 8] RFC 4719 Transport of Ethernet Frames over L2TPv3 November 2006
Aggarwal、他 L2TPv3 November 2006の上のイーサネットフレームの標準化過程[8ページ]RFC4719輸送
o While architecturally [RFC3985] outside the scope of the L2TPv3 PW
itself, if VLAN tags are present, the NSP may rewrite VLAN tags on
ingress or egress from the PW (see Section 3.1).
o VLANタグが存在しているなら、NSPはイングレスか出口でL2TPv3 PW自身の範囲の外でPWからVLANタグを建築上[RFC3985]書き直すかもしれませんが(セクション3.1を見てください)。
o The Ethernet or Ethernet VLAN PW only supports homogeneous
Ethernet frame type across the PW; both ends of the PW must be
either tagged or untagged. Heterogeneous frame type support
achieved with NSP functionality is outside the scope of this
document (see Section 3.1).
o イーサネットかイーサネットVLAN PWがPWの向こう側に均質のイーサネットフレームタイプを支持するだけです。 PWの両端にタグ付けをされなければならないか、または非タグ付けをしなければなりません。 このドキュメントの範囲の外にNSPの機能性で達成された異種のフレームタイプサポートがあります(セクション3.1を見てください)。
o Ethernet port or Ethernet VLAN status notification is provided
using the Circuit Status AVP in the SLI message (see Sections
2.3.2 and 2.3.3). Loss of connectivity between LCCEs can be
detected by the L2TPv3 keep-alive mechanism (see Section 2.3.1 of
this document and Section 4.4 of [RFC3931]). The LCCE can convey
these indications back to its attached Remote System.
o セクション2.3.2と2.3を見てください。SLIメッセージでCircuit Status AVPを使用することでイーサネットポートかイーサネットVLAN状態通知を提供する、(.3)。 L2TPv3生きている生活費メカニズムはLCCEsの間の接続性の損失を検出できます(この.1通のセクション2.3ドキュメントと[RFC3931]のセクション4.4を見てください)。 LCCEはこれらの指摘を付属Remote Systemに伝えて戻すことができます。
o The maximum frame size that can be supported is limited by the PSN
MTU minus the L2TPv3 header size, unless fragmentation and
reassembly is used (see Section 3.3 of this document and Section
4.1.4 of [RFC3931]).
o 支持できる最大のフレーム・サイズはL2TPv3ヘッダーサイズを引いてPSN MTUによって制限されます、断片化と再アセンブリが使用されていない場合(このドキュメントのセクション3.3と.4セクション4.1[RFC3931]を見てください)。
o The Packet Switched Network may reorder, duplicate, or silently
drop packets. Sequencing may be enabled in the Ethernet or
Ethernet VLAN PW for some or all packets to detect lost,
duplicate, or out-of-order packets on a per-session basis (see
Section 3.2).
o Packet Switched Networkがそうするかもしれない、追加注文、パケットをコピーするか、または静かに落としてください。 配列は1セッションあたり1個のベースに無くなっているか、写しの、または、故障しているパケットを検出するいくつかかすべてのパケットのためにイーサネットかイーサネットVLAN PWで可能にされるかもしれません(セクション3.2を見てください)。
o The faithfulness of an Ethernet or Ethernet VLAN PW may be
increased by leveraging Quality-of-Service (QoS) features of the
LCCEs and the underlying PSN. For example, for Ethernet 802.1Q
[802.1Q] VLAN transport, the ingress LCCE MAY consider the user
priority field (i.e., 802.1p) of the VLAN tag for traffic
classification and QoS treatments, such as determining the
Differentiated Services (DS) field [RFC2474] of the encapsulating
IP header. Similarly, the egress LCCE MAY consider the DS field
of the encapsulating IP header when rewriting the user priority
field of the VLAN tag or queuing the Ethernet frame before
forwarding the frame to the Remote System. The mapping between
the user priority field and the IP header DS field as well as the
Quality-of-Service model deployed are application specific and are
outside the scope of this document.
o イーサネットかイーサネットVLAN PWの忠実は、LCCEsと基本的なPSNのサービスのQuality(QoS)の特徴に投機することによって、増加するかもしれません。 例えば、イーサネット802.1Q[802.1Q]VLAN輸送のために、イングレスLCCE MAYは、ユーザ優先権分野が交通分類とQoS処理のためのVLANタグの(すなわち、802.1p)であると考えます、要約のIPヘッダーのDifferentiated Services(DS)分野[RFC2474]を決定するのなどように。 VLANタグのユーザ優先権分野を書き直すか、またはフレームをRemote Systemに送る前にイーサネットフレームを列に並ばせるとき、同様に、出口LCCE MAYは要約のIPヘッダーのDS分野を考えます。 サービスのQualityモデルが展開したので、ユーザ優先権分野とまた、IPヘッダーDS分野の間のマッピングは、アプリケーション特有であり、このドキュメントの範囲の外にあります。
Aggarwal, et al. Standards Track [Page 9] RFC 4719 Transport of Ethernet Frames over L2TPv3 November 2006
Aggarwal、他 L2TPv3 November 2006の上のイーサネットフレームの標準化過程[9ページ]RFC4719輸送
5. Congestion Control
5. 輻輳制御
As explained in [RFC3985], the PSN carrying the PW may be subject to congestion, with congestion characteristics depending on PSN type, network architecture, configuration, and loading. During congestion, the PSN may exhibit packet loss that will impact the service carried by the Ethernet or Ethernet VLAN PW. In addition, since Ethernet or Ethernet VLAN PWs carry a variety of services across the PSN, including but not restricted to TCP/IP, they may or may not behave in a TCP-friendly manner prescribed by [RFC2914] and thus consume more than their fair share.
[RFC3985]で説明されるように、PWを運ぶPSNは混雑を受けることがあるかもしれません、PSNタイプに頼る混雑の特性、ネットワークアーキテクチャ、構成、およびローディングで。 混雑の間、PSNはイーサネットかイーサネットVLAN PWによって提供されたサービスに影響を与えるパケット損失を示すかもしれません。 さらに、イーサネットかイーサネットVLAN PWsがTCP/IPに含んでいますが、制限されなかったPSNの向こう側にさまざまなサービスを提供するので、それらは、[RFC2914]によって定められたTCPに優しい態度で振る舞って、その結果、それらの正当な分け前以上を消費するかもしれません。
Whenever possible, Ethernet or Ethernet VLAN PWs should be run over traffic-engineered PSNs providing bandwidth allocation and admission control mechanisms. IntServ-enabled domains providing the Guaranteed Service (GS) or DiffServ-enabled domains using EF (expedited forwarding) are examples of traffic-engineered PSNs. Such PSNs will minimize loss and delay while providing some degree of isolation of the Ethernet or Ethernet VLAN PW's effects from neighboring streams.
可能であるときはいつも、帯域幅配分と入場がメカニズムを制御するなら、イーサネットかイーサネットVLAN PWsが交通で設計されたPSNsの上を走るべきです。EF(完全優先転送)を使用することでGuaranteed Service(GS)かDiffServによって可能にされたドメインを提供するIntServによって可能にされたドメインは交通で設計されたPSNsに関する例です。 そのようなPSNsはVLAN PWの効果を隣接している流れからイーサネットかイーサネットの孤立にいくらかの供給している間、損失と遅れを最小にするでしょう。
LCCEs SHOULD monitor for congestion (by using explicit congestion notification or by measuring packet loss) in order to ensure that the service using the Ethernet or Ethernet VLAN PW may be maintained. When severe congestion is detected (for example, when enabling sequencing and detecting that the packet loss is higher than a threshold), the Ethernet or Ethernet VLAN PW SHOULD be halted by tearing down the L2TP session via a CDN message. The PW may be restarted by manual intervention or by automatic means after an appropriate waiting time. Note that the thresholds and time periods for shutdown and possible automatic recovery need to be carefully configured. This is necessary to avoid loss of service due to temporary congestion and to prevent oscillation between the congested and halted states.
イーサネットかイーサネットVLAN PWを使用するサービスが維持されるかもしれないのを確実にして、LCCEs SHOULDは混雑(明白な混雑通知を使用するか、またはパケット損失を測定するのによる)のためにモニターします。 厳しい混雑がいつ検出されるか、そして、(それを配列して、検出しながら可能にするとき、例えば、パケット損失は敷居より高いです)イーサネットかイーサネットVLAN PW SHOULD、CDNメッセージでL2TPセッションを取りこわすことによって、止められてください。 PWは手動の介入か適切な待ち時間の後の自動手段で再開されるかもしれません。 閉鎖と可能な自動復旧のための敷居と期間が、慎重に構成される必要に注意してください。 これが、一時的な混雑によるサービスの損失を避けて、混雑していて停止している州の間の振動を防ぐのに必要です。
This specification offers no congestion control and is not TCP friendly [TFRC]. Future works for PW congestion control (being studied by the PWE3 Working Group) will provide congestion control for all PW types including Ethernet and Ethernet VLAN PWs.
この仕様は、輻輳制御を全く提供しないで、またTCPの好意的な[TFRC]ではありません。 PW輻輳制御(PWE3作業部会によって研究される)のための将来の作品はイーサネットとイーサネットVLAN PWsを含むすべてのPWタイプに輻輳制御を提供するでしょう。
6. Security Considerations
6. セキュリティ問題
Ethernet over L2TPv3 is subject to all of the general security considerations outlined in [RFC3931].
L2TPv3の上のイーサネットは[RFC3931]に概説された総合証券問題のすべてを受けることがあります。
Aggarwal, et al. Standards Track [Page 10] RFC 4719 Transport of Ethernet Frames over L2TPv3 November 2006
Aggarwal、他 L2TPv3 November 2006の上のイーサネットフレームの標準化過程[10ページ]RFC4719輸送
7. IANA Considerations
7. IANA問題
The signaling mechanisms defined in this document rely upon the following Ethernet Pseudowire Types (see Pseudowire Capabilities List as defined in 5.4.3 of [RFC3931] and L2TPv3 Pseudowire Types in 10.6 of [RFC3931]), which were allocated by the IANA (number space created as part of publication of [RFC3931]):
本書では定義されたシグナル伝達機構が以下のイーサネットPseudowire Typesを当てにする、(中で定義されるようにPseudowire Capabilities Listを見てください、5.4、.3、[RFC3931]とIANA([RFC3931]の公表の一部として作成された数のスペース)によって割り当てられた10.6[RFC3931)のL2TPv3 Pseudowire Typesについて:
Pseudowire Types
----------------
0x0004 Ethernet VLAN Pseudowire Type
0x0005 Ethernet Pseudowire Type
Pseudowireはタイプします。---------------- 0×0004 イーサネットVLAN Pseudowireタイプ0×0005イーサネットPseudowireはタイプします。
8. Contributors
8. 貢献者
The following is the complete list of contributors to this document.
↓これはこのドキュメントへの寄稿者の全リストです。
Rahul Aggarwal Juniper Networks
Rahul Aggarwal杜松ネットワーク
Xipeng Xiao Riverstone Networks
Xipeng Xiaoリバーストンネットワーク
W. Mark Townsley Stewart Bryant Maria Alice Dos Santos Cisco Systems
W.マークTownsleyスチュワートブライアントマリアアリスドス・サントスシスコシステムズ
Cheng-Yin Lee Alcatel
チェン-殷リーアルカテル
Tissa Senevirathne Consultant
Tissa Senevirathneコンサルタント
Mitsuru Higashiyama Anritsu Corporation
Mitsuru東山アンリツ
9. Acknowledgements
9. 承認
This RFC evolved from the document, "Ethernet Pseudo Wire Emulation Edge-to-Edge". We would like to thank its authors, T.So, X.Xiao, L. Anderson, C. Flores, N. Tingle, S. Khandekar, D. Zelig and G. Heron for their contribution. We would also like to thank S. Nanji, the author of "Ethernet Service for Layer Two Tunneling Protocol", for writing the first Ethernet over L2TP document.
ドキュメントから発展されたこのRFC、「イーサネットの疑似ワイヤのエミュレーションの縁から縁。」 彼らの貢献について作者(T.So)のX.Xiao、L.アンダーソン、C.フロレス、N.Tingle、S.カンデーカル、D.カメレオンマン、およびG.Heronに感謝申し上げます。 また、L2TPの上の最初のイーサネットが記録する書くことについてS.Nanji、「層Twoのトンネリングプロトコルのためのイーサネットサービス」の作者に感謝申し上げます。
Thanks to Carlos Pignataro for providing a thorough review and helpful input.
徹底的なレビューと有用な入力をカルロスPignataroに提供してくださってありがとうございます。
Aggarwal, et al. Standards Track [Page 11] RFC 4719 Transport of Ethernet Frames over L2TPv3 November 2006
Aggarwal、他 L2TPv3 November 2006の上のイーサネットフレームの標準化過程[11ページ]RFC4719輸送
10. References
10. 参照
10.1. Normative References
10.1. 引用規格
[RFC3931] Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling
Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005.
[RFC3931] ラウ、J.、Townsley、M.、およびI.Goyret、「2トンネリングプロトコルを層にしてください--バージョン3(L2TPv3)」、RFC3931、3月2005日
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC4623] Malis, A. and M. Townsley, "Pseudowire Emulation Edge-to-
Edge (PWE3) Fragmentation and Reassembly", RFC 4623,
August 2006.
[RFC4623] Malis、A.、M.Townsley、および「Pseudowireエミュレーション縁から縁(PWE3)への断片化とReassembly」、RFC4623、8月2006日
10.2. Informative References
10.2. 有益な参照
[RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to-
Edge (PWE3) Architecture", RFC 3985, March 2005.
[RFC3985] ブライアントとS.とP.頭、「疑似ワイヤエミュレーション縁から縁(PWE3)への構造」、RFC3985、2005年3月。
[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC
2914, September 2000.
[RFC2914]フロイド、S.、「輻輳制御プリンシプルズ」、BCP41、RFC2914、2000年9月。
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474, December
1998.
[RFC2474] ニコルズ、K.、ブレーク、S.、ベイカー、F.、およびD.黒、「IPv4とIPv6ヘッダーとの微分されたサービス分野(DS分野)の定義」、RFC2474(1998年12月)。
[802.3] IEEE, "IEEE std 802.3 -2005/Cor 1-2006 IEEE Standard for
Information Technology - Telecommuincations and
Information Exchange Between Systems - Local and
Metropolitan Area Networks", IEEE Std 802.3-2005/Cor
1-2006 (Corrigendum to IEEE Std 802.3-2005)
[802.3]IEEEと、「情報Technology(Telecommuincationsと情報Exchange Between Systems)における、地方のIEEE std802.3 -2005/心臓1-2006IEEE StandardとMetropolitan Area Networks」、IEEE Std802.3-2005/心臓1-2006(IEEE Std802.3-2005への間違い)
[802.1Q] IEEE, "IEEE standard for local and metropolitan area
networks virtual bridged local area networks", IEEE Std
802.1Q-2005 (Incorporates IEEE Std 802.1Q1998, IEEE Std
802.1u-2001, IEEE Std 802.1v-2001, and IEEE Std 802.1s-
2002)
[802.1Q]IEEE、「地方とメトロポリタンエリアネットワークにおける、仮想のIEEE規格はローカル・エリア・ネットワークに橋を架けた」IEEE Std 802.1Q-2005(IEEE Std 802.1Q1998、IEEE Std 802.1u-2001、IEEE Std 802.1v-2001、およびIEEE Std802.1s2002を組み込みます)
[802.1ad] IEEE, "IEEE Std 802.1ad - 2005 IEEE Standard for Local and
metropolitan area networks - virtual Bridged Local Area
Networks, Amendment 4: Provider Bridges", IEEE Std
802.1ad-2005 (Amendment to IEEE Std 8021Q-2005)
[802.1ad]IEEE、「IEEE Std 802.1ad--Localとメトロポリタンエリアネットワークのための2005IEEE Standard--仮想のBridgedローカル・エリア・ネットワーク、Amendment4:」 「プロバイダー橋」、IEEE Std 802.1ad-2005(IEEE Std 8021Q-2005の修正)
[TFRC] Handley, M., Floyd, S., Padhye, J., and J. Widmer, "TCP
Friendly Rate Control (TFRC): Protocol Specification", RFC
3448, January 2003.
[TFRC] ハンドレー、M.、フロイド、S.、Padhye、J.、およびJ.ウィトマー、「TCPの好意的なレートは(TFRC)を制御します」。 「プロトコル仕様」、RFC3448、2003年1月。
Aggarwal, et al. Standards Track [Page 12] RFC 4719 Transport of Ethernet Frames over L2TPv3 November 2006
Aggarwal、他 L2TPv3 November 2006の上のイーサネットフレームの標準化過程[12ページ]RFC4719輸送
Author Information
作者情報
Rahul Aggarwal Juniper Networks 1194 North Mathilda Avenue Sunnyvale, CA 94089
Rahul Aggarwal杜松は1194の北のマチルダ・Avenueサニーベル、カリフォルニア 94089をネットワークでつなぎます。
EMail: rahul@juniper.net
メール: rahul@juniper.net
W. Mark Townsley Cisco Systems 7025 Kit Creek Road PO Box 14987 Research Triangle Park, NC 27709
7025年のW.マークTownsleyシスコシステムズキットクリーク道路私書箱14987リサーチトライアングル公園、NC 27709
EMail: mark@townsley.net
メール: mark@townsley.net
Maria Alice Dos Santos Cisco Systems 170 W Tasman Dr San Jose, CA 95134
サンノゼ、マリアアリスドス・サントスシスコシステムズ170Wタスマン博士カリフォルニア 95134
EMail: mariados@cisco.com
メール: mariados@cisco.com
Aggarwal, et al. Standards Track [Page 13] RFC 4719 Transport of Ethernet Frames over L2TPv3 November 2006
Aggarwal、他 L2TPv3 November 2006の上のイーサネットフレームの標準化過程[13ページ]RFC4719輸送
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2006).
IETFが信じる著作権(C)(2006)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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機能のための基金は現在、インターネット協会によって提供されます。
Aggarwal, et al. Standards Track [Page 14]
Aggarwal、他 標準化過程[14ページ]
一覧
スポンサーリンク
