Network Working Group                                      N. Bitar, Ed.
Request for Comments: 5254                                       Verizon
Category: Informational                                    M. Bocci, Ed.
                                                         L. Martini, Ed.
                                                     Cisco Systems, Inc.
                                                            October 2008

Requirements for Multi-Segment Pseudowire Emulation Edge-to-Edge (PWE3)


Status of This Memo


This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.




This document describes the necessary requirements to allow a service provider to extend the reach of pseudowires across multiple domains. These domains can be autonomous systems under one provider administrative control, IGP areas in one autonomous system, different autonomous systems under the administrative control of two or more service providers, or administratively established pseudowire domains.


Table of Contents


   1. Introduction ....................................................3
      1.1. Scope ......................................................3
      1.2. Architecture ...............................................3
   2. Terminology .....................................................6
      2.1. Specification of Requirements ..............................6
   3. Use Cases .......................................................7
      3.1. Multi-Segment Pseudowire Setup Mechanisms ..................9
   4. Multi-Segment Pseudowire Requirements ..........................10
      4.1. All Mechanisms ............................................10
           4.1.1. Architecture .......................................10
           4.1.2. Resiliency .........................................11
           4.1.3. Quality of Service .................................11
           4.1.4. Congestion Control .................................12
           4.1.5  Generic Requirements for MS-PW Setup Mechanisms ....13
           4.1.6. Routing ............................................14
      4.2. Statically Configured MS-PWs ..............................15
           4.2.1. Architecture .......................................15
           4.2.2. MPLS-PWs ...........................................15
           4.2.3. Resiliency .........................................15
           4.2.4. Quality of Service .................................16
      4.3. Signaled PW Segments ......................................16
           4.3.1. Architecture .......................................16
           4.3.2. Resiliency .........................................16
           4.3.3. Quality of Service .................................17
           4.3.4. Routing ............................................17
           4.3.5. Additional Requirements on Signaled MS-PW Setup
                  Mechanisms .........................................17
      4.4. Signaled PW / Dynamic Route ...............................18
           4.4.1. Architecture .......................................18
           4.4.2. Resiliency .........................................18
           4.4.3. Quality of Service .................................18
           4.4.4. Routing ............................................18
   5. Operations and Maintenance (OAM) ...............................19
   6. Management of Multi-Segment Pseudowires ........................20
      6.1. MIB Requirements ..........................................20
      6.2. Management Interface Requirements .........................21
   7. Security Considerations ........................................21
      7.1. Inter-Provider MS-PWs .....................................21
           7.1.1. Data-Plane Security Requirements ...................21
           7.1.2. Control-Plane Security Requirements ................23
      7.2. Intra-Provider MS-PWs .....................................25
   8. Acknowledgments ................................................25
   9. References .....................................................25
      9.1. Normative References ......................................25
      9.2. Informative References ....................................25
1. Introduction
1. はじめに
1.1. Scope
1.1. 範囲

This document specifies requirements for extending pseudowires across more than one packet switched network (PSN) domain and/or more than one PSN tunnel. These pseudowires are called multi-segment pseudowires (MS-PWs). Requirements for single-segment pseudowires (SS-PWs) that extend edge to edge across only one PSN domain are specified in [RFC3916]. This document is not intended to invalidate any part of [RFC3985].


This document specifies additional requirements that apply to MS-PWs. These requirements do not apply to PSNs that only support SS-PWs.


1.2. Architecture
1.2. 建築

The following three figures describe the reference models that are derived from [RFC3985] to support PW emulated services.


         |<-------------- 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
            |                                            |
            |                                            |
    Attachment Circuit (AC)                    Attachment Circuit (AC)
      Native service                              Native service

Figure 1: PWE3 Reference Configuration


Figure 1 shows the PWE3 reference architecture [RFC3985]. This architecture applies to the case where a PSN tunnel extends between two edges of a single PSN domain to transport a PW with endpoints at these edges.


         Native  |<--------Multi-Segment Pseudowire----->|  Native
         Service |         PSN              PSN          |  Service
          (AC)   |     |<-Tunnel->|     |<-Tunnel->|     |  (AC)
           |     V     V     1    V     V     2    V     V   |
           |     +-----+          +-----+          +---- +   |
   +---+   |     |T-PE1|==========|S-PE1|==========|T-PE2|   |    +---+
   |   |---------|........PW1.......... |...PW3..........|---|----|   |
   |CE1|   |     |     |          |     |          |     |   |    |CE2|
   |   |---------|........PW2...........|...PW4..........|--------|   |
   +---+   |     |     |==========|     |==========|     |   |    +---+
       ^         +-----+          +-----+          +-----+        ^
       |     Provider Edge 1         ^        Provider Edge 3     |
       |                             |                            |
       |                             |                            |
       |                     PW switching point                   |
       |                                                          |
       |                                                          |
       |<------------------- Emulated Service ------------------->|

Figure 2: PW Switching Reference Model


Figure 2 extends this architecture to show a multi-segment case. Terminating PE1 (T-PE1) and Terminating PE3 (T-PE3) provide PWE3 service to CE1 and CE2. These PEs terminate different PSN tunnels, PSN Tunnel 1 and PSN Tunnel 2, and may reside in different PSN or pseudowire domains. One PSN tunnel extends from T-PE1 to S-PE1 across PSN1, and a second PSN tunnel extends from S-PE1 to T-PE2 across PSN2.


PWs are used to connect the Attachment circuits (ACs) attached to T-PE1 to the corresponding ACs attached to T-PE2. Each PW on PSN tunnel 1 is switched to a PW in the tunnel across PSN2 at S-PE1 to complete the multi-segment PW (MS-PW) between T-PE1 and T-PE2. S-PE1 is therefore the PW switching point and will be referred to as the PW switching provider edge (S-PE). PW1 and PW3 are segments of the same MS-PW while PW2 and PW4 are segments of another pseudowire. PW segments of the same MS-PW (e.g., PW1 and PW3) MAY be of the same PW type or different types, and PSN tunnels (e.g., PSN Tunnel 1 and PSN Tunnel 2) can be the same or different technology. This document requires support for MS-PWs with segments of the same PW type only.

PWSがT-PE2に取り付けられた対応するACSにT-PE1に取り付けられたアタッチメント回路(ACS)を接続するために使用されます。 PSNトンネル1の各PWは、T-PE1及びT-PE2の間にマルチセグメントPW(MS-PW)を完了するためにS-PE1におけるPSN2横切るトンネル内PWに切り換えられます。 S-PE1は、したがって、PW切り替えポイントであり、PWスイッチングプロバイダエッジ(S-PE)と呼ぶことにします。 PW2およびPW4は別の疑似回線のセグメントでありながらPW1およびPW3は、同じMS-PWのセグメントです。同じMS-PW(例えば、PW1およびPW3)のPWセグメントが同じPWタイプまたは異なるタイプ、およびPSNトンネルのものであってもよい(例えば、PSNトンネル1とPSNトンネル2)は同一または異なる技術であってもよいです。この文書は、同じPWタイプのセグメントとMS-のPWのサポートを必要とします。

An S-PE switches an MS-PW from one segment to another based on the PW identifiers (e.g., PW label in case of MPLS PWs). In Figure 2, the domains that PSN Tunnel 1 and PSN Tunnel 2 traverse could be IGP areas in the same IGP network or simply PWE3 domains in a single flat IGP network, for instance.


                |<------Multi-Segment Pseudowire------>|
                |         AS                AS         |
            AC  |    |<----1---->|     |<----2--->|    |  AC
            |   V    V           V     V          V    V  |
            |   +----+     +-----+     +----+     +----+  |
   +----+   |   |    |=====|     |=====|    |=====|    |  |    +----+
   |    |-------|.....PW1..........PW2.........PW3.....|-------|    |
   | CE1|   |   |    |     |     |     |    |     |    |  |    |CE2 |
   +----+   |   |    |=====|     |=====|    |=====|    |  |    +----+
        ^       +----+     +-----+     +----+     +----+       ^
        |       T-PE1       S-PE2       S-PE3     T-PE4        |
        |                     ^          ^                     |
        |                     |          |                     |
        |                  PW switching points                 |
        |                                                      |
        |                                                      |
        |<------------------- Emulated Service --------------->|

Figure 3: PW Switching Inter-Provider Reference Model


Note that although Figure 2 only shows a single S-PE, a PW may transit more than one S-PEs along its path. For instance, in the multi-AS case shown in Figure 3, there can be an S-PE (S-PE2) at the border of one AS (AS1) and another S-PE (S-PE3) at the border of the other AS (AS2). An MS-PW that extends from the edge of one AS (T-PE1) to the edge of the other AS (T-PE4) is composed of three segments: (1) PW1, a segment in AS1, (2) PW2, a segment between the two border routers (S-PE2 and S-PE3) that are switching PEs, and (3) PWE3, a segment in AS2. AS1 and AS2 could belong to the same provider (e.g., AS1 could be an access network or metro transport network, and AS2 could be an MPLS core network) or to two different providers (e.g., AS1 for Provider 1 and AS2 for Provider 2).

