[要約] RFC 5254は、マルチセグメントの仮想回線エミュレーションエッジ間(PWE3)の要件を定義しています。その目的は、異なるネットワークセグメント間での仮想回線のエミュレーションを可能にするための要件を提供することです。

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

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

マルチセグメントの擬似ワイヤエミュレーションエッジとエッジ(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.

このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。

Abstract

概要

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.

このドキュメントでは、サービスプロバイダーが複数のドメインにわたって擬似ワイヤの範囲を拡張できるようにするために必要な要件について説明します。これらのドメインは、1つのプロバイダー管理制御下の自律システム、1つの自律システムのIGPエリア、2つ以上のサービスプロバイダーの管理制御下での異なる自律システム、または管理上確立された擬似ワイヤドメインです。

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].

このドキュメントは、複数のパケットスイッチネットワーク(PSN)ドメインおよび/または複数のPSNトンネルに擬似動物を拡張するための要件を指定します。これらの擬似動物は、マルチセグメント擬似動物(MS-PWS)と呼ばれます。[RFC3916]で指定されている1つのPSNドメインのみでエッジまでエッジを拡張する単一セグメントの擬似動物(SS-PWS)の要件。このドキュメントは、[RFC3985]の一部を無効にすることを意図していません。

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

このドキュメントは、MS-PWSに適用される追加要件を指定します。これらの要件は、SS-PWSのみをサポートするPSNSには適用されません。

1.2. Architecture
1.2. 建築

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

次の3つの図は、PWエミュレートサービスをサポートするために[RFC3985]から派生した参照モデルについて説明しています。

         |<-------------- 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

図1:PWE3参照構成

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.

図1は、PWE3リファレンスアーキテクチャ[RFC3985]を示しています。このアーキテクチャは、PSNトンネルが単一のPSNドメインの2つのエッジの間に伸びて、これらのエッジでエンドポイントを備えたPWを輸送する場合に適用されます。

         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

図2:PWスイッチング参照モデル

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.

図2は、このアーキテクチャを拡張して、マルチセグメントのケースを示しています。終了PE1(T-PE1)と終端PE3(T-PE3)は、PWE3サービスをCE1およびCE2に提供します。これらのPEは、異なるPSNトンネル、PSNトンネル1およびPSNトンネル2を終了し、異なるPSNまたは擬似領域に存在する場合があります。1つのPSNトンネルは、PE1からPSN1を介してT-PE1からS-PE1に延び、2番目のPSNトンネルはS-PE1からPSN2全体でT-PE2に延びています。

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.

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

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.

S-PEは、PW識別子に基づいてMS-PWをあるセグメントから別のセグメントに切り替えます(例:MPLS PWSの場合のPWラベル)。図2では、PSNトンネル1およびPSNトンネル2トラバースのドメインは、たとえば、同じIGPネットワークのIGP領域、または単一のフラットIGPネットワークの単にPWE3ドメインである可能性があります。

                |<------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

図3:PWスイッチング間プロバイダー参照モデル

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-PEを通過する可能性があることに注意してください。たとえば、図3に示されている多ASの場合、1つの境界にs-pe(s-pe2)が(as1)as(as1)、および別のs-pe(s-pe3)がある場合があります。その他(AS2)。1つのas(t-pe1)の端から他方の端まで伸びるms-pwは(t-pe4)として3つのセグメントで構成されています。(1)PW1、AS1のセグメント、(2)PW2、PESを切り替えている2つの境界ルーター(S-PE2およびS-PE3)の間のセグメント、および(3)AS2のセグメントであるPWE3。AS1とAS2は同じプロバイダーに属している可能性があります(たとえば、AS1はアクセスネットワークまたはMetro Transport Networkである可能性があり、AS2はMPLSコアネットワークになる可能性があります)または2つの異なるプロバイダー(例:プロバイダー1のAS1およびAS2プロバイダー2)。

2. Terminology
2. 用語

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。MS-PWの最初と最後のセグメントに終了PEが存在します。これには、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の各方向は、2つの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として振る舞い、機能する2つ以上の連続した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セグメント。単一セグメントまたはマルチセグメントPWの一部。これは、2つのPEデバイス、T-PEおよび/またはS-PEの間にセットアップされています。

- 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].

「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。

3. Use Cases
3. ユースケース

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は、終端PE(T-PE)のペア間でSS-PWSを確立するためのシグナル伝達およびカプセル化技術を定義し、大部分の場合、これで十分です。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.

-私。パバイダー間PWS:プロバイダー間のPWは、あるプロバイダードメインのT-PEから別のプロバイダードメインのT-PEに拡張されるPWです。

