[要約] RFC 6658は、MPLS PSN上でのパケット擬似ワイヤーカプセル化に関する仕様です。このRFCの目的は、パケット擬似ワイヤーカプセル化の標準化と、MPLSネットワーク上でのパケットトランスポートの効率化を促進することです。
Internet Engineering Task Force (IETF) S. Bryant, Ed.
Request for Comments: 6658 L. Martini
Category: Standards Track G. Swallow
ISSN: 2070-1721 Cisco Systems
A. Malis
Verizon Communications
July 2012
Packet Pseudowire Encapsulation over an MPLS PSN
MPLS PSNを介したパケット疑似配線カプセル化
Abstract
概要
This document describes a pseudowire mechanism that is used to transport a packet service over an MPLS PSN in the case where the client Label Switching Router (LSR) and the server Provider Edge equipments are co-resident in the same equipment. This pseudowire mechanism may be used to carry all of the required layer 2 and layer 3 protocols between the pair of client LSRs.
このドキュメントでは、クライアントのラベルスイッチングルータ（LSR）とサーバーのプロバイダーエッジ機器が同じ機器に共存している場合に、MPLS PSNを介してパケットサービスを転送するために使用される疑似配線メカニズムについて説明します。この疑似配線メカニズムを使用して、クライアントLSRのペア間で必要なすべてのレイヤー2およびレイヤー3プロトコルを伝送できます。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6658.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6658で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2012 IETF Trustおよびドキュメントの作成者として特定された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Network Reference Model . . . . . . . . . . . . . . . . . . . 4
3. Client Network-Layer Model . . . . . . . . . . . . . . . . . . 5
4. Forwarding Model . . . . . . . . . . . . . . . . . . . . . . . 5
5. Packet PW Encapsulation . . . . . . . . . . . . . . . . . . . 7
6. Ethernet and IEEE 802.1 Functional Restrictions . . . . . . . 8
7. Congestion Considerations . . . . . . . . . . . . . . . . . . 8
8. Security Considerations . . . . . . . . . . . . . . . . . . . 8
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
11.1. Normative References . . . . . . . . . . . . . . . . . . . 9
11.2. Informative References . . . . . . . . . . . . . . . . . . 9
Appendix A. Encapsulation Approaches Considered . . . . . . . . . 11
A.1. A Protocol Identifier in the Control Word . . . . . . . . 11
A.2. PID Label . . . . . . . . . . . . . . . . . . . . . . . . 12
A.3. Parallel PWs . . . . . . . . . . . . . . . . . . . . . . . 13
A.4. Virtual Ethernet . . . . . . . . . . . . . . . . . . . . . 13
A.5. Recommended Encapsulation . . . . . . . . . . . . . . . . 14
There is a need to provide a method of carrying a packet service over an MPLS PSN in a way that provides isolation between the two networks. The server MPLS network may be an MPLS network or a network conforming to the MPLS Transport Profile (MPLS-TP) [RFC5317]. The client may also be either an MPLS network or a network conforming to the MPLS-TP. Considerations regarding the use of an MPLS network as a server for an MPLS-TP network are outside the scope of this document.
2つのネットワーク間の分離を提供する方法でMPLS PSNを介してパケットサービスを伝送する方法を提供する必要があります。サーバーMPLSネットワークは、MPLSネットワークまたはMPLSトランスポートプロファイル（MPLS-TP）[RFC5317]に準拠したネットワークである場合があります。クライアントは、MPLSネットワークまたはMPLS-TPに準拠したネットワークのいずれかです。 MPLS-TPネットワークのサーバーとしてのMPLSネットワークの使用に関する考慮事項は、このドキュメントの範囲外です。
Where the client equipment is connected to the server equipment via a physical interface, the same data-link type must be used to attach the clients to the Provider Edge (PE) equipments, and a pseudowire (PW) of the same type as the data-link must be used [RFC3985]. The reason that interworking between different physical and data-link attachment types is specifically disallowed in the pseudowire architecture is because this is a complex task and not a simple bit-mapping exercise. The interworking is not limited to the physical and data-link interfaces and the state-machines. It also requires a compatible approach to the formation of the adjacencies between attached client network equipment. As an example, the reader should consider the differences between router adjacency formation on a point-to-point link compared to a multipoint-to-multipoint interface (e.g., Ethernet).
クライアント機器が物理インターフェースを介してサーバー機器に接続されている場合、クライアントをプロバイダーエッジ（PE）機器に接続するには同じデータリンクタイプを使用し、データと同じタイプの疑似配線（PW）を使用する必要があります-linkを使用する必要があります[RFC3985]。さまざまな物理アタッチメントタイプとデータリンクアタッチメントタイプ間のインターワーキングが疑似配線アーキテクチャで特に禁止されている理由は、これが複雑なタスクであり、単純なビットマッピングの練習ではないためです。インターワーキングは、物理インターフェイスとデータリンクインターフェイス、およびステートマシンに限定されません。また、接続されたクライアントネットワーク機器間の隣接関係を形成するための互換性のあるアプローチも必要です。例として、リーダーは、マルチポイントツーマルチポイントインターフェイス（イーサネットなど）と比較した、ポイントツーポイントリンクでのルーター隣接関係の違いを考慮する必要があります。
A further consideration is that two adjacent MPLS Label Switching Routers (LSRs) do not simply exchange MPLS packets. They exchange IP packets for adjacency formation, control, routing, label exchange, management, and monitoring purposes. In addition, they may exchange data-link packets as part of routing (e.g., IS-IS Hellos and IS-IS Link State Packets) and for Operations, Administration, and Maintenance (OAM) purposes such as the Link-Layer Discovery Protocol [IEEE.802.1AB.2009]. Thus, the two clients require an attachment mechanism that can be used to multiplex a number of protocols. In addition, it is essential to the correct operation of the network layer that all of these protocols fate share.
さらに考慮すべき点は、隣接する2つのMPLSラベルスイッチングルーター（LSR）が単にMPLSパケットを交換するのではないということです。隣接関係の形成、制御、ルーティング、ラベル交換、管理、および監視の目的でIPパケットを交換します。さらに、ルーティングの一部としてデータリンクパケット（IS-IS HelloやIS-ISリンクステートパケットなど）を交換したり、Link-Layer Discovery Protocol [ IEEE.802.1AB.2009]。したがって、2つのクライアントには、多数のプロトコルを多重化するために使用できる接続メカニズムが必要です。さらに、これらすべてのプロトコルが運命を共有することは、ネットワーク層が正しく動作するために不可欠です。
Where the client LSR and server PE are co-located in the same equipment, the data-link layer can be simplified to a point-to-point Ethernet used to multiplex the various data-link types onto a pseudowire. This is the method described in this document.
クライアントLSRとサーバーPEが同じ機器に配置されている場合、データリンク層は、さまざまなデータリンクタイプを疑似配線に多重化するために使用されるポイントツーポイントイーサネットに簡略化できます。これは、このドキュメントで説明されている方法です。
Appendix A provides information on alternative approaches to providing a packet PW that were considered by the PWE3 Working Group and the reasons for using the method defined in this specification.
付録Aは、PWE3ワーキンググループによって検討されたパケットPWを提供するための代替アプローチと、この仕様で定義されている方法を使用する理由についての情報を提供します。
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」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [RFC2119]で説明されているように解釈されます。
The network reference model for the packet pseudowire operating in an MPLS network is shown in Figure 1. This is an extension of Figure 3 "Pre-processing within the PWE3 Network Reference Model" from [RFC3985].
MPLSネットワークで動作するパケット疑似配線のネットワーク参照モデルを図1に示します。これは、[RFC3985]の図3「PWE3ネットワーク参照モデル内の前処理」の拡張です。
PW PW
End Service End Service
| |
|<------- Pseudowire ------->|
| |
| Server |
| |<- PSN Tunnel ->| |
| V V |
------- +-----+-----+ +-----+-----+ -------
) | | |================| | | (
Client ) | MPLS| PE1 | PW1 | PE2 | MPLS| ( Client
MPLS PSN )+ LSR1+............................+ LSR2+( MPLS PSN
) | | | | | | (
) | | |================| | | (
------- +-----+-----+ +-----+-----+ --------
^ ^
| |
| |
|<---- Emulated Service----->|
| |
Virtual physical Virtual physical
termination termination
Figure 1: Packet PW Network Reference Model
図1：パケットPWネットワーク参照モデル
In this model, the LSRs (LSR1 and LSR2) are part of the client MPLS PSN. The PEs (PE1 and PE2) are part of the server PSN that is to be used to provide connectivity between the client LSRs. The attachment circuit that is used to connect the MPLS LSRs to the PEs is a virtual interface within the equipment. A packet pseudowire is used to provide connectivity between these virtual interfaces. This packet pseudowire is used to transport all of the required layer 2 and layer 3 protocols between LSR1 and LSR2.
このモデルでは、LSR（LSR1およびLSR2）はクライアントMPLS PSNの一部です。 PE（PE1およびPE2）は、クライアントLSR間の接続を提供するために使用されるサーバーPSNの一部です。 MPLS LSRをPEに接続するために使用される接続回線は、機器内の仮想インターフェイスです。パケット疑似配線は、これらの仮想インターフェイス間の接続を提供するために使用されます。このパケット疑似配線は、LSR1とLSR2の間で必要なすべてのレイヤー2およびレイヤー3プロトコルを転送するために使用されます。
The packet PW appears as a single point-to-point link to the client layer. Network-layer adjacency formation and maintenance between the client equipments will follow the normal practice needed to support the required relationship in the client layer. The assignment of metrics for this point-to-point link is a matter for the client layer. In a hop-by-hop routing network, the metrics would normally be assigned by appropriate configuration of the embedded client network-layer equipment (e.g., the embedded client LSR). Where the client was using the packet PW as part of a traffic-engineered path, it is up to the operator of the client network to ensure that the server-layer operator provides the necessary service-level agreement.
パケットPWは、クライアント層への単一のポイントツーポイントリンクとして表示されます。クライアント機器間のネットワーク層の隣接関係の形成と保守は、クライアント層で必要な関係をサポートするために必要な通常の方法に従います。このポイントツーポイントリンクのメトリックの割り当ては、クライアントレイヤーの問題です。ホップバイホップルーティングネットワークでは、メトリックは通常、組み込みクライアントネットワーク層機器（組み込みクライアントLSRなど）の適切な構成によって割り当てられます。クライアントがトラフィックエンジニアリングされたパスの一部としてパケットPWを使用していた場合、サーバー層のオペレーターが必要なサービスレベルアグリーメントを確実に提供するかどうかは、クライアントネットワークのオペレーター次第です。
The packet PW forwarding model is illustrated in Figure 2. The forwarding operation can be likened to a virtual private network (VPN), in which a forwarding decision is first taken at the client layer, an encapsulation is applied, and then a second forwarding decision is taken at the server layer.
パケットPW転送モデルを図2に示します。転送操作は、仮想プライベートネットワーク（VPN）に例えることができます。この場合、転送決定は最初にクライアントレイヤーで行われ、カプセル化が適用され、次に2番目の転送決定が適用されます。サーバー層で取得されます。
+------------------------------------------------+
| |
| +--------+ +--------+ |
| | | Pkt +-----+ | | |
------+ +---------+ PW1 +--------+ +------
| | Client | AC +-----+ | Server | |
Client | | LSR | | LSR | | Server
Network | | | Pkt +-----+ | | | Network
------+ +---------+ PW2 +--------+ +------
| | | AC +-----+ | | |
| +--------+ +--------+ |
| |
+------------------------------------------------+
Figure 2: Packet PW Forwarding Model
図2：パケットPW転送モデル
A packet PW PE comprises three components: the client LSR, a PW processor, and a server LSR. Note that [RFC3985] does not formally indicate the presence of the server LSR because it does not concern itself with the server layer. However it is useful in this document to recognize that the server LSR exists.
パケットPW PEは、クライアントLSR、PWプロセッサ、サーバーLSRの3つのコンポーネントで構成されています。 [RFC3985]はサーバーLSR自体に関係しないため、サーバーLSRの存在を正式に示していないことに注意してください。ただし、このドキュメントでは、サーバーLSRが存在することを認識すると役立ちます。
It may be useful to first recall the operation of a layer 2 PW such as an Ethernet PW [RFC4448] within this model. The client LSR is not present, and packets arrive directly on the attachment circuit (AC) that is part of the client network. The PW function undertakes any header processing, if configured to do so; it then optionally pushes the PW control word (CW) and finally pushes the PW label. The PW function then passes the packet to the LSR function, which pushes the label needed to reach the egress PE and forwards the packet to the next hop in the server network. At the egress PE, the packet typically arrives with the PW label at the top of the stack; the packet is thus directed to the correct PW instance. The PW instance performs any required reconstruction using, if necessary, the CW, and the packet is sent directly to the attachment circuit.
最初に、このモデル内のイーサネットPW [RFC4448]などのレイヤー2 PWの操作を思い出してください。クライアントLSRは存在せず、パケットはクライアントネットワークの一部である接続回線（AC）に直接到着します。 PW関数は、ヘッダー処理を行うように構成されている場合は、それを実行します。次に、オプションでPW制御ワード（CW）をプッシュし、最後にPWラベルをプッシュします。次に、PW機能はパケットをLSR機能に渡します。LSR機能は、出力PEに到達するために必要なラベルをプッシュし、パケットをサーバーネットワークの次のホップに転送します。出力PEでは、パケットは通常、PWラベルとともにスタックの最上部に到着します。したがって、パケットは正しいPWインスタンスに送信されます。 PWインスタンスは、必要に応じてCWを使用して必要な再構築を実行し、パケットは直接接続回線に送信されます。
Now let us consider the case of client-layer MPLS traffic being carried over a packet PW. An LSR belonging to the client layer is embedded within the PE equipment. This is a type of native service processing element [RFC3985]. The client LSR determines the next hop in the client layer, and pushes the label needed by the next hop in the client layer. It then encapsulates the packet in an Ethernet header setting the Ethertype to MPLS, and the client LSR passes the packet to the correct PW instance. The PW instance then proceeds as defined for an Ethernet PW [RFC4448] by optionally pushing the control word, then pushing the PW label, and finally handing the packet to the server-layer LSR for delivery to the egress PE in the server layer.
次に、クライアント層のMPLSトラフィックがパケットPWを介して伝送される場合を考えます。クライアント層に属するLSRは、PE機器内に組み込まれています。これは、ネイティブサービス処理要素のタイプです[RFC3985]。クライアントLSRは、クライアント層の次のホップを決定し、クライアント層の次のホップで必要なラベルをプッシュします。次に、EthertypeをMPLSに設定するイーサネットヘッダーにパケットをカプセル化し、クライアントLSRがパケットを正しいPWインスタンスに渡します。次に、PWインスタンスはイーサネットPW [RFC4448]の定義に従って、オプションでコントロールワードをプッシュし、次にPWラベルをプッシュし、最後にサーバー層の出力PEに配信するためにサーバー層LSRにパケットを渡します。
At the egress PE in the server layer, the packet is first processed by the server LSR, which uses the PW label to pass the packet to the correct PW instance. This PW instance processes the packet as described in [RFC4448]. The resultant Ethernet encapsulated client packet is then passed to the egress client LSR, which then processes the packet in the normal manner.
サーバーレイヤーの出力PEでは、パケットは最初にサーバーLSRによって処理されます。サーバーLSRは、PWラベルを使用してパケットを正しいPWインスタンスに渡します。このPWインスタンスは、[RFC4448]で説明されているようにパケットを処理します。結果として得られるイーサネットカプセル化クライアントパケットは、出力クライアントLSRに渡され、通常の方法でパケットが処理されます。
Note that although the description above is written in terms of the behavior of an MPLS LSR, the processing model would be similar for an IP packet or any other protocol type.
上記の説明はMPLS LSRの動作に関して記述されていますが、処理モデルはIPパケットやその他のプロトコルタイプでも同様です。
Note that the semantics of the PW between the client LSRs is a point-to-point link.
クライアントLSR間のPWのセマンティクスはポイントツーポイントリンクであることに注意してください。
The client network-layer packet encapsulation into a packet PW is shown in Figure 3.
パケットPWへのクライアントネットワーク層パケットのカプセル化を図3に示します。
+-------------------------------+
| Client |
| Network-Layer |
| Packet | n octets
| |
+-------------------------------+
| |
| Ethernet | 14 octets
| Header |
| +---------------+
| |
+---------------+---------------+
| Optional Control Word | 4 octets
+-------------------------------+
| PW Label | 4 octets
+-------------------------------+
| Server MPLS Tunnel Label(s) | n*4 octets (4 octets per label)
+-------------------------------+
Figure 3: Packet PW Encapsulation
図3：パケットPWカプセル化
This conforms to the PW protocols stack as defined in [RFC4448]. The protocol stack is unremarkable except to note that the stack does not retain 32-bit alignment between the virtual Ethernet header and the PW optional control word (or the PW label when the optional components are not present in the PW header). This loss of 32 bits of alignment is necessary to preserve backwards compatibility with the Ethernet PW design [RFC4448]
これは、[RFC4448]で定義されているPWプロトコルスタックに準拠しています。プロトコルスタックは、スタックが仮想イーサネットヘッダーとPWオプションコントロールワード（またはオプションコンポーネントがPWヘッダーに存在しない場合はPWラベル）の間の32ビットアライメントを保持しないことに注意することを除いて、注目に値しません。この32ビットのアライメントの損失は、イーサネットPW設計との下位互換性を維持するために必要です[RFC4448]
Ethernet Raw Mode (PW type 5) MUST be used for the packet PW.
パケットのPWには、イーサネットRawモード（PWタイプ5）を使用する必要があります。
The PEs MAY use a local Ethernet address for the Ethernet header used to encapsulate the client network-layer packet or MAY use the special Ethernet addresses "PacketPWEthA" or "PacketPWEthB" as described below.
PEは、クライアントのネットワーク層パケットをカプセル化するために使用されるイーサネットヘッダーにローカルイーサネットアドレスを使用する場合と、以下に説明するように、特別なイーサネットアドレス「PacketPWEthA」または「PacketPWEthB」を使用する場合があります。
IANA has allocated two unicast Ethernet addresses [RFC5342] for use with this protocol, referred to as "PacketPWEthA" and "PacketPWEthB". Where [RFC4447] signaling is used to set up the PW, the LDP peers numerically compare their IP addresses. The LDP PE with the higher-value IP address will use PacketPWEthA, whilst the LDP peer with the lower-value IP address uses PacketPWEthB.
IANAは、「PacketPWEthA」および「PacketPWEthB」と呼ばれる、このプロトコルで使用する2つのユニキャストイーサネットアドレス[RFC5342]を割り当てています。 [RFC4447]シグナリングを使用してPWをセットアップする場合、LDPピアはそれらのIPアドレスを数値的に比較します。値の大きいIPアドレスを持つLDP PEはPacketPWEthAを使用し、値の小さいIPアドレスを持つLDPピアはPacketPWEthBを使用します。
Where no signaling PW protocol is used, suitable Ethernet addresses MUST be configured at each PE.
シグナリングPWプロトコルを使用しない場合、適切なイーサネットアドレスを各PEで設定する必要があります。
Although this PW represents a point-to-point connection, the use of a multicast destination address in the Ethernet encapsulation is REQUIRED by some client-layer protocols. Peers MUST be prepared to handle a multicast destination address in the Ethernet encapsulation.
このPWはポイントツーポイント接続を表しますが、一部のクライアント層プロトコルでは、イーサネットカプセル化でのマルチキャスト宛先アドレスの使用が必要です。ピアは、イーサネットカプセル化でマルチキャスト宛先アドレスを処理できるように準備する必要があります。
The use of Ethernet as the encapsulation mechanism for traffic between the server LSRs is a convenience based on the widespread availability of existing hardware. In this application, there is no requirement for any Ethernet feature other than its protocol multiplexing capability. Thus, for example, a server LSR is not required to implement the Ethernet OAM.
サーバーLSR間のトラフィックのカプセル化メカニズムとしてイーサネットを使用すると、既存のハードウェアが広く利用できるようになるので便利です。このアプリケーションでは、プロトコル多重化機能以外のイーサネット機能は必要ありません。したがって、たとえば、サーバーLSRはイーサネットOAMを実装する必要はありません。
The use and applicability of VLANs, IEEE 802.1p, and IEEE 802.1Q tagging between PEs is not supported.
PE、PE間のVLAN、IEEE 802.1p、およびIEEE 802.1Qタギングの使用と適用性はサポートされていません。
Point-to-multipoint and multipoint-to-multipoint operation of the virtual Ethernet is not supported.
仮想イーサネットのポイントツーマルチポイントおよびマルチポイントツーマルチポイント操作はサポートされていません。
A packet pseudowire is normally used to carry IP, MPLS and their associated support protocols over an MPLS network. There are no congestion considerations beyond those that ordinarily apply to an IP or MPLS network. Where the packet protocol being carried is not IP or MPLS and the traffic volumes are greater than that ordinarily associated with the support protocols in an IP or MPLS network, the congestion considerations developed for PWs apply [RFC3985] [RFC5659].
パケット疑似配線は通常、MPLSネットワークを介してIP、MPLS、およびそれらに関連するサポートプロトコルを伝送するために使用されます。通常、IPまたはMPLSネットワークに適用される輻輳に関する考慮事項はありません。運ばれているパケットプロトコルがIPまたはMPLSではなく、トラフィック量がIPまたはMPLSネットワークのサポートプロトコルに通常関連付けられているものよりも多い場合、PW用に開発された輻輳の考慮事項が適用されます[RFC3985] [RFC5659]。
The virtual Ethernet approach to packet PW introduces no new security risks. A more detailed discussion of pseudowire security is given in [RFC3985], [RFC4447], and [RFC3916].
パケットPWへの仮想イーサネットアプローチは、新しいセキュリティリスクをもたらしません。疑似配線セキュリティの詳細については、[RFC3985]、[RFC4447]、および[RFC3916]で説明されています。
IANA has allocated two Ethernet unicast addresses from "IANA Unicast 48-bit MAC Addresses".
IANAは、「IANAユニキャスト48ビットMACアドレス」から2つのイーサネットユニキャストアドレスを割り当てました。
Address Usage Reference
------------------- ---------------- ---------
00-00-5E-00-52-00 PacketPWEthA [RFC6658]
00-00-5E-00-52-01 PacketPWEthB [RFC6658]
The authors acknowledge the contributions made to this document by Sami Boutros, Giles Herron, Siva Sivabalan, and David Ward.
著者は、Sami Boutros、Giles Herron、Siva Sivabalan、およびDavid Wardによるこのドキュメントへの貢献を認めます。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC4447] 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.
[RFC4447] Martini、L.、Rosen、E.、El-Aawar、N.、Smith、T。、およびG. Heron、「Pseudowire Setup and Maintenance Using a Label Distribution Protocol（LDP）」、RFC 4447、2006年4月。
[RFC4448] Martini, L., Rosen, E., El-Aawar, N., and G. Heron, "Encapsulation Methods for Transport of Ethernet over MPLS Networks", RFC 4448, April 2006.
[RFC4448] Martini、L.、Rosen、E.、El-Aawar、N.、and G. Heron、 "Encapsulation Methods for Transport of Ethernet over MPLS Networks"、RFC 4448、April 2006。
[RFC5342] Eastlake, D., "IANA Considerations and IETF Protocol Usage for IEEE 802 Parameters", BCP 141, RFC 5342, September 2008.
[RFC5342] Eastlake、D。、「IEEE考慮事項とIEEE 802パラメータのIETFプロトコルの使用」、BCP 141、RFC 5342、2008年9月。
[IEEE.802.1AB.2009] Institute of Electrical and Electronics Engineers, "IEEE Standard for Local and Metropolitan Area Networks -- Station and Media Access Control Connectivity Discovery", IEEE Standard 802.1AB, 2009.
[IEEE.802.1AB.2009] Institute of Electrical and Electronics Engineers、「IEEE Standard for Local and Metropolitan Area Networks-Station and Media Access Control Connectivity Discovery」、IEEE Standard 802.1AB、2009。
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[RFC3031]ローゼン、E。、ヴィスワナサン、A。、およびR.キャロン、「マルチプロトコルラベルスイッチングアーキテクチャ」、RFC 3031、2001年1月。
[RFC3916] Xiao, X., McPherson, D., and P. Pate, "Requirements for Pseudo-Wire Emulation Edge-to-Edge (PWE3)", RFC 3916, September 2004.
[RFC3916] Xiao、X.、McPherson、D。、およびP. Pate、「Pseudo-Wire Emulation Edge-to-Edge（PWE3）の要件」、RFC 3916、2004年9月。
[RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture", RFC 3985, March 2005.
[RFC3985]ブライアント、S。およびP.パテ、「疑似ワイヤーエミュレーションエッジツーエッジ（PWE3）アーキテクチャ」、RFC 3985、2005年3月。
[RFC4385] 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.
[RFC4385]ブライアント、S。、スワロー、G。、マティーニ、L。、およびD.マクファーソン、「MPLS PSNで使用する疑似配線エミュレーションエッジツーエッジ（PWE3）制御ワード」、RFC 4385、2006年2月。
[RFC5317] Bryant, S. and L. Andersson, "Joint Working Team (JWT) Report on MPLS Architectural Considerations for a Transport Profile", RFC 5317, February 2009.
[RFC5317]ブライアント、S。およびL.アンダーソン、「トランスポートプロファイルのMPLSアーキテクチャに関する考慮事項に関する共同作業チーム（JWT）レポート」、RFC 5317、2009年2月。
[RFC5659] Bocci, M. and S. Bryant, "An Architecture for Multi-Segment Pseudowire Emulation Edge-to-Edge", RFC 5659, October 2009.
[RFC5659] Bocci、M.およびS. Bryant、「An-Architecture for Multi-Segment Pseudowire Emulation Edge-to-Edge」、RFC 5659、2009年10月。
[RFC5921] Bocci, M., Bryant, S., Frost, D., Levrau, L., and L. Berger, "A Framework for MPLS in Transport Networks", RFC 5921, July 2010.
[RFC5921] Bocci、M.、Bryant、S.、Frost、D.、Levrau、L。、およびL. Berger、「A Transport Framework in MPLS in MPLS」、RFC 5921、2010年7月。
A number of approaches to the design of a packet pseudowire (PW) were investigated by the PWE3 Working Group and were discussed in IETF meetings and on the PWE3 list. This section describes the approaches that were analyzed and the technical issues that the authors took into consideration in arriving at the approach described in the main body of this document. This appendix is provided so that engineers considering alternative optimizations can have access to the rationale for the selection of the approach described in this document.
パケット疑似配線（PW）の設計に対する多くのアプローチがPWE3ワーキンググループによって調査され、IETFミーティングおよびPWE3リストで議論されました。このセクションでは、分析されたアプローチと、このドキュメントの本文で説明されているアプローチに到達する際に作成者が考慮した技術的な問題について説明します。この付録は、代替の最適化を検討しているエンジニアが、このドキュメントで説明されているアプローチを選択する根拠にアクセスできるように提供されています。
In a typical network, there are usually no more that four network-layer protocols that need to be supported: IPv4, IPv6, MPLS, and Connectionless Network Service (CLNS). However, any solution needs to be scalable to a larger number of protocols. The approaches considered in this appendix all satisfy this minimum requirement but vary in their ability to support larger numbers of network-layer protocols.
一般的なネットワークでは、サポートする必要のあるネットワーク層プロトコルは通常、IPv4、IPv6、MPLS、コネクションレス型ネットワークサービス（CLNS）の4つだけです。ただし、どのようなソリューションも、より多くのプロトコルに拡張できる必要があります。この付録で検討されているアプローチはすべてこの最小要件を満たしていますが、より多くのネットワーク層プロトコルをサポートする能力は異なります。
Additionally, it is beneficial if the complete set of protocols carried over the network in support of a set of CE peers fate share. It is additionally beneficial if a single OAM session can be used to monitor the behavior of this complete set. During the investigation, various views were expressed as to where these benefits lay on the scale from absolutely required to "nice to have", but in the end, they were not a factor in reaching our conclusion.
さらに、一連のCEピアの運命の共有をサポートするために、ネットワークを介して実行されるプロトコルの完全なセットがある場合、それは有益です。さらに、単一のOAMセッションを使用して、この完全なセットの動作を監視できると便利です。調査中に、これらの利点が絶対に必要なものから「持つのに良い」までのスケールでどこにあるかについてさまざまな見解が表明されましたが、結局、それらは私たちの結論に到達するための要因ではありませんでした。
Four candidate approaches were analyzed:
4つの候補アプローチが分析されました。
1. A protocol identifier (PID) in the PW control word (CW)
1. PWコントロールワード（CW）のプロトコル識別子（PID）
2. A PID label
2. PIDラベル
3. Parallel PWs - one per protocol
3. 並列PW-プロトコルごとに1つ
4. Virtual Ethernet
4. 仮想イーサネット
In this approach, a Protocol Identifier (PID) is included in the PW control word (CW) by appending it to the generic control word [RFC4385] to make a 6-byte CW (it was thought that this approach would include 2 reserved bytes to provide 32-bit alignment, but then this was optimized out). A variant of this is just to use a 2-byte PID without a control word.
このアプローチでは、プロトコル識別子（PID）がPW制御ワード（CW）に含まれ、汎用制御ワード[RFC4385]に追加されて6バイトのCWになります（このアプローチには2バイトの予約バイトが含まれると考えられていました） 32ビットアライメントを提供しますが、これは最適化されました）。これの変形は、コントロールワードなしで2バイトのPIDを使用することです。
This is a simple approach and is basically a virtual PPP interface without the PPP control protocol. This has a smaller MTU than, for example, a virtual Ethernet would need; however, in forwarding terms, it is not as simple as the PID label or multiple PW approaches described next and may not be deployable on a number of existing hardware platforms.
これは単純なアプローチであり、基本的にはPPP制御プロトコルを使用しない仮想PPPインターフェイスです。これは、たとえば、仮想イーサネットが必要とするよりも小さいMTUを持っています。ただし、転送に関しては、PIDラベルまたは次に説明する複数のPWアプローチほど単純ではなく、多くの既存のハードウェアプラットフォームに展開できない場合があります。
In this approach, the PID is indicated by including a label after the PW label that indicates the protocol type, as shown in Figure 4.
このアプローチでは、PIDは、図4に示すように、プロトコルタイプを示すPWラベルの後にラベルを含めることで示されます。
+-------------------------------+
| Client |
| Network-Layer |
| Packet | n octets
| |
+-------------------------------+
| Optional Control Word | 4 octets
+-------------------------------+
| PID Label (S=1) | 4 octets
+-------------------------------+
| PW Label | 4 octets
+-------------------------------+
| Server MPLS Tunnel Label(s) | n*4 octets (four octets per label)
+-------------------------------+
Figure 4: Encapsulation of a Pseudowire with a Pseudowire Load-Balancing Label
図4：疑似配線ロードバランシングラベルを使用した疑似配線のカプセル化
In the PID label approach, a new Label Distribution Protocol (LDP) Forwarding Equivalence Class (FEC) element is used to signal the mapping between protocol type and the PID label. This approach complies with [RFC3031].
PIDラベルアプローチでは、新しいラベル配布プロトコル（LDP）転送等価クラス（FEC）要素を使用して、プロトコルタイプとPIDラベル間のマッピングを通知します。このアプローチは[RFC3031]に準拠しています。
A similar approach to PID label is described in Section 3.4.5 of [RFC5921]. In this case, when the client is a network-layer packet service such as IP or MPLS, a service label and demultiplexer label (which may be combined) are used to provide the necessary identifications needed to carry this traffic over an LSP.
PIDラベルへの同様のアプローチは、[RFC5921]のセクション3.4.5で説明されています。この場合、クライアントがIPやMPLSなどのネットワーク層パケットサービスである場合、サービスラベルとデマルチプレクサラベル（組み合わせることもできます）を使用して、LSP経由でこのトラフィックを伝送するために必要な識別情報を提供します。
The authors surveyed the hardware designs produced by a number of companies across the industry and concluded that whilst the approach complies with the MPLS architecture, it may conflict with a number of designers' interpretations of the existing MPLS architecture. This led to concerns that the approach may result in unexpected difficulties in the future. Specifically, there was an assumption in many designs that a forwarding decision should be made on the basis of a single label. Whilst the approach is attractive, it cannot be supported by many commodity chip sets, and this would require new hardware, which would increase the cost of deployment and delay the introduction of a packet PW service.
著者は、業界全体の多くの企業が作成したハードウェア設計を調査し、このアプローチはMPLSアーキテクチャに準拠している一方で、多くの設計者による既存のMPLSアーキテクチャの解釈と矛盾する可能性があると結論付けました。これは、このアプローチが将来予期しない困難をもたらす可能性があるという懸念につながりました。具体的には、転送の決定は単一のラベルに基づいて行われるべきであるという多くの設計での仮定がありました。このアプローチは魅力的ですが、多くの汎用チップセットでサポートすることはできません。これには新しいハードウェアが必要になるため、導入コストが増加し、パケットPWサービスの導入が遅れます。
In this approach, one PW is constructed for each protocol type that must be carried between the PEs. Thus, a complete packet PW would consist of a bundle of PWs. This model would be very simple and efficient from a forwarding point of view. The number of parallel PWs required would normally be relatively small. In a typical network, there are usually no more that four network-layer protocols that need to be supported: IPv4, IPv6, MPLS, and CLNS. However, any solution needs to be scalable to a larger number of protocols.
このアプローチでは、PE間で伝送する必要があるプロトコルタイプごとに1つのPWが構築されます。したがって、完全なパケットPWは、PWのバンドルで構成されます。このモデルは、転送の観点から見ると非常にシンプルで効率的です。通常、必要な並列PWの数は比較的少なくなります。一般的なネットワークでは、サポートする必要のあるネットワーク層プロトコルは通常、IPv4、IPv6、MPLS、CLNSの4つだけです。ただし、どのようなソリューションも、より多くのプロトコルに拡張できる必要があります。
There are a number of serious downsides with this approach:
このアプローチには多くの深刻な欠点があります。
1. From an operational point of view, the lack of fate sharing between the protocol types can lead to complex faults that are difficult to diagnose.
1. 運用上の観点から、プロトコルタイプ間の運命共有の欠如は、診断が難しい複雑な障害につながる可能性があります。
2. There is an undesirable trade-off in the OAM related to the first point. We would have to run an OAM on each PW and bind them together, which leads to significant protocol and software complexity and does not scale well. Alternatively, we would need to run a single OAM session on one of the PWs as a proxy for the others and then diagnose any more complex failures on a case-by-case basis. To some extent, the issue of fate sharing between protocols in the bundle (for example, the assumed fate sharing between CLNS and IP in IS-IS) can be mitigated through the use of Bidirectional Forwarding Detection (BFD).
2. 最初のポイントに関連するOAMには望ましくないトレードオフがあります。各PWでOAMを実行してバインドする必要があるため、プロトコルとソフトウェアが大幅に複雑になり、十分に拡張できません。あるいは、PWの1つで他のプロキシのプロキシとして単一のOAMセッションを実行し、ケースバイケースでより複雑な障害を診断する必要があります。ある程度、バンドル内のプロトコル間の運命共有の問題（たとえば、IS-ISのCLNSとIP間の運命共有の想定）は、双方向転送検出（BFD）を使用することで軽減できます。
3. The need to configure, manage, and synchronize the behavior of a group of PWs as if they were a single PW leads to an increase in control-plane complexity.
3. 単一のPWであるかのように、PWのグループの動作を構成、管理、同期する必要があるため、コントロールプレーンが複雑になります。
The Parallel PW mechanism is therefore an approach that simplifies the forwarding plane, but only at a cost of a considerable increase in other aspects of the design, in particular, operation of the PW.
したがって、パラレルPWメカニズムは、転送プレーンを簡略化するアプローチですが、設計の他の側面、特にPWの操作が大幅に増加するという犠牲を払うだけです。
Using a virtual Ethernet to provide a packet PW would require PEs to include a virtual (internal) Ethernet interface and then to use an Ethernet PW [RFC4448] to carry the user traffic. This is conceptually simple and can be implemented today without any further standards action, although there are a number of applicability considerations that it are useful to bring to the attention of the community.
仮想イーサネットを使用してパケットPWを提供するには、PEに仮想（内部）イーサネットインターフェイスを含め、イーサネットPW [RFC4448]を使用してユーザートラフィックを伝送する必要があります。これは概念的には単純であり、コミュニティに注意を向けるのに役立ついくつかの適用性の考慮事項がありますが、それ以上の標準アクションなしで今日実装できます。
Conceptually, this is a simple approach, and some deployed equipments can already do this. However, the requirement to run a complete Ethernet adjacency led us to conclude that there was a need to identify a simpler approach. The packets encapsulated in an Ethernet header have a larger MTU than the other approaches, although this is not considered to be an issue on the networks needing to carry packet PWs.
概念的には、これは単純なアプローチであり、一部の展開済み機器はすでにこれを実行できます。ただし、完全なイーサネット隣接関係を実行する必要があるため、より単純なアプローチを特定する必要があると結論づけられました。イーサネットヘッダーにカプセル化されたパケットは、他のアプローチよりもMTUが大きくなりますが、これは、パケットPWを伝送する必要があるネットワークでは問題とは見なされません。
The virtual Ethernet mechanism was the first approach that the authors considered, before the merits of the other approaches appeared to make them more attractive. As we shall see below, however, the other approaches were not without issues, and it appears that the virtual Ethernet is the preferred approach to providing a packet PW.
仮想イーサネットメカニズムは、他のアプローチのメリットが魅力的になる前に、著者が最初に検討したアプローチでした。ただし、以下で説明するように、他のアプローチには問題がなかったわけではなく、仮想イーサネットがパケットPWを提供するための推奨アプローチであるようです。
The operational complexity and the breaking of fate-sharing assumptions associated with the parallel PW approach would suggest that this is not an approach that should be further pursued.
運用の複雑さと並列PWアプローチに関連する運命共有の仮定の破綻は、これがさらに追求されるべきアプローチではないことを示唆しています。
The PID label approach gives rise to the concerns that it will break implicit behavioral and label-stack size assumptions in many implementations. Whilst those assumptions may be addressed with new hardware, this would delay the introduction of the technology to the point where it is unlikely to gain acceptance in competition with an approach that needs no new protocol design and is already supportable on many existing hardware platforms.
PIDラベルアプローチは、多くの実装で暗黙的な動作およびラベルスタックサイズの仮定を破るという懸念を引き起こします。これらの前提条件は新しいハードウェアで対処できますが、これにより、新しいプロトコルの設計を必要とせず、多くの既存のハードウェアプラットフォームで既にサポートされているアプローチと競合しても、技術の導入が遅れる可能性があります。
The PID in the CW leads to the most compact protocol stack, is simple, and requires minimal protocol work. However, it is a new forwarding design and, apart from the issue of the larger packet header and the simpler adjacency formation, offers no advantage over the virtual Ethernet.
CWのPIDは、最もコンパクトなプロトコルスタックにつながり、シンプルで、最小限のプロトコル作業しか必要としません。ただし、これは新しい転送設計であり、より大きなパケットヘッダーと単純な隣接関係の問題は別として、仮想イーサネットに勝る利点はありません。
The above considerations bring us back to the virtual Ethernet, which is a well-known protocol stack with a well-known (internal) client interface. It is already implemented in many hardware platforms and is therefore readily deployable. After considering a number of initially promising alternatives, the authors conclude that the simplicity and existing hardware make the virtual Ethernet approach to the packet PW the most attractive solution.
上記の考慮事項は、よく知られている（内部）クライアントインターフェイスを備えたよく知られているプロトコルスタックである仮想イーサネットに戻ります。すでに多くのハードウェアプラットフォームに実装されているため、簡単に展開できます。最初に有望ないくつかの代替案を検討した後、著者らは、シンプルさと既存のハードウェアにより、パケットPWへの仮想イーサネットアプローチが最も魅力的なソリューションになると結論付けています。
Authors' Addresses
著者のアドレス
Stewart Bryant (editor) Cisco Systems 250, Longwater, Green Park, Reading, Berks RG2 6GB UK
Stewart Bryant（editor）Cisco Systems 250、Longwater、Green Park、Reading、Berks RG2 6GB UK
EMail: stbryant@cisco.com
Luca Martini Cisco Systems 9155 East Nichols Avenue, Suite 400 Englewood, CO 80112 USA
Luca Martini Cisco Systems 9155 East Nichols Avenue、Suite 400 Englewood、CO 80112 USA
EMail: lmartini@cisco.com
George Swallow Cisco Systems 1414 Massachusetts Ave Boxborough, MA 01719 USA
George Swallow Cisco Systems 1414 Massachusetts Ave Boxborough、MA 01719 USA
EMail: swallow@cisco.com
Andrew G. Malis Verizon Communications 60 Sylvan Rd. Waltham, MA 02451 USA
アンドリューG.マリスベライゾンコミュニケーションズ60シルバンロードアメリカ合衆国、マサチューセッツ州ウォルサム
EMail: andrew.g.malis@verizon.com