図2が単一のS-PEを示していることに注意し、PWよいトランジットつ以上のS-PESその経路に沿っ。例えば、図3に示したマルチASの場合、境界の1つのAS(AS1)と他のS-PE(S-PE3)の境界におけるS-PE(S-PE2)が存在し得ます他のAS(AS2)。 (1)PW1、AS1内のセグメント、(2)PW2、その他のAS(T-PE4)のエッジ1つのAS(T-PE1)の縁から延びMS-PWは三つのセグメントから構成されていますPEのスイッチングされた2つの境界ルータ(S-PE2及びS-PE3)との間のセグメント、および(3)PWE3、AS2内のセグメント。 AS1とAS2は、同じプロバイダに(例えば、AS1は、アクセスネットワークまたはメトロトランスポートネットワークすることができ、AS2は、MPLSコアネットワークすることができる)または2つの異なるプロバイダ(例えば、プロバイダ1、プロバイダ2のためのAS2用AS1)に属している可能性があり。

2. Terminology

RFC 3985 [RFC3985] provides terminology for PWE3. The following additional terminology is defined for multi-segment pseudowires:

RFC 3985 [RFC3985]はPWE3ための用語を提供します。以下の追加の用語がマルチセグメント疑似回線用に定義されます。

- PW Terminating Provider Edge (T-PE). A PE where the customer-facing attachment circuits (ACs) are bound to a PW forwarder. A Terminating PE is present in the first and last segments of an MS-PW. This incorporates the functionality of a PE as defined in RFC 3985.

- PWの終端プロバイダエッジ(T-PE)。顧客向けの接続回線(ACS)がPWフォワーダに結合されているPE。終端PEは、MS-PWの最初と最後のセグメントに存在します。 RFC 3985で定義されるように、これはPEの機能を組み込んでいます。

- Single-Segment Pseudowire (SS-PW). A PW setup directly between two PE devices. Each direction of an SS-PW traverses one PSN tunnel that connects the two PEs.

- 単一セグメント擬似回線(SS-PW)。 2つのPEデバイス間の直接PWセットアップ。 SS-PWの各方向は、二つのPEを接続する1つのPSNトンネルを横断します。

- Multi-Segment Pseudowire (MS-PW). A static or dynamically configured set of two or more contiguous PW segments that behave and function as a single point-to-point PW. Each end of an MS-PW by definition MUST terminate on a T-PE.

- マルチセグメント疑似回線(MS-PW)。シングルポイント・ツー・ポイントPWとして動作および機能二つ以上の連続するPWセグメントの静的または動的に構成されたセット。定義によるMS-PWの各端部は、T-PEで終端しなければなりません。

- PW Segment. A single-segment or a part of a multi-segment PW, which is set up between two PE devices, T-PEs and/or S-PEs.

- PWセグメント。単一セグメントまたは2つのPEデバイス、T-PESおよび/またはS-PE間で設定されているマルチセグメントPWの一部。

- PW Switching Provider Edge (S-PE). A PE capable of switching the control and data planes of the preceding and succeeding PW segments in an MS-PW. The S-PE terminates the PSN tunnels transporting the preceding and succeeding segments of the MS-PW. It is therefore a PW switching point for an MS-PW. A PW switching point is never the S-PE and the T-PE for the same MS-PW. A PW switching point runs necessary protocols to set up and manage PW segments with other PW switching points and terminating PEs.

- PWスイッチングプロバイダエッジ(S-PE)。 MS-PWに前後PWセグメントの制御およびデータプレーンを切り替えることができるPE。 S-PEは、MS-PWの先行及び後続のセグメントを輸送するPSNトンネルを終了します。したがって、MS-PWのためのPW切り替えポイントです。 PW切り替えポイントは、同一のMS-PW用のS-PE及びT-PEことはありません。 PW切り替えポイントを設定し、他のPWスイッチング点と終了のPEとPWセグメントを管理するために必要なプロトコルを実行します。

2.1. Specification of Requirements
2.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 [RFC2119].

この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。

3. Use Cases

PWE3 defines the signaling and encapsulation techniques for establishing SS-PWs between a pair of terminating PEs (T-PEs), and in the vast majority of cases, this will be sufficient. MS-PWs may be useful in the following situations:

PWE3は終了PES(T-PES)の対の間にSS-のPWを確立するためのシグナリングおよびカプセル化技術を定義し、ほとんどの場合において、これは十分であろう。 MS-PWSが以下の状況で有用である可能性があります。

-i. Inter-Provider PWs: An Inter-Provider PW is a PW that extends from a T-PE in one provider domain to a T-PE in another provider domain.


-ii. It may not be possible, desirable, or feasible to establish a direct PW control channel between the T-PEs, residing in different provider networks, to set up and maintain PWs. At a minimum, a direct PW control channel establishment (e.g., targeted LDP session) requires knowledge of and reachability to the remote T-PE IP address. The local T-PE may not have access to this information due to operational or security constraints. Moreover, an SS-PW would require the existence of a PSN tunnel between the local T-PE and the remote T-PE. It may not be feasible or desirable to extend single, contiguous PSN tunnels between T-PEs in one domain and T-PEs in another domain for security and/or scalability reasons or because the two domains may be using different PSN technologies.

-II。セットアップおよびPWを維持するために、異なるプロバイダネットワーク内に存在する、T-PE間直接PW制御チャネルを確立するために、可能望ましい、または可能でないかもしれません。最低でも、直接PW制御チャネル確立(例えば、ターゲットLDPセッション)は、リモートT-PE IPアドレスの知識および到達可能性を必要とします。ローカルT-PEが原因運用やセキュリティ制約のため、この情報へのアクセスを持っていないかもしれません。また、SS-PWは、ローカルT-PEとリモートT-PE間のPSNトンネルの存在を必要とするであろう。これは、セキュリティ及び/又は拡張性の理由のために、または2つのドメインが異なるPSN技術を使用することができるので、別のドメインで実行可能、または1つのドメイン内のT-PE間で単一の連続PSNトンネルを延長することが望ましいとT-PESでなくてもよいです。

-iii. MS-PW setup, maintenance, and forwarding procedures must satisfy requirements placed by the constraints of a multi-provider environment. An example is the inter-AS L2VPN scenario where the T-PEs reside in different provider networks (ASs) and it is the current practice to MD5-key all control traffic exchanged between two networks. An MS-PW allows the providers to confine MD5 key administration for the LDP session to just the PW switching points connecting the two domains.

-III。 MS-PWのセットアップ、メンテナンス、および転送手順は、マルチプロバイダ環境の制約によって配置要件を満たす必要があります。例では、T-PEが異なるプロバイダネットワーク(のAS)に存在する間AS L2VPNシナリオであり、それは全ての制御トラフィックは、2つのネットワーク間で交換MD5キーに現在の慣行です。 MS-PWは、プロバイダは、2つのドメインを連結するだけPW切り替えポイントにLDPセッションのためにMD5鍵管理を閉じ込めることを可能にします。

-iv. PSN Interworking: PWE3 signaling protocols and PSN types may differ in different provider networks. The terminating PEs may be connected to networks employing different PW signaling and/or PSN protocols. In this case, it is not possible to use an SS-PW. An MS-PW with the appropriate interworking performed at the PW switching points can enable PW connectivity between the terminating PEs in this scenario.

-iv。 PSNのインターワーキング:PWE3プロトコルとPSNタイプのシグナリングは、異なるプロバイダのネットワークが異なっていてもよいです。終端PEは異なるPWシグナリングおよび/またはPSNプロトコルを用いるネットワークに接続されてもよいです。このような場合には、SS-PWを使用することはできません。 PW切り替えポイントで行う適切なインターワーキングを持つMS-PWは、このシナリオで終端PE間PWの接続を可能にすることができます。

-v. Traffic Engineered PSN Tunnels and bandwidth-managed PWs: There is a requirement to deploy PWs edge to edge in large service provider networks. Such networks typically encompass hundreds or thousands of aggregation devices at the edge, each of which would be a PE. Furthermore, there is a requirement that these PWs have explicit bandwidth guarantees. To satisfy these requirements, the PWs will be tunneled over PSN TE-tunnels with bandwidth constraints. A single-segment pseudowire architecture would require that a full mesh of PSN TE-tunnels be provisioned to allow PWs to be established between all PEs. Inter-provider PWs riding traffic engineered tunnels further add to the number of tunnels that would have to be supported by the PEs and the core network as the total number of PEs increases.

-v。交通エンジニアPSNトンネルと帯域幅管理のPW:大規模サービスプロバイダーネットワークのエッジするPWのエッジを展開する必要があります。そのようなネットワークは、典型的には、PEであろうその各々の端部に集約デバイスの数百または数千を包含する。さらに、これらのPWSは、明示的な帯域保証を持っている必要はあり。これらの要件を満たすために、PWSが帯域幅の制約とPSN TE-トンネルを介してトンネルされます。単一セグメント疑似回線アーキテクチャは、PSN-TEトンネルの完全なメッシュはPWSはすべてのPEとの間で確立されることを可能にするためにプロビジョニングすることを必要とするであろう。トラヒックエンジニアリングトンネルに乗っ間プロバイダPWSがさらにPEとPEの増加の合計数として、コアネットワークによってサポートされなければならないトンネルの数に加えます。

          In this environment, there is a requirement either to support
          a sparse mesh of PSN TE-tunnels and PW signaling adjacencies,
          or to partition the network into a number of smaller PWE3
          domains.  In either case, a PW would have to pass through more
          than one PSN tunnel hop along its path.  An objective is to
          reduce the number of tunnels that must be supported, and thus
          the complexity and scalability problem that may arise.