-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。PWSをセットアップおよび維持するために、T-PESの間に直接PW制御チャネルを確立することは不可能、望ましい、または実行不可能です。少なくとも、直接PW制御チャネルの確立(ターゲットを絞ったLDPセッションなど)には、リモートT-PE IPアドレスの知識と到達可能性が必要です。ローカルT-PEは、運用またはセキュリティの制約のためにこの情報にアクセスできない場合があります。さらに、SS-PWには、ローカルT-PEとリモートT-PEの間にPSNトンネルが存在する必要があります。セキュリティおよび/またはスケーラビリティの理由のために、または2つのドメインが異なるPSNテクノロジーを使用している可能性があるため、1つのドメインのT-PEと別のドメインのT-PEの間に単一の連続的なPSNトンネルを拡張することは、実現可能でも望ましくもない場合があります。

-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が異なるプロバイダーネットワーク(ASS)に存在するL2VPN間シナリオと、2つのネットワーク間で交換されるMD5キーのすべての制御トラフィックに対する現在の慣行です。MS-PWを使用すると、プロバイダーは、2つのドメインを接続するPWスイッチングポイントのみにMD5キー管理をLDPセッションに限定できます。

-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トンネルと帯域幅管理PWS:大規模なサービスプロバイダーネットワークでPWS Edgeをエッジに展開する必要があります。このようなネットワークは通常、端にある数百または数千の集約デバイスを網羅しており、それぞれがPEになります。さらに、これらのPWSに明示的な帯域幅保証があるという要件があります。これらの要件を満たすために、PWSは帯域幅の制約を備えたPSN Te-Tunnelsでトンネル化されます。単一セグメントの擬似ワイヤーアーキテクチャでは、すべてのPEの間にPWを確立できるように、PSN TE-Tunnelの完全なメッシュをプロビジョニングする必要があります。トラフィックエンジニアリングトンネルに乗るプロバイダー間のPWSは、PESの総数が増加するにつれてPESとコアネットワークによってサポートされる必要があるトンネルの数をさらに追加します。

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.

この環境では、PSN Te-TunnelsとPWシグナリングの隣接するまばらなメッシュをサポートするか、ネットワークを多数の小さなPWE3ドメインに分割するための要件があります。どちらの場合でも、PWはその経路に沿って複数のPSNトンネルホップを通過する必要があります。目的は、サポートする必要があるトンネルの数を減らすこと、したがって、発生する可能性のある複雑さとスケーラビリティの問題を減らすことです。

-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.

これらのアーキテクチャのため、アクセス/メトロのサーキット(例:イーサネット仮想回路(EVC)、ATM VC、TDM回路)は、従来、ネイティブ形式のアタッチメント回路として、IP-MPLSネットワークのエッジに取り付けられています。PWが始まります。この組み合わせには、複数の個別のアクセスネットワークが必要であり、エンドツーエンドの制御、プロビジョニング、およびメンテナンスを複雑にします。さらに、TDMまたはSONET/SDHアクセスネットワークがパケットベースのインフラストラクチャに置き換えると、統計的多重化がエンドユーザーに近づき、複数のサービスを単一のアクセスネットワークに収束させるため、費用が削減される場合があります。

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.

アクセスネットワークには、PWSの適用に影響を与える多くのプロパティがあります。たとえば、PSNがIETF指定タイプではなく、PW層でPWE3のメカニズムと互換性のあるメカニズムを使用するアクセスメカニズムが存在します。

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-PWSを使用すると、アクセスおよびメトロネットワーク要素は、直接接続するPESとの隣接をPWの信号を維持するだけです。彼らは、他のすべてのアクセスおよびメトロネットワークデバイスとの隣接を信号する必要はありません。PSNバックボーンのPESは、互いにPWのシグナル伝達を維持します。さらに、PSNトンネルは、アクセス要素と接続するPEの間に設置されています。PSNバックボーンのすべてのPEペアの間に別のPSNトンネルを確立する必要があります。MS-PWは、1つのアクセスネットワーク要素から3つのセグメントを備えた別のアクセス要素にセットアップできます。要素にアクセスします。このMS-PWセットアップでは、アクセス要素はT-PESであり、PSN-PEはS-PEです。PSNバックボーンをPWE3ドメインにセグメント化して、PWあたりのセグメントが多くなることに注意する必要があります。

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:

この要件文書は、上記のユースケースが次のメカニズムの1つ以上を使用して実現されることを前提としています。

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

-私。静的構成:T-PEに加えて、スイッチングポイント(S-PE)は、各セグメントに対して手動でプロビジョニングされます。

-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.

-ii。事前に決定されたルート:PWは、S-PEで自動化されたステッチを備えたエンドツーエンドのシグナル伝達プロトコルを使用して、管理上決定されたルートに沿って確立されます。

