RFC4623 日本語訳
4623 Pseudowire Emulation Edge-to-Edge (PWE3) Fragmentation andReassembly. A. Malis, M. Townsley. August 2006. (Format: TXT=36369 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group A. Malis
Request for Comments: 4623 Tellabs
Category: Standards Track M. Townsley
Cisco Systems
August 2006
Malisがコメントのために要求するワーキンググループA.をネットワークでつないでください: 4623年のTellabsカテゴリ: 標準化過程M.Townsleyシスコシステムズ2006年8月
Pseudowire Emulation Edge-to-Edge (PWE3)
Fragmentation and Reassembly
Pseudowireのエミュレーションの縁から縁(PWE3)への断片化とReassembly
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 Internet Society (2006).
Copyright(C)インターネット協会(2006)。
Abstract
要約
This document defines a generalized method of performing fragmentation for use by Pseudowire Emulation Edge-to-Edge (PWE3) protocols and services.
このドキュメントはPseudowire Emulation Edgeから縁(PWE3)へのプロトコルとサービスで使用のための断片化を実行する一般的な方法を定義します。
Malis & Townsley Standards Track [Page 1] RFC 4623 PWE3 Fragmentation and Reassembly August 2006
Malis&Townsley標準化過程[1ページ]RFC4623PWE3断片化とReassembly2006年8月
Table of Contents
目次
1. Introduction ....................................................3
2. Conventions Used in This Document ...............................4
3. Alternatives to PWE3 Fragmentation/Reassembly ...................5
4. PWE3 Fragmentation with MPLS ....................................5
4.1. Fragment Bit Locations for MPLS ............................6
4.2. Other Considerations .......................................6
5. PWE3 Fragmentation with L2TP ....................................6
5.1. PW-Specific Fragmentation vs. IP fragmentation .............7
5.2. Advertising Reassembly Support in L2TP .....................7
5.3. L2TP Maximum Receive Unit (MRU) AVP ........................8
5.4. L2TP Maximum Reassembled Receive Unit (MRRU) AVP ...........8
5.5. Fragment Bit Locations for L2TPv3 Encapsulation ............9
5.6. Fragment Bit Locations for L2TPv2 Encapsulation ............9
6. Security Considerations ........................................10
7. IANA Considerations ............................................10
7.1. Control Message Attribute Value Pairs (AVPs) ..............11
7.2. Default L2-Specific Sublayer Bits .........................11
7.3. Leading Bits of the L2TPv2 Message Header .................11
8. Acknowledgements ...............................................11
9. Normative References ...........................................12
10. Informative References ........................................12
Appendix A. Relationship Between This Document and RFC 1990 .......14
1. 序論…3 2. このドキュメントで中古のコンベンション…4 3. PWE3断片化/Reassemblyへの代替手段…5 4. MPLSとのPWE3断片化…5 4.1. MPLSのためにビット・ロケーションを断片化してください…6 4.2. 他の問題…6 5. L2TPとのPWE3断片化…6 5.1. PW特有のFragmentation対IP断片化…7 5.2. ReassemblyがL2TPで支持する広告…7 5.3. L2TP最大はユニット(MRU)AVPを受けます…8 5.4. 最大が組み立て直したL2TPはユニット(MRRU)AVPを受けます…8 5.5. L2TPv3カプセル化のためにビット・ロケーションを断片化してください…9 5.6. L2TPv2カプセル化のためにビット・ロケーションを断片化してください…9 6. セキュリティ問題…10 7. IANA問題…10 7.1. メッセージ属性値ペア(AVPs)を制御してください…11 7.2. デフォルトL2特有の副層ビット…11 7.3. L2TPv2メッセージヘッダーの主なビット…11 8. 承認…11 9. 標準の参照…12 10. 有益な参照…12 このドキュメントとRFC1990との付録A.関係…14
Malis & Townsley Standards Track [Page 2] RFC 4623 PWE3 Fragmentation and Reassembly August 2006
Malis&Townsley標準化過程[2ページ]RFC4623PWE3断片化とReassembly2006年8月
1. Introduction
1. 序論
The Pseudowire Emulation Edge-to-Edge Architecture Document [Architecture] defines a network reference model for PWE3:
Pseudowire Emulation Edgeから縁へのArchitecture Document[構造]はPWE3のためにネットワーク規範モデルを定義します:
|<-------------- Emulated Service ---------------->|
| |
| |<------- Pseudowire ------->| |
| | | |
| | |<-- PSN Tunnel -->| | |
| PW End V V V V PW End |
V Service +----+ +----+ Service V
+-----+ | | PE1|==================| PE2| | +-----+
| |----------|............PW1.............|----------| |
| CE1 | | | | | | | | CE2 |
| |----------|............PW2.............|----------| |
+-----+ ^ | | |==================| | | ^ +-----+
^ | +----+ +----+ | | ^
| | Provider Edge 1 Provider Edge 2 | |
| | | |
Customer | | Customer
Edge 1 | | Edge 2
| |
| |
native service native service
| <。-------------- 見習われたサービス---------------->|、|、|、| | <、-、-、-、-、-、-- Pseudowire------->|、|、|、|、|、|、|、| | <-- PSNはトンネルを堀ります-->|、|、|、| PW終わりのV V V V PWエンド| Vサービス+----+ +----+ サービス対+-----+ | | PE1|==================| PE2| | +-----+ | |----------|............PW1…|----------| | | CE1| | | | | | | | CE2| | |----------|............PW2…|----------| | +-----+ ^ | | |==================| | | ^ +-----+ ^ | +----+ +----+ | | ^ | | 1つのプロバイダー縁のプロバイダー縁2| | | | | | 顧客| | 顧客縁1| | 縁2| | | | ネイティブのサービスネイティブのサービス
Figure 1: PWE3 Network Reference Model
図1: PWE3ネットワーク規範モデル
A Pseudowire (PW) payload is normally relayed across the PW as a single IP or MPLS Packet Switched Network (PSN) Protocol Data Unit (PDU). However, there are cases where the combined size of the payload and its associated PWE3 and PSN headers may exceed the PSN path Maximum Transmission Unit (MTU). When a packet exceeds the MTU of a given network, fragmentation and reassembly will allow the packet to traverse the network and reach its intended destination.
通常、Pseudowire(PW)ペイロードは単一のIPかMPLS Packet Switched Network(PSN)プロトコルData Unit(PDU)としてPWの向こう側にリレーされます。 しかしながら、ケースがそのペイロードの結合したサイズ、関連PWE3、およびPSNヘッダーがPSN経路Maximum Transmission Unit(MTU)を超えるかもしれないところにあります。 パケットが与えられたネットワークのMTUを超えているとき、断片化と再アセンブリはパケットをネットワークを横断して、意図している目的地に達させるでしょう。
The purpose of this document is to define a generalized method of performing fragmentation for use with all PWE3 protocols and services. This method should be utilized only in cases where MTU- management methods fail. Due to the increased processing overhead, fragmentation and reassembly in core network devices should always be considered something to avoid whenever possible.
このドキュメントの目的はすべてのPWE3プロトコルとサービスで使用のための断片化を実行する一般的な方法を定義することです。 この方法はMTU管理法が失敗する場合だけで利用されるべきです。 増加する処理オーバヘッドのために、いつもコアネットワーク装置の断片化と再アセンブリは可能であるときはいつも、避ける考えられた何かであるべきです。
The PWE3 fragmentation and reassembly domain is shown in Figure 2:
PWE3断片化と再アセンブリドメインは図2に示されます:
Malis & Townsley Standards Track [Page 3] RFC 4623 PWE3 Fragmentation and Reassembly August 2006
Malis&Townsley標準化過程[3ページ]RFC4623PWE3断片化とReassembly2006年8月
|<-------------- Emulated Service ---------------->|
| |<---Fragmentation Domain--->| |
| ||<------- Pseudowire ----->|| |
| || || |
| || |<-- PSN Tunnel -->| || |
| PW End VV V V VV PW End |
V Service +----+ +----+ Service V
+-----+ | | PE1|==================| PE2| | +-----+
| |----------|............PW1.............|----------| |
| CE1 | | | | | | | | CE2 |
| |----------|............PW2.............|----------| |
+-----+ ^ | | |==================| | | ^ +-----+
^ | +----+ +----+ | | ^
| | Provider Edge 1 Provider Edge 2 | |
| | | |
Customer | | Customer
Edge 1 | | Edge 2
| |
| |
native service native service
| <。-------------- 見習われたサービス---------------->|、| | <、-、--断片化ドメイン--->|、|、| | | <、-、-、-、-、-、-- Pseudowire----->|、|、|、| || || | | || | <-- PSNはトンネルを堀ります-->| || | | PW終わりのVV V V VV PWエンド| Vサービス+----+ +----+ サービス対+-----+ | | PE1|==================| PE2| | +-----+ | |----------|............PW1…|----------| | | CE1| | | | | | | | CE2| | |----------|............PW2…|----------| | +-----+ ^ | | |==================| | | ^ +-----+ ^ | +----+ +----+ | | ^ | | 1つのプロバイダー縁のプロバイダー縁2| | | | | | 顧客| | 顧客縁1| | 縁2| | | | ネイティブのサービスネイティブのサービス
Figure 2: PWE3 Fragmentation/Reassembly Domain
図2: PWE3断片化/Reassemblyドメイン
Fragmentation takes place in the transmitting PE immediately prior to PW encapsulation, and reassembly takes place in the receiving PE immediately after PW decapsulation.
断片化はPWカプセル化のすぐ前に伝わっているPEで行われます、そして、再アセンブリはPW被膜剥離術直後受信PEで行われます。
Since a sequence number is necessary for the fragmentation and reassembly procedures, using the Sequence Number field on fragmented packets is REQUIRED (see Sections 4.1 and 5.5 for the location of the Sequence Number fields for MPLS and L2TPv3 encapsulations, respectively). The order of operation is that first fragmentation is performed, and then the resulting fragments are assigned sequential sequence numbers.
一連番号が断片化と再アセンブリ手順に必要であるので、断片化しているパケットのSequence Number分野を使用するのは、REQUIRED(MPLSとL2TPv3カプセル化に関してそれぞれSequence Number分野の位置にセクション4.1と5.5を見る)です。 操作の注文は最初に、断片化が実行されて、次に、連続した一連番号が結果として起こる断片に割り当てられるということです。
Depending on the specific PWE3 encapsulation in use, the value 0 may not be a part of the sequence number space, in which case its use for fragmentation must follow this same rule: as the sequence number is incremented, it skips zero and wraps from 65535 to 1. Conversely, if the value 0 is part of the sequence space, then the same sequence space is also used for fragmentation and reassembly.
使用中の特定のPWE3カプセル化によって、値0が一連番号スペースの一部でないかもしれない、その場合、断片化の使用はこの同じ規則に従わなければなりません: 一連番号が増加されているので、それは65535〜1までゼロと機密をスキップします。 また、逆に、同じ当時の系列スペースは値0が系列スペースの一部であるなら、断片化と再アセンブリに使用されます。
2. Conventions Used in This Document
2. 本書では使用されるコンベンション
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 RFC 2119 [KEYWORDS].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[キーワード]で説明されるように本書では解釈されることであるべきですか?
Malis & Townsley Standards Track [Page 4] RFC 4623 PWE3 Fragmentation and Reassembly August 2006
Malis&Townsley標準化過程[4ページ]RFC4623PWE3断片化とReassembly2006年8月
3. Alternatives to PWE3 Fragmentation/Reassembly
3. PWE3断片化/Reassemblyへの代替手段
Fragmentation and reassembly in network equipment generally requires significantly greater resources than sending a packet as a single unit. As such, fragmentation and reassembly should be avoided whenever possible. Ideal solutions for avoiding fragmentation include proper configuration and management of MTU sizes between the Customer Edge (CE) router and Provider Edge (PE) router and across the PSN, as well as adaptive measures that operate with the originating host (e.g., [PATHMTU], [PATHMTUv6]) to reduce the packet sizes at the source.
一般に、ネットワーク装置の断片化と再アセンブリは単一の単位としてパケットを送るよりかなりすばらしいリソースを必要とします。 そういうものとして、可能であるときはいつも、断片化と再アセンブリは避けられるべきです。 断片化を避ける理想的な解決はCustomer Edge(CE)ルータとProvider Edge(PE)ルータの間と、そして、PSNの向こう側にMTUサイズの適切な構成と管理を含んでいます、ソースにおけるパケットサイズを減少させるために送信元ホスト(例えば、[PATHMTU]、[PATHMTUv6])と共に作動する適応型の測定と同様に。
In some cases, a PE may be able to fragment an IP version 4 (IPv4) [RFC791] packet before it enters a PW. For example, if the PE can fragment and forward IPv4 packets with the DF bit clear in a manner that is identical to an IPv4 router, it may fragment packets arriving from a CE, forwarding the IPv4 fragments with associated framing for that attachment circuit (AC) over the PW. Architecturally, the IPv4 fragmentation happens before reaching the PW, presenting multiple frames to the PW to forward in the normal manner for that PWType. Thus, this method is entirely transparent to the PW encapsulation and to the remote end of the PW itself. Packet fragments are ultimately reassembled on the destination IPv4 host in the normal way. IPv6 packets are not to be fragmented in this manner.
いくつかの場合、PWに入る前にPEはIPバージョン4(IPv4)[RFC791]パケットを断片化できるかもしれません。 例えば、PEが断片化できて、DFビットがある前進のIPv4パケットがIPv4ルータと同じ方法できれいにされるなら、CEから到着するパケットを断片化するかもしれません、PWの上のその付属サーキット(西暦)のための関連縁どりと共にIPv4断片を進めて。 建築上、PWに達する前にIPv4断片化は起こります、そのPWTypeのために正常な方法でPWへの複数のフレームをフォワードに贈って。 したがって、この方法はPWカプセル化と、そして、PW自身のリモートエンドに完全に見え透いています。 パケット断片は結局、目的地IPv4ホストの上で正常な方法で組み立て直されます。 この様にIPv6パケットを断片化してはいけません。
4. PWE3 Fragmentation with MPLS
4. MPLSとのPWE3断片化
When using the signaling procedures in [MPLS-Control], there is a Pseudowire Interface Parameter Sub-TLV type used to signal the use of fragmentation when advertising a VC label [IANA]:
[MPLS-コントロール]でシグナリング手順を用いるとき、VCラベル[IANA]の広告を出すとき断片化の使用に合図するのに使用されるPseudowire Interface Parameter Sub-TLVタイプがあります:
Parameter Length Description
0x09 4 Fragmentation indicator
パラメタLength記述0x09 4Fragmentationインディケータ
The presence of this parameter in the VC FEC element indicates that the receiver is able to reassemble fragments when the control word is in use for the VC label being advertised. It does not obligate the sender to use fragmentation; it is simply an indication that the sender MAY use fragmentation. The sender MUST NOT use fragmentation if this parameter is not present in the VC FEC element.
VC FEC要素でのこのパラメタの存在は、広告に掲載されているVCラベルに、規制単語が使用中であるときに、受信機が断片を組み立て直すことができるのを示します。 それは、送付者が断片化を使用するのを義務付けません。 それは単に送付者が断片化を使用するかもしれないという指示です。 このパラメタがVC FEC要素に存在していないなら、送付者は断片化を使用してはいけません。
If [MPLS-Control] signaling is not in use, then whether or not to use fragmentation MUST be configured in the sender.
[MPLS-コントロール]シグナリングが使用中でないなら、送付者で断片化を使用するかどうか構成しなければなりません。
Malis & Townsley Standards Track [Page 5] RFC 4623 PWE3 Fragmentation and Reassembly August 2006
Malis&Townsley標準化過程[5ページ]RFC4623PWE3断片化とReassembly2006年8月
4.1. Fragment Bit Locations for MPLS
4.1. MPLSのための断片ビット・ロケーション
MPLS-based PWE3 uses the following control word format [Control-Word], with the B and E fragmentation bits identified in position 8 and 9:
MPLSベースのPWE3は以下のコントロール語形式[コントロールして言い表す]を使用します、BとE断片化ビットが位置8と9で特定されている状態で:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0| Flags |B|E| Length | 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0| 旗|B|E| 長さ| 一連番号| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Preferred PW MPLS Control Word
図3: コントロールが言い表す都合のよいPW MPLS
The B and E bits are defined as follows:
BとEビットは以下の通り定義されます:
BE
--
00 indicates that the entire (un-fragmented) payload is carried
in a single packet
01 indicates the packet carrying the first fragment
10 indicates the packet carrying the last fragment
11 indicates a packet carrying an intermediate fragment
いてください--、00が示す、全体(不-断片化される)のペイロードが中まで運ばれて、単一のパケット01が、1番目を運ぶパケットが10を断片化するのを示すということであることは、最後の断片11を運ぶパケットが中間的断片を運ぶパケットを示すのを示します。
See Appendix A for a discussion of the derivation of these values for the B and E bits.
これらの値の派生の議論に関してAppendix AをBとEビット見てください。
See Section 1 for the description of the use of the Sequence Number field.
Sequence Number分野の使用の記述に関してセクション1を見てください。
4.2. Other Considerations
4.2. 他の問題
Path MTU [PATHMTU] [PATHMTUv6] may be used to dynamically determine the maximum size for fragments. The application of path MTU to MPLS is discussed in [LABELSTACK]. The maximum size of the fragments may also be configured. The signaled Interface MTU parameter in [MPLS-Control] SHOULD be used to set the maximum size of the reassembly buffer for received packets to make optimal use of reassembly buffer resources.
経路MTU[PATHMTU][PATHMTUv6]は、断片のためにダイナミックに最大サイズを測定するのに使用されるかもしれません。 [LABELSTACK]でMPLSへの経路MTUのアプリケーションについて議論します。 また、断片の最大サイズは構成されるかもしれません。 [MPLS-コントロール]SHOULDでは、合図されたInterface MTUパラメタ、使用されて、容認されたパケットのための再アセンブリバッファの最大サイズに再アセンブリバッファ資源の最適の使用をするように設定してください。
5. PWE3 Fragmentation with L2TP
5. L2TPとのPWE3断片化
This section defines the location of the B and E bits for L2TPv3 [L2TPv3] and L2TPv2 [L2TPv2] headers, as well as the signaling mechanism for advertising MRU (Maximum Receive Unit) values and support for fragmentation on a given PW. As IP is the most common PSN used with L2TP, IP PSN fragmentation and reassembly is discussed as well.
このセクションはL2TPv3[L2TPv3]とL2TPv2[L2TPv2]ヘッダーのためにBとEビットの位置を定義します、広告MRU(最大のReceive Unit)値のためのシグナル伝達機構と与えられたPWにおける断片化のサポートと同様に。 IPが最も一般的であるので、また、L2TP、IP PSN断片化、および再アセンブリと共に使用されるPSNについて議論します。
Malis & Townsley Standards Track [Page 6] RFC 4623 PWE3 Fragmentation and Reassembly August 2006
Malis&Townsley標準化過程[6ページ]RFC4623PWE3断片化とReassembly2006年8月
5.1. PW-Specific Fragmentation vs. IP fragmentation
5.1. PW特有のFragmentation対IP断片化
When proper MTU management across a network fails, IP PSN fragmentation and reassembly may be used to accommodate MTU mismatches between tunnel endpoints. If the overall traffic requiring fragmentation and reassembly is very light, or there are sufficient optimized mechanisms for IP PSN fragmentation and reassembly available, IP PSN fragmentation and reassembly may be sufficient.
ネットワークの向こう側の適切なMTU管理が行き詰まると、IP PSN断片化と再アセンブリは、トンネル終点の間にMTUミスマッチを収容するのに使用されるかもしれません。 断片化と再アセンブリを必要とする総合的な交通が非常に軽いか、または利用可能なIP PSN断片化と再アセンブリに、十分な最適化されたメカニズムがあれば、IP PSN断片化と再アセンブリは十分であるかもしれません。
When facing a large number of PW packets requiring fragmentation and reassembly, a PW-specific method has properties that potentially allow for more resource-friendly implementations. Specifically, the ability to assign buffer usage on a per-PW basis and PW sequencing may be utilized to gain advantage over a general mechanism applying to all IP packets across all PWs. Further, PW fragmentation may be more easily enabled in a selective manner for some or all PWs, rather than enabling reassembly for all IP traffic arriving at a given node.
断片化と再アセンブリを必要とする多くのPWパケットに面しているとき、PW特有の方法には、潜在的に以上に、リソースに優しい実現を許す特性があります。 明確に、1PWあたりの基礎とPW配列のときにバッファの使用状況を割り当てる能力は、すべてのPWsの向こう側にすべてのIPパケットに適用される一般的機構より利点を獲得するのに利用されるかもしれません。 さらに、PW断片化はいくつかかすべてのPWsのために選択している方法で再アセンブリを与えられたノードに到着するすべてのIP交通に有効にするより容易にむしろ可能にされるかもしれません。
Deployments SHOULD avoid a situation that uses a combination of IP PSN and PW fragmentation and reassembly on the same node. Such operation clearly defeats the purpose behind the mechanism defined in this document. This is especially important for L2TPv3 pseudowires, since potentially fragmentation can take place in three different places (the IP PSN, the PW, and the encapsulated payload). Care must be taken to ensure that the MTU/MRU values are set and advertised properly at each tunnel endpoint to avoid this. When fragmentation is enabled within a given PW, the DF bit MUST be set on all L2TP over IP packets for that PW.
展開SHOULDはIP PSNとPW断片化の組み合わせを使用する状況を避けて、同じノードの上で再アセンブリします。 そのような操作は本書では定義されたメカニズムの後ろで明確に目的をくつがえします。 L2TPv3 pseudowiresに、これは特に重要です、断片化が3つの異なった場所(IP PSN、PW、および要約のペイロード)で潜在的に行われることができるので。 注意をMTU/MRU値が設定されるのを保証するために払って、これを避けるためにそれぞれのトンネル終点に適切に広告を出さなければなりません。 断片化が与えられたPWの中で可能にされるとき、DFビットはそのPWのためのIPパケットの上のすべてのL2TPのセットであるに違いありません。
L2TPv3 nodes SHOULD participate in Path MTU ([PATHMTU], [PATHMTUv6]) for automatic adjustment of the PSN MTU. When the payload is IP, Path MTU should be used at they payload level as well.
L2TPv3ノードSHOULDはPSN MTUの自動調整のために、Path MTU([PATHMTU]、[PATHMTUv6])に参加します。 ペイロードがIPである、Path MTUがいつ使用されるべきであるか、それら、また、ペイロードレベル。
5.2. Advertising Reassembly Support in L2TP
5.2. ReassemblyがL2TPで支持する広告
The constructs defined in this section for advertising fragmentation support in L2TP are applicable to [L2TPv3] and [L2TPv2].
L2TPでの広告断片化サポートのためにこのセクションで定義された構造物は[L2TPv3]と[L2TPv2]に適切です。
This document defines two new AVPs to advertise maximum receive unit values and reassembly support. These AVPs MAY be present in the Incoming-Call-Request (ICRQ), Incoming-Call-Reply (ICRP), Incoming- Call-Connected (ICCN), Outgoing-Call-Request (OCRQ), Outgoing-Call- Reply (OCRP), Outgoing-Call-Connected (OCCN), or Set-Link-Info (SLI) messages. The most recent value received always takes precedence over a previous value and MUST be dynamic over the life of the
このドキュメントは、最大の状態で広告を出すために2新しいAVPsを定義します。単価と再アセンブリサポートを受けてください。 これらのAVPsがIncoming呼び出し要求(ICRQ)、Incoming呼び出し回答(ICRP)、Incomingの呼び出しで接続された(ICCN)に存在しているかもしれない、Outgoing呼び出し要求、(OCRQ)、Outgoing-呼び出し回答(OCRP)、Outgoing呼び出しが接続したか(OCCN)、またはSetリンクインフォメーション(SLI)は通信します。 最新の対価領収は、前の値の上でいつも優先して、人生の間、ダイナミックであるに違いありません。
Malis & Townsley Standards Track [Page 7] RFC 4623 PWE3 Fragmentation and Reassembly August 2006
Malis&Townsley標準化過程[7ページ]RFC4623PWE3断片化とReassembly2006年8月
session if received via the SLI message. One of the two new AVPs (MRRU) is used to advertise that PWE3 reassembly is supported by the sender of the AVP. Reassembly support MAY be unidirectional.
SLIを通して受け取るなら、セッションは通信します。 2新しいAVPs(MRRU)の1つは、PWE3 reassemblyがAVPの送付者によって支持されるのは広告を出すのに使用されます。 Reassemblyサポートは単方向であるかもしれません。
5.3. L2TP Maximum Receive Unit (MRU) AVP
5.3. L2TP最大はユニット(MRU)AVPを受けます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|H|0|0|0|0| Length | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MRU |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |M|H|0|0|0|0| 長さ| 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ムル人| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: L2TP Maximum Receive Unit (MRU) AVP
図4: L2TP最大はユニット(MRU)AVPを受けます。
MRU (Maximum Receive Unit), attribute number 94, is the maximum size, in octets, of a fragmented or complete PW frame, including L2TP encapsulation, receivable by the side of the PW advertising this value. The advertised MRU does NOT include the PSN header (i.e., the IP and/or UDP header). This AVP does not imply that PWE3 fragmentation or reassembly is supported. If reassembly is not enabled or unavailable, this AVP may be used alone to advertise the MRU for a complete frame.
MRU(最大のReceive Unit)(属性No.94)は最大サイズです、断片化しているか完全なPWフレームの八重奏で、L2TPカプセル化を含んでいて、この値の広告を出すPWの側面で、受け取ることができます。 広告を出しているMRUはPSNヘッダー(すなわち、IP、そして/または、UDPヘッダー)を含んでいません。 このAVPは、PWE3断片化か再アセンブリが支持されるのを含意しません。 再アセンブリが可能にされないで、また入手できなくないなら、このAVPは、完全なフレームにMRUの広告を出すのに単独で使用されるかもしれません。
This AVP MAY be hidden (the H bit MAY be 0 or 1). The mandatory (M) bit for this AVP SHOULD be set to 0. The Length (before hiding) is 8. The Vendor ID is the IETF Vendor ID of 0.
このAVP MAY、隠されてください(Hビットは、0か1であるかもしれません)。 義務的な(M)はこのAVP SHOULDのために噛み付きました。0に設定されます。 Length(隠れることの前の)は8歳です。 Vendor IDは0のIETF Vendor IDです。
5.4. L2TP Maximum Reassembled Receive Unit (MRRU) AVP
5.4. 最大が組み立て直したL2TPはユニット(MRRU)AVPを受けます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|H|0|0|0|0| Length | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MRRU |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |M|H|0|0|0|0| 長さ| 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MRRU| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: L2TP Maximum Reassembled Receive Unit (MRRU) AVP
図5: 最大が組み立て直したL2TPはユニット(MRRU)AVPを受けます。
MRRU (Maximum Reassembled Receive Unit AVP), attribute number 95, is the maximum size, in octets, of a reassembled frame, including any PW framing, but not including the L2TP encapsulation or L2-specific sublayer. Presence of this AVP signifies the ability to receive PW fragments and reassemble them. Packet fragments MUST NOT be sent by a peer that has not received this AVP in a control message. If the MRRU is present in a message, the MRU AVP MUST be present as well.
MRRU(最大のReassembled Receive Unit AVP)(属性No.95)は最大サイズです、組み立て直されたフレームの八重奏で、どんなPW縁どりも含んでいますが、L2TPカプセル化かL2特有の副層は含んでいなくて。 このAVPの存在はPW断片を受けて、それらを組み立て直す能力を意味します。 パケット断片はコントロールメッセージにこのAVPを受け取っていない同輩によって送られてはいけません。 MRRUであるなら、プレゼントが同じくらい良かったなら、プレゼントがメッセージ、MRU AVP MUSTにありますか?
Malis & Townsley Standards Track [Page 8] RFC 4623 PWE3 Fragmentation and Reassembly August 2006
Malis&Townsley標準化過程[8ページ]RFC4623PWE3断片化とReassembly2006年8月
The MRRU SHOULD be used to set the maximum size of the reassembly buffer for received packets to make optimal use of reassembly buffer resources.
MRRU SHOULD、使用されて、容認されたパケットのための再アセンブリバッファの最大サイズに再アセンブリバッファ資源の最適の使用をするように設定してください。
This AVP MAY be hidden (the H bit MAY be 0 or 1). The mandatory (M) bit for this AVP SHOULD be set to 0. The Length (before hiding) is 8. The Vendor ID is the IETF Vendor ID of 0.
このAVP MAY、隠されてください(Hビットは、0か1であるかもしれません)。 義務的な(M)はこのAVP SHOULDのために噛み付きました。0に設定されます。 Length(隠れることの前の)は8歳です。 Vendor IDは0のIETF Vendor IDです。
5.5. Fragment Bit Locations for L2TPv3 Encapsulation
5.5. L2TPv3カプセル化のための断片ビット・ロケーション
The usage of the B and E bits is described in Section 4.1. For L2TPv3 encapsulation, the B and E bits are defined as bits 2 and 3 in the leading bits of the Default L2-Specific Sublayer (see Section 7).
BとEビットの使用法はセクション4.1で説明されます。 L2TPv3カプセル化において、BとEビットはDefault L2特有のSublayerの主なビットでビット2と3と定義されます(セクション7を見てください)。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|H|0|0|0|0| Length | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x|S|B|E|x|x|x|x| 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |M|H|0|0|0|0| 長さ| 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |x|S|B|E|x|x|x|x| 一連番号| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: B and E Bits Location in the Default L2-Specific Sublayer
図6: デフォルトのL2特有の副層におけるBとEビット位置
The S (Sequence) bit is as defined in [L2TPv3]. Location of the B and E bits for PW-Types that use a variant L2 specific sublayer are outside the scope of this document.
S(系列)ビットが[L2TPv3]で定義されるようにあります。 このドキュメントの範囲の外に異形のL2の特定の副層を使用するBの位置とPW-タイプのためのEビットがあります。
When fragmentation is used, an L2-Specific Sublayer with B and E bits defined MUST be present in all data packets for a given session. The presence and format of the L2-Specific Sublayer is advertised via the L2-Specific Sublayer AVP, Attribute Type 69, defined in Section 5.4.4 of [L2TPv3].
断片化が使用されているとき、BとEビットが定義されているL2特有のSublayerは与えられたセッションの間、すべてのデータ・パケットに存在していなければなりません。 L2特有のSublayer AVP、.4セクション5.4[L2TPv3]で定義されたAttribute Type69を通してL2特有のSublayerの存在と形式の広告を出します。
See Section 1 for the description of the use of the Sequence Number field.
Sequence Number分野の使用の記述に関してセクション1を見てください。
5.6. Fragment Bit Locations for L2TPv2 Encapsulation
5.6. L2TPv2カプセル化のための断片ビット・ロケーション
The usage of the B and E bits is described in Section 4.1. For L2TPv2 encapsulation, the B and E bits are defined as bits 8 and 9 in the leading bits of the L2TPv2 header as depicted below (see Section 7).
BとEビットの使用法はセクション4.1で説明されます。 L2TPv2カプセル化において、BとEビットは以下に表現されるL2TPv2ヘッダーの主なビットの8と9ビットと定義されます(セクション7を見てください)。
Malis & Townsley Standards Track [Page 9] RFC 4623 PWE3 Fragmentation and Reassembly August 2006
Malis&Townsley標準化過程[9ページ]RFC4623PWE3断片化とReassembly2006年8月
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|H|0|0|0|0| Length | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T|L|x|x|S|x|O|P|B|E|x|x| Ver | Length (opt) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |M|H|0|0|0|0| 長さ| 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |T|L|x|x|S|x|O|P|B|E|x|x| Ver| 長さ(選びます)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: B and E bits location in the L2TPv2 Message Header
図7: L2TPv2 Message HeaderのBとEビット位置
6. Security Considerations
6. セキュリティ問題
As with any additional protocol construct, each level of complexity adds the potential to exploit protocol and implementation errors. Implementers should be especially careful of not tying up an abundance of resources, even for the most pathological combination of packet fragments that could be received. Beyond these issues of general implementation quality, there are no known notable security issues with using the mechanism defined in this document. It should be pointed out that RFC 1990, on which this document is based, and its derivatives have been widely implemented and extensively used in the Internet and elsewhere.
どんな追加議定書構造物のようにも、それぞれのレベルの複雑さはプロトコルと実現誤りを利用する可能性を加えます。 Implementersはリソースの豊富をタイアップしないように特に注意しているべきです、受け取ることができたパケット断片の最も病理学的な組み合わせのためにさえ。 一般的な実現品質のこれらの問題を超えて、メカニズムを使用する本書では定義される注目に値する安全保障問題は知られていません。 このドキュメントが基づいているRFC1990、およびその派生物が広く実行されて、インターネットとほかの場所で手広く使用されたと指摘されるべきです。
[IPFRAG-SEC] and [TINYFRAG] describe potential network attacks associated with IP fragmentation and reassembly. The issues described in these documents attempt to bypass IP access controls by sending various carefully formed "tiny fragments", or by exploiting the IP offset field to cause fragments to overlap and rewrite interesting portions of an IP packet after access checks have been performed. The latter is not an issue with the PW-specific fragmentation method described in this document, as there is no offset field. However, implementations MUST be sure not to allow more than one whole fragment to overwrite another in a reconstructed frame. The former may be a concern if packet filtering and access controls are being placed on tunneled frames within the PW encapsulation. To circumvent any possible attacks in either case, all filtering and access controls should be applied to the resulting reconstructed frame rather than any PW fragments.
[IPFRAG-SEC]と[TINYFRAG]は、IP断片化に関連している潜在的ネットワーク攻撃について説明して、再アセンブリします。 これらのドキュメントで説明された問題は、様々な慎重に形成された「小さい断片」を送ることによってIPアクセス管理を迂回させたか、またはアクセスがチェックした後に断片がIPパケットのおもしろい部分を重ね合わせて、書き直すことを引き起こすのにIPのオフセット分野を利用することによって実行されたのを試みます。 後者は本書では説明されるPW特有の断片化方法の問題ではありません、どんなオフセット分野もないとき。 しかしながら、実現は、1個以上の全体の断片が再建されたフレームで別のものを上書きするのを許容しないように確かでなければなりません。 パケットフィルタリングとアクセス管理がPWカプセル化の中にトンネルを堀られたフレームに置かれているなら、前者は関心であるかもしれません。 どちらかのケース、すべてのフィルタリング、およびアクセス管理におけるどんな可能な攻撃も回避するのはどんなPW断片よりもむしろ結果として起こる再建されたフレームに適用されるべきです。
7. IANA Considerations
7. IANA問題
This document does not define any new registries for IANA to maintain.
このドキュメントはIANAが維持するどんな新しい登録も定義しません。
Note that [IANA] has already allocated the Fragmentation Indicator interface parameter, so no further IANA action is required.
さらなるIANA動作は全く必要でないように[IANA]が既にFragmentation Indicatorインタフェース・パラメータを割り当てたことに注意してください。
Malis & Townsley Standards Track [Page 10] RFC 4623 PWE3 Fragmentation and Reassembly August 2006
Malis&Townsley標準化過程[10ページ]RFC4623PWE3断片化とReassembly2006年8月
This document requires IANA to assign new values for registries already managed by IANA (see Sections 7.1 and 7.2) and two reserved bits in an existing header (see Section 7.3).
このドキュメントは、IANAがIANAによって既に管理された登録に新しい値を割り当てるのを必要とします、そして、(セクション7.1と7.2を見てください)2は既存のヘッダーでビットを予約しました(セクション7.3を見てください)。
7.1. Control Message Attribute Value Pairs (AVPs)
7.1. コントロールメッセージ属性値ペア(AVPs)
Two additional AVP Attributes are specified in Sections 5.3 and 5.4. They are required to be defined by IANA as described in Section 2.2 of [BCP0068].
2追加AVP Attributesがセクション5.3と5.4で指定されます。 [BCP0068]のセクション2.2で説明されるIANAによって彼らは定義されなければなりません。
Control Message Attribute Value Pairs -------------------------------------
コントロールメッセージ属性値ペア-------------------------------------
94 - Maximum Receive Unit (MRU) AVP 95 - Maximum Reassembled Receive Unit (MRRU) AVP
最大がユニット(MRU)AVP95を受けるという最大が組み立て直した94はユニット(MRRU)AVPを受けます。
7.2. Default L2-Specific Sublayer Bits
7.2. デフォルトL2特有の副層ビット
This registry was created as part of the publication of [L2TPv3]. This document defines two reserved bits in the Default L2-Specific Sublayer in Section 5.5, which may be assigned by IETF Consensus [RFC2434]. They are required to be assigned by IANA.
この登録は[L2TPv3]の公表の一部として作成されました。 このドキュメントはセクション5.5でDefault L2特有のSublayerで予約された2ビットを定義します。(それは、IETF Consensus[RFC2434]によって割り当てられるかもしれません)。 IANAによって彼らは割り当てられなければなりません。
Default L2-Specific Sublayer bits - per [L2TPv3] ---------------------------------
[L2TPv3]あたりのデフォルトL2特有のSublayerビット---------------------------------
Bit 2 - B (Fragmentation) bit Bit 3 - E (Fragmentation) bit
ビット2--B(断片化)はBit3に噛み付きました--E(断片化)に噛み付きました。
7.3. Leading Bits of the L2TPv2 Message Header
7.3. L2TPv2メッセージヘッダーの主なビット
This document requires definition of two reserved bits in the L2TPv2 [L2TPv2] header. Locations are noted by the "B" and "E" bits in Section 5.6.
このドキュメントはL2TPv2[L2TPv2]ヘッダーとの予約された2ビットの定義を必要とします。 位置はセクション5.6に「B」と「E」ビットによって述べられます。
Leading Bits of the L2TPv2 Message Header - per [L2TPv2, L2TPv3] -----------------------------------------
[L2TPv2、L2TPv3]あたりのL2TPv2メッセージヘッダーの主なビット-----------------------------------------
Bit 8 - B (Fragmentation) bit Bit 9 - E (Fragmentation) bit
ビット8--B(断片化)はBit9に噛み付きました--E(断片化)に噛み付きました。
8. Acknowledgements
8. 承認
The authors wish to thank Eric Rosen and Carlos Pignataro, both of Cisco Systems, for their review of this document.
作者は彼らのこのドキュメントのレビューについてシスコシステムズの両方の、エリック・ローゼンとカルロスPignataroに感謝したがっています。
Malis & Townsley Standards Track [Page 11] RFC 4623 PWE3 Fragmentation and Reassembly August 2006
Malis&Townsley標準化過程[11ページ]RFC4623PWE3断片化とReassembly2006年8月
9. Normative References
9. 引用規格
[Control-Word] Bryant, S., Swallow, G., Martini, L., and D.
McPherson, "Pseudowire Emulation Edge-to-Edge (PWE3)
Control Word for Use over an MPLS PSN", RFC 4385,
February 2006.
[コントロールして言い表します] ブライアント、S.は飲み込まれます、マティーニ、L.とD.マクファーソン、「縁から縁(PWE3)へのコントロールがMPLS PSNの上の使用のために言い表すPseudowireエミュレーション」RFC4385、G.、2006年2月。
[IANA] Martini, L., "IANA Allocations for Pseudowire Edge to
Edge Emulation (PWE3)", BCP 116, RFC 4446, April 2006.
[IANA] マティーニ、L.、「PseudowireのためのIANA配分はエミュレーション(PWE3)を斜めに進ませるために斜めに進む」BCP116、RFC4446、2006年4月。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[KEYWORDS]ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[LABELSTACK] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
Encoding", RFC 3032, January 2001.
[LABELSTACK] ローゼン、E.、タッパン、D.、Fedorkow、G.、Rekhter、Y.、ファリナッチ、D.、李、T.、およびA.コンタ、「MPLSラベルスタックコード化」、RFC3032(2001年1月)。
[L2TPv2] Townsley, W., Valencia, A., Rubens, A., Pall, G.,
Zorn, G., and B. Palter, "Layer Two Tunneling Protocol
"L2TP"", RFC 2661, August 1999.
[L2TPv2]Townsley、W.、バレンシア、A.、ルーベン、A.、祭服、G.、ゾルン、G.、およびB.はあしらいます、「層Twoはプロトコル"L2TP"にトンネルを堀っ」て、RFC2661、1999年8月。
[L2TPv3] Lau, J., Townsley, M., and I. Goyret, "Layer Two
Tunneling Protocol - Version 3 (L2TPv3)", RFC 3931,
March 2005.
[L2TPv3] ラウ、J.、Townsley、M.、およびI.Goyret、「2トンネリングプロトコルを層にしてください--バージョン3(L2TPv3)」、RFC3931、3月2005日
[MLPPP] Sklower, K., Lloyd, B., McGregor, G., Carr, D., and T.
Coradetti, "The PPP Multilink Protocol (MP)", RFC
1990, August 1996.
[MLPPP] Sklower、K.、ロイド、B.、マクレガー、G.、カー、D.、およびT.Coradetti、「pppマルチリンクは(MP)について議定書の中で述べます」、RFC1990、1996年8月。
[MPLS-Control] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and
G. Heron, "Pseudowire Setup and Maintenance Using the
Label Distribution Protocol (LDP)", RFC 4447, April
2006.
[MPLS-コントロール]のマティーニ、L.、ローゼン、E.、高架鉄道-Aawar、N.、スミス、T.、およびG.サギ、「ラベル分配を使用するPseudowireセットアップと維持が(自由民主党)について議定書の中で述べます」、RFC4447、2006年4月。
[PATHMTU] Mogul, J. and S. Deering, "Path MTU discovery", RFC
1191, November 1990.
[PATHMTU] ムガール人とJ.とS.デアリング、「経路MTU探索」、RFC1191、1990年11月。
[PATHMTUv6] McCann, J., Deering, S., and J. Mogul, "Path MTU
Discovery for IP version 6", RFC 1981, August 1996.
[PATHMTUv6] マッキャン、J.、デアリング、S.、およびJ.ムガール人、「IPのための経路MTUディスカバリー、バージョン6インチ、RFC1981、1996インチ年8月。
10. Informative References
10. 有益な参照
[Architecture] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-
to-Edge (PWE3) Architecture", RFC 3985, March 2005.
[構造] ブライアントとS.とP.頭、「疑似ワイヤエミュレーション縁縁への(PWE3)構造」、RFC3985、2005年3月。
Malis & Townsley Standards Track [Page 12] RFC 4623 PWE3 Fragmentation and Reassembly August 2006
Malis&Townsley標準化過程[12ページ]RFC4623PWE3断片化とReassembly2006年8月
[BCP0068] Townsley, W., "Layer Two Tunneling Protocol (L2TP)
Internet Assigned Numbers Authority (IANA)
Considerations Update", BCP 68, RFC 3438, December
2002.
w.[BCP0068]Townsley、「層Twoのトンネリングプロトコル(L2TP)インターネットは問題がアップデートする数の権威(IANA)を割り当てました」、BCP68、RFC3438、2002年12月。
[FAST] ATM Forum, "Frame Based ATM over SONET/SDH Transport
(FAST)", af-fbatm-0151.000, July 2000.
[FAST]ATM Forum、「Sonet/SDH輸送(速い)の上のフレームのベースの気圧」、af-fbatm-0151.000、2000年7月。
[FRF.12] Frame Relay Forum, "Frame Relay Fragmentation
Implementation Agreement", FRF.12, December 1997.
[FRF.12] フレームリレーフォーラム、「フレームリレー断片化実現協定」、FRF.12、1997年12月。
[IPFRAG-SEC] Ziemba, G., Reed, D., and P. Traina, "Security
Considerations for IP Fragment Filtering", RFC 1858,
October 1995.
[IPFRAG-SEC] 1995年10月のZiembaとG.とリード、D.とP.Traina、「IP断片フィルタリングのためのセキュリティ問題」RFC1858。
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing
an IANA Considerations Section in RFCs", BCP 26, RFC
2434, October 1998.
[RFC2434]Narten、T.とH.Alvestrand、「RFCsにIANA問題部に書くためのガイドライン」BCP26、RFC2434(1998年10月)。
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981.
[RFC791] ポステル、J.、「インターネットプロトコル」、STD5、RFC791、1981年9月。
[TINYFRAG] Miller, I., "Protection Against a Variant of the Tiny
Fragment Attack (RFC 1858)", RFC 3128, June 2001.
[TINYFRAG]ミラー、I.、「小さい断片攻撃の異形に対する保護、(RFC1858)、」、RFC3128、6月2001日
Malis & Townsley Standards Track [Page 13] RFC 4623 PWE3 Fragmentation and Reassembly August 2006
Malis&Townsley標準化過程[13ページ]RFC4623PWE3断片化とReassembly2006年8月
Appendix A. Relationship between This Document and RFC 1990
このドキュメントとRFC1990との付録A.関係
The fragmentation of large packets into smaller units for transmission is not new. One fragmentation and reassembly method was defined in RFC 1990, Multi-Link PPP [MLPPP]. This method was also adopted for both Frame Relay [FRF.12] and ATM [FAST] network technology. This document adopts the RFC 1990 fragmentation and reassembly procedures as well, with some distinct modifications described in this appendix. Familiarity with RFC 1990 is assumed.
トランスミッションのための、より小さい単位への大きいパケットの断片化は新しくはありません。 1つの断片化と再アセンブリ方法はRFC1990、Multi-リンクPPP[MLPPP]で定義されました。 また、この方法はFrame Relay[FRF.12]とATM[FAST]ネットワーク技術の両方のために採られました。 いくつかの異なった変更がこの付録で説明されている状態で、このドキュメントはまた、1990年のRFC断片化と再アセンブリ手順を取り入れます。 RFC1990への親しみは想定されます。
RFC 1990 was designed for use in environments where packet fragments may arrive out of order due to their transmission on multiple parallel links, specifying that buffering be used to place the fragments in correct order. For PWE3, the ability to reorder fragments prior to reassembly is OPTIONAL; receivers MAY choose to drop frames when a lost fragment is detected. Thus, when the sequence number on received fragments shows that a fragment has been skipped, the partially reassembled packet MAY be dropped, or the receiver MAY wish to wait for the fragment to arrive out of order. In the latter case, a reassembly timer MUST be used to avoid locking up buffer resources for too long a period.
RFC1990はパケット断片が彼らのトランスミッションで複数の平行なリンクで故障していた状態で届くかもしれない環境における使用のために設計されました、バッファリングが正しいオーダーに断片を置くのに使用されると指定して。 PWE3に関しては、再アセンブリの前の追加注文断片への能力はOPTIONALです。 受信機は、無くなっている断片がいつ検出されるかをコマ落ちに選ぶかもしれません。 容認された断片の一連番号が、断片がスキップされたのを示すとき、したがって、部分的に組み立て直されたパケットが落とされるかもしれませんか、または受信機は、断片が故障していた状態で届くのを待ちたがっているかもしれません。 後者の場合では、長過ぎる期間、バッファ資源に鍵をかけるのを避けるのに再アセンブリタイマを使用しなければなりません。
Dropping out-of-order fragments on a given PW can provide a considerable scalability advantage for network equipment performing reassembly. If out-of-order fragments are a relatively rare event on a given PW, throughput should not be adversely affected by this. Note, however, if there are cases where fragments of a given frame are received out-or-order in a consistent manner (e.g., a short fragment is always switched ahead of a larger fragment), then dropping out-of-order fragments will cause the fragmented frame never to be received. This condition may result in an effective denial of service to a higher-lever application. As such, implementations fragmenting a PW frame MUST at the very least ensure that all fragments are sent in order from their own egress point.
故障していた状態で低下して、与えられたPWの上の断片はかなりのスケーラビリティ利点を再アセンブリに働くネットワーク装置に供給できます。 不適切な断片が与えられたPWにおける比較的まれな出来事であるなら、スループットはこれで悪影響を受けるべきではありません。 しかしながら、故障していた状態で低下して、ケースが当然のことのフレームの断片がaのアウトかオーダーの容認された一貫した方法(例えば脆い断片はいつもより大きい断片の前に切り換えられる)であるところにあると断片で断片化しているフレームを決して受け取らないことに注意してください。 この状態は有効なより高いレバーアプリケーションに対するサービスの否定をもたらすかもしれません。 そういうものとして、PWフレームを断片化する実現は、すべての断片がそれら自身の出口ポイントから整然とした状態で送られるのを少なくとも確実にしなければなりません。
An implementation may also choose to allow reassembly of a limited number of fragmented frames on a given PW, or across a set of PWs with reassembly enabled. This allows for a more even distribution of reassembly resources, reducing the chance that a single or small set of PWs will exhaust all reassembly resources for a node. As with dropping out-of-order fragments, there are perceivable cases where this may also provide an effective denial of service. For example, if fragments of multiple frames are consistently received before each frame can be reconstructed in a set of limited PW reassembly buffers, then a set of these fragmented frames will never be delivered.
また、実現は、与えられたPWの上、または、再アセンブリが有効にされているPWsの1セットの向こう側に限られた数の断片化しているフレームの再アセンブリを許容するのを選ぶかもしれません。 これは再アセンブリリソースの、より同等の分配を考慮します、ノードのためのすべての再アセンブリリソースがPWsの単一の、または、小さいセットでくたくたになるという可能性を小さくして。 断片であり知覚できるケースはまた、これが有効なサービスの否定を提供するかもしれないところの故障している低下のようです。 例えば、1セットの限られたPW reassemblyバッファで各フレームを再建できる前に一貫して複数のフレームの断片を受け取ると、これらの断片化しているフレームの1セットを決して届けないでしょう。
Malis & Townsley Standards Track [Page 14] RFC 4623 PWE3 Fragmentation and Reassembly August 2006
Malis&Townsley標準化過程[14ページ]RFC4623PWE3断片化とReassembly2006年8月
RFC 1990 headers use two bits that indicate the first and last fragments in a frame, and a sequence number. The sequence number may be either 12 or 24 bits in length (from [MLPPP]):
RFC1990ヘッダーは、1番目を示す2ビットを使用して、フレーム、および一連番号で断片を持続します。 長さ([MLPPP]からの)は、一連番号が12ビットか24ビットであるかもしれません:
0 7 8 15
+-+-+-+-+-------+---------------+
|B|E|0|0| sequence number |
+-+-+-+-+-------+---------------+
0 7 8 15 +-+-+-+-+-------+---------------+ |B|E|0|0| 一連番号| +-+-+-+-+-------+---------------+
+-+-+-+-+-+-+-+-+---------------+
|B|E|0|0|0|0|0|0|sequence number|
+-+-+-+-+-+-+-+-+---------------+
| sequence number (L) |
+---------------+---------------+
+-+-+-+-+-+-+-+-+---------------+ |B|E|0|0|0|0|0|0|一連番号| +-+-+-+-+-+-+-+-+---------------+ | 一連番号(L)| +---------------+---------------+
Figure 6: RFC 1990 Header Formats
図6: RFC1990ヘッダー形式
PWE3 fragmentation takes advantage of existing PW sequence numbers and control bit fields wherever possible, rather than defining a separate header exclusively for the use of fragmentation. Thus, it uses neither of the RFC 1990 sequence number formats described above, relying instead on the sequence number that already exists in the PWE3 header.
PWE3断片化は排他的に断片化の使用のために別々のヘッダーを定義するよりむしろどこでも、PW一連番号とコントロールビットが可能であるところでさばく存在を利用します。 したがって、上で説明されたRFC1990一連番号形式のどちらも使用しません、代わりにPWE3ヘッダーに既に存在する一連番号を当てにして。
RFC 1990 defines two one-bit fields: a (B)eginning fragment bit and an (E)nding fragment bit. The B bit is set to 1 on the first fragment derived from a PPP packet and set to 0 for all other fragments from the same PPP packet. The E bit is set to 1 on the last fragment and set to 0 for all other fragments. A complete unfragmented frame has both the B and E bits set to 1.
RFC1990は2つの1ビットの分野を定義します: (B)eginning断片ビットと(E)nding断片ビット。 Bビットは他のすべての断片のために同じPPPパケットからPPPパケットとセットから0まで引き出された最初の断片の上の1へのセットです。 Eビットは他のすべての断片のための0への最後の断片とセットの1へのセットです。 完全な非断片化しているフレームで、BとEビットの両方を1に設定します。
PWE3 fragmentation inverts the value of the B and E bits, while retaining the operational concept of marking the beginning and ending of a fragmented frame. Thus, for PW the B bit is set to 0 on the first fragment derived from a PW frame and set to 1 for all other fragments derived from the same frame. The E bit is set to 0 on the last fragment and set to 1 for all other fragments. A complete unfragmented frame has both the B and E bits set to 0. The motivation behind this value inversion for the B and E bits is to allow complete frames (and particularly, implementations that only support complete frames) simply to leave the B and E bits in the header set to 0.
PWE3断片化は断片化しているフレームの始めと結末を示す操作上の概念を保有している間、BとEビットの価値を逆にします。 したがって、PWに関して、Bビットは同じフレームから得られた他のすべての断片のためにPWフレームとセットから1まで引き出された最初の断片の上の0へのセットです。 Eビットは他のすべての断片のための1への最後の断片とセットの0へのセットです。 完全な非断片化しているフレームで、BとEビットの両方を0に設定します。 このBとEビット値の逆の後ろの動機は完全なフレーム(そして、特に完全なフレームを支えるだけである実現)が単にヘッダーセットにおけるビットにBとEを0に任せるのを許容することです。
In order to support fragmentation, the B and E bits MUST be defined or identified for all PWE3 tunneling protocols. Sections 4 and 5 define these locations for PWE3 MPLS [Control-Word], L2TPv2 [L2TPv2], and L2TPv3 [L2TPv3] tunneling protocols.
断片化を支持して、すべてのPWE3トンネリングプロトコルのためにBとEビットを定義されなければならないか、または特定しなければなりません。 セクション4と5は、PWE3 MPLS[コントロールして言い表す]、L2TPv2[L2TPv2]、およびL2TPv3[L2TPv3]のためにプロトコルにトンネルを堀りながら、これらの位置を定義します。
Malis & Townsley Standards Track [Page 15] RFC 4623 PWE3 Fragmentation and Reassembly August 2006
Malis&Townsley標準化過程[15ページ]RFC4623PWE3断片化とReassembly2006年8月
Authors' Addresses
作者のアドレス
Andrew G. Malis Tellabs 1415 West Diehl Road Naperville, IL 60563
イリノイ アンドリューG.Malis Tellabs1415の西ディール・Roadナパービル、60563
EMail: Andy.Malis@tellabs.com
メール: Andy.Malis@tellabs.com
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
Malis & Townsley Standards Track [Page 16] RFC 4623 PWE3 Fragmentation and Reassembly August 2006
Malis&Townsley標準化過程[16ページ]RFC4623PWE3断片化とReassembly2006年8月
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2006).
Copyright(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 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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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 provided by the IETF Administrative Support Activity (IASA).
RFC Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
Malis & Townsley Standards Track [Page 17]
Malis&Townsley標準化過程[17ページ]
一覧
スポンサーリンク