-vi. Pseudowires in access/metro networks: Service providers wish to extend PW technology to access and metro networks in order to reduce maintenance complexity and operational costs. Today's access and metro networks are either legacy (Time Division Multiplexed (TDM), Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH), or Frame Relay/Asynchronous Transfer Mode (ATM)), Ethernet, or IP based.

-vi。アクセス/メトロネットワークでの疑似回線:サービスプロバイダは、メンテナンスの複雑さと運用コストを削減するためにアクセスし、メトロネットワークにPW技術を拡張したいです。今日のアクセスとメトロネットワークベースのいずれかのレガシー(時分割多重(TDM)、同期光ネットワーク/同期デジタル階層(SONET / SDH)、またはフレームリレー/非同期転送モード(ATM))、イーサネット、またはIPです。

          Due to these architectures, circuits (e.g., Ethernet Virtual
          Circuits (EVCs), ATM VCs, TDM circuits) in the access/metro
          are traditionally handled as attachment circuits, in their
          native format, to the edge of the IP-MPLS network where the PW
          starts.  This combination requires multiple separate access
          networks and complicates end-to-end control, provisioning, and
          maintenance.  In addition, when a TDM or SONET/SDH access
          network is replaced with a packet-based infrastructure,
          expenses may be lowered due to moving statistical multiplexing
          closer to the end-user and converging multiple services onto a
          single access network.

Access networks have a number of properties that impact the application of PWs. For example, there exist access mechanisms where the PSN is not of an IETF specified type, but uses mechanisms compatible with those of PWE3 at the PW layer.


Here, use case (iv) may apply. In addition, many networks consist of hundreds or thousands of access devices. There is therefore a desire to support a sparse mesh of PW signaling adjacencies and PSN tunnels. Use case (v) may therefore apply. Finally, access networks also tend to differ from core networks in that the access PW setup and maintenance mechanism may only be a subset of that used in the core.

ここで、(IV)適用される場合がありますケースを使用しています。また、多くのネットワークは、アクセスデバイスの数百または数千から構成されています。 PWシグナリング隣接関係とPSNトンネルのまばらなメッシュをサポートしたいとされています。ケースを使用してください(v)のため、適用される場合があります。最後に、アクセスネットワークは、アクセスPWセットアップ及びメンテナンス機構のみをコアに使用されるもののサブセットであってもよいという点で、コアネットワークと異なる傾向があります。

Using the MS-PWs, access and metro network elements need only maintain PW signaling adjacencies with the PEs to which they directly connect. They do not need PW signaling adjacencies with every other access and metro network device. PEs in the PSN backbone, in turn, maintain PW signaling adjacencies among each other. In addition, a PSN tunnel is set up between an access element and the PE to which it connects. Another PSN tunnel needs to be established between every PE pair in the PSN backbone. An MS-PW may be set up from one access network element to another access element with three segments: (1) access-element - PSN-PE, (2) PSN-PE to PSN-PE, and (3) PSN-PE to access element. In this MS-PW setup, access elements are T-PEs while PSN-PEs are S-PEs. It should be noted that the PSN backbone can be also segmented into PWE3 domains resulting in more segments per PW.

MS-PWをを使用して、アクセスとメトロネットワーク要素は、彼らが直接接続するためのPEとPWシグナリング隣接関係を維持するだけで済みます。彼らは、他のすべてのアクセスとメトロネットワークデバイスとPWシグナリング隣接関係を必要としません。 PSNのバックボーン内のPEは、順番に、互いの間でPWシグナリング隣接関係を維持します。また、PSNトンネルは、アクセス要素と、それが接続するPEとの間に設定されています。別のPSNトンネルはPSNバックボーン内のすべてのPEのペア間で確立される必要があります。 MS-PWは三つのセグメントと他のアクセス構成要素に一つのアクセスネットワーク要素から設定することができる:(1)アクセス要素 - (2)PSN-PEは、PSN-PEに、PSN-PE、及び(3)PSN-PE要素にアクセスします。 PSN-PEがS-PESであるが、このMS-PWセットアップで、アクセス要素は、T-PESです。 PSN骨格はまた、PWあたり複数のセグメントをもたらすPWE3ドメインに分割することができることに留意すべきです。

3.1. Multi-Segment Pseudowire Setup Mechanisms
3.1. マルチセグメント擬似回線のセットアップメカニズム

This requirements document assumes that the above use cases are realized using one or more of the following mechanisms:


-i. Static Configuration: The switching points (S-PEs), in addition to the T-PEs, are manually provisioned for each segment.


-ii. Pre-Determined Route: The PW is established along an administratively determined route using an end-to-end signaling protocol with automated stitching at the S-PEs.


-iii. Signaled Dynamic Route: The PW is established along a dynamically determined route using an end-to-end signaling protocol with automated stitching at the S-PEs. The route is selected with the aid of one or more dynamic routing protocols.


Note that we define the PW route to be the set of S-PEs through which an MS-PW will pass between a given pair of T-PEs. PSN tunnels along that route can be explicitly specified or locally selected at the S-PEs and T-PEs. The routing of the PSN tunnels themselves is outside the scope of the requirements specified in this document.

我々はMS-PWは、T-PEの所与の対の間に通過する、それを通してS-PEの設定するPWの経路を定義することに留意されたいです。そのルートに沿ったPSNトンネルが明示的に指定または局所S-PEとT-PESで選択することができます。 PSNのルーティング自体は、この文書で指定された要件の範囲外であるトンネル。

4. Multi-Segment Pseudowire Requirements

The following sections detail the requirements that the above use cases put on the MS-PW setup mechanisms.


4.1. All Mechanisms
4.1. すべてのメカニズム

The following generic requirements apply to the three MS-PW setup mechanisms defined in the previous section.


4.1.1. Architecture
4.1.1. 建築
      -i. If MS-PWs are tunneled across a PSN that only supports SS-PWs,
          then only the requirements of [RFC3916] apply to that PSN.
          The fact that the overlay is carrying MS-PWs MUST be
          transparent to the routers in the PSN.

-ii. The PWs MUST remain transparent to the P-routers. A P-router is not an S-PE or an T-PE from the MS-PW architecture viewpoint. P-routers provide transparent PSN transport for PWs and MUST not have any knowledge of the PWs traversing them.

-II。 PWSがP-ルータに透明のままでなければなりません。 Pルータは、MS-PWのアーキテクチャの観点から、S-PEまたはT-PEではありません。 P-ルータはPWのための透明PSN輸送を提供し、それらを横断PWを任意の知識を持ってはいけません。

-iii. The MS-PWs MUST use the same encapsulation modes specified for SS-PWs.

-III。 MS-PWSがSS-PWのために指定したのと同じカプセル化モードを使用しなければなりません。

-iv. The MS-PWs MUST be composed of SS-PWs.

-iv。 MS-PWSがSS-のPWで構成されなければなりません。

-v. An MS-PW MUST be able to pass across PSNs of all technologies supported by PWE3 for SS-PWs. When crossing from one PSN technology to another, an S-PE must provide the necessary PSN interworking functions in that case.

-v。 MS-PWのSS-PWのためのPWE3によってサポートされるすべての技術のPSNを通過できなければなりません。別のPSN技術から横断するとき、S-PEは、その場合に必要なPSNのインターワーキング機能を提供しなければなりません。

-vi. Both directions of a PW segment MUST terminate on the same S-PE/T-PE.

-vi。 PWセグメントの両方の方向は、同じS-PE / T-PEで終端しなければなりません。

-vii. S-PEs MAY only support switching PWs of the same PW type. In this case, the PW type is transparent to the S-PE in the forwarding plane, except for functions needed to provide for interworking between different PSN technologies.

-VII。 S-PEは、同じPWタイプのスイッチングPWををサポートするかもしれません。この場合、PWタイプが異なるPSN技術間のインターワーキングを提供するために必要な機能を除いて、転送プレーン内のS-PEへトランスペアレントです。

-viii. Solutions MAY provide a way to prioritize the setup and maintenance process among PWs.


4.1.2. Resiliency
4.1.2. 回復力

Mechanisms to protect an MS-PW when an element on the existing path of an MS-PW fails MUST be provided. These mechanisms will depend on the MS-PW setup. The following are the generic resiliency requirements that apply to all MS-PW setup mechanisms:


-i. Configuration and establishment of a backup PW to a primary PW SHOULD be supported. Mechanisms to perform a switchover from a primary PW to a backup PW upon failure detection SHOULD be provided.


-ii. The ability to configure an end-to-end backup PW path for a primary PW path SHOULD be supported. The primary and backup paths may be statically configured, statically specified for signaling, or dynamically selected via dynamic routing depending on the MS-PW establishment mechanism. Backup and primary paths should have the ability to traverse separate S-PEs. The backup path MAY be signaled at configuration time or after failure.


-iii. The ability to configure a primary PW and a backup PW with a different T-PE from the primary SHOULD be supported.


-iv. Automatic Mechanisms to perform a fast switchover from a primary PW to a backup PW upon failure detection SHOULD be provided.


-v. A mechanism to automatically revert to a primary PW from a backup PW MAY be provided. When provided, it MUST be configurable.


4.1.3. Quality of Service
4.1.3. サービスの質