-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.

-III。シグナル付き動的ルート:PWは、S-PEで自動化されたステッチを備えたエンドツーエンドのシグナル伝達プロトコルを使用して、動的に決定されたルートに沿って確立されます。ルートは、1つ以上の動的ルーティングプロトコルを使用して選択されます。

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.

PWルートを、MS-PWが特定のT-PEのペア間を通過するS-PESのセットと定義することに注意してください。そのルートに沿ったPSNトンネルは、S-PESおよびT-PEで明示的に指定または局所的に選択できます。PSNトンネル自体のルーティングは、このドキュメントで指定された要件の範囲外です。

4. Multi-Segment Pseudowire Requirements
4. マルチセグメントの擬似ワイヤー要件

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

次のセクションでは、上記のユースケースがMS-PWセットアップメカニズムに掲載されている要件を詳しく説明しています。

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

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

以下の一般的な要件は、前のセクションで定義された3つのMS-PWセットアップメカニズムに適用されます。

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.

-私。SS-PWSのみをサポートするPSNにMS-PWがトンネル化されている場合、[RFC3916]の要件のみがそのPSNに適用されます。オーバーレイがMS-PWを運んでいるという事実は、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ルーターは、PWSに透明なPSN輸送を提供し、それらを通過するPWSの知識を持たないはずです。

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

-III。MS-PWSは、SS-PWSに指定された同じカプセル化モードを使用する必要があります。

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

-iv。MS-PWSはSS-PWSで構成する必要があります。

-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-PWSのPWE3がサポートするすべてのテクノロジーのPSNを通過できる必要があります。ある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タイプのPWSのスイッチングのみをサポートできます。この場合、PWタイプは、異なるPSNテクノロジー間のインターワーキングに必要な機能を除き、転送面のS-PEに対して透明です。

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

-viii。ソリューションは、PW間のセットアップとメンテナンスプロセスに優先順位を付ける方法を提供する場合があります。

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:

MS-PWの既存のパス上の要素が失敗した場合にMS-PWを保護するメカニズムを提供する必要があります。これらのメカニズムは、MS-PWセットアップに依存します。以下は、すべてのMS-PWセットアップメカニズムに適用される一般的な回復力の要件です。

-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.

-私。プライマリPWへのバックアップPWの構成と確立をサポートする必要があります。障害検出時にプライマリPWからバックアップPWへのスイッチオーバーを実行するメカニズムを提供する必要があります。

-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.

-ii。プライマリPWパスのエンドツーエンドバックアップPWパスを構成する機能をサポートする必要があります。プライマリおよびバックアップパスは、静的に構成され、シグナリング用に静的に指定されている、またはMS-PW確立メカニズムに応じて動的ルーティングを介して動的に選択される場合があります。バックアップとプライマリパスには、S-PEを個別に通過する機能が必要です。バックアップパスは、構成時間または障害後に通知される場合があります。

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

-III。プライマリPWとバックアップPWをプライマリとは異なるT-PEで構成する機能をサポートする必要があります。

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

-iv。障害検出時にプライマリPWからバックアップPWへの高速スイッチオーバーを実行する自動メカニズムを提供する必要があります。

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

-v。バックアップPWからプライマリPWに自動的に戻るメカニズムが提供される場合があります。提供されると、構成可能でなければなりません。

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.

Pseudowiresは、関連1人あたりのサービス品質(QoS)要件を持つ可能性のあるエミュレートサービス(TDMやATMなど)をサポートすることを目的としています。これには、パケットの損失、遅延、およびジッターに関する絶対的または相対的な保証が含まれる場合があります。これらの保証は、部分的には、十分なネットワークリソース(帯域幅など)を予約し、ネットワーク全体で適切なパケットごとの処理(例:優先順位とドロップの優先順位)を提供することによって提供されます。

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.

