[要約] RFC 7267は、マルチセグメント疑似ワイヤの動的配置に関する標準化ドキュメントです。このRFCの目的は、異なるネットワークセグメント間での疑似ワイヤの動的な配置を可能にするための手法を提供することです。
Internet Engineering Task Force (IETF) L. Martini, Ed.
Request for Comments: 7267 Cisco Systems, Inc.
Updates: 6073 M. Bocci, Ed.
Category: Standards Track F. Balus, Ed.
ISSN: 2070-1721 Alcatel-Lucent
June 2014
Dynamic Placement of Multi-Segment Pseudowires
マルチセグメント疑似配線の動的配置
Abstract
概要
RFC 5254 describes the service provider requirements for extending the reach of pseudowires (PWs) across multiple Packet Switched Network domains. A multi-segment PW is defined as a set of two or more contiguous PW segments that behave and function as a single point-to-point PW. This document describes extensions to the PW control protocol to dynamically place the segments of the multi-segment pseudowire among a set of Provider Edge (PE) routers. This document also updates RFC 6073 by updating the value of the Length field of the PW Switching Point PE Sub-TLV Type 0x06 to 14.
RFC 5254は、複数のパケット交換ネットワークドメインにまたがる疑似配線（PW）の到達範囲を拡張するためのサービスプロバイダーの要件について説明しています。マルチセグメントPWは、単一のポイントツーポイントPWとして動作し、機能する2つ以上の隣接するPWセグメントのセットとして定義されます。このドキュメントでは、プロバイダーエッジ（PE）ルーターのセットの間にマルチセグメント疑似配線のセグメントを動的に配置するためのPW制御プロトコルの拡張について説明します。このドキュメントでは、PWスイッチングポイントPEサブTLVタイプ0x06の長さフィールドの値を14に更新することにより、RFC 6073も更新しています。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7267.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7267で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2014 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日より前に公開または公開されたIETFドキュメントまたはIETFコントリビューションの素材が含まれている場合があります。 IETF標準プロセス外。このような資料の著作権を管理する人から適切なライセンスを取得せずに、このドキュメントをIETF標準プロセス外で変更したり、その派生物をIETF標準プロセス外で作成したりすることはできません。 RFCとして、またはそれを英語以外の言語に翻訳するための出版物。
Table of Contents
目次
1. Introduction ....................................................4
1.1. Scope ......................................................4
1.2. Specification of Requirements ..............................4
1.3. Terminology ................................................4
1.4. Architecture Overview ......................................5
2. Applicability ...................................................6
2.1. Changes to Existing PW Signaling ...........................6
3. PW Layer 2 Addressing ...........................................6
3.1. Attachment Circuit Addressing ..............................7
3.2. S-PE Addressing ............................................8
4. Dynamic Placement of MS-PWs .....................................8
4.1. Pseudowire Routing Procedures ..............................8
4.1.1. AII PW Routing Table Lookup Aggregation Rules .......9
4.1.2. PW Static Route .....................................9
4.1.3. Dynamic Advertisement with BGP .....................10
4.2. LDP Signaling .............................................11
4.2.1. Multiple Alternative Paths in PW Routing ...........13
4.2.2. Active/Passive T-PE Election Procedure .............14
4.2.3. Detailed Signaling Procedures ......................15
5. Procedures for Failure Handling ................................16
5.1. PSN Failures ..............................................16
5.2. S-PE Failures .............................................17
5.3. PW Reachability Changes ...................................17
6. Operations, Administration, and Maintenance (OAM) ..............18
7. Security Considerations ........................................18
8. IANA Considerations ............................................19
8.1. Correction ................................................19
8.2. LDP TLV Type Name Space ...................................19
8.3. LDP Status Codes ..........................................20
8.4. BGP SAFI ..................................................20
9. References .....................................................20
9.1. Normative References ......................................20
9.2. Informative References ....................................21
10. Contributors ..................................................22
11. Acknowledgements ..............................................23
[RFC5254] describes the service provider requirements for extending the reach of pseudowires across multiple Packet Switched Network (PSN) domains. This is achieved using a multi-segment pseudowire (MS-PW). An MS-PW is defined as a set of two or more contiguous pseudowire (PW) segments that behave and function as a single point-to-point PW. This architecture is described in [RFC5659].
[RFC5254]は、疑似配線の到達範囲を複数のパケット交換ネットワーク（PSN）ドメインに拡張するためのサービスプロバイダーの要件について説明しています。これは、マルチセグメント疑似配線（MS-PW）を使用して実現されます。 MS-PWは、単一のポイントツーポイントPWとして動作し、機能する2つ以上の連続した疑似配線（PW）セグメントのセットとして定義されます。このアーキテクチャは[RFC5659]で説明されています。
The procedures for establishing PWs that extend across a single PSN domain are described in [RFC4447], while procedures for setting up PWs across multiple PSN domains or control plane domains are described in [RFC6073].
単一のPSNドメインにまたがるPWを確立する手順は、[RFC4447]で説明されています。一方、複数のPSNドメインまたはコントロールプレーンドメインでPWを設定する手順は、[RFC6073]で説明されています。
The purpose of this document is to specify extensions to the pseudowire control protocol [RFC4447], and [RFC6073] procedures, to enable multi-segment PWs to be dynamically placed. The procedures follow the guidelines defined in [RFC5036] and enable the reuse of existing TLVs, and procedures defined for Single-Segment Pseudowires (SS-PWs) in [RFC4447]. Dynamic placement of point-to-multipoint (P2MP) PWs is for further study and outside the scope of this document.
このドキュメントの目的は、疑似配線制御プロトコル[RFC4447]と[RFC6073]の手順の拡張を指定して、マルチセグメントPWを動的に配置できるようにすることです。手順は、[RFC5036]で定義されたガイドラインに従い、既存のTLVの再利用を可能にし、[RFC4447]で単一セグメントの疑似配線（SS-PW）に対して定義された手順です。ポイントツーマルチポイント（P2MP）PWの動的配置は、今後の検討のためであり、このドキュメントの範囲外です。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [RFC2119]で説明されているように解釈されます。
[RFC5659] provides terminology for multi-segment pseudowires.
[RFC5659]は、マルチセグメント疑似配線の用語を提供します。
This document defines the following additional terms:
このドキュメントでは、次の追加の用語を定義しています。
- Source Terminating Provider Edge (ST-PE): A Terminating Provider Edge (T-PE) that assumes the active signaling role and initiates the signaling for multi-segment PWs.
- 送信元終端プロバイダーエッジ（ST-PE）：アクティブなシグナリングの役割を引き受け、マルチセグメントPWのシグナリングを開始する終端プロバイダーエッジ（T-PE）。
- Target Terminating Provider Edge (TT-PE): A Terminating Provider Edge (T-PE) that assumes the passive signaling role. It waits and responds to the multi-segment PW signaling message in the reverse direction.
- ターゲット終端プロバイダーエッジ（TT-PE）：パッシブシグナリングの役割を担う終端プロバイダーエッジ（T-PE）。それは逆方向のマルチセグメントPWシグナリングメッセージを待機して応答します。
- Forward Direction: ST-PE to TT-PE.
- 順方向：ST-PEからTT-PE。
- Reverse Direction: TT-PE to ST-PE.
- 逆方向：TT-PEからST-PE。
- Pseudowire Routing (PW routing): The dynamic placement of the segments that compose an MS-PW, as well as the automatic selection of Switching PEs (S-PEs).
- 疑似配線ルーティング（PWルーティング）：MS-PWを構成するセグメントの動的配置と、スイッチングPE（S-PE）の自動選択。
The following figure shows the reference model, derived from [RFC5659], to support PW emulated services using multi-segment PWs.
次の図は、[RFC5659]から派生した、マルチセグメントPWを使用して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| | +---+
| |------|...... PW.Seg't 1....X....PW.Seg't 3.......|-------| |
|CE1| | | | | | | | | |CE2|
| |------|...... PW.Seg't 2....X....PW.Seg't 4.......|-------| |
+---+ | | |============| |============| | | +---+
^ +-----+ +-----+ +-----+ ^
| Provider Edge 1 ^ Provider Edge 2 |
| | |
| | |
| PW switching point |
| |
|<-------------------- Emulated Service ------------------>|
Figure 1: MS-PW Reference Model
図1：MS-PW参照モデル
The PEs that provide services to CE1 and CE2 are Terminating PE1 (T-PE1) and Terminating PE2 (T-PE2), respectively. A PSN tunnel extends from T-PE1 to Switching PE1 (S-PE1), and a second PSN tunnel extends from S-PE1 to T-PE2 . PWs are used to connect the attachment circuits (ACs) attached to PE1 to the corresponding ACs attached to T-PE2.
CE1およびCE2にサービスを提供するPEは、それぞれターミネーションPE1（T-PE1）およびターミネーティングPE2（T-PE2）です。 PSNトンネルはT-PE1からスイッチングPE1（S-PE1）に伸び、2番目のPSNトンネルはS-PE1からT-PE2に伸びます。 PWは、PE1に接続されている接続回路（AC）を、T-PE2に接続されている対応するACに接続するために使用されます。
A PW segment on PSN Tunnel 1 is connected to a PW segment on PSN Tunnel 2 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 is referred to as the switching provider edge (S-PE). PW Segment 1 and PW Segment 3 are segments of the same MS-PW, while PW Segment 2 and PW Segment 4 are segments of another MS-PW. PW segments of the same MS-PW (e.g., PW Segment 1 and PW Segment 3) MUST be of the same PW type, and PSN tunnels can be of the same or a different technology. An S-PE switches an MS-PW from one segment to another based on the PW identifiers (PWid, or Attachment Individual Identifier (AII)). How the PW protocol data units (PDUs) are switched at the S-PE depends on the PSN tunnel technology: in the case of a Multiprotocol Label Switching (MPLS) PSN to another MPLS PSN, PW switching involves a standard MPLS label swap operation.
PSNトンネル1のPWセグメントは、S-PE1でPSNトンネル2のPWセグメントに接続され、T-PE1とT-PE2間のマルチセグメントPW（MS-PW）を完了します。したがって、S-PE1はPWスイッチングポイントであり、スイッチングプロバイダーエッジ（S-PE）と呼ばれます。 PWセグメント1とPWセグメント3は同じMS-PWのセグメントであり、PWセグメント2とPWセグメント4は別のMS-PWのセグメントです。同じMS-PWのPWセグメント（たとえば、PWセグメント1とPWセグメント3）は同じPWタイプである必要があり、PSNトンネルは同じまたは異なるテクノロジーである必要があります。 S-PEは、PW識別子（PWid、またはAttachment Individual Identifier（AII））に基づいて、MS-PWをあるセグメントから別のセグメントに切り替えます。 PWプロトコルデータユニット（PDU）がS-PEでどのように切り替えられるかは、PSNトンネルテクノロジーによって異なります。マルチプロトコルラベルスイッチング（MPLS）PSNから別のMPLS PSNへの場合、PWスイッチングには標準のMPLSラベルスワップ操作が含まれます。
Note that although Figure 1 only shows a single S-PE, a PW may transit more than one S-PE along its path. Although [RFC5659] describes MS-PWs that span more than one PSN, this document does not specify how the Label Distribution Protocol (LDP) is used for PW control [RFC4447] in an inter-AS (Autonomous System) environment.
図1は単一のS-PEのみを示していますが、PWはパスに沿って複数のS-PEを通過する場合があることに注意してください。 [RFC5659]は複数のPSNにまたがるMS-PWについて説明していますが、このドキュメントでは、AS間（自律システム）環境でPW制御[RFC4447]にラベル配布プロトコル（LDP）を使用する方法を指定していません。
This document describes the case where the PSNs carrying the MS-PW are only MPLS PSNs using the Generalized Pseudowire Identifier (PWid) Forwarding Equivalence Class (FEC) element (also known as FEC 129).
このドキュメントでは、MS-PWを伝送するPSNが、一般化された疑似配線識別子（PWid）転送等価クラス（FEC）要素（FEC 129とも呼ばれる）を使用するMPLS PSNのみである場合について説明します。
Interactions with an IP PSN using the Layer 2 Tunneling Protocol version 3 (L2TPv3) as described in Section 8 of [RFC6073] are left for further study.
[RFC6073]のセクション8で説明されている、レイヤー2トンネリングプロトコルバージョン3（L2TPv3）を使用したIP PSNとの相互作用は、今後の検討課題として残されています。
The procedures described in this document make use of existing LDP TLVs and related PW signaling procedures described in [RFC4447] and [RFC6073]. The following optional TLV is also defined:
このドキュメントで説明されている手順は、既存のLDP TLVと、[RFC4447]および[RFC6073]で説明されている関連するPWシグナリング手順を利用しています。次のオプションのTLVも定義されています。
- A Bandwidth TLV to address QoS Signaling requirements (see Section 4.2).
- QoSシグナリング要件に対処するための帯域幅TLV（セクション4.2を参照）。
This document also updates the value of the Length field of the PW Switching Point PE Sub-TLV Type 0x06 to 14.
このドキュメントでは、PWスイッチングポイントPEサブTLVタイプ0x06の長さフィールドの値も14に更新されています。
Single-segment pseudowires on an MPLS PSN can use attachment circuit identifiers for a PW using FEC 129. In the case of a dynamically placed MS-PW, there is a requirement for the attachment circuit identifiers to be globally unique, for the purposes of reachability and manageability of the PW. Referencing Figure 1 above, individual globally unique addresses MUST be allocated to all the ACs and S-PEs of an MS-PW.
MPLS PSNの単一セグメント疑似配線は、FEC 129を使用してPWの接続回路識別子を使用できます。動的に配置されたMS-PWの場合、到達可能性のために、接続回路識別子はグローバルに一意である必要があります。 PWの管理性。上記の図1を参照して、MS-PWのすべてのACおよびS-PEに個別のグローバルに一意のアドレスを割り当てる必要があります。
The attachment circuit addressing is derived from AII Type 2 [RFC5003], as shown here:
接続回線のアドレス指定は、次に示すように、AIIタイプ2 [RFC5003]から派生しています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AII Type=02 | Length | Global ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Global ID (continued) | Prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix (continued) | AC ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AC ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: AII Type 2 TLV Structure
図2：AIIタイプ2 TLV構造
The fields are defined in Section 3.2 of [RFC5003].
フィールドは、[RFC5003]のセクション3.2で定義されています。
Addressing schemes based on AII Type 2 permit varying levels of AII summarization, thus reducing the scaling burden on PW routing. PW addressing based on AII Type 2 is suitable for point-to-point provisioning models where auto-discovery of the address at the TT-PE is not required. That is, it is known a priori by provisioning.
AIIタイプ2に基づくアドレッシング方式では、さまざまなレベルのAII要約が可能であるため、PWルーティングのスケーリングの負担が軽減されます。 AIIタイプ2に基づくPWアドレッシングは、TT-PEでのアドレスの自動検出が不要なポイントツーポイントプロビジョニングモデルに適しています。つまり、プロビジョニングによってアプリオリに知られています。
Implementations of the following procedure MUST interpret the AII type to determine the meaning of the address format of the AII, irrespective of the number of segments in the MS-PW. All segments of the PW MUST be signaled with the same AII type.
次の手順の実装は、MS-PW内のセグメントの数に関係なく、AIIタイプを解釈してAIIのアドレス形式の意味を決定する必要があります。 PWのすべてのセグメントは、同じAIIタイプでシグナリングされる必要があります。
A unique combination of Global ID, Prefix, and AC ID parts of the AII Type 2 are assigned to each AC. In general, the same Global ID and Prefix are be assigned for all ACs belonging to the same T-PE. This is not a strict requirement, however. A particular T-PE might have more than one Prefix assigned to it, and likewise a fully qualified AII with the same Global ID/Prefix but different AC IDs might belong to different T-PEs.
AIIタイプ2のグローバルID、プレフィックス、AC IDの部分の一意の組み合わせが各ACに割り当てられます。通常、同じT-PEに属するすべてのACには、同じグローバルIDとプレフィックスが割り当てられます。ただし、これは厳密な要件ではありません。特定のT-PEには複数のプレフィックスが割り当てられている場合があります。同様に、同じグローバルID /プレフィックスを持つ完全修飾AIIが、異なるAC IDが異なるT-PEに属している場合があります。
For the purpose of MS-PWs, the AII MUST be globally unique across all PSNs that are spanned by the MS-PW.
MS-PWの目的のために、AIIは、MS-PWがまたがるすべてのPSNにわたってグローバルに一意である必要があります。
The AII for a local attachment circuit of a given T-PE of an MS-PW and the AII of the corresponding attachment circuit on a far-end T-PE (with respect to the LDP signaling) are known as the Source Attachment Individual Identifier (SAII) and Target Attachment Individual Identifier (TAII) as per [RFC6074].
MS-PWの特定のT-PEのローカル接続回線のAII、および（LDPシグナリングに関して）遠端T-PEの対応する接続回線のAIIは、ソース接続個別識別子として知られています。 （SAII）および[RFC6074]に基づくターゲット添付ファイル個別識別子（TAII）。
Each S-PE MUST be assigned an address that uniquely identifies it from a pseudowire perspective, in order to populate the PW Switching Point PE (SP-PE) TLV specified in [RFC6073]. For this purpose, at least one Attachment Identifier (AI) address of the format similar to AII Type 2 [RFC5003] composed of the Global ID, and Prefix part, only, MUST be assigned to each S-PE.
[RFC6073]で指定されたPWスイッチングポイントPE（SP-PE）TLVに入力するために、各S-PEには、疑似配線の観点から一意に識別するアドレスを割り当てる必要があります。この目的のために、グローバルIDとプレフィックス部分のみで構成されるAIIタイプ2 [RFC5003]に類似した形式の少なくとも1つのAttachment Identifier（AI）アドレスを各S-PEに割り当てる必要があります。
If an S-PE is capable of dynamic MS-PW signaling but is not assigned with an S-PE address, then on receiving a dynamic MS-PW Label Mapping message the S-PE MUST return a Label Release with the "Resources Unavailable" (0x38) status code.
S-PEが動的MS-PWシグナリングに対応しているが、S-PEアドレスが割り当てられていない場合、S-PEは動的MS-PWラベルマッピングメッセージを受信すると、「リソース利用不可」のラベルリリースを返さなければなりません（MUST）。 （0x38）ステータスコード。
[RFC6073] describes a procedure for concatenating multiple pseudowires together. This procedure requires each S-PE to be manually configured with the information required for each segment of the MS-PW. The procedures in the following sections describe a method to extend [RFC6073] by allowing the automatic selection of predefined S-PEs and dynamically establishing an MS-PW between two T-PEs.
[RFC6073]は、複数の疑似配線を連結する手順を説明しています。この手順では、MS-PWの各セグメントに必要な情報を使用して、各S-PEを手動で構成する必要があります。次のセクションの手順では、事前定義されたS-PEの自動選択を許可し、2つのT-PE間にMS-PWを動的に確立することで[RFC6073]を拡張する方法について説明します。
The AII Type 2 described above contains a Global ID, Prefix, and AC ID. The TAII is used by S-PEs to determine the next SS-PW destination for LDP signaling.
上記のAIIタイプ2には、グローバルID、プレフィックス、およびAC IDが含まれています。 TAIIは、S-PEがLDPシグナリングの次のSS-PW宛先を決定するために使用します。
Once an S-PE receives an MS-PW Label Mapping message containing a TAII with an AII that is not locally present, the S-PE performs a lookup in a PW AII routing table. If this lookup results in an IP address for the next-hop PE with reachability information for the AII in question, then the S-PE will initiate the necessary LDP messaging procedure to set up the next PW segment. If the PW AII routing table lookup does not result in an IP address for a next-hop PE, the destination AII has become unreachable, and the PW setup MUST fail. In this case, the next PW segment is considered unprovisioned, and a Label Release MUST be returned to the T-PE with a status message of "AII Unreachable".
S-PEが、ローカルに存在しないAIIを持つTAIIを含むMS-PWラベルマッピングメッセージを受信すると、S-PEはPW AIIルーティングテーブルでルックアップを実行します。このルックアップの結果、問題のAIIの到達可能性情報を含むネクストホップPEのIPアドレスになる場合、S-PEは次のPWセグメントをセットアップするために必要なLDPメッセージング手順を開始します。 PW AIIルーティングテーブルのルックアップでネクストホップPEのIPアドレスが生成されない場合、宛先AIIが到達不能になり、PWセットアップは失敗する必要があります。この場合、次のPWセグメントはプロビジョニングされていないと見なされ、「AII Unreachable」のステータスメッセージとともにラベルリリースをT-PEに返す必要があります。
If the TAII of an MS-PW Label Mapping message received by a PE contains the Prefix matching the locally provisioned prefix on that PE but an AC ID that is not provisioned, then the LDP liberal label retention procedures apply, and the Label Mapping message is retained.
PEが受信したMS-PWラベルマッピングメッセージのTAIIに、そのPEでローカルにプロビジョニングされたプレフィックスと一致するプレフィックスが含まれているが、プロビジョニングされていないAC IDである場合、LDPリベラルラベル保持手順が適用され、ラベルマッピングメッセージは次のようになります。保持。
To allow for dynamic end-to-end signaling of MS-PWs, information MUST be present in S-PEs to support the determination of the next PW signaling hop. Such information can be provisioned (equivalent to a static route) on each S-PE, or disseminated via regular routing protocols (e.g., BGP).
MS-PWの動的なエンドツーエンドシグナリングを可能にするために、次のPWシグナリングホップの決定をサポートする情報がS-PEに存在する必要があります。このような情報は、各S-PEでプロビジョニング（静的ルートに相当）するか、通常のルーティングプロトコル（BGPなど）を介して配布できます。
All PEs capable of dynamic MS-PW path selection MUST build a PW AII routing table to be used for PW next-hop selection.
動的MS-PWパス選択が可能なすべてのPEは、PWネクストホップ選択に使用されるPW AIIルーティングテーブルを構築する必要があります。
The PW addressing scheme (AII Type 2 as defined in [RFC5003]) consists of a Global ID, a 32-bit Prefix, and a 32-bit Attachment Circuit ID.
PWアドレス指定スキーム（[RFC5003]で定義されているAIIタイプ2）は、グローバルID、32ビットのプレフィックス、および32ビットの接続回路IDで構成されています。
An aggregation scheme similar to that used for classless IPv4 addresses can be employed. A length mask (8 bits) is specified as a number ranging from 0 to 96 that indicates which Most Significant Bits (MSBs) are relevant in the address field when performing the PW address-matching algorithm.
クラスレスIPv4アドレスに使用されるのと同様の集約方式を使用できます。長さマスク（8ビット）は、0〜96の範囲の数値として指定され、PWアドレスマッチングアルゴリズムの実行時にアドレスフィールドで関連する最上位ビット（MSB）を示します。
0 31 32 63 64 95 (bits)
+-----------+--------+--------+
| Global ID | Prefix | AC ID |
+-----------+--------+--------+
Figure 3: PW Addressing Scheme
図3：PWアドレス指定スキーム
During the signaling phase, the content of the (fully qualified) TAII Type 2 field from the FEC 129 TLV is compared against routes from the PW routing table. Similar to the IPv4 case, the route with the longest match is selected, determining the next signaling hop and implicitly the next PW segment to be signaled.
シグナリングフェーズ中に、FEC 129 TLVの（完全修飾）TAIIタイプ2フィールドの内容が、PWルーティングテーブルのルートと比較されます。 IPv4の場合と同様に、最長一致のルートが選択され、次のシグナリングホップが決定され、暗黙的にシグナリングされる次のPWセグメントが決定されます。
For the purpose of determining the next signaling hop for a segment of the pseudowire, the PEs MAY be provisioned with fixed-route entries in the PW next-hop routing table. The static PW entries will follow all the addressing rules and aggregation rules described in the previous sections. The most common use of PW static provisioned routes is this example of the "default" route entry as follows:
疑似配線のセグメントの次のシグナリングホップを決定するために、PEには、PWネクストホップルーティングテーブルの固定ルートエントリをプロビジョニングできます。静的PWエントリは、前のセクションで説明したすべてのアドレッシングルールと集約ルールに従います。 PW静的プロビジョニングされたルートの最も一般的な使用は、次の「デフォルト」ルートエントリのこの例です。
Global ID = 0 Prefix = 0 AC ID = 0, Prefix Length = 0
Next Signaling Hop = {IP Address of next-hop S-PE or T-PE}
Any suitable routing protocol capable of carrying external routing information MAY be used to propagate MS-PW path information among S-PEs and T-PEs. However, T-PEs and S-PEs MAY choose to use the Border Gateway Protocol (BGP) [RFC4271] with the Multiprotocol Extensions as defined in [RFC4760] to propagate PW address information throughout the PSN. PW address information is only propagated by PEs that are capable of PW switching. Therefore, the multiprotocol BGP neighbor topology MUST coincide with the topology of T-PEs and S-PEs.
外部ルーティング情報を伝送できる適切なルーティングプロトコルを使用して、S-PEとT-PE間でMS-PWパス情報を伝播できます。ただし、T-PEとS-PEは、[RFC4760]で定義されているマルチプロトコル拡張を備えたボーダーゲートウェイプロトコル（BGP）[RFC4271]を使用して、PSN全体にPWアドレス情報を伝播することを選択できます（MAY）。 PWアドレス情報は、PWスイッチングが可能なPEによってのみ伝達されます。したがって、マルチプロトコルBGPネイバートポロジは、T-PEおよびS-PEのトポロジと一致する必要があります。
Contrary to Layer 2 VPN signaling methods that use BGP for auto-discovery [RFC6074], in the case of the dynamically placed MS-PW, the source T-PE knows a priori (by provisioning) the AC ID on the terminating T-PE that signaling should use. Hence, there is no need to advertise a "fully qualified" 96-bit address on a per-PW attachment circuit basis. Only the T-PE Global ID, Prefix, and prefix length need to be advertised as part of well-known BGP procedures; see [RFC4760].
自動検出にBGPを使用するレイヤー2 VPNシグナリング方法[RFC6074]とは対照的に、動的に配置されたMS-PWの場合、ソースT-PEは、終端T-PEのAC IDを（プロビジョニングすることにより）アプリオリに認識します。そのシグナリングが使用する必要があります。したがって、PW接続回路ごとに「完全修飾」96ビットアドレスをアドバタイズする必要はありません。 T-PEグローバルID、プレフィックス、およびプレフィックス長のみが、既知のBGP手順の一部として通知される必要があります。 [RFC4760]を参照してください。
Since PW Endpoints are provisioned in the T-PEs, the ST-PE will use this information to obtain the first S-PE hop (i.e., first BGP next hop) to where the first PW segment will be established. Any subsequent S-PEs will use the same information (i.e., the next BGP next hop(s)) to obtain the next signaling hop(s) on the path to the TT-PE.
PWエンドポイントはT-PEでプロビジョニングされるため、ST-PEはこの情報を使用して、最初のPWセグメントが確立される最初のS-PEホップ（つまり、最初のBGPネクストホップ）を取得します。後続のS-PEは同じ情報（つまり、次のBGPネクストホップ）を使用して、TT-PEへのパス上の次のシグナリングホップを取得します。
The PW dynamic path Network Layer Reachability Information (NLRI) is advertised in BGP UPDATE messages using the MP_REACH_NLRI and MP_UNREACH_NLRI attributes [RFC4760]. The {AFI, SAFI} value pair used to identify this NLRI is (AFI=25, SAFI=6). A route target MAY also be advertised along with the NLRI.
PW動的パスネットワーク層到達可能性情報（NLRI）は、MP_REACH_NLRIおよびMP_UNREACH_NLRI属性[RFC4760]を使用してBGP UPDATEメッセージでアドバタイズされます。このNLRIを識別するために使用される{AFI、SAFI}値のペアは（AFI = 25、SAFI = 6）です。ルートターゲットもNLRIとともにアドバタイズされる場合があります。
The Next Hop field of the MP_REACH_NLRI attribute SHALL be interpreted as an IPv4 address whenever the length of the NextHop address is 4 octets, and as an IPv6 address whenever the length of the NextHop address is 16 octets.
MP_REACH_NLRI属性のNext Hopフィールドは、NextHopアドレスの長さが4オクテットの場合は常にIPv4アドレスとして解釈され、NextHopアドレスの長さが16オクテットの場合は常にIPv6アドレスとして解釈される必要があります。
The NLRI field in the MP_REACH_NLRI and MP_UNREACH_NLRI is a prefix comprising an 8-octet Route Distinguisher, the Global ID, the Prefix, and the AC ID, and encoded as defined in Section 4 of [RFC4760].
MP_REACH_NLRIおよびMP_UNREACH_NLRIのNLRIフィールドは、8オクテットのルート識別子、グローバルID、プレフィックス、AC IDで構成されるプレフィックスであり、[RFC4760]のセクション4で定義されているようにエンコードされます。
This NLRI is structured as follows:
このNLRIは次のように構成されています。
Bit
0 7 8 71 72 103 104 135 136 167
+------+----------------+-----------+--------+--------+
|Length| Route Dist | Global ID | Prefix | AC ID |
+------+----------------+-----------+--------+--------+
Figure 4: NLRI Field Structure
図4：NLRIフィールドの構造
The Length field is the prefix length of the Route Distinguisher + Global ID + Prefix + AC ID in bits.
長さフィールドは、ビットのルート識別子+グローバルID +プレフィックス+ AC IDのプレフィックス長です。
Except for the default PW route, which is encoded as a 0-length Prefix, the minimum value of the Length field is 96 bits. Lengths of 128 bits to 159 bits are invalid, as the AC ID field cannot be aggregated. The maximum value of the Length field is 160 bits. BGP advertisements received with invalid Prefix lengths MUST be rejected as having a bad packet format.
長さ0のプレフィックスとしてエンコードされるデフォルトのPWルートを除いて、長さフィールドの最小値は96ビットです。 AC IDフィールドは集約できないため、128ビットから159ビットの長さは無効です。長さフィールドの最大値は160ビットです。無効なプレフィックス長で受信されたBGPアドバタイズメントは、不正なパケットフォーマットを持つものとして拒否される必要があります。
The LDP signaling procedures are described in [RFC4447] and expanded in [RFC6073]. No new LDP signaling components are required for setting up a dynamically placed MS-PW. However, some optional signaling extensions are described below.
LDPシグナリング手順は[RFC4447]で説明され、[RFC6073]で拡張されています。動的に配置されたMS-PWをセットアップするために、新しいLDPシグナリングコンポーネントは必要ありません。ただし、オプションのシグナリング拡張の一部を以下で説明します。
One of the requirements that MUST be met in order to achieve the QoS objectives for a PW on a segment is that a PSN tunnel MUST be selected that can support at least the required class of service and that has sufficient bandwidth available.
セグメント上のPWのQoS目標を達成するために満たさなければならない要件の1つは、少なくとも必要なサービスクラスをサポートでき、十分な帯域幅を利用できるPSNトンネルを選択する必要があることです。
Such PSN tunnel selection can be achieved where the next hop for a PW segment is explicitly configured at each PE, whether the PE is a T-PE or an S-PE in the case of a segmented PW, without dynamic path selection (as per [RFC6073]). In these cases, it is possible to explicitly configure the bandwidth required for a PW so that the T-PE or S-PE can reserve that bandwidth on the PSN tunnel.
このようなPSNトンネルの選択は、PWセグメントのネクストホップが各PEで明示的に構成されている場合に実現できます。PEがセグメント化されたPWの場合、T-PEかS-PEかにかかわらず、動的パス選択はありません（ [RFC6073]）。これらの場合、PWに必要な帯域幅を明示的に構成して、T-PEまたはS-PEがPSNトンネルでその帯域幅を予約できるようにすることができます。
Where dynamic path selection is used and the next hop is therefore not explicitly configured by the operator at the S-PE, a mechanism to signal the bandwidth for the PW from the T-PE to the S-PEs is required. This is accomplished by including an optional PW Bandwidth TLV. The PW Bandwidth TLV is specified as follows:
動的パス選択が使用され、したがってネクストホップがS-PEでオペレーターによって明示的に構成されていない場合、T-PEからS-PEへのPWの帯域幅を通知するメカニズムが必要です。これは、オプションのPW帯域幅TLVを含めることによって実現されます。 PW帯域幅TLVは次のように指定されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|0| PW BW TLV (0x096E) | TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Forward SENDER_TSPEC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reverse SENDER_TSPEC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: PW Bandwidth TLV Structure
図5：PW帯域幅TLV構造
The PW Bandwidth TLV fields are as follows:
PW Bandwidth TLVフィールドは次のとおりです。
- TLV Length: The length of the value fields in octets. Value = 64.
- TLV長：オクテット単位の値フィールドの長さ。値= 64。
- Forward SENDER_TSPEC = the SENDER_TSPEC for the forward direction of the PW, as defined in Section 3.1 of [RFC2210].
- Forward SENDER_TSPEC = [RFC2210]のセクション3.1で定義されている、PWの順方向のSENDER_TSPEC。
- Reverse SENDER_TSPEC = the SENDER_TSPEC for the reverse direction of the PW, as defined in Section 3.1 of [RFC2210].
- 逆SENDER_TSPEC = [RFC2210]のセクション3.1で定義されている、PWの逆方向のSENDER_TSPEC。
The complete definitions of the content of the SENDER_TSPEC objects are found in Section 3.1 of [RFC2210]. The forward SENDER_TSPEC refers to the data path in the direction ST-PE to TT-PE. The reverse SENDER_TSPEC refers to the data path in the direction TT-PE to ST-PE.
SENDER_TSPECオブジェクトのコンテンツの完全な定義は、[RFC2210]のセクション3.1にあります。フォワードSENDER_TSPECは、ST-PEからTT-PEへの方向のデータパスを参照します。逆のSENDER_TSPECは、TT-PEからST-PEへの方向のデータパスを指します。
In the forward direction, after a next-hop selection is determined, a T/S-PE SHOULD reference the forward SENDER_TSPEC object to determine an appropriate PSN tunnel towards the next signaling hop. If such a tunnel exists, the MS-PW signaling procedures are invoked with the inclusion of the PW Bandwidth TLV. When the PE searches for a PSN tunnel, any tunnel that points to a next hop equivalent to the next hop selected will be included in the search (the LDP address TLV is used to determine the next-hop equivalence).
フォワード方向では、ネクストホップの選択が決定された後、T / S-PEは、フォワードSENDER_TSPECオブジェクトを参照して、次のシグナリングホップへの適切なPSNトンネルを決定する必要があります（SHOULD）。そのようなトンネルが存在する場合、MS-PWシグナリング手順は、PW帯域幅TLVを含めて呼び出されます。 PEがPSNトンネルを検索するとき、選択されたネクストホップと同等のネクストホップを指すすべてのトンネルが検索に含まれます（LDPアドレスTLVはネクストホップの同等性を決定するために使用されます）。
When an S/T-PE receives a PW Bandwidth TLV, once the PW next hop is selected, the S/T-PE MUST request the appropriate resources from the PSN. The resources described in the reverse SENDER_TSPEC are allocated from the PSN toward the originator of the message or previous hop. When resources are allocated from the PSN for a specific PW, the allocation SHOULD account for the resource usage of the PW.
S / T-PEがPW帯域幅TLVを受信すると、PWネクストホップが選択されると、S / T-PEはPSNから適切なリソースを要求する必要があります。リバースSENDER_TSPECに記述されているリソースは、PSNからメッセージの発信者または前のホップに向かって割り当てられます。特定のPWのPSNからリソースが割り当てられる場合、割り当てはPWのリソース使用量を考慮してください。
In the case where PSN resources towards the previous hop are not available, the following procedure MUST be followed:
前のホップへのPSNリソースが利用できない場合は、次の手順に従う必要があります。
i. The PSN MAY allocate more QoS resources, e.g., bandwidth, to the PSN tunnel.
i. PSNは、PSNトンネルに帯域幅などのより多くのQoSリソースを割り当てることができます。
ii. The S-PE MAY attempt to set up another PSN tunnel to accommodate the new PW QoS requirements.
ii。 S-PEは、新しいPW QoS要件に対応するために別のPSNトンネルをセットアップしようとする場合があります。
iii. If the S-PE cannot get enough resources to set up the segment in the MS-PW, a Label Release MUST be returned to the previous hop with a status message of "Bandwidth resources unavailable".
iii。 S-PEがMS-PWでセグメントを設定するのに十分なリソースを取得できない場合は、「帯域幅リソースを利用できません」というステータスメッセージとともにラベルリリースを前のホップに返さなければなりません（MUST）。
In the latter case, the T-PE receiving the status message MUST also withdraw the corresponding PW Label Mapping message for the opposite direction if it has already been successfully set up.
後者の場合、ステータスメッセージを受信したT-PEは、すでに正常に設定されている場合、反対方向の対応するPWラベルマッピングメッセージも取り消す必要があります。
If an ST-PE receives a Label Mapping message, the following procedure MUST be followed:
ST-PEがラベルマッピングメッセージを受信した場合、次の手順に従う必要があります。
If the ST-PE has already sent a Label Mapping message for this PW, then the ST-PE MUST check to see if this Label Mapping message originated from the same LDP peer to which the corresponding Label Mapping message for this particular PW was sent. If it is the same peer, the PW is established. If it is a different peer, then the ST-PE MUST send a Label Release message with a status code of "PW Loop Detected" to the PE that originated the LDP Label Mapping message.
ST-PEがこのPWのラベルマッピングメッセージをすでに送信している場合、ST-PEは、このラベルマッピングメッセージがこの特定のPWの対応するラベルマッピングメッセージが送信された同じLDPピアから発信されたかどうかを確認する必要があります。同じピアの場合、PWが確立されます。それが異なるピアである場合、ST-PEは、LDPラベルマッピングメッセージを発信したPEに、ステータスコード「PWループが検出されました」を含むラベル解放メッセージを送信する必要があります。
If the PE has not yet sent a Label Mapping message for this particular PW, then it MUST send the Label Mapping message to this LDP peer, regardless of what the PW TAII routing lookup result is.
PEがこの特定のPWのラベルマッピングメッセージをまだ送信していない場合は、PW TAIIルーティングルックアップの結果に関係なく、ラベルマッピングメッセージをこのLDPピアに送信する必要があります。
A next-hop selection for a specific PW may find a match with a PW route that has multiple next hops associated with it. Multiple next hops may be either configured explicitly as static routes or learned through BGP routing procedures. Implementations at an S-PE or T-PE MAY use selection algorithms, such as CRC32 on the FEC TLV or flow-aware transport of PWs [RFC6391], for load balancing of PWs across multiple next hops, so that each PW has a single next hop. The details of such selection algorithms are outside the scope of this document.
特定のPWのネクストホップを選択すると、複数のネクストホップが関連付けられているPWルートとの一致が見つかる場合があります。複数のネクストホップは、静的ルートとして明示的に構成するか、BGPルーティング手順を通じて学習することができます。 S-PEまたはT-PEでの実装では、FEC TLVのCRC32またはPWのフロー対応トランスポート[RFC6391]などの選択アルゴリズムを使用して、複数のネクストホップ間でPWのロードバランシングを行い、各PWに単一のネクストホップ。そのような選択アルゴリズムの詳細は、このドキュメントの範囲外です。
When an MS-PW is signaled, each T-PE might independently initiate signaling the MS-PW. This could result in a different path being used by each direction of the PW. To avoid this situation, one T-PE MUST initiate PW signaling (i.e., take an active role), while the other T-PE waits to receive the LDP Label Mapping message before sending the LDP Label Mapping message for the reverse direction of the PW (i.e., take a passive role). The active T-PE (the ST-PE) and the passive T-PE (the TT-PE) MUST be identified before signaling begins for a given MS-PW. Both T-PEs MUST use the same method for identifying which is active and which is passive.
MS-PWがシグナリングされると、各T-PEは独立してMS-PWのシグナリングを開始します。これにより、PWの各方向で異なるパスが使用される可能性があります。この状況を回避するには、1つのT-PEがPWシグナリングを開始する（つまり、アクティブな役割を担う）必要がありますが、他のT-PEは、LDPラベルマッピングメッセージの受信を待ってから、PWの逆方向のLDPラベルマッピングメッセージを送信します。 （つまり、受動的な役割を果たします）。アクティブなT-PE（ST-PE）とパッシブT-PE（TT-PE）は、特定のMS-PWのシグナリングが始まる前に識別されなければなりません。両方のT-PEは、どちらがアクティブでどれがパッシブであるかを識別するために同じ方法を使用する必要があります。
A T-PE SHOULD determine whether it assumes the active role or the passive role using procedures similar to those of [RFC5036], Section 2.5.2, Bullet 2. The T-PE compares the Source Attachment Individual Identifier (SAII) [RFC6074] with the Target Attachment Individual Identifier (TAII) [RFC6074] as unsigned integers, and if the SAII > TAII, the T-PE assumes the active role. Otherwise, it assumes the passive role.
T-PEは、[RFC5036]、セクション2.5.2、箇条書き2と同様の手順を使用して、アクティブな役割またはパッシブな役割を引き受けるかどうかを決定する必要があります。T-PEは、ソース添付ファイル個別識別子（SAII）を比較します[RFC6074]ターゲット添付ファイル個別識別子（TAII）[RFC6074]を符号なし整数として使用し、SAII> TAIIの場合、T-PEがアクティブな役割を引き受けます。それ以外の場合は、受動的な役割を担います。
The following procedure for comparing the SAII and TAII as unsigned integers SHOULD be used:
符号なし整数としてSAIIとTAIIを比較するには、次の手順を使用する必要があります（SHOULD）。
- If the SAII Global ID > TAII Global ID, then the T-PE is active
- SAIIグローバルID> TAIIグローバルIDの場合、T-PEはアクティブです
- else if the SAII Global ID < TAII Global ID, then the T-PE is passive
- それ以外の場合、SAIIグローバルID <TAIIグローバルIDの場合、T-PEはパッシブです
- else if the SAII Prefix > TAII Prefix, then the T-PE is active
- それ以外の場合、SAIIプレフィックス> TAIIプレフィックスの場合、T-PEはアクティブです。
- else if the SAII Prefix < TAII Prefix, then the T-PE is passive
- それ以外の場合、SAIIプレフィックス<TAIIプレフィックスの場合、T-PEはパッシブです
- else if the SAII AC ID > TAII AC ID, then the T-PE is active
- それ以外の場合、SAII AC ID> TAII AC IDの場合、T-PEはアクティブです
- else if the SAII AC ID < TAII AC ID, then the T-PE is passive
- それ以外の場合、SAII AC ID <TAII AC IDの場合、T-PEはパッシブです
- else there is a configuration error
- それ以外の場合、構成エラーがあります
On receiving a Label Mapping message, the S-PE MUST inspect the FEC TLV. If the receiving node has no local AII matching the TAII for that Label Mapping message, then the Label Mapping message SHOULD be forwarded on to another S-PE or T-PE. The S-PE will check to see if the FEC is already installed for the forward direction:
ラベルマッピングメッセージを受信すると、S-PEはFEC TLVを検査する必要があります。受信ノードに、そのラベルマッピングメッセージのTAIIと一致するローカルAIIがない場合、ラベルマッピングメッセージは別のS-PEまたはT-PEに転送する必要があります（SHOULD）。 S-PEは、FECがすでに順方向にインストールされているかどうかを確認します。
- If the FEC is already installed and the received Label Mapping was received from the same LDP peer to which the forward LDP Label Mapping was sent, then this Label Mapping represents signaling in the reverse direction for this MS-PW segment.
- FECがすでにインストールされており、受信したラベルマッピングが、フォワードLDPラベルマッピングの送信先と同じLDPピアから受信された場合、このラベルマッピングは、このMS-PWセグメントの逆方向のシグナリングを表します。
- If the FEC is already installed and the received Label Mapping was received from a different LDP peer to which the forward LDP Label Mapping was sent, then the received Label Mapping MUST be released with a status code of "PW Loop Detected".
- FECが既にインストールされており、受信したラベルマッピングが、転送LDPラベルマッピングの送信先である別のLDPピアから受信された場合、受信したラベルマッピングは、「PWループ検出」のステータスコードで解放する必要があります。
- If the FEC is not already installed, then this represents signaling in the forward direction.
- FECがまだインストールされていない場合、これは順方向のシグナリングを表します。
The following procedures are then executed, depending on whether the Label Mapping was determined to be for the forward or the reverse direction of the MS-PW.
その後、ラベルマッピングがMS-PWの順方向または逆方向のどちらであると判断されたかに応じて、次の手順が実行されます。
For the forward direction:
順方向の場合：
i. Determine the next-hop S-PE or T-PE according to the procedures above. If next-hop reachability is not found in the S-PE's PW AII routing table, then a Label Release MUST be sent with status code "AII Unreachable". If the next-hop S-PE or T-PE is found and is the same LDP peer that sent the Label Mapping message, then a Label Release MUST be returned with status code "PW Loop Detected". If the SAII in the received Label Mapping is local to the S-PE, then a Label Release MUST be returned with status code "PW Loop Detected".
i. 上記の手順に従って、ネクストホップS-PEまたはT-PEを決定します。 S-PEのPW AIIルーティングテーブルにネクストホップ到達可能性が見つからない場合、ステータスコード「AII Unreachable」とともにラベルリリースを送信する必要があります。ネクストホップS-PEまたはT-PEが見つかり、ラベルマッピングメッセージを送信したのと同じLDPピアである場合、ラベルリリースはステータスコード「PWループが検出されました」とともに返される必要があります。受信したラベルマッピングのSAIIがS-PEに対してローカルである場合、ステータスコード「PWループが検出されました」とともにラベルリリースを返す必要があります。
ii. Check to see if a PSN tunnel exists to the next-hop S-PE or T-PE. If no tunnel exists to the next-hop S-PE or T-PE, the S-PE MAY attempt to set up a PSN tunnel.
ii。ネクストホップS-PEまたはT-PEへのPSNトンネルが存在するかどうかを確認します。ネクストホップS-PEまたはT-PEへのトンネルが存在しない場合、S-PEはPSNトンネルのセットアップを試行する場合があります。
iii. Check to see if a PSN tunnel exists to the previous hop. If no tunnel exists to the previous-hop S-PE or T-PE, the S-PE MAY attempt to set up a PSN tunnel.
iii。前のホップへのPSNトンネルが存在するかどうかを確認します。前のホップのS-PEまたはT-PEへのトンネルが存在しない場合、S-PEはPSNトンネルのセットアップを試行してもよい（MAY）。
iv. If the S-PE cannot get enough PSN resources to set up the segment to the next-hop or previous-hop S-PE or T-PE, a Label Release MUST be returned to the T-PE with a status message of "Resources Unavailable".
iv。 S-PEが次のホップまたは前のホップのS-PEまたはT-PEにセグメントを設定するのに十分なPSNリソースを取得できない場合、「リソース」というステータスメッセージでラベルリリースをT-PEに返す必要があります。利用できません。」
v. If the Label Mapping message contains a Bandwidth TLV, allocate the required resources on the PSN tunnels in the forward and reverse directions according to the procedures above.
v. ラベルマッピングメッセージに帯域幅TLVが含まれている場合は、上記の手順に従って、必要なリソースをPSNトンネルに順方向および逆方向に割り当てます。
vi. Allocate a new PW label for the forward direction.
vi。順方向の新しいPWラベルを割り当てます。
vii. Install the FEC for the forward direction.
vii。順方向のFECをインストールします。
viii. Send the Label Mapping message with the new forward label and the FEC to the next-hop S-PE/T-PE.
viii。新しい転送ラベルとFECを含むラベルマッピングメッセージをネクストホップS-PE / T-PEに送信します。
For the reverse direction:
逆方向の場合：
i. Install the FEC received in the Label Mapping message for the reverse direction.
i. 逆方向のラベルマッピングメッセージで受信したFECをインストールします。
ii. Determine the next signaling hop by referencing the LDP sessions used to set up the PW in the forward direction.
ii。フォワード方向でPWを設定するために使用されるLDPセッションを参照して、次のシグナリングホップを決定します。
iii. Allocate a new PW label for the next hop in the reverse direction.
iii。逆方向のネクストホップに新しいPWラベルを割り当てます。
iv. Install the FEC for the next hop in the reverse direction.
iv。ネクストホップ用のFECを逆方向にインストールします。
v. Send the Label Mapping message with a new label and the FEC to the next-hop S-PE/ST-PE.
v. 新しいラベルとFECを含むラベルマッピングメッセージをネクストホップS-PE / ST-PEに送信します。
Failures of the PSN tunnel MUST be handled by PSN mechanisms. An example of such a PSN mechanism is MPLS fast reroute [RFC4090]. If the PSN is unable to re-establish the PSN tunnel, then the S-PE SHOULD follow the procedures defined in Section 10 of [RFC6073].
PSNトンネルの障害は、PSNメカニズムで処理する必要があります。このようなPSNメカニズムの例は、MPLS高速リルート[RFC4090]です。 PSNがPSNトンネルを再確立できない場合、S-PEは[RFC6073]のセクション10で定義されている手順に従う必要があります。
For defects in an S-PE, the procedures defined in [RFC6073] SHOULD be followed. A T-PE or S-PE may receive an unsolicited Label Release message from another S-PE or T-PE with various failure codes, such as "Loop Detected", "PW Loop Detected", "Resources Unavailable", "Bad Strict Node Error", or "AII Unreachable". All these failure codes indicate a generic class of PW failures at an S-PE or T-PE.
S-PEの欠陥については、[RFC6073]で定義されている手順に従う必要があります（SHOULD）。 T-PEまたはS-PEは、「ループが検出されました」、「PWループが検出されました」、「リソースが利用できません」、「厳密な不良」などのさまざまな障害コードとともに、別のS-PEまたはT-PEから非請求ラベル解放メッセージを受信する場合がありますノードエラー」、または「AII到達不能」。これらすべての障害コードは、S-PEまたはT-PEでのPW障害の一般的なクラスを示します。
If an unsolicited Label Release message with such a failure status code is received at a T-PE, then it is RECOMMENDED that the T-PE attempt to re-establish the PW immediately. However, the T-PE MUST throttle its PW setup message retry attempts with an exponential backoff in situations where PW setup messages are being constantly released. It is also RECOMMENDED that a T-PE detecting such a situation take action to notify an operator.
T-PEでこのような障害ステータスコードを含む未承諾のラベル解放メッセージが受信された場合、T-PEがPWをすぐに再確立しようとすることが推奨されます。ただし、PWセットアップメッセージが絶えず解放されている状況では、T-PEは指数バックオフを使用してPWセットアップメッセージの再試行を抑制しなければなりません（MUST）。このような状況を検出したT-PEが、オペレータに通知するためのアクションを実行することも推奨されます。
S-PEs that receive an unsolicited Label Release message with a failure status code SHOULD follow this procedure:
障害ステータスコードを含む未承諾のラベル解放メッセージを受信するS-PEは、次の手順に従う必要があります。
i. If the Label Release is received from an S-PE or T-PE in the forward or reverse signaling direction, then the S-PE MUST tear down both segments of the PW. The status code received in the Label Release message SHOULD be propagated when sending the Label Release for the next segment.
i. ラベル解放がS-PEまたはT-PEから順方向または逆方向のシグナリング方向で受信された場合、S-PEはPWの両方のセグメントを破棄する必要があります。ラベルリリースメッセージで受信したステータスコードは、次のセグメントのラベルリリースを送信するときに伝播する必要があります。
In general, an established MS-PW will not be affected by next-hop changes in AII reachability information.
一般に、確立されたMS-PWは、AII到達可能性情報のネクストホップ変更の影響を受けません。
If there is a next-hop change in AII reachability information in the forward direction, the T-PE MAY elect to tear down the MS-PW by sending a Label Withdraw message to the downstream S-PE or T-PE. The teardown MUST also be accompanied by an unsolicited Label Release message and will be followed by an attempt by the T-PE to re-establish the MS-PW.
順方向のAII到達可能性情報にネクストホップの変更がある場合、T-PEは、Label WithdrawメッセージをダウンストリームS-PEまたはT-PEに送信することにより、MS-PWを破棄することを選択できます（MAY）。ティアダウンには、非送信請求ラベルリリースメッセージも伴う必要があり、その後にT-PEによるMS-PWの再確立の試みが続きます。
If there is a change in the AII reachability information in the forward direction at an S-PE, the S-PE MAY elect to tear down the MS-PW in both directions. A label withdrawal is sent in each direction followed by an unsolicited Label Release. The unsolicited Label Release messages MUST be accompanied by the status code "AII Unreachable". This procedure is OPTIONAL. Note that this procedure is likely to be disruptive to the emulated service. PW Redundancy [RFC6718] MAY be used to maintain the connectivity used by the emulated service in the case of a failure of the PSN or S-PE.
S-PEで順方向のAII到達可能性情報に変更がある場合、S-PEは両方向でMS-PWを破棄することを選択できます（MAY）。ラベルの引き出しが各方向に送信され、その後、非送信請求ラベルリリースが送信されます。非送信請求ラベルリリースメッセージには、ステータスコード「AII Unreachable」が付随している必要があります。この手順はオプションです。この手順は、エミュレートされたサービスを破壊する可能性が高いことに注意してください。 PW冗長性[RFC6718]は、PSNまたはS-PEに障害が発生した場合に、エミュレートされたサービスによって使用される接続を維持するために使用される場合があります。
A change in AII reachability information in the reverse direction has no effect on an MS-PW.
逆方向のAII到達可能性情報の変更は、MS-PWに影響を与えません。
The OAM procedures defined in [RFC6073] may also be used for dynamically placed MS-PWs. A PW Switching Point PE TLV [RFC6073] is used to record the switching points that the PW traverses.
[RFC6073]で定義されているOAM手順は、動的に配置されたMS-PWにも使用できます。 PWスイッチングポイントPE TLV [RFC6073]は、PWが通過するスイッチングポイントを記録するために使用されます。
In the case of an MS-PW where the PW Endpoints are identified by using globally unique AII addresses based on FEC 129, there is no pseudowire identifier (PWid) defined on a per-segment basis. Each individual PW segment is identified by the address of the adjacent S-PE(s) in conjunction with the SAII and TAII.
PECエンドポイントがFEC 129に基づいてグローバルに一意のAIIアドレスを使用して識別されるMS-PWの場合、セグメントごとに定義された疑似配線識別子（PWid）はありません。個々のPWセグメントは、SAIIおよびTAIIに関連する隣接S-PEのアドレスによって識別されます。
In this case, the following TLV type (0x06) MUST be used in place of type 0x01 in the PW Switching Point PE TLV:
この場合、PWスイッチングポイントPE TLVでタイプ0x01の代わりに次のTLVタイプ（0x06）を使用する必要があります。
Type Length Description
---- ------ -----------------------------------
0x06 14 L2 PW address of PW Switching Point
The above sub-TLV MUST be included in the PW Switching Point PE TLV once per individual PW switching point, following the same rules and procedures as those described in [RFC6073]. A more detailed description of this sub-TLV is also given in Section 7.4.1 of [RFC6073]. However, the length value MUST be set to 14 ([RFC6073] states that the length value is 12, but this does not correctly represent the actual length of the TLV).
上記のサブTLVは、[RFC6073]で説明されているものと同じルールと手順に従って、個々のPWスイッチングポイントごとに1回、PWスイッチングポイントPE TLVに含める必要があります。このサブTLVの詳細な説明は、[RFC6073]のセクション7.4.1にも記載されています。ただし、長さの値は14に設定する必要があります（[RFC6073]は長さの値が12であることを示していますが、これはTLVの実際の長さを正しく表していません）。
This document specifies extensions to the protocols already defined in [RFC4447] and [RFC6073]. The extensions defined in this document do not affect the security considerations for those protocols, but [RFC4447] and [RFC6073] do impose a set of security considerations that are applicable to the protocol extensions specified in this document.
このドキュメントは、[RFC4447]と[RFC6073]ですでに定義されているプロトコルへの拡張を指定します。このドキュメントで定義されている拡張機能は、これらのプロトコルのセキュリティに関する考慮事項に影響を与えませんが、[RFC4447]と[RFC6073]は、このドキュメントで指定されているプロトコル拡張機能に適用される一連のセキュリティに関する考慮事項を課します。
It should be noted that the dynamic path selection mechanisms specified in this document enable the network to automatically select the S-PEs that are used to forward packets on the MS-PW. Appropriate tools, such as the Virtual Circuit Connectivity Verification (VCCV) trace mechanisms specified in [RFC6073], can be used by an operator of the network to verify the path taken by the MS-PW and therefore be satisfied that the path does not represent an additional security risk.
このドキュメントで指定されている動的パス選択メカニズムにより、ネットワークは、MS-PWでパケットを転送するために使用されるS-PEを自動的に選択できるようになります。 [RFC6073]で指定されているVirtual Circuit Connectivity Verification（VCCV）トレースメカニズムなどの適切なツールをネットワークのオペレーターが使用して、MS-PWがたどるパスを確認し、パスが表していないことを確認できます。追加のセキュリティリスク。
Note that the PW control protocol may be used to establish and maintain an MS-PW across administrative boundaries. Section 13 of [RFC6073] specifies security considerations applicable to LDP used in this manner, including considerations for establishing the integrity of, and authenticating, LDP control messages. These considerations also apply to the protocol extensions specified in this document.
PW制御プロトコルを使用して、管理境界を越えてMS-PWを確立および維持できることに注意してください。 [RFC6073]のセクション13は、LDP制御メッセージの整合性を確立し、認証するための考慮事項を含む、この方法で使用されるLDPに適用可能なセキュリティの考慮事項を指定します。これらの考慮事項は、このドキュメントで指定されているプロトコル拡張にも適用されます。
Note that the protocols for dynamically distributing AII reachability information may have their own security considerations. However, those protocol specifications are outside the scope of this document.
AII到達可能性情報を動的に配布するためのプロトコルには、独自のセキュリティ上の考慮事項がある場合があることに注意してください。ただし、これらのプロトコル仕様はこのドキュメントの範囲外です。
IANA has corrected a minor error in the "Pseudowire Switching Point PE sub-TLV Type" registry. The entry 0x06 "L2 PW address of the PW Switching Point" has been corrected to Length 14 and the reference changed to [RFC6073] and this document as follows:
IANAは、「Pseudowire Switching Point PE sub-TLV Type」レジストリのマイナーエラーを修正しました。エントリ0x06「PWスイッチングポイントのL2 PWアドレス」は長さ14に修正され、参照は[RFC6073]に変更され、このドキュメントは次のように変更されました。
Type Length Description Reference
---- ------ ----------------------------------- ------------------
0x06 14 L2 PW Address of PW Switching Point [RFC6073][RFC7267]
This document defines one new LDP TLV type. IANA already maintains a registry for LDP TLV types, called the "TLV Type Name Space" registry, within the "Label Distribution Protocol (LDP) Parameters" registry as defined by [RFC5036]. IANA has assigned the following value.
このドキュメントでは、1つの新しいLDP TLVタイプを定義しています。 IANAは、[RFC5036]で定義されている「Label Distribution Protocol（LDP）Parameters」レジストリ内に、「TLV Type Name Space」レジストリと呼ばれるLDP TLVタイプのレジストリをすでに維持しています。 IANAは次の値を割り当てました。
Value Description Reference Notes/Registration Date
------ ------------- ------------- -----------------------
0x096E Bandwidth TLV This document
This document defines three new LDP status codes. IANA maintains a registry of these codes, called the "Status Code Name Space" registry, in the "Label Distribution Protocol (LDP) Parameters" registry as defined by [RFC5036]. The IANA has assigned the following values.
このドキュメントでは、3つの新しいLDPステータスコードを定義しています。 IANAは、「ステータスコードネームスペース」レジストリと呼ばれるこれらのコードのレジストリを、[RFC5036]で定義されている「ラベル配布プロトコル（LDP）パラメータ」レジストリに維持します。 IANAは次の値を割り当てました。
Range/Value E Description Reference
----------- ----- ------------------------------- -------------
0x00000037 0 Bandwidth resources unavailable This document
0x00000038 0 Resources Unavailable This document
0x00000039 0 AII Unreachable This document
IANA has allocated a new BGP SAFI for "Network Layer Reachability Information used for Dynamic Placement of Multi-Segment Pseudowires" in the IANA "SAFI Values" registry [RFC4760] within the "Subsequent Address Family Identifiers (SAFI) Parameters" registry. The IANA has assigned the following value.
IANAは、「後続のアドレスファミリ識別子（SAFI）パラメータ」レジストリ内のIANA「SAFI値」レジストリ[RFC4760]の「マルチセグメント疑似配線の動的配置に使用されるネットワーク層到達可能性情報」に新しいBGP SAFIを割り当てました。 IANAは次の値を割り当てました。
Value Description Reference
----- ------------------------------------------- -------------
6 Network Layer Reachability Information This document
used for Dynamic Placement of Multi-Segment
Pseudowires
[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月。
[RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated Services", RFC 2210, September 1997.
[RFC2210] Wroclawski、J。、「The Use of RSVP with IETF Integrated Services」、RFC 2210、1997年9月。
[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。、Rosen、E.、El-Aawar、N.、Smith、T.、and G. Heron、 "Pseudowire Setup and Maintenance Using the Label Distribution Protocol（LDP）"、RFC 4447 、2006年4月。
[RFC5003] Metz, C., Martini, L., Balus, F., and J. Sugimoto, "Attachment Individual Identifier (AII) Types for Aggregation", RFC 5003, September 2007.
[RFC5003] Metz、C.、Martini、L.、Balus、F。、およびJ. Sugimoto、「Attachment Individual Identifier（AII）Types for Aggregation」、RFC 5003、2007年9月。
[RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., "LDP Specification", RFC 5036, October 2007.
[RFC5036] Andersson、L.、Ed。、Minei、I.、Ed。、and B. Thomas、Ed。、 "LDP Specification"、RFC 5036、October 2007。
[RFC6073] Martini, L., Metz, C., Nadeau, T., Bocci, M., and M. Aissaoui, "Segmented Pseudowire", RFC 6073, January 2011.
[RFC6073]マティーニ、L。、メス、C。、ナドー、T。、ボッチ、M。、およびM.アイサウイ、「セグメント化された疑似配線」、RFC 6073、2011年1月。
[RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May 2005.
[RFC4090]パン、P。、編、スワロー、G。、編、およびA.アトラス、編、「LSPトンネル用のRSVP-TEへの高速リルート拡張」、RFC 4090、2005年5月。
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4271] Rekhter、Y。、編、Li、T。、編、S。Hares、編、「A Border Gateway Protocol 4（BGP-4）」、RFC 4271、2006年1月。
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, January 2007.
[RFC4760]ベイツ、T。、チャンドラ、R。、カッツ、D。、およびY.レクター、「BGP-4のマルチプロトコル拡張機能」、RFC 4760、2007年1月。
[RFC5254] Bitar, N., Ed., Bocci, M., Ed., and L. Martini, Ed., "Requirements for Multi-Segment Pseudowire Emulation Edge-to-Edge (PWE3)", RFC 5254, October 2008.
[RFC5254] Bitar、N.、Ed。、Bocci、M.、Ed。、and L. Martini、Ed。、 "Requirements for Multi-Segment Pseudowire Emulation Edge-to-Edge（PWE3）"、RFC 5254、October 2008 。
[RFC5659] Bocci, M. and S. Bryant, "An Architecture for Multi-Segment Pseudowire Emulation Edge-to-Edge", RFC 5659, October 2009.
[RFC5659] Bocci、M.およびS. Bryant、「An-Architecture for Multi-Segment Pseudowire Emulation Edge-to-Edge」、RFC 5659、2009年10月。
[RFC6074] Rosen, E., Davie, B., Radoaca, V., and W. Luo, "Provisioning, Auto-Discovery, and Signaling in Layer 2 Virtual Private Networks (L2VPNs)", RFC 6074, January 2011.
[RFC6074]ローゼン、E。、デービー、B。、ラドアカ、V。、およびW.ルオ、「プロビジョニング、自動検出、およびレイヤー2仮想プライベートネットワーク（L2VPN）でのシグナリング」、RFC 6074、2011年1月。
[RFC6391] Bryant, S., Ed., Filsfils, C., Drafz, U., Kompella, V., Regan, J., and S. Amante, "Flow-Aware Transport of Pseudowires over an MPLS Packet Switched Network", RFC 6391, November 2011.
[RFC6391]ブライアント、S。、エド、フィルスフィルス、C。、ドラフズ、U。、コンペラ、V。、リーガン、J。、およびS.アマンテ、「MPLSパケット交換ネットワーク上の疑似配線のフロー対応トランスポート」 、RFC 6391、2011年11月。
[RFC6718] Muley, P., Aissaoui, M., and M. Bocci, "Pseudowire Redundancy", RFC 6718, August 2012.
[RFC6718] Muley、P.、Aissaoui、M。、およびM. Bocci、「Pseudowire Redundancy」、RFC 6718、2012年8月。
The editors gratefully acknowledge the following people for their contributions to this document:
編集者は、このドキュメントへの貢献に対して以下の人々に感謝します。
Nabil Bitar Verizon 40 Sylvan Road Waltham, MA 02145 US
Nabil Bitar Verizon 40 Sylvan Road Waltham、MA 02145 US
EMail: nabil.bitar@verizon.com
Himanshu Shah Ciena Corp. 35 Nagog Park Acton, MA 01720 US
ヒマンシュシャーシエナ35 Nagog Park Acton、MA 01720 US
EMail: hshah@ciena.com
Mustapha Aissaoui Alcatel-Lucent 600 March Road Kanata ON, Canada
Mustapha Aissaoui Alcatel-Lucent 600 March RoadカナタON、カナダ
EMail: mustapha.aissaoui@alcatel-lucent.com
Jason Rusmisel Alcatel-Lucent 600 March Road Kanata ON, Canada
Jason Rusmisel Alcatel-Lucent 600 March RoadカナタON、カナダ
EMail: Jason.rusmisel@alcatel-lucent.com
Andrew G. Malis Huawei 2330 Central Expressway Santa Clara, CA 95050 US
アンドリューG.マリスファーウェイ2330セントラルエクスプレスウェイサンタクララ、CA 95050 US
EMail: agmalis@gmail.com Chris Metz Cisco Systems, Inc. 3700 Cisco Way San Jose, CA 95134 US
メール：agmalis@gmail.com Chris Metz Cisco Systems、Inc. 3700 Cisco Way San Jose、CA 95134 US
EMail: chmetz@cisco.com
David McDysan Verizon 22001 Loudoun County Pkwy. Ashburn, VA 20147 US
David McDysan Verizon 22001ラウドン郡Pkwy。 Ashburn、VA 20147 US
EMail: dave.mcdysan@verizon.com
Jeff Sugimoto Alcatel-Lucent 701 E. Middlefield Rd. Mountain View, CA 94043 US
ジェフ杉本アルカテル-ルーセント701 E. Middlefield Rd。マウンテンビュー、CA 94043 US
EMail: jeffery.sugimoto@alcatel-lucent.com
Mike Loomis Alcatel-Lucent 701 E. Middlefield Rd. Mountain View, CA 94043 US
マイクルーミスアルカテルルーセント701 E.ミドルフィールドロードマウンテンビュー、CA 94043 US
EMail: mike.loomis@alcatel-lucent.com
The editors also gratefully acknowledge the input of the following people: Paul Doolan, Mike Duckett, Pranjal Dutta, Ping Pan, Prayson Pate, Vasile Radoaca, Yeongil Seo, Yetik Serbest, and Yuichiro Wada.
編集者は、Paul Doolan、Mike Duckett、Pranjal Dutta、Ping Pan、Prayson Pate、Vasile Radoaca、Yeongil Seo、Yetik Serbest、Wada Yuichiroの各氏の意見にも感謝します。
Authors' Addresses
著者のアドレス
Luca Martini (editor) Cisco Systems, Inc. 9155 East Nichols Avenue, Suite 400 Englewood, CO 80112 US
Luca Martini（編集者）Cisco Systems、Inc. 9155 East Nichols Avenue、Suite 400 Englewood、CO 80112 US
EMail: lmartini@cisco.com
Matthew Bocci (editor) Alcatel-Lucent Voyager Place Shoppenhangers Road Maidenhead Berks, UK
マシュー・ボッチ（編集）アルカテル・ルーセント・ボイジャー・プレイスショップペンハンガーズ・ロードメイデンヘッド・バークス、イギリス
EMail: matthew.bocci@alcatel-lucent.com
Florin Balus (editor) Alcatel-Lucent 701 E. Middlefield Rd. Mountain View, CA 94043 US
フローリン・バルス（編者）アルカテル・ルーセント701 E.ミドルフィールドロードマウンテンビュー、CA 94043 US
EMail: florin@nuagenetworks.net