Pseudowires are intended to support emulated services (e.g., TDM and ATM) that may have strict per-connection quality-of-service (QoS) requirements. This may include either absolute or relative guarantees on packet loss, delay, and jitter. These guarantees are, in part, delivered by reserving sufficient network resources (e.g., bandwidth), and by providing appropriate per-packet treatment (e.g., scheduling priority and drop precedence) throughout the network.


For SS-PWs, a traffic engineered PSN tunnel (i.e., MPLS-TE) may be used to ensure that sufficient resources are reserved in the P-routers to provide QoS to PWs on the tunnel. In this case, T-PEs MUST have the ability to automatically request the PSN tunnel resources in the direction of traffic (e.g., admission control of PWs onto the PSN tunnel and accounting for reserved bandwidth and available bandwidth on the tunnel). In cases where the tunnel supports multiple classes of service (CoS) (e.g., E-LSP), bandwidth management is required per CoS.


For MS-PWs, each S-PE maps a PW segment to a PSN tunnel. Solutions MUST enable S-PEs and T-PEs to automatically bind a PW segment to a PSN tunnel based on CoS and bandwidth requirements when these attributes are specified for a PW. Solutions SHOULD also provide the capability of binding a PW segment to a tunnel as a matter of policy configuration. S-PEs and T-PEs must be capable of automatically requesting PSN tunnel resources per CoS.

MS-のPWのために、各S-PEは、PSNトンネルにPWセグメントをマッピングします。ソリューションは、自動的にこれらの属性がPWに指定されたCoSおよび帯域幅要件に基づいて、PSNトンネルにPWセグメントを結合するためにS-PEとT-PESを有効にする必要があります。溶液はまた、ポリシー設定の問題としてトンネルにPWセグメントを結合する能力を提供すべきです。 S-PEとT-PEは自動的のCoSごとPSNトンネルリソースを要求することができなければなりません。

S-PEs and T-PEs MUST be able to associate a CoS marking (e.g., EXP field value for MPLS PWs) with PW PDUs. CoS marking in the PW PDUs affects packet treatment. The CoS marking depends on the PSN technology. Thus, solutions must enable the configuration of necessary mapping for CoS marking when the MS-PW crosses from one PSN technology to another. Similarly, different administrative domains may use different CoS values to imply the same CoS treatment. Solutions MUST provide the ability to define CoS marking maps on S-PEs at administrative domain boundaries to translate from one CoS value to another as a PW PDU crosses from one domain to the next.

S-PEとT-PEはCoSマーキングを関連付けることができなければなりません(例えば、MPLSのPW用のEXPフィールド値)PW PDUを有します。 PWのPDUにCoSマーキングは、パケット処理に影響を与えます。 CoSマーキングは、PSNの技術に依存します。したがって、ソリューションは、MS-PWは、別のPSN技術から横切るときCoSマーキングに必要なマッピングの設定を有効にする必要があります。同様に、異なる管理ドメインは、同一のCoS処理を意味する異なるCoS値を使用してもよいです。ソリューションは、PW PDUは、次のドメインに横切るよう別のCoS値から変換するために管理ドメインの境界でS-PESの地図をCoSマーキングを定義する機能を提供しなければなりません。

[RFC3985] requires PWs to respond to path congestion by reducing their transmission rate. Alternatively, RFC 3985 permits PWs that do not have a congestion control mechanism to transmit using explicitly reserved capacity along a provisioned path. Because MS-PWs are a type of PW, this requirement extends to them as well. RFC 3985 applied to MS-PWs consequently requires that MS-PWs employ a congestion control mechanism that is effective across an MS path, or requires an explicit provisioning action that reserves sufficient capacity in all domains along the MS path before the MS-PW begins transmission. S-PEs are therefore REQUIRED to reject attempts to establish MS-PW segments for PW types that either do not utilize an appropriate congestion control scheme or when resources that are sufficient to support the transmission rate of the PW cannot be reserved along the path.

[RFC3985]はその伝送速度を低減することにより、パスの混雑に対応するためのPWが必要です。あるいは、RFC 3985は、プロビジョニングパスに沿って明示的に予約容量を使用して送信するための輻輳制御機構を持っていないのPWを可能にします。 MS-PWSはPWのタイプであるので、この要件は、同様に、それらに延びています。 RFC 3985は、結果としてMS-PWSはMS路を挟んで有効である、またはMS-PWは、送信を開始する前に、MSの経路に沿った全てのドメインに十分な容量を確保し、明示的なプロビジョニングアクションを必要とする輻輳制御機構を採用することを必要とするMS-のPWに適用しました。 S-PEは、従ってPWの伝送レートをサポートするのに十分なリソースが経路に沿って予約することができない場合のいずれかが適切な輻輳制御方式を利用するか、ないPWタイプにMS-PWセグメントを確立する試みを拒否するために必要とされます。

4.1.4. Congestion Control
4.1.4. 輻輳制御

[RFC3985] requires all PWs to respond to congestion, in order to conform to [RFC2914]. In the absence of a well-defined congestion control mechanism, [RFC3985] permits PWs to be carried across paths that have been provisioned such that the traffic caused by PWs has no harmful effect on concurrent traffic that shares the path, even under congestion. These requirements extend to the MS-PWs defined in this document.


Path provisioning is frequently performed through QoS reservation protocols or network management protocols. In the case of SS-PWs, which remain within a single administrative domain, a number of existing protocols can provide this provisioning functionality. MS-PWs, however, may transmit across network domains that are under the control of multiple entities. QoS provisioning across such paths is inherently more difficult, due to the required inter-domain interactions. It is important to note that these difficulties do not invalidate the requirement to provision path capacity for MS-PW use. Each domain MUST individually implement a method to control congestion. This can be by QoS reservation, or other congestion control method. MS-PWs MUST NOT transmit across unprovisioned, best effort, paths in the absence of other congestion control schemes, as required by [RFC3985].

パスのプロビジョニングは、頻繁にQoS予約プロトコルやネットワーク管理プロトコルを介して行われます。単一の管理ドメイン内に留まるSS-のPWの場合には、既存のプロトコルの数は、このプロビジョニング機能を提供することができます。 MS-PWSが、しかし、複数のエンティティの制御下にあるネットワークドメイン間で送信することができます。そのような経路を横切ってプロビジョニングQoSは、本質的に必要なドメイン間相互作用に起因する、より困難です。これらの問題は、MS-PW用のプロビジョニングパス能力への要求を無効にしていないことに注意することが重要です。各ドメインは、個別に輻輳を制御する方法を実装しなければなりません。これは、QoS予約、または他の輻輳制御方法によることができます。 [RFC3985]によって必要とされるMS-PWSが、他の輻輳制御方式の非存在下で、プロビジョニングされていない、ベストエフォート横切るパスを送信してはいけません。

Solutions MUST enable S-PEs and T-PEs on the path of an MS-PW to notify other S-PEs and T-PEs on that path of congestion, when it occurs. Congestion may be indicated by queue length, packet loss rate, or bandwidth measurement (among others) crossing a respective threshold. The action taken by a T-PE that receives a notification of congestion along the path of one of its PWs could be to re-route the MS-PW to an alternative path, including an alternative T-PE if available. If a PE, or an S-PE has knowledge that a particular link or tunnel is experiencing congestion, it MUST not set up any new MS-PW that utilize that link or tunnel. Some PW types, such as TDM PWs, are more sensitive to congestion than others. The reaction to a congestion notification MAY vary per PW type.

解決策は、それが発生した場合、輻輳のそのパス上の他のS-PEとT-PESを通知するMS-PWの経路上にS-PEとT-PESを有効にする必要があります。輻輳がそれぞれの閾値を横切る(とりわけ)キュー長、パケット損失率、または帯域幅測定によって示されてもよいです。代替T-PE可能な場合を含む代替経路にMS-PW、ルートを再することができ、そののPWの一つの経路に沿った輻輳通知を受信T-PEによるアクション。 PEまたはS-PEは、特定のリンク又はトンネルが輻輳を経験しているという知識を持っている場合、そのリンクまたはトンネルを利用する任意の新しいMS-PWを設定してはいけません。このようTDM PWをなどの一部のPWタイプには、他よりも混雑に敏感です。輻輳通知への反応はPWタイプごとに異なる場合があります。

4.1.5. Additional Generic Requirements for MS-PW Setup Mechanisms
4.1.5. MS-PWセットアップメカニズムに関するその他の一般的な要件

The MS-PW setup mechanisms MUST accommodate the service provider's practices, especially in relation to security, confidentiality of SP information, and traffic engineering. Security and confidentiality are especially important when the MS-PWs are set up across autonomous systems in different administrative domains. The following are generic requirements that apply to the three MS-PW setup mechanisms defined earlier:

MS-PWセットアップメカニズムは、特にセキュリティ、SP情報の機密性、およびトラフィックエンジニアリングに関連して、サービスプロバイダの慣行に対応しなければなりません。 MS-PWのは、異なる管理ドメインに自律システム全体に設定されている場合、セキュリティと機密性が特に重要です。先に定義された3 MS-PWセットアップメカニズムに適用される一般的な要件は次のとおりです。

-i. The ability to statically select S-PEs and PSN tunnels on a PW path MUST be provided. Static selection of S-PEs is by definition a requirement for the static configuration and signaled/static route setup mechanisms. This requirement satisfies the need for forcing an MS-PW to traverse specific S-PEs to enforce service provider security and administrative policies.