SS-PWSの場合、トラフィックエンジニアリングPSNトンネル(つまり、MPLS-TE)を使用して、トンネル上のPWSにQoSを提供するためにP-Routerに十分なリソースが予約されるようにすることができます。この場合、T-PEには、交通の方向にPSNトンネルリソースを自動的に要求する機能が必要です(たとえば、PSNトンネルへのPWSの入場制御と、予約帯域幅とトンネルでの利用可能な帯域幅を考慮しています)。トンネルが複数のクラスのサービス(COS)(E-LSPなど)をサポートする場合、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-PWSの場合、各S-PEはPWセグメントをPSNトンネルにマッピングします。ソリューションは、S-PEとT-PEがPWに指定されている場合、COSおよび帯域幅要件に基づいてPWセグメントをPSNトンネルに自動的に結合できるようにする必要があります。ソリューションは、ポリシー構成の問題として、PWセグメントをトンネルに結合する能力も提供する必要があります。S-PESおよび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-PESおよびT-PEは、COSマーキング(例:MPLS PWSのEXPフィールド値)をPW PDUSに関連付けることができなければなりません。PW PDUのCOSマーキングは、パケット処理に影響します。COSマーキングはPSNテクノロジーに依存します。したがって、MS-PWがあるPSNテクノロジーから別のテクノロジーに交差する場合、ソリューションはCOSマーキングに必要なマッピングの構成を有効にする必要があります。同様に、異なる管理ドメインは、異なるCOS値を使用して同じCOS処理を暗示する場合があります。ソリューションは、PW PDUがあるドメインから次のドメインに交差するときに、あるCOS値から別のCOS値に変換するために、管理ドメイン境界でS-PEの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]は、伝送速度を下げることにより、PWSにパス渋滞に応答する必要があります。あるいは、RFC 3985は、プロビジョニングされたパスに沿って明示的に予約された容量を使用して送信するための輻輳制御メカニズムを持たないPWSを許可します。MS-PWはPWの一種であるため、この要件も同様に拡張されます。したがって、MS-PWSに適用されるRFC 3985では、MS-PWがMSパス全体で効果的な渋滞制御メカニズムを採用するか、MS-PWが送信を開始する前にMSパスに沿ってすべてのドメインで十分な容量を留保する明示的なプロビジョニングアクションを必要とする必要があります。。したがって、S-PEは、適切な渋滞制御スキームを使用しない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.

[RFC3985]は、[RFC2914]に準拠するために、すべてのPWSがうっ血に応答することを要求しています。明確に定義された輻輳制御メカニズムがない場合、[RFC3985]は、PWSによって引き起こされるトラフィックが、混雑の下でさえ、パスを共有する同時トラフィックに有害な影響を与えないように、PWSをプロビジョニングされたパスを越えて運ぶことを許可します。これらの要件は、このドキュメントで定義されているMS-PWSに拡張されます。

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-PWSの場合、多くの既存のプロトコルがこのプロビジョニング機能を提供できます。ただし、MS-PWは、複数のエンティティの管理下にあるネットワークドメインを介して送信する場合があります。必要なドメイン間相互作用のため、このようなパス全体のQoSプロビジョニングは本質的に困難です。これらの困難は、MS-PW使用のためにパス容量を提供する要件を無効にしないことに注意することが重要です。各ドメインは、輻輳を制御する方法を個別に実装する必要があります。これは、QoS予約、またはその他の混雑制御方法によって行うことができます。MS-PWSは、[RFC3985]で要求されるように、他の輻輳制御スキームがない場合、未定の最良の努力、パスを介して送信してはなりません。

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.

ソリューションは、MS-PWのパスでS-PEとT-PEを有効にして、その渋滞が発生したときに他のS-PEとT-PEをそのパスで通知する必要があります。輻輳は、キューの長さ、パケット損失率、またはそれぞれのしきい値を通過する帯域幅の測定によって示される場合があります。PWSの1つのパスに沿って輻輳の通知を受け取るT-PEが取ったアクションは、MS-PWを代替T-PEを含む代替パスに再ルーティングすることです。PE、またはS-PEには、特定のリンクまたはトンネルが混雑が発生していることを知っている場合、そのリンクまたはトンネルを利用する新しいMS-PWを設定してはなりません。TDM PWSなどの一部の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-PESおよびPSNトンネルを静的に選択する機能を提供する必要があります。S-PEの静的選択は、定義上、静的構成と信号/静的ルートセットアップメカニズムの要件です。この要件は、サービスプロバイダーのセキュリティと管理ポリシーを実施するために、MS-PWに特定のS-PEを横断することを強制する必要性を満たします。

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

-ii。ソリューションは、MS-PWのセットアップに必要な構成の量を最小限に抑える必要があります。

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

-III。ソリューションは、同じT-PE、S-PE、およびPSNネットワークのさまざまなPWセットアップメカニズムをサポートする必要があります。

-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.

-iv。ソリューションでは、T-PEが[RFC447]で指定されているSS-PWシグナル伝達メカニズムの使用とMS-PWシグナル伝達メカニズムを同時にサポートできるようにする必要があります。

-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.

-v。ソリューションは、帯域幅、COS、およびその他の可能な属性のPW制約を満たすパスがネットワークに存在する場合、MS-PWを設定する必要があります。

-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-PEの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.

-viii。PSNトンネルに新しいPWに対応するために必要なリソースがない場合、新しいPSNトンネルをシグナルにする試み、または既存のPSNトンネルの容量を増やす試みができます。拡張されたPSNトンネルがセットアップに失敗した場合、PWはセットアップに失敗する必要があります。

