RFC4385 日本語訳
4385 Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Useover an MPLS PSN. S. Bryant, G. Swallow, L. Martini, D. McPherson. February 2006. (Format: TXT=22440 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group S. Bryant
Request for Comments: 4385 G. Swallow
Category: Standards Track L. Martini
Cisco Systems
D. McPherson
Arbor Networks
February 2006
コメントを求めるワーキンググループS.ブライアント要求をネットワークでつないでください: 4385年のG.ツバメカテゴリ: 規格は2006年2月にL.マティーニシスコシステムズD.マクファーソンあずまやネットワークを追跡します。
Pseudowire Emulation Edge-to-Edge (PWE3)
Control Word for Use over an MPLS PSN
縁から縁(PWE3)へのコントロールがMPLS PSNの上の使用のために言い表すPseudowireエミュレーション
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 describes the preferred design of a Pseudowire Emulation Edge-to-Edge (PWE3) Control Word to be used over an MPLS packet switched network, and the Pseudowire Associated Channel Header. The design of these fields is chosen so that an MPLS Label Switching Router performing MPLS payload inspection will not confuse a PWE3 payload with an IP payload.
このドキュメントは、MPLSパケット交換網、およびPseudowire Associated Channel Headerの上で使用されるためにPseudowire Emulation Edgeから縁(PWE3)へのコントロールWordの都合のよいデザインについて説明します。 これらの分野のデザインは、MPLSペイロード点検を実行するMPLS Label Switching RouterがPWE3ペイロードをIPペイロードに間違えないように、選ばれています。
1. Introduction
1. 序論
The standard MPLS encapsulations have no explicit protocol identifier. In order for a pseudowire (PW) [RFC3985] to operate correctly over an MPLS packet switched network (PSN) that performs MPLS payload inspection, a PW packet must not appear to a label switching router (LSR) as if it were an IP packet [BCP]. An example of an LSR that performs MPLS payload inspection is one that is performing equal-cost multiple-path load-balancing (ECMP) [RFC2992]. If ECMP were performed on PW packets, the packets in the PW may not all follow the same path through the PSN. This may result in misordered packet delivery to the egress PE. The inability to ensure that all packets belonging to a PW follow the same path may also prevent the PW Operations and Management (OAM) [VCCV] mechanism from correctly monitoring the PW.
標準のMPLSカプセル化には、どんな明白なプロトコル識別子もありません。 pseudowire(PW)[RFC3985]がMPLSペイロード点検を実行するMPLSパケット交換網(PSN)の上で正しく作動するように、PWパケットはまるでそれがIPパケット[BCP]であるかのようにラベル切り換えルータ(LSR)に見えてはいけません。 MPLSペイロード点検を実行するLSRに関する例は等しい費用複数の経路負荷分散(ECMP)[RFC2992]を実行しているものです。 ECMPがPWパケットに実行されたなら、PWのパケットはすべて、PSNを通して同じ経路に続かないかもしれません。 これは出口PEへのmisorderedパケット配信をもたらすかもしれません。 また、PWに属すすべてのパケットが同じ経路に続くのを保証できないことは、PW OperationsとManagement(OAM)[VCCV]メカニズムが正しくPWをモニターするのを防ぐかもしれません。
Bryant, et al. Standards Track [Page 1] RFC 4385 PW3 Control Word for Use over an MPLS PSN February 2006
ブライアント、他 RFC4385PW3コントロールが2006年2月にMPLS PSNの上の使用のために言い表す標準化過程[1ページ]
This document specifies how the PW control word is used to distinguish a PW payload from an IP payload carried over an MPLS PSN. It then describes the preferred design of a PW Control Word to be use over an MPLS PSN, and the Pseudowire Associated Channel Header.
このドキュメントは存在というIPペイロードとPWペイロードを区別するのに使用されるPW規制単語がどうMPLS PSNを引き継いだかを指定します。 そして、それは、MPLS PSN、およびPseudowire Associated Channel Headerの上の使用になるようにPW Control Wordの都合のよいデザインについて説明します。
1.1. Conventions Used in This Document
1.1. 本書では使用されるコンベンション
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 [RFC2119].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[RFC2119]で説明されるように本書では解釈されることであるべきですか?
2. Avoiding ECMP
2. ECMPを避けます。
A PW that is carried over an MPLS PSN that uses the contents of the MPLS payload to select the ECMP path may be subjected to packet misordering [BCP]. In cases where the application using the PW is sensitive to packet misordering, or where packet misordering will disrupt the operation of the PW, it is necessary to prevent the PW being subjected to ECMP.
ECMP経路を選択するのにMPLSペイロードのコンテンツを使用するMPLS PSNの上まで運ばれるPWはパケットmisordering[BCP]にかけられるかもしれません。 PWを使用するアプリケーションがパケットmisorderingに敏感であるか、またはパケットmisorderingがPWの操作を中断する場合では、PWがECMPにかけられるのを防ぐのが必要です。
All IP packets [RFC791] [RFC2460] start with a version number that is checked by LSRs performing MPLS payload inspection. To prevent the incorrect processing of packets carried within a PW, PW packets carried over an MPLS PSN MUST NOT start with the value 4 (IPv4) or the value 6 (IPv6) in the first nibble [BCP], as those are assumed to carry normal IP payloads.
すべてのIPパケット[RFC791][RFC2460]がMPLSペイロード点検を実行するLSRsによってチェックされるバージョン番号から始まります。 PWの中で運ばれたパケットの不正確な処理を防ぐために、PWパケットは最初の少量[BCP]で値4(IPv4)か値6(IPv6)でMPLS PSN MUST NOT始めを引き継ぎました、それらが標準のIPペイロードを運ぶと思われるとき。
This document defines a PW header and two general formats of that header. These two formats are the PW MPLS Control Word (PWMCW), which is used for data passing across the PW, and a PW Associated Channel Header (PWACH), which can be used for functions such as OAM.
このドキュメントはそのヘッダーのPWヘッダーと2つの一般形式を定義します。 (PWの向こう側に終わるデータにそれを、使用します)。これらの2つの形式が、PW MPLS Control Word(PWMCW)とPW Associated Channel Header(PWACH)です。(OAMなどの機能にPW Associated Channel Headerを使用できます)。
If the first nibble of a PW packet carried over an MPLS PSN has a value of 0, this indicates that the packet starts with a PWMCW. If the first nibble of a packet carried over an MPLS PSN has a value of 1, it starts with a PWACH. The use of any other first nibble value for a PW packet carried over an MPLS PSN is deprecated.
MPLS PSNの上まで運ばれたPWパケットの最初の少量に0の値があるなら、これは、パケットがPWMCWから始まるのを示します。 MPLS PSNの上まで運ばれたパケットの最初の少量に1の値があるなら、それはPWACHから始まります。 いかなる他の最初の少量価値のMPLS PSNの上まで運ばれたPWパケットの使用も推奨しないです。
If a PW is sensitive to packet misordering and is being carried over an MPLS PSN that uses the contents of the MPLS payload to select the ECMP path, it MUST employ a mechanism that prevents packet misordering. A suitable mechanism is the PWMCW described in Section 3 for data, and the PWACH described in Section 5 for channel- associated traffic.
PWがパケットmisorderingに敏感、そして、ECMP経路を選択するのにMPLSペイロードのコンテンツを使用するMPLS PSNの上まで運ばれるなら、それはパケットがmisorderingされるのを防ぐメカニズムを使わなければなりません。 適当なメカニズムは、データのためにセクション3で説明されたPWMCWと、セクション5でチャンネルの関連交通に説明されたPWACHです。
The PWMCW or the PWACH MUST immediately follow the bottom of the MPLS label stack.
PWMCWかPWACH MUSTがすぐに、MPLSラベルスタックの下部に続きます。
Bryant, et al. Standards Track [Page 2] RFC 4385 PW3 Control Word for Use over an MPLS PSN February 2006
ブライアント、他 RFC4385PW3コントロールが2006年2月にMPLS PSNの上の使用のために言い表す標準化過程[2ページ]
3. Generic PW MPLS Control Word
3. コントロールが言い表す一般的なPW MPLS
The Generic PW MPLS Control Word (PWMCW) is shown in Figure 1.
Generic PW MPLS Control Word(PWMCW)は図1に示されます。
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| Specified by PW Encapsulation |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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| PWカプセル化で、指定されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Generic PW MPLS Control Word
図1: コントロールが言い表す一般的なPW MPLS
The PW set-up protocol or configuration mechanism determines whether a PW uses a PWMCW. Bits 0..3 differ from the first four bits of an IP packet [BCP] and hence provide the necessary MPLS payload discrimination.
PWセットアッププロトコルか構成メカニズムが、PWがPWMCWを使用するかどうか決定します。 ビット0。3は、IPパケット[BCP]の最初の4ビットと異なっていて、したがって、ペイロード区別を必要なMPLSに供給します。
When a PWMCW is used, it MUST adhere to the Generic format illustrated in Figure 1 above. To provide consistency between the designs of different types of PW, it SHOULD also use the following preferred format:
PWMCWが使用されているとき、それは上の図1で例証されたGeneric形式を固く守らなければなりません。 異なることのデザインの間の一貫性を提供するのはPWをタイプして、それはSHOULDです。また、以下の都合のよい形式を使用してください:
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 |FRG| 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| 旗|FRG| 長さ| 一連番号| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Preferred PW MPLS Control Word
図2: コントロールが言い表す都合のよいPW MPLS
The meaning of the fields of the Preferred PW MPLS Control Word (Figure 2) is as follows:
Preferred PW MPLS Control Word(図2)の分野の意味は以下の通りです:
Flags (bits 4 to 7):
旗(ビット4〜7):
These bits MAY be used by for per-payload signaling. Their
semantics MUST be defined in the PW specification.
これらのビットは1ペイロードあたりのシグナリングに使用されるかもしれません。 PW仕様に基づきそれらの意味論を定義しなければなりません。
FRG (bits 8 and 9):
FRG(ビット8と9):
These bits are used when fragmenting a PW payload. Their use
is described in [FRAG], which is currently a work in progress.
When the PW is of a type that will never need payload
fragmentation, these bits may be used as general purpose
flags.
PWペイロードを断片化するとき、これらのビットは使用されています。 彼らの使用は[FRAG]で説明されます。(現在、それは、処理中の作業です)。 ペイロード断片化を決して必要としないタイプにはPWがあるとき、汎用が弛んで、これらのビットは使用されるかもしれません。
Bryant, et al. Standards Track [Page 3] RFC 4385 PW3 Control Word for Use over an MPLS PSN February 2006
ブライアント、他 RFC4385PW3コントロールが2006年2月にMPLS PSNの上の使用のために言い表す標準化過程[3ページ]
Length (bits 10 to 15):
長さ(ビット10〜15):
When the PSN path between the PEs includes an Ethernet
segment, the PW packet arriving at the CE-bound PE from the
PSN may include padding appended by the Ethernet Data Link
Layer. The CE-bound PE uses the length field to determine
the size of the padding added by the PSN, and hence extract
the PW payload from the PW packet.
PEsの間のPSN経路がイーサネットセグメントを含んでいるとき、PSNからCE行きのPEに到着するPWパケットは、イーサネットData Link Layerによって追加される状態でそっと歩くのを含むかもしれません。 CE行きのPEは、PSNによって加えられた詰め物のサイズを決定して、したがって、PWパケットからPWペイロードを抽出するのに長さの分野を使用します。
If the MPLS payload is less than 64 bytes, the length field
MUST be set to the length of the PW payload plus the length
of the PWMCW. Otherwise it MUST be set to zero.
MPLSペイロードが64バイト未満であるなら、PWペイロードの長さとPWMCWの長さに長さの分野を設定しなければなりません。 さもなければ、ゼロにそれを設定しなければなりません。
Sequence number (Bit 16 to 31):
一連番号(ビット16〜31):
The sequence number implements the sequencing function
[RFC3985]. The use of this field is described in Section 4.
一連番号は配列機能[RFC3985]を実行します。 この分野の使用はセクション4で説明されます。
4. Sequencing
4. 配列
The sequence number mechanism is PW specific. The PW encapsulation specification MAY define a sequence number mechanism to be used, or it may indicate that the mechanism described here is to be used. A pseudo-code description of this mechanism is given in the non- normative Appendix.
一連番号メカニズムはPW特有です。 PWカプセル化仕様が使用されるために一連番号メカニズムを定義するかもしれませんか、またはそれは、ここで説明されたメカニズムが使用されていることであることを示すかもしれません。 非標準のAppendixでこのメカニズムの中間コード記述を与えます。
The sequence number mechanism described here uses a circular unsigned 16-bit number space that excludes the value zero.
ここで説明された一連番号メカニズムは値ゼロを除く円形の無記名の16ビットの数のスペースを使用します。
4.1. Setting the Sequence Number
4.1. 一連番号を設定します。
For a given PW, and a pair of routers PE1 and PE2, if PE1 supports packet sequencing and packet sequencing is enabled for the PW, then the following procedures MUST be used:
1組のルータの与えられたPW、PE1、およびPE2のために、PE1がパケット順序制御を支持して、パケット順序制御がPWのために可能にされるなら、以下の手順を用いなければなりません:
o The initial packet transmitted on the PW MUST be sent with
sequence number one.
o 初期のパケットはPW MUSTを伝わりました。一連番号1と共に送ります。
o Subsequent packets MUST increment the sequence number by one for
each packet.
o その後のパケットは一連番号を各パケットあたり1つ増加しなければなりません。
o The sequence number that follows 65535 (maximum unsigned 16-bit
number) is one.
o 65535(最大の無記名の16ビットの数)に続く一連番号は1です。
If the transmitting router PE1 does not support sequence number processing, or packet sequencing is disabled, then the sequence number field in the control word MUST be set to zero for all packets transmitted on the PW.
伝えるルータPE1が一連番号処理を支持しないか、またはパケット順序制御は障害があるなら、PWで伝えられたすべてのパケットのためのゼロに規制単語による一連番号分野を設定しなければなりません。
Bryant, et al. Standards Track [Page 4] RFC 4385 PW3 Control Word for Use over an MPLS PSN February 2006
ブライアント、他 RFC4385PW3コントロールが2006年2月にMPLS PSNの上の使用のために言い表す標準化過程[4ページ]
4.2. Processing the Sequence Number
4.2. 一連番号を処理します。
If a router PE2 supports receive sequence number processing, and packet sequencing is enabled for this PW, then the following procedure is used:
ルータであるなら、PE2サポートは一連番号処理を受けます、そして、パケット順序制御はこのPWのために可能にされます、そして、次に、以下の手順は使用されています:
When a PW is initially set up, the "expected sequence number" associated with it MUST be initialized to one.
PWが初めはセットアップされるとき、それに関連している「予想された一連番号」を1つに初期化しなければなりません。
When a packet is received on that PW, the sequence number SHOULD be processed as follows:
aであるときに、そのPW、一連番号SHOULDにパケットを受け取ります。以下の通り処理されてください:
o If the sequence number on the packet is zero, the sequence
integrity of the packets cannot be determined. In this case, the
received packet is considered to be in order.
o パケットの一連番号がゼロであるなら、パケットの系列保全は決定できません。 この場合、容認されたパケットが整然とすると考えられます。
o Otherwise if the packet sequence number equals the expected
sequence number, the packet is in order.
o さもなければ、パケット一連番号が予想された一連番号と等しいなら、パケットは整然としています。
o Otherwise if the packet sequence number is greater than the
expected sequence number, and the packet sequence number minus
the expected sequence number is less than 32768, the packet is
within the allowed receive sequence number window. The
implementation MAY treat the packet as in order.
o さもなければ、パケット一連番号が予想された一連番号より大きく、予想された一連番号を引いたパケット一連番号が32768未満であるなら、パケットは許容の中で一連番号ウィンドウを受けることです。 実現はオーダーのようにパケットを扱うかもしれません。
o Otherwise if the packet sequence number is less than the expected
sequence number and the expected sequence number minus the packet
sequence number is greater than or equal to 32768, the packet is
within the allowed receive sequence number window. The
implementation MAY treat the packet as in order.
o さもなければ、パケット一連番号が予想された一連番号より少なく、パケット一連番号を引いた予想された一連番号が32768以上であるなら、パケットは許容の中で一連番号ウィンドウを受けることです。 実現はオーダーのようにパケットを扱うかもしれません。
o Otherwise the packet is out of order.
o さもなければ、パケットは故障しています。
If the packet is found to be in order, it MAY be delivered immediately.
パケットが整然とするのがわかっているなら、すぐに、それを届けるかもしれません。
If the packet sequence number was not zero, then the expected sequence number is set to the packet sequence number plus one. The expected sequence number that follows 65535 (maximum unsigned 16-bit number) is one.
パケット一連番号がゼロでなかったなら、予想された一連番号はパケット一連番号と1つに設定されます。 65535(最大の無記名の16ビットの数)に続く予想された一連番号は1です。
Packets that are received out of order MAY either be dropped or reordered. The choice between dropping or reordering an out-of- sequence packet is at the discretion of the receiver.
故障していた状態で受け取られるパケットは、落とされるか、または再命令されるかもしれません。 間の選択、-アウトを低下するか、または再命令して、受信機の裁量にはパケットが系列に、あります。
If a PE negotiated not to use receive sequence number processing, and it received a non-zero sequence number, then it SHOULD send a PW status message indicating a receive fault, and disable the PW.
PEが交渉したなら一連番号処理を使用でないのに受けないでください。そうすれば、非ゼロ一連番号を受けて、次に、それはSHOULDです。PWステータスメッセージにaが欠点を受けるのを示させてください、そして、PWを無効にしてください。
Bryant, et al. Standards Track [Page 5] RFC 4385 PW3 Control Word for Use over an MPLS PSN February 2006
ブライアント、他 RFC4385PW3コントロールが2006年2月にMPLS PSNの上の使用のために言い表す標準化過程[5ページ]
5. PW Associated Channel
5. PWの関連チャンネル
For some PW features, an associated channel is required. An associated channel is a channel that is multiplexed in the PW with user traffic, and thus follows the same path through the PSN as user traffic. Note that the use of the term "channel" is not a "PW channel type" as used in subsection 5.1.2 of [RFC3985].
いくつかのPWの特徴に関しては、関連チャンネルが必要です。 関連チャンネルはユーザ交通を伴うPWで多重送信されて、その結果ユーザ交通としてPSNを通して同じ経路の後をつけるチャンネルです。 「チャンネル」という用語の使用が小区分に使用されるように「PWチャンネルタイプ」でないと述べてください、5.1、.2、[RFC3985]について。
When MPLS is used as the PSN, the PW Associated Channel (PWAC) is identified by the following header:
MPLSがPSNとして使用されるとき、PW Associated Channel(PWAC)は以下のヘッダーによって特定されます:
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 1|Version| Reserved | Channel Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 1|バージョン| 予約されます。| チャンネルタイプ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: PW Associated Channel Header
図3: PWの関連チャンネルヘッダー
The meanings of the fields in the PW Associated Channel Header (PWACH) (Figure 3) are:
PW Associated Channel Header(PWACH)(図3)の分野の意味は以下の通りです。
Version:
バージョン:
This is the version number of the PWACH. This specification
defines version 0.
これはPWACHのバージョン番号です。 この仕様はバージョン0を定義します。
Reserved:
予約される:
MUST be sent as 0, and ignored on reception.
0として送られて、レセプションで無視しなければなりません。
Channel Type:
タイプはチャネルを開設します:
The PW Associated Channel Type is defined in the IANA PW
Associated Channel Type registry [IANA].
PW Associated Channel TypeはIANA PW Associated Channel Type登録[IANA]で定義されます。
Bits 0..3 MUST be 0001. This allows the packet to be distinguished from an IP packet [BCP] and from a PW data packet.
ビット0。3は0001であるに違いありません。 これは、パケットがIPパケット[BCP]とPWデータ・パケットと区別されるのを許容します。
6. IANA Considerations
6. IANA問題
IANA has set up a registry of "Pseudowire Associated Channel Types". These are 16-bit values. Registry entries are assigned by using the "IETF Consensus" policy defined in [RFC2434]. The value 0x21 indicates that the Associated Channel carries an IPv4 packet. The value 0x57 indicates that the Associated Channel carries an IPv6 packet.
IANAは「Pseudowireの関連チャンネル種別」の登録をセットアップしました。 これらは16ビットの値です。 登録エントリーは、[RFC2434]で定義された「IETFコンセンサス」方針を使用することによって、割り当てられます。 値0x21は、Associated ChannelがIPv4パケットを運ぶのを示します。 値0x57は、Associated ChannelがIPv6パケットを運ぶのを示します。
Bryant, et al. Standards Track [Page 6] RFC 4385 PW3 Control Word for Use over an MPLS PSN February 2006
ブライアント、他 RFC4385PW3コントロールが2006年2月にMPLS PSNの上の使用のために言い表す標準化過程[6ページ]
7. Security Considerations
7. セキュリティ問題
An application using a PW Associated Channel must be aware that the channel can potentially be misused. Any application using the Associated Channel MUST therefore fully consider the resultant security issues, and provide mechanisms to prevent an attacker from using this as a mechanism to disrupt the operation of the PW or the PE, and to stop this channel from being used as a conduit to deliver packets elsewhere. The selection of a suitable security mechanism for an application using a PW Associated Channel is outside the scope of this document.
PW Associated Channelを使用するアプリケーションは潜在的にチャンネルを誤用できるのを意識しているに違いありません。 Associated Channelを使用するどんなアプリケーションも、したがって、結果の安全保障問題を完全に考えて、攻撃者がPWかPEの操作を中断して、このチャンネルがパケットをほかの場所に届けるのに導管として使用されるのを止めるのにメカニズムとしてこれを使用するのを防ぐためにメカニズムを提供しなければなりません。 このドキュメントの範囲の外にPW Associated Channelを使用するアプリケーションのための適当なセキュリティー対策の選択があります。
If a PW has been configured to operate without a CW, the PW Associated Channel Type mechanism described in the document MUST NOT be used. This is to prevent user payloads being fabricated in such a way that they mimic the PW Associated Channel Header, and thereby provide a method of attacking the application that is using the Associated Channel.
PWがCWなしで作動するために構成されたなら、ドキュメントで説明されたPW Associated Channel Typeメカニズムを使用してはいけません。 これは、ユーザペイロードがPW Associated Channel Headerをまねるような方法で作られるのを防いで、その結果、Associated Channelを使用しているアプリケーションを攻撃する方法を前提とするためのものです。
8. Acknowledgements
8. 承認
The authors wish to thank David Allan, Thomas Nadeau, Yaakov Stein, and Mark Townsley for their input to this work.
作者はこの仕事への彼らの入力についてデヴィッド・アラン、トーマス・ナドー、Yaakovシタイン、およびマークTownsleyに感謝したがっています。
Bryant, et al. Standards Track [Page 7] RFC 4385 PW3 Control Word for Use over an MPLS PSN February 2006
ブライアント、他 RFC4385PW3コントロールが2006年2月にMPLS PSNの上の使用のために言い表す標準化過程[7ページ]
9. Normative References
9. 引用規格
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September
1981.
[RFC791] ポステル、J.、「インターネットプロトコル」、STD5、RFC791、1981年9月。
[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月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[RFC2460]デアリング、S.とR.Hinden、「インターネットプロトコル、バージョン6(IPv6)仕様」、RFC2460、12月1998日
10. Informative References
10. 有益な参照
[BCP] Swallow, G., Bryant, S., and L. Andersson, "Avoiding Equal
Cost Multipath Treatment in MPLS Networks", Work in
Progress, September 2005.
[BCP]は飲み込んで、「MPLSネットワークで等しい費用多重通路処理を避け」て、G.、ブライアント、S.、およびL.アンデションは進行中(2005年9月)で働いています。
[FRAG] Malis, A. and M. Townsley, "PWE3 Fragmentation and
Reassembly", Work in Progress, November 2005.
[破片手榴弾で殺傷します] A.、M.Townsley、および「PWE3断片化とReassembly」というMalisは進歩、2005年11月に働いています。
[IANA] Martini, L., "IANA Allocations for Pseudowire Edge to Edge
Emulation (PWE3)", Work in Progress, November 2005.
[IANA] マティーニ、L.、「PseudowireのためのIANA配分はエミュレーション(PWE3)を斜めに進ませるために斜めに進むこと」が進歩、2005年11月に働いています。
[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月)。
[RFC2992] Hopps, C., "Analysis of an Equal-Cost Multi-Path
Algorithm", RFC 2992, November 2000.
[RFC2992]ホップス、C.、「等しい費用マルチ経路アルゴリズムの分析」、RFC2992、2000年11月。
[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月。
[VCCV] Nadeau, T. and R. Aggarwal, "Pseudowire Virtual Circuit
Connectivity Verification (VCCV)", Work in Progress,
August 2005.
[VCCV] 「Pseudowireの仮想のサーキット接続性検証(VCCV)」というナドー、T.、およびR.Aggarwalは進歩、2005年8月に働いています。
Bryant, et al. Standards Track [Page 8] RFC 4385 PW3 Control Word for Use over an MPLS PSN February 2006
ブライアント、他 RFC4385PW3コントロールが2006年2月にMPLS PSNの上の使用のために言い表す標準化過程[8ページ]
Appendix. Sequence Number Processing
付録。 一連番号処理
This appendix is non-normative.
この付録は非規範的です。
This appendix provides a pseudo-code description of the sequence number processing mechanism described in Section 4.2.
この付録はセクション4.2で説明された一連番号処理メカニズムの中間コード記述を提供します。
unsigned16 RECEIVED /* packet sequence number
unsigned16 EXPECTED = 1 /* expected sequence number
/* initialized to one
boolean sequencingDisabled
boolean dropOutOfOrder /* policy on in-window out of sequence
/* packets
一連番号/*が系列/*からの窓のパケットに関する1つの論理演算子sequencingDisabled論理演算子dropOutOfOrder/*方針に初期化した1/*が、予想したunsigned16 RECEIVED/*パケット一連番号unsigned16 EXPECTED=
updateExpected()
begin
EXPECTED := RECEIVED + 1;
/* Because EXPECTED is an unsigned16 it will wrap
/* from 65535 to 0
/* zero is skipped
if (EXPECTED = 0)
EXPECTED := 1;
return;
end;
updateExpected()はEXPECTED:=RECEIVED+1を始めます。 *EXPECTEDがそれが包装/*65535〜0/*ゼロを望んでいるunsigned16であるので、/は(EXPECTED=0)EXPECTED:=1であるならスキップされます。 戻ってください。 終わってください。
On receipt of a PW packet from PSN:
begin
if (RECEIVED = 0) then begin
processPacket();
return;
end;
PSNからのPWパケットを受け取り次第: 次に、(RECEIVED=0)がprocessPacket()を始めるなら、始まってください。 戻ってください。 終わってください。
if (sequencingDisabled) then begin
/* A packet was received with non-zero sequence number, but
/* sequencing is disabled
indicateReceiveFault();
disablePW();
return;
end;
(sequencingDisabled)であるなら/*を始めてください。非ゼロ一連番号でパケットを受け取りましたが、/*配列は障害があるindicateReceiveFault()です。 disablePW()。 戻ってください。 終わってください。
/* The received sequence is the expected sequence number
if ((RECEIVED = EXPECTED) then begin
/* packet is in order
processPacket();
updateExpected();
return;
end;
受け取られているのが配列する/*による次に、(RECEIVED=EXPECTED)が/*パケットを始めるなら、期待している一連番号がオーダーprocessPacket()にあります; updateExpected(); リターン;が終わるということです。
Bryant, et al. Standards Track [Page 9] RFC 4385 PW3 Control Word for Use over an MPLS PSN February 2006
ブライアント、他 RFC4385PW3コントロールが2006年2月にMPLS PSNの上の使用のために言い表す標準化過程[9ページ]
/* Test for received sequence number is greater than
/* the expected sequence number and is within the
/* allowed receive sequence number window
if ((RECEIVED > EXPECTED) and
((RECEIVED - EXPECTED) < 32768) then begin
/* packet is in the window, but there are late/missing
/* packets
if (dropOutOfOrder) then begin
/* policy is to receive immediately, dropping
/* out of sequence packets
processPacket();
updateExpected();
return;
end else begin
/* policy is to wait for late packets
processMissingPackets();
return;
end;
end;
次に、(RECEIVED>EXPECTED)と((RECEIVED--EXPECTED)<32768)が/を始めるなら、*が許容した/の中では、一連番号ウィンドウを受けてください。容認された一連番号のための/*テストが/*より大きい、予想された一連番号、存在、*パケットが窓にあります; しかし、次に、(dropOutOfOrder)が*方針がすぐに受けることになっている/を始めるなら、late/missing /*パケットがあります、順序が狂って低下/*パケットprocessPacket(); updateExpected(); リターン;ほかの終わりは*方針が故パケットprocessMissingPackets(); リターン;終わりの間に待つことになっている/を始めます; 終わってください。
/* Test for the received sequence is less than the
/* expected sequence number and is within the allowed
/* receive sequence number window
if ((RECEIVED < EXPECTED) and
((EXPECTED - RECEIVED) >= 32768) then begin
/* packet is in the window, but there are late/missing
/* packets
容認された系列が/*が一連番号を予想して、次に、((RECEIVED<EXPECTED)と(EXPECTED--RECEIVED)>=32768)が/*パケットを始めるなら許容/*の中で一連番号ウィンドウを受けることであるより少ないので、/*テストが窓にありますが、late/missing /*パケットがあります。
if (dropOutOfOrder) then begin
/* policy is to receive immediately, dropping
/* out of sequence packets
processPacket();
updateExpected();
return;
end else begin
/* policy is to wait for late packets
processMissingPackets();
return;
end;
end;
次に、(dropOutOfOrder)が*方針がすぐに受けることになっている/を始めるなら、低下/*パケット順序が狂ってprocessPacket()です。 updateExpected()。 戻ってください。 ほかの終わりは故パケットprocessMissingPackets()のために、*方針が待つことになっている/を始めます。 戻ってください。 終わってください。 終わってください。
/* Received packet was outside the allowed receive
/* sequence number window
processOutOfWindow();
end;
*容認された/パケットは/*一連番号ウィンドウprocessOutOfWindow()を許容の外に受けることでした。 終わってください。
Bryant, et al. Standards Track [Page 10] RFC 4385 PW3 Control Word for Use over an MPLS PSN February 2006
ブライアント、他 RFC4385PW3コントロールが2006年2月にMPLS PSNの上の使用のために言い表す標準化過程[10ページ]
Authors' Addresses
作者のアドレス
Stewart Bryant Cisco Systems, 250, Longwater, Green Park, Reading, RG2 6GB, United Kingdom.
スチュワートブライアントシスコシステムズ、250、Longwater、グリーンパーク読書、RG2 6GB、イギリス。
EMail: stbryant@cisco.com
メール: stbryant@cisco.com
George Swallow Cisco Systems, Inc. 1414 Massachusetts Ave Boxborough, MA 01719
マサチューセッツAve Boxborough、ジョージツバメシスコシステムズInc.1414MA 01719
EMail: swallow@cisco.com
メール: swallow@cisco.com
Luca Martini Cisco Systems, Inc. 9155 East Nichols Avenue, Suite 400 Englewood, CO, 80112
ルカマティーニシスコシステムズ, Inc.9155のEastニコルズAvenue、イングルウッド、Suite400CO 80112
EMail: lmartini@cisco.com
メール: lmartini@cisco.com
Danny McPherson Arbor Networks, Inc.
ダニーマクファーソンあずまやはInc.をネットワークでつなぎます。
EMail: danny@arbor.net
メール: danny@arbor.net
Bryant, et al. Standards Track [Page 11] RFC 4385 PW3 Control Word for Use over an MPLS PSN February 2006
ブライアント、他 RFC4385PW3コントロールが2006年2月にMPLS PSNの上の使用のために言い表す標準化過程[11ページ]
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)によって提供されます。
Bryant, et al. Standards Track [Page 12]
ブライアント、他 標準化過程[12ページ]
一覧
スポンサーリンク