-私。静的PW経路上S-PEとPSNトンネルを選択する能力を提供しなければなりません。 S-PEの静的選択は定義により静的構成およびシグナリング/スタティック経路設定メカニズムのための要件です。この要件は、サービスプロバイダのセキュリティおよび管理ポリシーを施行するために、特定のS-PESを横断するMS-PWを強制する必要性を満たします。

-ii. Solutions SHOULD minimize the amount of configuration needed to set up an MS-PW.


-iii. Solutions should support different PW setup mechanisms on the same T-PE, S-PE, and PSN network.


-iv. Solutions MUST allow T-PEs to simultaneously support use of SS-PW signaling mechanisms as specified in [RFC4447], as well as MS-PW signaling mechanisms.


-v. Solutions MUST ensure that an MS-PW will be set up when a path that satisfies the PW constraints for bandwidth, CoS, and other possible attributes does exist in the network.


-vi. Solutions must clearly define the setup procedures for each mechanism so that an MS-PW setup on T-PEs can be interpreted as successful only when all PW segments are successfully set up.

-vi。 T-PES上のMS-PWのセットアップがすべてPWセグメントが正常に設定されている場合にのみ成功したと解釈することができるように、溶液は、明らかに、各機構のセットアップ手順を定義する必要があります。

-vii. Admission control to the PSN tunnel needs to be performed against available resources, when applicable. This process MUST be performed at each PW segment comprising the MS-PW. PW admission control into a PSN tunnel MUST be configurable.

-VII。 PSNトンネルへのアドミッション制御は、適用可能な場合、利用可能なリソースに対して実行される必要があります。このプロセスは、MS-PWを構成する各PWセグメントで行われなければなりません。 PSNトンネルへのPWアドミッション制御は設定していなければなりません。

-viii. In case the PSN tunnel lacks the resources necessary to accommodate the new PW, an attempt to signal a new PSN tunnel, or increase the capacity of the existing PSN tunnel MAY be made. If the expanded PSN tunnel fails to set up, the PW MUST fail to set up.