-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トンネルを構成およびセットアップする必要なく境界として交差する場合、2つの(自律システム境界ルーター(ASBR)の間にPWセグメントをセットアップできます。この場合、入学制御を実行する必要があります。有効にすると、S-PES間のリンクで。

4.1.6. Routing
4.1.6. ルーティング

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

MS-PWSの目的は、次の接続をサポートすることです。

-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-PWS

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

MS-PWセグメントが静的に構成されている場合、以前に定義された一般的な要件に加えて、次の要件が適用されます。

4.2.1. Architecture
4.2.1. 建築

There are no additional requirements on the architecture.

アーキテクチャには追加の要件はありません。

4.2.2. MPLS-PWs
4.2.2. MPLS-PWS

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セグメントの静的ラベルの構成を許可するT-PEまたはS-PEも同時に、他のMS-PWセグメントの動的ラベル割り当てを可能にする必要があります。2つの相互接続されたS-PEにMS-PWセグメントをセットアップする目的でシグナリングピアリングがない場合、PWまたは接続回路の欠陥通知を中継するバンド内のPW操作とメンテナンス(OAM)機能が必要であることに注意してください。隣接するS-PE。

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.

このソリューションは、PWセグメント、隣接するPWセグメントのセット、およびエンドツーエンドパスの保護を可能にする必要があります。プライマリと保護セグメントは、同じセグメントのエンドポイントを共有する必要があります。ソリューションは、障害の前または障害の結果として、バックアップパスを設定することを可能にする必要があります。選択は構成によって行う必要があります。リソースが限られており、すべてのPWSを満たすことができない場合、セットアップされている他のPWのセットアップ優先順位または既存のPWSの保持優先順位と比較した場合、より高いセットアップ優先順位を持つPWSを優先する必要があります。

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

ソリューションは、T-PE間のトラフィックの損失を最小限に抑えるよう努力する必要があります。

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.

MS-PWのCOSと帯域幅は、T-PESおよび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.

MS-PWセグメントが動的に信号を送られると、以前に定義された一般的な要件に加えて、次の要件が適用されます。信号されたMS-PWセグメントは、静的に構成されたMS-PWのパス、信号/静的ルーティングMS-PW、またはSignaled/動的にルーティングされたMS-PWのパスにあります。

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

SS-PWSをセットアップするために定義される4つの異なるメカニズムがあります。

-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.

MS-PWセットアップメカニズムは、上記のプロトコルのいずれかで合図されたPWセグメントをサポートできる必要があります。ただし、SS-PWシグナル伝達プロトコルの組み合わせの仕様は、特定の実装によってサポートされています。このドキュメントの範囲外です。

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.

信号/静的にルーティングされ、信号/動的にルーティングされたMS-PWセットアップメカニズムの場合、以前に定義された一般的な要件に加えて、次の要件が適用されます。

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.

ソリューションでは、PWセグメントの保護パスの信号、セグメントのシーケンス、またはエンドツーエンドパスを可能にする必要があります。保護されたセグメントの保護パスと主要なパスは、それぞれのセグメントのエンドポイントを共有します。入場制御が有効になっている場合、システムは、マージされたポイント(トンネルなど)での帯域幅の割り当てを2倍にしないように注意する必要があります。ソリューションは、障害の前または障害の結果として、バックアップパスを設定することを可能にする必要があります。選択は、保護されたパスのエンドポイントで構成によって行う必要があります。リソースが限られており、すべてのPWSを満たすことができない場合、セットアップされている他のPWのセットアップ優先順位または既存のPWSの保持優先順位と比較した場合、より高いセットアップ優先順位を持つPWSを優先する必要があります。手順は、プライマリとバックアップパスを多様にする必要があります。

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

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

T-PEがMS-PWのシグナルを試みる場合、次の機能が必要です。

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

-私。シグナル伝達は、MS-PWに関連するCOSを識別できる必要があります。

-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.

-ii。シグナリングは、COSあたりMS-PWのトラフィックパラメーターを運ぶことができなければなりません。トラフィックパラメーターは、既存のINTSERV定義に基づいている必要があり、入学制御が有効になっている場合は、入場制御に使用する必要があります。

-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.

-v。シグナリングプロトコルは、PW間のPWセットアップおよびメンテナンス操作に優先順位を付ける方法に対応できる必要があります。

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:

以下は、シグナル付きMS-PWセットアップメカニズムに関するさらなる要件です。

-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.

-私。MS-PWのすべてのセグメントが正常にセットアップされた場合、MS-PWのセットアップが成功すると見なされるように、シグナリング手順を定義する必要があります。

-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-PEのみをプロビジョニングすることにより、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.

-III。動的なMS-PWセットアップでは、一意の識別子をPWに関連付け、信号メッセージに携帯する必要があります。その識別子には、中間S-PEを介してリモートT-PEへのパスを決定するのに十分な情報を含める必要があります。

-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。単一プロバイダードメインでは、IPアドレスの1つによってT-PEを識別するのは自然です。これは、同じプロバイダーによって動作する複数のドメインにMS-PWがセットアップされる場合にも適用される場合があります。ただし、一部のサービスプロバイダーには、ネットワーク内のルーターへの到達可能性を他のプロバイダーに広告することを妨げるセキュリティおよび機密保持ポリシーがあります(ASBRへの到達可能性は例外です)。したがって、これらの条件下でMS-PWSの動的なセットアップを可能にするために手順を提供する必要があります。

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.1および4.3の要件に加えて、適用されます。

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.

PWルーティング関数は、動的セットアップメソッドを使用してセグメントをセットアップする場合、障害ポイント周辺の動的な再ルーティングをサポートする必要があります。

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

There are no additional QoS requirements.

追加のQoS要件はありません。

4.4.4. Routing
4.4.4. ルーティング

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

以下は、MS-PWの動的ルート選択に関連する要件です。

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

-私。ルーティングでは、S-PEとT-PEが宛先T-PEへのパスでS-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-PEを自動的に選択する機能が必要です。一部の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.

-iv。ルーティングプロトコルは、アタッチメント回路(AC)エンドポイントの到達可能性情報を宣伝できる必要があります。この到達可能性情報は、シグナル伝達で運ばれるAC識別子と一致する必要があります。

5. Operations and Maintenance (OAM)
5. 運用とメンテナンス(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.

アタッチメント回路のOAMメカニズムは、PWエミュレートされた特定の技術の仕様で定義されています(たとえば、ATMのITU-T I.610 [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.

ACSとPWS間のSS-PWSのOAMメカニズムの相互作用は、[PWE3-OAM]で定義されています。これらにより、障害からの障害と回復に続いて、PWE3ネットワーク全体で欠陥状態を伝播できます。

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-PWSのOAMメカニズムは、SS-PWSの機能と少なくとも同じ機能を提供する必要があります。さらに、マルチセグメントネットワークに欠陥を局在させるために、欠陥通知と接続検証の両方のセグメントとエンドツーエンドのOAMメカニズムの両方をサポートすることが可能です。つまり、PW OAMセグメントは、T-PEからT-PE、T-PEからS-PE、またはS-PEからS-PEです。

The following requirements apply to OAM for MS-PWs:

MS-PWSのOAMには次の要件が適用されます。

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

-私。PWセグメントの故障検出のメカニズムとMS-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.

-III。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-PWSをサポートするために拡張する必要があります。

-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トンネルを利用するすべてのPWSに伝播する必要があります。

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

-vii。欠陥通知の方向性は、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をT-PE PW OAMメッセージに透過的に渡すことができる必要があります。

-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.

-バツ。MS-PWSとSS-PWSの両方に、往復遅延、一元配置遅延、ジッター、およびパケット損失率を測定するには、パフォーマンスOAMが必要です。

6. Management of Multi-Segment Pseudowires
6. マルチセグメントの擬似動物の管理

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-PWSを使用する各PWE3アプローチは、ネットワークオペレーターがエミュレートサービスを管理するためのいくつかのメカニズムを提供する必要があります。MS-PWSの管理メカニズムは、[RFC3916]で定義されているように、SS-PWSの機能と少なくとも同じ機能を提供する必要があります。

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-PWSの追加属性を管理することも可能です。MS-PWの確立を開始する演算子は、MS-PWのパスに沿ったS-PEとT-PEの1つ、MS-PWのリモート管理のメカニズムから異なるPSNドメインに存在する可能性があるため提供する必要があります。

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.

-私。MIBテーブルは、S-PESおよびT-PEでのMS-PWの構成とプロビジョニングを容易にするように設計する必要があります。

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

-ii。MIB(S)は、ACSのInter-PSN構成と監視を促進する必要があります。

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.

-私。S-PEまたはT-PEでMS-PWのリモート管理を有効にするために、メカニズムを提供する必要があります。これらのメカニズムがPSNドメイン全体で動作することが可能であるはずです。一般的に利用可能なメカニズムの例は、Telnetセッション上のコマンドラインインターフェイス(CLI)です。

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

-ii。セキュリティまたはその他の理由により、MS-PWのリモート管理を無効にすることが可能である必要があります。

7. Security Considerations
7. セキュリティに関する考慮事項

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).

このドキュメントは、1つまたは複数のサービスプロバイダーが管理するドメインの境界を越えてセットアップできるMS-PWS(Provider Inter-Provider MS-PWS)の要件と、1つのプロバイダーでのみセットアップされるMS-PW(プロバイダーMS-PWS)。

7.1. Inter-Provider MS-PWs
7.1. Provider Inter-Provider MS-PWS

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.

1つのサービスプロバイダーが管理するドメイン全体のMS-PWセットアップのセキュリティ要件は、[RFC4447]および[RFC3916]のセキュリティに関する考慮事項で説明されているものと同じです。これらの要件は、プロバイダー間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-PWSに適用されるL2 VPNのユーザーおよびプロバイダーの要件を識別します。このセクションでは、コントロールプレーンとデータプレーンの両方でMS-PWSのプロバイダー間操作のための追加のセキュリティ要件に焦点を当てており、これらの要件の一部は[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または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は、SPドメインの1つのT-PEを別のプロバイダードメインのT-PEに接続できます。また、2つのT-PEが1つのspの制御下にある場合でも、他のプロバイダードメインを通過する場合があります。これらのシナリオでは、1つ以上の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-PWSのサービスプロバイダー国境にあるデータプレーンのセキュリティ要件は、Provider間BGP/MPLS IP仮想ネットワーク[RFC4364]のデータプレーンのセキュリティ要件に似ています。特に、S-PEまたはT-PEは、次の2つの条件のいずれかが保持されない限り、サービスプロバイダーのボーダーを介して特定の隣人から受け取ったパケットを破棄する必要があります。

-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

-私。受信S-PEまたはT-PEで処理されたMPLSラベル、PSNトンネルラベルまたはPWラベルなどのラベルには、受信システムがその隣接に配布したラベル値があります。また

-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).

-ii。PSNトンネルラベルやPWラベルなど、受信S-PEまたはT-PEで処理されたMPLSラベルには、受信S-PEまたはT-PEが以前にピアS-PEまたはTに分布していたラベル値があります。-peその隣人を超えて(つまり、ラベルが受信システムに配布されているシステムからのパスがその隣人を介してあることがわかっている場合)。

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.

MS-PWと交差したドメインの1つは、盗聴のためにMS-PWのPDUを選択的にミラーリングすることを決定する場合があります。また、PDUを目的地から遠ざけることにより、MS-PWのPDUを選択的にハイジャックすることもできます。どちらの場合でも、MS-PWのプライバシーに違反する可能性があります。

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.

イングレスS-PEは、MS-PWがS-PEでそのMS-PWに対して構成または信号を設定したCOS処理を受信することを確認する必要があります。具体的には、S-PEは、EXPビットまたはIPヘッダー差別化されたサービス(DS)フィールド(PSNに応じて)にマークされたパケットを、受信するよりも優れたCOSに対して守る必要があります。

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.

イングレスS-PEは、インターフェイスごとまたはインターフェイスグループ(グループはピアプロバイダーにインターフェイスに対応する場合がある)をMPLS-PWSのラベルスペースを定義できる必要があります。ボトムラベルがパケットが到着したインターフェイス上のS-PEによって割り当てられたPWラベルでない限り、S-PEは別のプロバイダーからラベル付きパケットを受け入れないように構成可能である必要があります。

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

[RFC3985]で指定されたSS-PWのデータプレーンセキュリティ上の考慮事項も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は、2つのアタッチメントサーキットを接続します。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-PE)は、2つのプロバイダーを相互接続するASBRにある必要があります。物理的に安全なリンクを使用してS-PEを直接相互接続し、S-PE間のシグナリングとルーティング認証を有効にすると、信頼できないピアからMS-PWシグナリングメッセージまたはパケットを受信する可能性がなくなります。他の構成が可能です。たとえば、隣接するS-PES/T-PEの間のPSNトンネルのPルーターは、ASBRSに存在する場合があります。その場合、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.

構成およびメンテナンスプロトコルは、強力な認証および制御プロトコルデータ保護メカニズムを提供する必要があります。このオプションは実装する必要がありますが、特定のPSN環境要件に従って展開する必要があります。さらに、全体的な制御プロトコルセッション認証とメッセージ検証に加えて、個々のMS-PWセットアップメッセージに署名を使用した認証が利用可能でなければなりません。

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とのみ信頼関係を持ちます。他のお尻。したがって、手動のキー管理に基づく現在のセキュリティメカニズムで十分であると予想されます。他のASSのS-PESへの大規模な接続を必要とする展開の状況が発生する場合、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-PESおよびT-PESでのMS-PWSの静的な手動構成は、より多くのセキュリティを提供します。MS-PWの両端の識別が構成され、信号メッセージに伝達される場合、S-PEは構成に対して信号メッセージを検証できます。エンドポイントのみがプロビジョニングされ、S-PEが動的に発見されるMS-PWSの動的信号をサポートするには、サーバー上のそのような情報を構成し、検証の接続試行中にその情報を使用するメカニズムを提供する必要があります。

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.

IPソースアドレスが「適格な」ピアのソースであることが知られていない限り、着信MS-PWリクエスト/返信は受け入れられないでください。適格なピアは、S-PEまたはT-PEであり、そこではS-PEまたはT-PEが信頼関係を持っています。このような信頼できるT-PEまたはS-PEの数は境界があり、コントロールプレーン認証メカニズムのスケーリング問題を作成するとは予想されていません。

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.

セットアップのリクエスト/回答を交換する前に、ピアリング隣接を確立する必要がある場合、ピアリングは資格のあるピアでのみ行う必要があります。適格なピアのセットは、事前に構成されている可能性があり(IPアドレスのリストとして、またはアドレス/マスクの組み合わせのリストとして)、ローカルPW構成情報から自動的に生成されます。

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.

1つのプロバイダードメインを別のプロバイダードメインに接続するS-PESには、DOS攻撃を防ぐために、信号トラフィックをレートに格付けする機能が必要です。さらに、プロトコル固有のさまざまな形態の攻撃に対する奇形のパケットの検出と処分を提供する必要があります。

7.2. Intra-Provider MS-PWs
7.2. プロバイダー内MS-PWS

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

擬似動物のセキュリティ要件は[RFC3916]に提供されています。これらの要件は、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.

MS-PWSは、特にPEがサービスの究極のエンドポイントに近いアクセスおよびメトロ環境で、従来のSS-PWよりも多くのPESが特定のサービスプロバイダーネットワークでPWE3サービスを提供できるようにすることを目的としています。サービスプロバイダーネットワークでの1つのT-PEの妥協の影響を制限するために、そのような場合、プロバイダー間MS-PWSのデータパスセキュリティ要件もプロバイダー内MS-PWSに適用されます。

8. Acknowledgments
8. 謝辞

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).

編集者は、次の貢献者に感謝して認めています:Dimitri Papadimitriou(Alcatel-Lucent)、Peter Busschbach(Alcatel-Lucent)、Sasha Vainshtein(Axerra)、Richard Spencer(British Telecom)、Simon Delord(France Telecom)、Deborah Brungard(&Th)David McDysan(Verizon)、Rahul Aggarwal(Juniper)、Du Ke(Zte)、Cagatay Buyukkoc(ZTE)、Stewart Bryant(Cisco)。

9. References
9. 参考文献
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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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] Xiao、X.、ed。、McPherson、D.、ed。、およびP. Pate、ed。、「Pseudo-Wireエミュレーションエッジツーエッジ(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] Bryant、S.、ed。、およびP. Pate、ed。、「Pseudo Wire Emulation Edge-to-Edge(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] Nadeau、T.、ed。、およびC. Pignataro、ed。、「Pseudowire Virtual Curnecivity Verification(VCCV):Pseudowiresの制御チャネル」、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] Martini、L.、Ed。、Ed。、Rosen、E.、El-Aawar、N.、Smith、T。、およびG. Heron、「擬似ワイヤー分布プロトコル(LDP)を使用した擬似ワイヤーのセットアップとメンテナンス」、RFC 4447、2006年4月。

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

[RFC4111] Fang、L.、ed。、「プロバイダーが提供する仮想プライベートネットワーク(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] Nadeau、T.、Ed。、Morrow、M.、Ed。、Busschbach、P.、ed。、Alissaoui、M.、ed。、D。Allen、ed。、 "Pseudo Wire(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] Rosen、E。およびY. Rekhter、「BGP/MPLS IP仮想プライベートネットワーク(VPNS)」、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: nabil.n.bitar@verizon.com

Nabil Bitar Verizon 117 West Street Waltham、MA 02145メール:nabil.n.bitar@verizon.com

Matthew Bocci Alcatel-Lucent Telecom Ltd, Voyager Place Shoppenhangers Road Maidenhead Berks, UK EMail: matthew.bocci@alcatel-lucent.co.uk

Matthew Bocci Alcatel-Lucent Telecom Ltd、Voyager Place Shoppenhangers Road Maidenhead Berks、英国メール:matthew.bocci@alcatel-lucent.co.uk

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

Luca Martini Cisco Systems、Inc。9155 East Nichols Avenue、Suite 400 Englewood、Co、80112メール:lmartini@cisco.com

Full Copyright Statement

完全な著作権声明

Copyright (C) The IETF Trust (2008).

著作権(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に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織(もしあれば)、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。

Intellectual Property

知的財産

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。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 http://www.ietf.org/ipr.

IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。