-ix. The setup mechanisms must allow the setup of a PW segment between two directly connected S-PEs without the existence of a PSN tunnel. This requirement allows a PW segment to be set up between two (Autonomous System Border Routers (ASBRs) when the MS-PW crosses AS boundaries without the need for configuring and setting up a PSN tunnel. In this case, admission control must be done, when enabled, on the link between the S-PEs.

-ix。セットアップメカニズムは、PSNトンネルの存在なしに直接接続された2つのS-PE間のPWセグメントの設定を可能にしなければなりません。この要件は、MS-PWを構成し、PSNトンネルを設定する必要なし境界と交差する場合PWセグメント)は、2つ(自律システム境界ルータ(ASBR間に設定されることを可能にする。この場合、アドミッション制御が行われなければなりません、 S-PE間のリンク上で、有効な場合。

4.1.6. Routing
4.1.6. ルーティング

An objective of MS-PWs is to provide support for the following connectivity:


-i. MS-PWs MUST be able to traverse multiple service provider administrative domains.

-私。 MS-PWSが、複数のサービス・プロバイダの管理ドメインを横切ることができなければなりません。

-ii. MS-PWs MUST be able to traverse multiple autonomous systems within the same administrative domain.

-II。 MS-PWSが同一の管理ドメイン内の複数の自律システムを通過できなければなりません。

-iii. MS-PWs MUST be able to traverse multiple autonomous systems belonging to different administrative domains.

-III。 MS-PWSが異なる管理ドメインに属する複数の自律システムを通過できなければなりません。

-iv. MS-PWs MUST be able to support any hybrid combination of the aforementioned connectivity scenarios, including both PW transit and termination in a domain.

-iv。 MS-PWSがドメインにおけるPWトランジットおよび終了の両方を含む前述の接続シナリオの任意のハイブリッドの組み合わせをサポートすることができなければなりません。

4.2. Statically Configured MS-PWs
4.2. 静的に設定されたMS-PWを

When the MS-PW segments are statically configured, the following requirements apply in addition to the generic requirements previously defined.


4.2.1. Architecture
4.2.1. 建築

There are no additional requirements on the architecture.


4.2.2. MPLS-PWs
4.2.2. BLS-方法

Solutions should allow for the static configuration of MPLS labels for MPLS-PW segments and the cross-connection of these labels to preceding and succeeding segments. This is especially useful when an MS-PW crosses provider boundaries and two providers do not want to run any PW signaling protocol between them. A T-PE or S-PE that allows the configuration of static labels for MS-PW segments should also simultaneously allow for dynamic label assignments for other MS-PW segments. It should be noted that when two interconnected S-PEs do not have signaling peering for the purpose of setting up MS-PW segments, they should have in-band PW Operations and Maintenance (OAM) capabilities that relay PW or attachment circuit defect notifications between the adjacent S-PEs.

ソリューションは、MPLS-PWセグメントのMPLSラベルの静的な構成とセグメントを前後にこれらのラベルの相互接続を可能にすべきです。 MS-PWは、プロバイダの境界を横断し、2つのプロバイダは、それらの間の任意のPWシグナリングプロトコルを実行したくない場合に特に便利です。 MS-PWセグメントの静的ラベルの設定も同時に他のMS-PWセグメントのダイナミックラベルの割り当てを可能にすべきであることができ、T-PEまたはS-PE。 2つの相互接続されたS-PEは、MS-PWセグメントを設定するためにピアリングシグナリングを持っていない場合、それらは間PW又はアタッチメント回路欠陥通知を中継帯域内PWオペレーションおよびメンテナンス(OAM)機能を有していなければならないことに留意すべきです隣接するS-PES。

4.2.3. Resiliency
4.2.3. 回復力

The solution should allow for the protection of a PW segment, a contiguous set of PW segments, as well as the end-to-end path. The primary and protection segments must share the same segment endpoints. Solutions should allow for having the backup paths set up prior to the failure or as a result of failure. The choice should be made by configuration. When resources are limited and cannot satisfy all PWs, the PWs with the higher setup priorities should be given preference when compared with the setup priorities of other PWs being set up or the holding priorities of existing PWs.


Solutions should strive to minimize traffic loss between T-PEs.


4.2.4. Quality of Service
4.2.4. サービスの質

The CoS and bandwidth of the MS-PW must be configurable at T-PEs and S-PEs.


4.3. Signaled PW Segments
4.3. 合図PWセグメント

When the MS-PW segments are dynamically signaled, the following requirements apply in addition to the generic requirements previously defined. The signaled MS-PW segments can be on the path of a statically configured MS-PW, signaled/statically routed MS-PW, or signaled/dynamically routed MS-PW.


There are four different mechanisms that are defined to setup SS-PWs:


-i. Static set up of the SS-PW (MPLS or L2TPv3 forwarding)

-私。 SS-PW(MPLSまたは転送のL2TPv3)の静的なセットアップ

-ii. LDP using PWid Forwarding Equivalence Class (FEC) 128

-II。 PWID転送等価クラス(FEC)128を使用してLDP

-iii. LDP using the generalized PW FEC 129

-III。一般PW FEC 129を使用してLDP

-iv. L2TPv3

-iv。 L2TPv3の

The MS-PW setup mechanism MUST be able to support PW segments signaled with any of the above protocols; however, the specification of which combinations of SS-PW signaling protocols are supported by a specific implementation is outside the scope of this document.


For the signaled/statically routed and signaled/dynamically routed MS-PW setup mechanisms, the following requirements apply in addition to the generic requirements previously defined.


4.3.1. Architecture
4.3.1. 建築

There are no additional requirements on the architecture.


4.3.2. Resiliency
4.3.2. 回復力

Solutions should allow for the signaling of a protection path for a PW segment, sequence of segments, or end-to-end path. The protection and primary paths for the protected segment(s) share the same respective segments endpoints. When admission control is enabled, systems must be careful not to double account for bandwidth allocation at merged points (e.g., tunnels). Solutions should allow for having the backup paths set up prior to the failure or as a result of failure. The choice should be made by configuration at the endpoints of the protected path. When resources are limited and cannot satisfy all PWs, the PWs with the higher setup priorities should be given preference when compared with the setup priorities of other PWs being set up or the holding priorities of existing PWs. Procedures must allow for the primary and backup paths to be diverse.


4.3.3. Quality of Service
4.3.3. サービスの質

When the T-PE attempts to signal an MS-PW, the following capability is required:


-i. Signaling must be able to identify the CoS associated with an MS-PW.


-ii. Signaling must be able to carry the traffic parameters for an MS-PW per CoS. Traffic parameters should be based on existing INTSERV definitions and must be used for admission control when admission control is enabled.


-iii. The PW signaling MUST enable separate traffic parameter values to be specified for the forward and reverse directions of the PW.

-III。 PWシグナリングが順方向に指定する別個のトラフィックパラメータ値を有効にし、PWの方向を逆にしなければなりません。

-iv. PW traffic parameter representations MUST be the same for all types of MS-PWs.

-iv。 PWトラフィックパラメータ表現は、MS-PWのすべてのタイプで同じでなければなりません。

-v. The signaling protocol must be able to accommodate a method to prioritize the PW setup and maintenance operation among PWs.


4.3.4. Routing
4.3.4. ルーティング

See the requirements for "Resiliency" above.


4.3.5. Additional Requirements on Signaled MS-PW Setup Mechanisms
4.3.5. 合図MS-PWセットアップメカニズムに関する追加要件

The following are further requirements on signaled MS-PW setup mechanisms:


-i. The signaling procedures MUST be defined such that the setup of an MS-PW is considered successful if all segments of the MS-PW are successfully set up.


-ii. The MS-PW path MUST have the ability to be dynamically set up between the T-PEs by provisioning only the T-PEs.

-II。 MS-PWの経路を動的のみT-PESをプロビジョニングすることによってT-PE間に設定される能力を持たなければなりません。

-iii. Dynamic MS-PW setup requires that a unique identifier be associated with a PW and be carried in the signaling message. That identifier must contain sufficient information to determine the path to the remote T-PE through intermediate S-PEs.


-iv. In a single-provider domain, it is natural to have the T-PE identified by one of its IP addresses. This may also apply when an MS-PW is set up across multiple domains operated by the same provider. However, some service providers have security and confidentiality policies that prevent them from advertising reachability to routers in their networks to other providers (reachability to an ASBR is an exception). Thus, procedures MUST be provided to allow dynamic set up of MS-PWs under these conditions.

-iv。単一プロバイダードメインでは、T-PEは、そのIPアドレスのいずれかによって同定されているのが自然です。 MS-PWは、同じプロバイダによって操作される複数のドメイン間に設定されている場合にも適用することができます。しかし、いくつかのサービスプロバイダは、他のプロバイダにそのネットワーク内のルータに広告到達可能性からそれらを防ぐセキュリティおよび機密保持ポリシーを持っている(ASBRへの到達可能性は例外です)。したがって、手順は、これらの条件下でMS-のPWの動的セットアップを可能にするために提供されなければなりません。

4.4. Signaled PW / Dynamic Route
4.4. PW /動的経路を合図

The following requirements apply, in addition to those in Sections 4.1 and 4.3, when both dynamic signaling and dynamic routing are used.


4.4.1. Architecture
4.4.1. 建築

There are no additional architectural requirements.


4.4.2. Resiliency
4.4.2. 回復力

The PW routing function MUST support dynamic re-routing around failure points when segments are set up using the dynamic setup method.


4.4.3. Quality of Service
4.4.3. サービスの質

There are no additional QoS requirements.


4.4.4. Routing
4.4.4. ルーティング

The following are requirements associated with dynamic route selection for an MS-PW:


-i. Routing must enable S-PEs and T-PEs to discover S-PEs on the path to a destination T-PE.


-ii. The MS-PW routing function MUST have the ability to automatically select the S-PEs along the MS-PW path. Some of the S-PEs MAY be statically selected and carried in the signaling to constrain the route selection process.

-II。 MS-PWのルーティング機能は自動的にMS-PWの経路に沿ってS-PESを選択する能力を持たなければなりません。 S-PEのいくつかは、静的に経路選択処理を制限するシグナルに選択して実施することができます。

-iii. The PW routing function MUST support re-routing around failures that occur between the statically configured segment endpoints. This may be done by choosing another PSN tunnel between the two segment endpoints or setting up an alternative tunnel.

-III。 PWルーティング機能は、静的に構成されたセグメントのエンドポイント間で発生する障害の周りに再ルーティングをサポートしなければなりません。これは、2つのセグメントのエンドポイントとの間の別のPSNトンネルを選択するか、別のトンネルを設定することによって行うことができます。

-iv. Routing protocols must be able to advertise reachability information of attachment circuit (AC) endpoints. This reachability information must be consistent with the AC identifiers carried in signaling.


5. Operations and Maintenance (OAM)

OAM mechanisms for the attachment circuits are defined in the specifications for PW emulated specific technologies (e.g., ITU-T I.610 [i610] for ATM). These mechanisms enable, among other things, defects in the network to be detected, localized, and diagnosed. They also enable communication of PW defect states on the PW attachment circuit. Note that this document uses the term OAM as Operations and Management as per ITU-T I.610.

PWは、特定の技術をエミュレートするための接続回線用のOAMメカニズムは、仕様で定義されている(例えば、ITU-T I.610 ATMのための[i610])。これらのメカニズムは、ネットワーク内の欠陥が、検出されたローカライズされた、と診断される、とりわけ、有効にしてください。彼らはまた、PWの接続回線上のPW欠陥状態の通信を可能にします。このドキュメントは、ITU-T I.610ごとに運用・管理する用語のOAMを使用することに注意してください。

The interworking of OAM mechanisms for SS-PWs between ACs and PWs is defined in [PWE3-OAM]. These enable defect states to be propagated across a PWE3 network following the failure and recovery from faults.


OAM mechanisms for MS-PWs MUST provide at least the same capabilities as those for SS-PWs. In addition, it should be possible to support both segment and end-to-end OAM mechanisms for both defect notifications and connectivity verification in order to allow defects to be localized in a multi-segment network. That is, PW OAM segments can be T-PE to T-PE, T-PE to S-PE, or S-PE to S-PE.

MS-のPW用のOAMメカニズムはSS-のPWのものと少なくとも同じ機能を提供しなければなりません。また、欠陥は、マルチセグメント・ネットワークに局在化されることを可能にするために欠陥通知および接続性検証の両方のためにセグメントおよびエンドツーエンドのOAMメカニズムの両方をサポートすることが可能であるべきです。すなわち、PW OAMセグメントがT-PE、T-PEとS-PEまたはS-PEへのS-PEへのT-PEすることが可能です。

The following requirements apply to OAM for MS-PWs:


-i. Mechanisms for PW segment failure detection and notification to other segments of an MS-PW MUST be provided.

-私。 MS-PWの他のセグメントにPWセグメントの障害検出および通知するためのメカニズムを提供しなければなりません。

-ii. MS-PW OAM SHOULD be supported end-to-end across the network.

-II。 MS-PW OAMは、エンドツーエンドのネットワークを介してサポートされてください。

-iii. Single ended monitoring SHOULD be supported for both directions of the MS-PW.


-iv. SS-PW OAM mechanisms (e.g., [RFC5085]) SHOULD be extended to support MS-PWs on both an end-to-end basis and segment basis.

-iv。 SS-PW OAMメカニズム(例えば、[RFC5085])は、エンドツーエンドの基礎とセグメント単位の両方でMS-のPWをサポートするように拡張されるべきです。

-v. All PE routers along the MS-PW MUST agree on a common PW OAM mechanism to use for the MS-PW.

-v。 MS-PWに沿ってすべてのPEルータは、MS-PWのために使用するのが一般的PW OAMメカニズムに同意しなければなりません。

-vi. At the S-PE, defects on an PSN tunnel MUST be propagated to all PWs that utilize that particular PSN tunnel.

-vi。 S-PEでは、PSNトンネル上の欠陥は、その特定のPSNトンネルを利用する全てのPWに伝播されなければなりません。

-vii. The directionality of defect notifications MUST be maintained across the S-PE.


-viii. The S-PE SHOULD be able to behave as a segment endpoint for PW OAM mechanisms.

-VIII。 S-PEはPW OAMメカニズムのセグメントエンドポイントとして動作することができるべきです。

-ix. The S-PE MUST be able to pass T-PE to T-PE PW OAM messages transparently.

-ix。 S-PEは、透過T-PE PW OAMメッセージをT-PEを通過できなければなりません。

-x. Performance OAM is required for both MS-PWs and SS-PWs to measure round-trip delay, one-way delay, jitter, and packet loss ratio.


6. Management of Multi-Segment Pseudowires

Each PWE3 approach that uses MS-PWs SHOULD provide some mechanisms for network operators to manage the emulated service. Management mechanisms for MS-PWs MUST provide at least the same capabilities as those for SS-PWs, as defined in [RFC3916].

ネットワークオペレータは、エミュレートされたサービスを管理するためのMS-のPWを使用する各PWE3アプローチは、いくつかのメカニズムを提供しなければなりません。 [RFC3916]で定義されるようにMS-のPWの管理メカニズムは、SS-のPWのものと少なくとも同じ機能を提供しなければなりません。

It SHOULD also be possible to manage the additional attributes for MS-PWs. Since the operator that initiates the establishment of an MS-PW may reside in a different PSN domain from the S-PEs and one of the T-PEs along the path of the MS-PW, mechanisms for the remote management of the MS-PW SHOULD be provided.

また、MS-PWのための追加の属性を管理することが可能です。 MS-PWの確立を開始するオペレータは、MS-PWの経路に沿ってS-PEとT-PEのいずれかから異なるPSN領域でMS-PWのリモート管理のためのメカニズムが存在することができるので提供されるべきです。

The following additional requirements apply:


6.1. MIB Requirements
6.1. MIBの要件
      -i. MIB Tables MUST be designed to facilitate configuration and
          provisioning of the MS-PW at the S-PEs and T-PEs.

-ii. The MIB(s) MUST facilitate inter-PSN configuration and monitoring of the ACs.

-II。 MIB(複数可)間PSN構成およびACSの監視を容易にしなければなりません。

6.2. Management Interface Requirements
6.2. 管理インターフェイスの要件
      -i. Mechanisms MUST be provided to enable remote management of an
          MS-PW at an S-PE or T-PE.  It SHOULD be possible for these
          mechanisms to operate across PSN domains.  An example of a
          commonly available mechanism is the command line interface
          (CLI) over a telnet session.

-ii. For security or other reasons, it SHOULD be possible to disable the remote management of an MS-PW.


7. Security Considerations

This document specifies the requirements both for MS-PWs that can be set up across domain boundaries administered by one or more service providers (inter-provider MS-PWs), and for MS-PWs that are only set up across one provider (intra-provider MS-PWs).


7.1. Inter-Provider MS-PWs
7.1. インタープロバイダNS-方法

The security requirements for MS-PW setup across domains administered by one service provider are the same as those described under security considerations in [RFC4447] and [RFC3916]. These requirements also apply to inter-provider MS-PWs.


In addition, [RFC4111] identifies user and provider requirements for L2 VPNs that apply to MS-PWs described in this document. In this section, the focus is on the additional security requirements for inter-provider operation of MS-PWs in both the control plane and data plane, and some of these requirements may overlap with those in [RFC4111].

また、[RFC4111]は、この文書に記載MS-のPWに適用L2 VPNのユーザとプロバイダの要件を識別する。このセクションでは、焦点は、制御プレーンとデータプレーンの両方でMS-のPWの間プロバイダ操作のための追加のセキュリティ要件にあり、これらの要件の一部は、[RFC4111]のものと重複してもよいです。

7.1.1. Data-Plane Security Requirements
7.1.1. データプレーンのセキュリティ要件

By security in the "data plane", we mean protection against the following possibilities:


-i. Packets from within an MS-PW traveling to a PE or an AC to which the PW is not intended to be connected, other than in a manner consistent with the policies of the MS-PW.

-私。 MS-PWのポリシーと一致した方法以外のPWが接続されるものではないれたPEまたはACへの移動MS-PW内からパケット。

-ii. Packets from outside an MS-PW entering the MS-PW, other than in a manner consistent with the policies of the MS-PW.

-II。 MS-PWは、MS-PWのポリシーと一致した方法以外のMS-PWを入力する外部からのパケット。

MS-PWs that cross service provider (SP) domain boundaries may connect one T-PE in a SP domain to a T-PE in another provider domain. They may also transit other provider domains even if the two T-PEs are under the control of one SP. Under these scenarios, there is a chance that one or more PDUs could be falsely inserted into an MS-PW at any of the originating, terminating, or transit domains. Such false injection can be the result of a malicious attack or fault in the S-PE. Solutions MAY provide mechanisms for ensuring the end-to-end authenticity of MS-PW PDUs.

サービスプロバイダ(SP)のドメイン境界を越えるMS-PWSが別のプロバイダのドメイン内のT-PEとSPドメインの一方T-PEを接続することができます。彼らは、2つのT-PEが1つのSPの制御下にある場合でも、また、トランジット他のプロバイダはドメインもよいです。これらのシナリオの下で、一つ以上のPDUが誤って発信、着信、またはトランジットドメインのいずれかでMS-PWに挿入することができる可能性があります。このような偽の注入は、S-PEでの悪意のある攻撃や障害の結果であり得ます。ソリューションは、MS-PW PDUのエンドツーエンドの信頼性を確保するためのメカニズムを提供してもよいです。

The data plane security requirements at a service provider border for MS-PWs are similar to those for inter-provider BGP/MPLS IP Virtual Private Networks [RFC4364]. In particular, an S-PE or T-PE SHOULD discard a packet received from a particular neighbor over the service provider border unless one of the following two conditions holds:

MS-PWのためのサービスプロバイダの境界にデータプレーンのセキュリティ要件は、[RFC4364]インタープロバイダBGP / MPLS IP仮想プライベートネットワークのためのものと同様です。次の2つの条件のいずれかが成立しない限り、具体的には、S-PEまたはT-PEは、サービスプロバイダの境界上の特定のネイバーから受信したパケットを破棄すべきです。

-i. Any MPLS label processed at the receiving S-PE or T-PE, such the PSN tunnel label or the PW label has a label value that the receiving system has distributed to that neighbor; or


-ii. Any MPLS label processed at the receiving S-PE or T-PE, such as the PSN tunnel label or the PW label has a label value that the receiving S-PE or T-PE has previously distributed to the peer S-PE or T-PE beyond that neighbor (i.e., when it is known that the path from the system to which the label was distributed to the receiving system is via that neighbor).


One of the domains crossed by an MS-PW may decide to selectively mirror the PDUs of an MS-PW for eavesdropping purposes. It may also decide to selectively hijack the PDUs of an MS-PW by directing the PDUs away from their destination. In either case, the privacy of an MS-PW can be violated.


Some types of PWs make assumptions about the security of the underlying PSN. The minimal security provided by an MPLS PSN might not be sufficient to meet the security requirements expected by the applications using the MS-PW. This document does not place any requirements on protecting the privacy of an MS-PW PDU via encryption. However, encryption may be required at a higher layer in the protocol stack, based on the application or network requirements.

PWの一部のタイプは、基本的なPSNのセキュリティについての仮定を行います。 MPLS PSNが提供する最小限のセキュリティは、MS-PWを使用するアプリケーションが期待するセキュリティ要件を満たすのに十分ではないかもしれません。この文書は、暗号化を経由してMS-PW PDUのプライバシーを保護する上で任意の要件を置いていません。しかし、暗号化は、アプリケーションまたはネットワークの要件に基づいて、プロトコルスタックの上位層に必要とされ得ます。

The data plane of an S-PE at a domain boundary MUST be able to police incoming MS-PW traffic to the MS-PW traffic parameters or to an administratively configured profile. The option to enable/disable policing MUST be provided to the network administrator. This is to ensure that an MS-PW or a group of MS-PWs do not grab more resources than they are allocated. In addition, the data plane of an S-PE MUST be able to police OAM messages to a pre-configured traffic profile or to filter out these messages upon administrative configuration.

ドメイン境界でS-PEのデータプレーンは、MS-PWのトラフィックパラメータまたは管理構成プロファイルに入ってくるMS-PWのトラフィックをポリシングできなければなりません。 /無効ポリシングを有効にするオプションは、ネットワーク管理者に提供しなければなりません。これは、MS-PWまたはMS-PWをのグループは、それらが割り当てられているよりも多くのリソースをつかむないようにすることです。また、S-PEのデータプレーンは、予め設定されたトラフィックプロファイルに警察OAMメッセージことができなければならない、または管理構成時にこれらのメッセージをフィルタリングします。

An ingress S-PE MUST ensure that an MS-PW receives the CoS treatment configured or signaled for that MS-PW at the S-PE. Specifically, an S-PE MUST guard against packets marked in the exp bits or IP-header Differentiated Services (DS) field (depending on the PSN) for a better CoS than they should receive.


An ingress S-PE MUST be able to define per-interface or interface-group (a group may correspond to interfaces to a peer-provider) label space for MPLS-PWs. An S-PE MUST be configurable not to accept labeled packets from another provider unless the bottom label is a PW-label assigned by the S-PE on the interface on which the packet arrived.


Data plane security considerations for SS-PWs specified in [RFC3985] also apply to MS-PWs.


7.1.2. Control-Plane Security Requirements
7.1.2. コントロールプレーンのセキュリティ要件

An MS-PW connects two attachment circuits. It is important to make sure that PW connections are not arbitrarily accepted from anywhere, or else a local attachment circuit might get connected to an arbitrary remote attachment circuit. The fault in the connection can start at a remote T-PE or an S-PE.

MS-PWは、二つの接続回線を接続しています。 PWの接続が任意のどこから受け入れられないか、あるいはローカル接続回線は、任意のリモート接続回線に接続される可能性がありますことを確認することが重要です。接続に障害が遠隔T-PEまたはS-PEで開始することができます。

Where a PW segment crosses a border between one provider and another provider, the PW segment endpoints (S-PEs) SHOULD be on ASBRs interconnecting the two providers. Directly interconnecting the S-PEs using a physically secure link, and enabling signaling and routing authentication between the S-PEs, eliminates the possibility of receiving an MS-PW signaling message or packet from an untrusted peer. Other configurations are possible. For example, P routers for the PSN tunnel between the adjacent S-PEs/T-PEs may reside on the ASBRs. In which case, the S-PEs/T-PEs MUST satisfy themselves of the security and privacy of the path.

PWセグメントは1つのプロバイダと他のプロバイダとの間の境界を横切る場合、PWセグメントエンドポイント(S-PES)は、2つのプロバイダを相互接続するのASBRにする必要があり。直接、物理的にセキュアなリンクを使用して、S-PESを相互接続し、S-PE間のシグナリングおよびルーティング認証を有効にすると、信頼できないピアからMS-PWシグナリングメッセージ又はパケットを受信する可能性を排除します。他の構成も可能です。例えば、隣接するS-PE間のPSNトンネルのPルータ/ T-PEはのASBR上に存在してもよいです。その場合に、S-PES / T-PEは経路のセキュリティとプライバシーの自身を満足させなければなりません。

The configuration and maintenance protocol MUST provide a strong authentication and control protocol data protection mechanism. This option MUST be implemented, but it should be deployed according to the specific PSN environment requirements. Furthermore, authentication using a signature for each individual MS-PW setup message MUST be available, in addition to an overall control protocol session authentication and message validation.


Since S-PEs in different provider networks SHOULD reside at each end of a physically secure link, or be interconnected by a limited number of trusted PSN tunnels, each S-PE will have a trust relationship with only a limited number of S-PEs in other ASs. Thus, it is expected that current security mechanisms based on manual key management will be sufficient. If deployment situations arise that require large scale connection to S-PEs in other ASs, then a mechanism based on RFC 4107 [RFC4107] MUST be developed.

異なるプロバイダ・ネットワークにおけるS-PEが物理的に安全なリンクの各端部に存在する必要があり、または信頼PSNトンネルの限られた数によって相互接続されるので、各S-PEは、でS-PEの限られた数と信頼関係を有することになります他のAS。したがって、手動鍵管理に基づいて、現在のセキュリティメカニズムが十分であることが期待されます。配備状況は、他のお尻のS-PEへの大規模な接続を必要と発生した場合は、RFC 4107 [RFC4107]に基づくメカニズムを開発しなければなりません。

Peer authentication protects against IP address spoofing but does not prevent one peer (S-PE or T-PE) from connecting to the wrong attachment circuit. Under a single administrative authority, this may be the result of a misconfiguration. When the MS-PW crosses multiple provider domains, this may be the result of a malicious act by a service provider or a security hole in that provider network. Static manual configuration of MS-PWs at S-PEs and T-PEs provides a greater degree of security. If an identification of both ends of an MS-PW is configured and carried in the signaling message, an S-PE can verify the signaling message against the configuration. To support dynamic signaling of MS-PWs, whereby only endpoints are provisioned and S-PEs are dynamically discovered, mechanisms SHOULD be provided to configure such information on a server and to use that information during a connection attempt for validation.

ピア認証は、IPスプーフィングに対する保護が、間違った接続回線への接続から1つのピア(S-PEまたはT-PE)を妨げません。単一の管理権限下では、これは設定ミスの結果である可能性があります。 MS-PWは、複数のプロバイダドメインを横断するとき、これは、サービスプロバイダまたはそのプロバイダのネットワークにおけるセキュリティホールにより、悪意のある行為の結果であり得ます。 S-PEとT-PESでMS-のPWの静的手動設定は、セキュリティのより大きな程度を提供します。 MS-PWの両端の識別情報が設定され、シグナリングメッセージで運ばれている場合、S-PEは、構成に対するシグナリングメッセージを検証することができます。エンドポイントのみがプロビジョニングされ、S-PEが動的に発見されるMS-のPWの動的シグナリングをサポートするために、メカニズムはサーバ上でそのような情報を設定し、検証のための接続試行中にその情報を使用するように提供されるべきです。

An incoming MS-PW request/reply MUST NOT be accepted unless its IP source address is known to be the source of an "eligible" peer. An eligible peer is an S-PE or a T-PE with which the originating S-PE or T-PE has a trust relationship. The number of such trusted T-PEs or S-PEs is bounded and not anticipated to create a scaling issue for the control plane authentication mechanisms.


If a peering adjacency has to be established prior to exchanging setup requests/responses, peering MUST only be done with eligible peers. The set of eligible peers could be pre-configured (either as a list of IP addresses, or as a list of address/mask combinations) or automatically generated from the local PW configuration information.


Furthermore, the restriction of peering sessions to specific interfaces MUST also be provided. The S-PE and T-PE MUST drop the unaccepted signaling messages in the data path to avoid a Denial-of-Service (DoS) attack on the control plane.

さらに、特定のインターフェイスにセッションをピアリングの制限も設けなければなりません。 S-PE及びT-PEは、制御プレーン上のサービス拒否(DoS)攻撃を回避するために、データパスに未承認のシグナリングメッセージを削除する必要があります。

Even if a connection request appears to come from an eligible peer, its source address may have been spoofed. Thus, means of preventing source address spoofing must be in place. For example, if eligible peers are in the same network, source address filtering at the border routers of that network could eliminate the possibility of source address spoofing.


S-PEs that connect one provider domain to another provider domain MUST have the capability to rate-limit signaling traffic in order to prevent DoS attacks on the control plane. Furthermore, detection and disposition of malformed packets and defense against various forms of attacks that can be protocol-specific MUST be provided.


7.2. Intra-Provider MS-PWs
7.2. インドラNS-プロバイダ - どのように

Security requirements for pseudowires are provided in [RFC3916]. These requirements also apply to MS-PWs.


MS-PWs are intended to enable many more PEs to provide PWE3 services in a given service provider network than traditional SS-PWs, particularly in access and metro environments where the PE may be situated closer to the ultimate endpoint of the service. In order to limit the impact of a compromise of one T-PE in a service provider network, the data path security requirements for inter-provider MS-PWs also apply to intra-provider MS-PWs in such cases.


8. Acknowledgments

The editors gratefully acknowledge the following contributors: Dimitri Papadimitriou (Alcatel-Lucent), Peter Busschbach (Alcatel-Lucent), Sasha Vainshtein (Axerra), Richard Spencer (British Telecom), Simon Delord (France Telecom), Deborah Brungard (AT&T), David McDysan (Verizon), Rahul Aggarwal (Juniper), Du Ke (ZTE), Cagatay Buyukkoc (ZTE), and Stewart Bryant (Cisco).

、ディミトリPapadimitriou(アルカテル・ルーセント)、ピーター・Busschbach(アルカテル・ルーセント)、サーシャVainshtein(Axerra)、リチャード・スペンサー(ブリティッシュテレコム)、サイモン・Delord(フランステレコム)、デボラBrungard(AT&T):エディタは感謝して以下の貢献を認めますデビッドMcDysan(ベライゾン)、ラウール・アガーウォール(ジュニパー)、デュ柯(ZTE)、Cagatay Buyukkoc(ZTE)、およびスチュワートブライアント(シスコ)。

9. References
9.1. Normative References
9.1. 引用規格

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。

[RFC3916] Xiao, X., Ed., McPherson, D., Ed., and P. Pate, Ed., "Requirements for Pseudo-Wire Emulation Edge-to-Edge (PWE3)", RFC 3916, September 2004.

[RFC3916]シャオ、X.、エド。、マクファーソン、D.、エド。、およびP.パテ、エド。、 "疑似ワイヤー・エミュレーション・エッジ・ツー・エッジ(PWE3)の要件"、RFC 3916、2004年9月。

[RFC3985] Bryant, S., Ed., and P. Pate, Ed., "Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture", RFC 3985, March 2005.

[RFC3985]ブライアント、S.、エド。、およびP.パテ、エド。、 "疑似ワイヤーエミュレーション端から端まで(PWE3)アーキテクチャ"、RFC 3985、2005年3月。

9.2. Informative References
9.2. 参考文献

[i610] Recommendation I.610 "B-ISDN operation and maintenance principles and functions", February 1999.

[i610]推奨I.610 "B-ISDNの運用保守原則と機能"、1999年2月。

[RFC5085] Nadeau, T., Ed., and C. Pignataro, Ed., "Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control Channel for Pseudowires", RFC 5085, December 2007.

[RFC5085]ナドー、T.、エド、およびC. Pignataro、エド、 "Pseudowireの仮想回線接続性検証(VCCV):スードワイヤ用制御チャネル"。。、RFC 5085、2007年12月。

[RFC4447] Martini, L., Ed., 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]、RFC 4447マティーニ、L.、エド。、ローゼン、E.、エルAawar、N.、スミス、T.、およびG.サギ、 "ラベル配布プロトコル(LDP)を使用して疑似回線の設定とメンテナンス" 、2006年4月。

[RFC4111] Fang, L., Ed., "Security Framework for Provider-Provisioned Virtual Private Networks (PPVPNs)", RFC 4111, July 2005.

[RFC4111]牙、L.、エド。、 "セキュリティフレームワークプロバイダ・プロビジョニングされた仮想プライベートネットワーク(PPVPNs)について"、RFC 4111、2005年7月。

[PWE3-OAM] Nadeau, T., Ed., Morrow, M., Ed., Busschbach, P., Ed., Alissaoui, M.,Ed., D. Allen, Ed., "Pseudo Wire (PW) OAM Message Mapping", Work in Progress, March 2005.

[PWE3-OAM]ナドー、T.、エド。、モロー、M.編、Busschbach、P.編、Alissaoui、M.編、D.アレン、エド。、「疑似ワイヤ(PW) OAMメッセージマッピング」、進歩、2005年3月に作業。

[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914, September 2000.

[RFC2914]フロイド、S.、 "輻輳制御の原理"、BCP 41、RFC 2914、2000年9月。

[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006.

[RFC4364]ローゼン、E.およびY. Rekhter、 "BGP / MPLS IP仮想プライベートネットワーク(VPN)"、RFC 4364、2006年2月。

[RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic Key Management", BCP 107, RFC 4107, June 2005.

[RFC4107] Bellovin氏、S.とR. Housley氏、 "暗号鍵管理のためのガイドライン"、BCP 107、RFC 4107、2005年6月。

Authors' Addresses


Nabil Bitar Verizon 117 West Street Waltham, MA 02145 EMail:

ナビル・ビタールベライゾン117西ストリートウォルサム、MA 02145 Eメール

Matthew Bocci Alcatel-Lucent Telecom Ltd, Voyager Place Shoppenhangers Road Maidenhead Berks, UK EMail:


Luca Martini Cisco Systems, Inc. 9155 East Nichols Avenue, Suite 400 Englewood, CO, 80112 EMail:

ルカ・マティーニシスコシステムズ株式会社9155東ニコルズアベニュー、スイート400イングルウッド、CO、80112 Eメール

Full Copyright Statement


Copyright (C) The IETF Trust (2008).


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.

この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。


この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、(もしあれば)を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。

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は、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。

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


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は、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。