RFC 6370 - MPLS Transport Profile (MPLS-TP) Identifiers 日本語訳

URL : https://tools.ietf.org/html/rfc6370
タイトル : RFC 6370 - MPLSトランスポートプロファイル（MPLS-TP）識別子
翻訳編集 : 自動生成

Internet Engineering Task Force (IETF)                          M. Bocci
Request for Comments: 6370                                Alcatel-Lucent
Category: Standards Track                                     G. Swallow
ISSN: 2070-1721                                                    Cisco
                                                                 E. Gray
                                                                Ericsson
                                                          September 2011

              MPLS Transport Profile (MPLS-TP) Identifiers

Abstract

抽象

This document specifies an initial set of identifiers to be used in the Transport Profile of Multiprotocol Label Switching (MPLS-TP). The MPLS-TP requirements (RFC 5654) require that the elements and objects in an MPLS-TP environment are able to be configured and managed without a control plane. In such an environment, many conventions for defining identifiers are possible. This document defines identifiers for MPLS-TP management and Operations, Administration, and Maintenance (OAM) functions compatible with IP/ MPLS conventions.

この文書では、マルチプロトコルラベルスイッチング（MPLS-TP）のトランスポートプロファイルに使用される識別子の最初のセットを指定します。 MPLS-TP要求（RFC 5654）は、MPLS-TP環境の要素及びオブジェクトは、制御プレーンなしで構成および管理することができることを必要とします。このような環境では、識別子を定義するための多くの規則が可能です。この文書では、MPLS-TPの管理とIP / MPLS規則と互換性の操作、管理、および保守（OAM）機能のための識別子を定義します。

This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunication Union Telecommunication Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge (PWE3) architectures to support the capabilities and functionalities of a packet transport network as defined by the ITU-T.

この文書は、IETF MPLSおよび擬似回線エミュレーションエッジツーエッジ（PWE3）アーキテクチャ内MPLSトランスポートプロファイルを含めるための共同のインターネットエンジニアリングタスクフォース（IETF）/国際電気通信連合電気通信標準化部門（ITU-T）の努力の産物でありますITU-Tによって定義されるようなパケットトランスポートネットワークの能力と機能性をサポートします。

Status of This Memo

このメモのステータス

This is an Internet Standards Track document.

これは、インターネット標準化過程文書です。

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）の製品です。これは、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/rfc6370.

このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6370で取得することができます。

著作権表示

著作権（C）2011 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。

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ドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。

Table of Contents

   1. Introduction ....................................................3
      1.1. Terminology ................................................3
      1.2. Requirements Language ......................................4
      1.3. Notational Conventions .....................................4
   2. Named Entities ..................................................5
   3. Uniquely Identifying an Operator - the Global_ID ................5
   4. Node and Interface Identifiers ..................................6
   5. MPLS-TP Tunnel and LSP Identifiers ..............................7
      5.1. MPLS-TP Point-to-Point Tunnel Identifiers ..................8
      5.2. MPLS-TP LSP Identifiers ....................................9
           5.2.1. MPLS-TP Co-Routed Bidirectional LSP Identifiers .....9
           5.2.2. MPLS-TP Associated Bidirectional LSP Identifiers ....9
      5.3. Mapping to RSVP Signaling .................................10
   6. Pseudowire Path Identifiers ....................................11
   7. Maintenance Identifiers ........................................13
      7.1. Maintenance Entity Group Identifiers ......................13
           7.1.1. MPLS-TP Section MEG_IDs ............................13
           7.1.2. MPLS-TP LSP MEG_IDs ................................13
           7.1.3. Pseudowire MEG_IDs .................................14
      7.2. Maintenance Entity Group End Point Identifiers ............14
           7.2.1. MPLS-TP Section MEP_IDs ............................14
           7.2.2. MPLS-TP LSP_MEP_ID .................................15
           7.2.3. MEP_IDs for Pseudowires ............................15
      7.3. Maintenance Entity Group Intermediate Point Identifiers ...15
   8. Security Considerations ........................................15
   9. References .....................................................16
      9.1. Normative References ......................................16
      9.2. Informative References ....................................17

1. Introduction

1. はじめに

This document specifies an initial set of identifiers to be used in the Transport Profile of Multiprotocol Label Switching (MPLS-TP). The MPLS-TP requirements (RFC 5654 [7]) require that the elements and objects in an MPLS-TP environment are able to be configured and managed without a control plane. In such an environment, many conventions for defining identifiers are possible. This document defines identifiers for MPLS-TP management and OAM functions compatible with IP/MPLS conventions. That is, the identifiers have been chosen to be compatible with existing IP, MPLS, GMPLS, and Pseudowire definitions.

この文書では、マルチプロトコルラベルスイッチング（MPLS-TP）のトランスポートプロファイルに使用される識別子の最初のセットを指定します。 MPLS-TP要求（RFC 5654 [7]）MPLS-TP環境の要素及びオブジェクトは、制御プレーンなしで構成および管理することができることを必要とします。このような環境では、識別子を定義するための多くの規則が可能です。この文書では、IP / MPLS規則と互換性のMPLS-TP管理およびOAM機能のための識別子を定義します。それは、識別子は、既存のIP、MPLS、GMPLS、および擬似回線の定義と適合するように選択されている、です。

1.1. Terminology

1.1. 用語

AGI: Attachment Group Identifier

AGI：添付ファイルのグループ識別子

AII: Attachment Interface Identifier

AII：添付ファイルインタフェース識別子

AS: Autonomous System

AS：自律システム

ASN: Autonomous System Number

ASN：自律システム番号

EGP: Exterior Gateway Protocol

EGP：エクステリアゲートウェイプロトコル

FEC: Forwarding Equivalence Class

FEC：転送等価クラス

GMPLS: Generalized Multiprotocol Label Switching

GMPLS：一般マルチプロトコルラベルスイッチング

IGP: Interior Gateway Protocol

IGP：インテリアゲートウェイプロトコル

LSP: Label Switched Path

LSP：ラベルスイッチパス

LSR: Label Switching Router

LSR：ラベルスイッチングルータ

MEG: Maintenance Entity Group

MEG：メンテナンスエンティティグループ

MEP: Maintenance Entity Group End Point

MEP：メンテナンスエンティティグループエンドポイント

MIP: Maintenance Entity Group Intermediate Point

MIP：メンテナンスエンティティグループの中間点

MPLS: Multiprotocol Label Switching

MPLS：マルチプロトコルラベルスイッチング

NNI: Network-to-Network Interface

NNI：ネットワーク間インターフェイス

OAM: Operations, Administration, and Maintenance

OAM：オペレーション、管理、およびメンテナンス

PW: Pseudowire

PO：Psefdoviri

RSVP: Resource Reservation Protocol

RSVP：リソース予約プロトコル

RSVP-TE: RSVP Traffic Engineering

RSVP-TE：RSVPトラフィックエンジニアリング

SAII: Source AII

SAII：ソースAII

SPME: Sub-Path Maintenance Entity

SPME：サブパスメンテナンスエンティティ

T-PE: Terminating Provider Edge

T-PE：終端プロバイダエッジ

TAII: Target AII

TAII：ターゲットAII

1.2. Requirements Language

1.2. 要件言語

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

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

1.3. Notational Conventions

1.3. 表記規則

All multiple-word atomic identifiers use underscores (_) between the words to join the words. Many of the identifiers are composed of a set of other identifiers. These are expressed by listing the latter identifiers joined with double-colon "::" notation.

すべての複数ワード原子の識別子は、言葉に参加する単語間にアンダースコア（_）を使用します。識別子の多くは、他の識別子のセットで構成されています。これらは、二重コロンと結合後者の識別子をリスト「::」の表記で表されます。

Where the same identifier type is used multiple times in a concatenation, they are qualified by a prefix joined to the identifier by a dash (-). For example, A1-Node_ID is the Node_ID of a node referred to as A1.

同じ識別子タイプが連結に複数回使用される場合、それらは、ダッシュによって識別子に接合接頭辞によって修飾されました（ - ）。例えば、A1-NODE_IDはA1と呼ばれるノードのNODE_IDあります。

The notation defines a preferred ordering of the fields. Specifically, the designation A1 is used to indicate the lower sort order of a field or set of fields and Z9 is used to indicate the higher sort order of the same. The sort is either alphanumeric or numeric depending on the field's definition. Where the sort applies to a group of fields, those fields are grouped with {...}.

表記は、フィールドの好ましい順序を定義します。具体的には、指定A1は、フィールドの下ソート順序を示すために使用されるか、またはフィールドのセットとZ9は、同一の高いソート順序を示すために使用されます。ソートは、フィールドの定義に応じて、英数字または数値のいずれかです。ソートフィールドのグループに適用される場合、これらのフィールドは、{...}でグループ化されます。

Note, however, that the uniqueness of an identifier does not depend on the ordering, but rather, upon the uniqueness and scoping of the fields that compose the identifier. Further, the preferred ordering is not intended to constrain protocol designs by dictating a particular field sequence (for example, see Section 5.2.1) or even what fields appear in which objects (for example, see Section 5.3).

識別子のユニークさは、順序に依存しないこと、しかし、注意してくださいではなく、識別子を構成するフィールドの一意性とスコープに依存します。さらに、好ましい順序付けは、特定のフィールドシーケンスを指示することにより、プロトコルの設計を制約することを意図していない（例えば、セクション5.2.1を参照）または偶数フィールドをするオブジェクト現れるもの（例えば、セクション5.3を参照）。

2. Named Entities

2.名前付きエンティティ

In order to configure, operate, and manage a transport network based on the MPLS Transport Profile, a number of entities require identification. Identifiers for the following entities are defined in this document:

、設定、運用、およびMPLSトランスポートプロファイルに基づいて、伝送ネットワークを管理するために、エンティティの数は、識別が必要です。次のエンティティの識別子は、この文書で定義されています。

* Global_ID

* Node

＊ので

* Interface

*インタフェース

* Tunnel

*トンネル

* LSP

* PW

* PM

* MEG

* YOUを

* MEP

* MIP

Note that we have borrowed the term "tunnel" from RSVP-TE (RFC 3209 [2]) where it is used to describe an entity that provides a logical association between a source and destination LSR. The tunnel, in turn, is instantiated by one or more LSPs, where the additional LSPs are used for protection or re-grooming of the tunnel.

我々は、RSVP-TEから用語「トンネル」を借りていることに留意されたい（RFC 3209 [2]）は、それが送信元と宛先LSR間の論理的な関連付けを提供するエンティティを記述するために使用されます。トンネルは、順番に、追加のLSPをトンネルの保護または再グルーミングのために使用される1つのまたは複数のLSPによってインスタンス化されます。

3. Uniquely Identifying an Operator - the Global_ID

3.一意オペレータの識別 - Global_ID

The Global_ID is defined to uniquely identify an operator. RFC 5003 [3] defines a globally unique Attachment Interface Identifier (AII). That AII is composed of three parts: a Global_ID that uniquely identifies an operator, a prefix, and, finally, an attachment circuit identifier. We have chosen to use that Global ID for MPLS-TP. Quoting from RFC 5003, Section 3.2:

Global_IDを一意オペレータを識別するために定義されています。 RFC 5003 [3]は、グローバルに一意なアタッチメントインタフェース識別子（AII）を定義します。一意オペレータを識別するGlobal_ID、接頭辞、及び、最後に、接続回線識別子：AIIは、3つの部分で構成されていること。私たちは、MPLS-TPのためにそのグローバルIDを使用することを選択しました。 RFC 5003、セクション3.2からの引用：

The global ID can contain the 2-octet or 4-octet value of the provider's Autonomous System Number (ASN). It is expected that the global ID will be derived from the globally unique ASN of the autonomous system hosting the PEs containing the actual AIIs. The presence of a global ID based on the operator's ASN ensures that the AII will be globally unique.

グローバルIDは、プロバイダの自律システム番号（ASN）の2オクテット又は4オクテット値を含むことができます。グローバルIDは、実際のAIIsを含むのPEをホスティングしている自律システムのグローバル一意ASNから導出されることが期待されます。オペレータのASNに基づいてグローバルIDの存在は、AIIがグローバルに一意であることが保証されます。

A Global_ID is an unsigned 32-bit value and MUST be derived from a 4-octet AS number assigned to the operator. Note that 2-octet AS numbers have been incorporated in the 4-octet by placing the 2-octet AS number in the low-order octets and setting the two high-order octets to zero.

Global_IDは、符号なし32ビット値であり、オペレータに割り当てられた4オクテットAS番号から導出されなければなりません。 AS番号2オクテットは下位オクテット数として2-オクテットを配置し、ゼロに上位2オクテットを設定することにより、4オクテットに組み込まれていることに留意されたいです。

ASN 0 is reserved and cannot be assigned to an operator. An identifier containing a Global_ID of zero means that no Global_ID is specified. Note that a Global_ID of zero is limited to entities contained within a single operator and MUST NOT be used across an NNI.

ASN 0は予約されており、オペレータに割り当てることはできません。ゼロのGlobal_IDを含む識別子にはGlobal_IDが指定されていないことを意味します。ゼロのGlobal_IDは単一のオペレータ内に含まれるエンティティに制限され、NNIにわたって使用されてはならないことに注意してください。

The Global_ID is used solely to provide a globally unique context for other MPLS-TP identifiers. While the AS number used in the Global_ID MUST be one that the operator is entitled to use, the use of the Global_ID is not related to the use of the ASN in protocols such as BGP.

Global_IDは、他のMPLS-TP識別子のグローバル一意のコンテキストを提供するためにのみ使用されます。 Global_IDに使用AS番号をオペレータが使用する権利を有するものでなければならないが、Global_IDの使用は、BGPなどのプロトコルにおけるASNの使用に関連していません。

4. Node and Interface Identifiers

4.ノードとインタフェースの識別子

An LSR requires identification of the node itself and of its interfaces. An interface is the attachment point to a server (sub-)layer, e.g., MPLS-TP section or MPLS-TP tunnel.

LSRは、ノード自体およびそのインターフェースの識別を必要とします。インターフェースは、サーバ（サブ）レイヤ、例えば、MPLS-TPセクションまたはMPLS-TPトンネルへの結合点です。

We call the identifier associated with a node a "Node Identifier" (Node_ID). The Node_ID is a unique 32-bit value assigned by the operator within the scope of a Global_ID. The structure of the Node_ID is operator-specific and is outside the scope of this document. However, the value zero is reserved and MUST NOT be used. Where IPv4 addresses are used, it may be convenient to use the Node's IPv4 loopback address as the Node_ID; however, the Node_ID does not need to have any association with the IPv4 address space used in the operator's IGP or EGP. Where IPv6 addresses are used exclusively, a 32-bit value unique within the scope of a Global_ID is assigned.

我々は、ノード「ノード識別子」（NODE_ID）に関連付けられた識別子を呼び出します。 NODE_IDはGlobal_IDの範囲内でオペレータによって割り当てられたユニークな32ビットの値です。 NODE_IDの構造は、オペレータ固有であり、この文書の範囲外です。しかし、ゼロ値は予約されており、使用してはいけません。 IPv4アドレスを使用する場合、NODE_IDとしてノードのIPv4ループバックアドレスを使用すると便利かもしれ。しかし、NODE_IDは、オペレータのIGPまたはEGPで使用されるIPv4アドレス空間を持つ任意の関連を持っている必要はありません。 IPv6アドレスを排他的に使用される場合、Global_IDの範囲内で一意の32ビット値が割り当てられます。

An LSR can support multiple layers (e.g., hierarchical LSPs) and the Node_ID belongs to the multiple-layer context, i.e., it is applicable to all LSPs or PWs that originate on, have an intermediate point on, or terminate on the node.

LSRは、複数の層（例えば、階層のLSP）をサポートすることができ、NODE_ID、すなわち多層コンテキストに属し、それは、上の起源上の中間点を有し、またはノードで終端する全てのLSPまたはのPWにも適用可能です。

In situations where a Node_ID needs to be globally unique, this is accomplished by prefixing the identifier with the operator's Global_ID.

NODE_IDはグローバルに一意である必要が状況で、これは、オペレータのGlobal_IDとの識別子を付けることによって達成されます。

The term "interface" is used for the attachment point to an MPLS-TP section. Within the context of a particular node, we call the identifier associated with an interface an "Interface Number" (IF_Num). The IF_Num is a 32-bit unsigned integer assigned by the operator and MUST be unique within the scope of a Node_ID. The IF_Num value 0 has special meaning (see Section 7.3, MIP Identifiers) and MUST NOT be used to identify an MPLS-TP interface.

用語「インタフェース」は、MPLS-TP部にアタッチメントポイントのために使用されます。特定のノードのコンテキスト内で、我々はインターフェース「インターフェース番号」（IF_Num）に関連付けられた識別子を呼び出します。 IF_Numオペレータによって割り当てられた32ビットの符号なし整数であり、NODE_IDの範囲内で一意でなければなりません。 IF_Num値0は特別な意味を持っている（7.3節、MIP識別子を参照）、MPLS-TPインタフェースを識別するために使用してはいけません。

Note that IF_Num has no relation with the ifNum object defined in RFC 2863 [8]. Further, no mapping is mandated between IF_Num and ifIndex in RFC 2863.

IF_Numは、RFC 2863で定義されたifNumオブジェクトとは関係ないことに注意してください[8]。さらに、何のマッピングはRFC 2863にIF_NumとifIndexの間で義務付けられていません。

An "Interface Identifier" (IF_ID) identifies an interface uniquely within the context of a Global_ID. It is formed by concatenating the Node_ID with the IF_Num. That is, an IF_ID is a 64-bit identifier formed as Node_ID::IF_Num.

「インタフェース識別子」（IF_ID）はGlobal_IDのコンテキスト内で一意のインタフェースを識別する。それはIF_NumでNODE_IDを連結することによって形成されます。すなわちIF_IDはNODE_ID :: IF_Numとして形成された64ビットの識別子です。

This convention was chosen to allow compatibility with GMPLS. The GMPLS signaling functional description [4] requires interface identification. GMPLS allows three formats for the Interface_ID. The third format consists of an IPv4 address plus a 32-bit unsigned integer for the specific interface. The format defined for MPLS-TP is consistent with this format, but uses the Node_ID instead of an IPv4 address.

この規則は、GMPLSとの互換性を可能にするために選ばれました。機能説明[4] GMPLSシグナリングは、インタフェース識別を必要とします。 GMPLSはInterface_IDのための3つのフォーマットが可能になります。第三の形式は、IPv4アドレスに加えて、特定のインターフェイスのために32ビットの符号なし整数から成ります。 MPLS-TP用に定義されたフォーマットは、このフォーマットと一致しているが、NODE_ID代わりにIPv4アドレスを使用します。

If an IF_ID needs to be globally unique, this is accomplished by prefixing the identifier with the operator's Global_ID.

IF_IDがグローバルに一意である必要がある場合、これはオペレータのGlobal_IDとの識別子を付けることによって達成されます。

Note that MPLS-TP supports hierarchical sections. The attachment point to an MPLS-TP section at any (sub-)layer requires a node-unique IF_Num.

MPLS-TPは、階層のセクションをサポートしていることに注意してください。任意の（サブ）レイヤにMPLS-TP部への取り付け点は、ノード固有IF_Numを必要とします。

5. MPLS-TP Tunnel and LSP Identifiers

5. MPLS-TPトンネルおよびLSP識別子

In MPLS, the actual transport of packets is provided by Label Switched Paths (LSPs). A transport service may be composed of multiple LSPs. Further, the LSPs providing a service may change over time due to protection and restoration events. In order to clearly identify the service, we use the term "MPLS-TP Tunnel" or simply "tunnel" for a service provided by (for example) a working LSP and protected by a protection LSP. The "Tunnel Identifier" (Tunnel_ID) identifies the transport service and provides a stable binding to the client in the face of changes in the data-plane LSPs used to provide the service due to protection or restoration events. This section defines an MPLS-TP Tunnel_ID to uniquely identify a tunnel, and an MPLS-TP LSP Identifier (LSP_ID) to uniquely identify an LSP associated with a tunnel.

MPLSは、ラベルによって提供されるパケットの実際の移送は、パス（LSPを）スイッチ。トランスポート・サービスは、複数のLSPから構成されてもよいです。さらに、サービスを提供するLSPは、原因の保護と復旧のイベントに時間の経過とともに変化することがあります。明確サービスを識別するために、我々は、用語「MPLS-TPトンネル」又は単に（例えば）によって提供されるサービスのための「トンネル」ワーキングLSPを使用して、保護LSPによって保護します。「トンネル識別子」（Tunnel_ID）は、トランスポート・サービスを識別し、保護または修復事象によるサービスを提供するために使用されるデータプレーンのLSPの変化に直面してクライアントに結合する安定を提供します。このセクションでは、一意のトンネルを識別するために、MPLS-TP Tunnel_IDを定義し、MPLS-TP LSP識別子（LSP_ID）が一意にトンネルに関連付けられているLSPを識別します。

For the case where multiple LSPs (for example) are used to support a single service with a common set of end points, using the Tunnel_ID allows for a trivial mapping between the server and client layers, providing a common service identifier that may be either defined by or used by the client.

Tunnel_IDを使用して、複数のLSPは、（例えば）エンドポイントの共通のセットを使用して単一のサービスをサポートするために使用されている場合、のいずれかのために定義することができる共通サービス識別子を提供する、サーバとクライアント層の間の些細なマッピングを可能にしますまたはクライアントによって使用されます。

Note that this usage is not intended to constrain protection schemes, and may be used to identify any service (protected or unprotected) that may appear to the client as a single service attachment point. Keeping the Tunnel_ID consistent across working and protection LSPs is a useful construct currently employed within GMPLS. However, the Tunnel_ID for a protection LSP MAY differ from that used by its corresponding working LSP.

この使用は、保護スキームを制約するものではなく、単一のサービス接続ポイントとしてクライアントに表示されることがあり、任意のサービス（保護または非保護）を識別するために使用されてもよいことに留意されたいです。作業および保護のLSP一貫したTunnel_IDを保つことは、現在GMPLS内で用いられる便利な構成です。しかし、保護LSPのためのTunnel_IDは、その対応する作業LSPで使用されたものと異なる場合があります。

5.1. MPLS-TP Point-to-Point Tunnel Identifiers

5.1. MPLS-TPポイントツーポイントトンネル識別子

At each end point, a tunnel is uniquely identified by the end point's Node_ID and a locally assigned tunnel number. Specifically, a "Tunnel Number" (Tunnel_Num) is a 16-bit unsigned integer unique within the context of the Node_ID. The motivation for each end point having its own tunnel number is to allow a compact form for the MEP_ID. See Section 7.2.2.

各エンドポイントにおいて、トンネルは、一意のエンドポイントのNODE_IDとローカルに割り当てられたトンネル番号によって識別されます。具体的には、「トンネル数」（Tunnel_Num）はNODE_IDのコンテキスト内で一意の16ビットの符号なし整数です。独自のトンネル番号を有する各エンドポイントのための動機はMEP_IDためのコンパクトな形態を可能にすることです。 7.2.2項を参照してください。

Having two tunnel numbers also serves to simplify other signaling (e.g., setup of associated bidirectional tunnels as described in Section 5.3).

2つのトンネル番号を有する他のシグナリングを簡略化するのに役立つ（例えば、第5.3節で説明したように、関連する双方向トンネルの設定）。

The concatenation of the two end point identifiers serves as the full identifier. Using the A1/Z9 convention, the format of a Tunnel_ID is:

二つのエンドポイント識別子の連結は、完全な識別子として機能します。 A1 / Z9規則を使用して、Tunnel_IDの形式は次のとおりです。

A1-{Node_ID::Tunnel_Num}::Z9-{Node_ID::Tunnel_Num}

A1- {NODE_ID :: Tunnel_Num} :: Z9- {NODE_ID :: Tunnel_Num}

Where the Tunnel_ID needs to be globally unique, this is accomplished by using globally unique Node_IDs as defined above. Thus, a globally unique Tunnel_ID becomes:

Tunnel_IDはグローバルに一意である必要がある場合、これは、上で定義したグローバルにユニークNode_IDsを使用することによって達成されます。このように、グローバルに一意Tunnel_IDは次のようになります。

A1-{Global_ID::Node_ID::Tunnel_Num}::Z9-{Global_ID::Node_ID:: Tunnel_Num}

A1- {Global_ID :: NODE_ID :: Tunnel_Num} :: Z9- {Global_ID :: NODE_ID :: Tunnel_Num}

When an MPLS-TP Tunnel is configured, it MUST be assigned a unique IF_ID at each end point. As usual, the IF_ID is composed of the local Node_ID concatenated with a 32-bit IF_Num.

MPLS-TPトンネルが設定されている場合には、各エンドポイントにユニークIF_IDを割り当てなければなりません。通常通り、IF_IDは32ビットIF_Numと連結ローカルNODE_IDから構成されています。

5.2. MPLS-TP LSP Identifiers

5.2. MPLS-TP LSP識別子

This section defines identifiers for MPLS-TP co-routed bidirectional and associated bidirectional LSPs. Note that MPLS-TP Sub-Path Maintenance Entities (SPMEs), as defined in RFC 5921 [9], are also LSPs and use these same forms of identifiers.

このセクションでは、MPLS-TPの共同ルーティング双方向および関連する双方向のLSPの識別子を定義します。 RFC 5921で定義されるように、そのMPLS-TPサブパス保守エンティティ（SPMEs）の注[9]ものLSPであり、識別子のこれらの同じフォームを使用します。

5.2.1. MPLS-TP Co-Routed Bidirectional LSP Identifiers

5.2.1. MPLS-TP共同ルーティング双方向LSP識別子

A co-routed bidirectional LSP can be uniquely identified by a single LSP number within the scope of an MPLS-TP Tunnel_ID. Specifically, an LSP Number (LSP_Num) is a 16-bit unsigned integer unique within the Tunnel_ID. Thus, the format of an MPLS-TP co-routed bidirectional LSP_ID is:

共ルーティング双方向LSPを一意MPLS-TP Tunnel_IDの範囲内の単一のLSP番号によって同定することができます。具体的には、LSP番号（LSP_Num）はTunnel_ID内で一意の16ビットの符号なし整数です。このように、MPLS-TPの共同ルーティングされた双方向LSP_IDの形式は次のとおりです。

A1-{Node_ID::Tunnel_Num}::Z9-{Node_ID::Tunnel_Num}::LSP_Num

A1- {NODE_ID :: Tunnel_Num} :: Z9- {NODE_ID :: Tunnel_Num} :: LSP_Num

Note that the uniqueness of identifiers does not depend on the A1/Z9 sort ordering. Thus, the identifier:

識別子のユニークさは、A1 / Z9のソート順序に依存しないことに注意してください。このように、識別子：

Z9-{Node_ID::Tunnel_Num}::A1-{Node_ID::Tunnel_Num}::LSP_Num

Z9- {NODE_ID :: Tunnel_Num} :: A1- {NODE_ID :: Tunnel_Num} :: LSP_Num

is synonymous with the one above.

上記1と同義です。

At the data-plane level, a co-routed bidirectional LSP is composed of two unidirectional LSPs traversing the same links in opposite directions. Since a co-routed bidirectional LSP is provisioned or signaled as a single entity, a single LSP_Num is used for both unidirectional LSPs. The unidirectional LSPs can be referenced by the identifiers:

データプレーンレベルでは、共ルーティング双方向LSPは、反対方向に同じリンクを横断する2つの単方向のLSPから構成されています。共ルーティング双方向LSPがプロビジョニングまたは単一のエンティティとしてシグナリングされるので、単一LSP_Numは、一方向のLSPの両方のために使用されます。単方向LSPは、識別子によって参照することができます。

A1-Node_ID::A1-Tunnel_Num::LSP_Num::Z9-Node_ID and

A1-NODE_ID :: A1-Tunnel_Num :: LSP_Num :: Z9-NODE_IDと

Z9-Node_ID::Z9-Tunnel_Num::LSP_Num::A1-Node_ID, respectively.

Z9-NODE_ID :: Z9-Tunnel_Num :: LSP_Num :: A1-NODE_ID、それぞれ。

Where the LSP_ID needs to be globally unique, this is accomplished by using globally unique Node_IDs as defined above. Thus, a globally unique LSP_ID becomes:

LSP_IDはグローバルに一意である必要がある場合、これは、上で定義したグローバルにユニークNode_IDsを使用することによって達成されます。このように、グローバルに一意LSP_IDは次のようになります。

A1-{Global_ID::Node_ID::Tunnel_Num}::Z9-{Global_ID:: Node_ID::Tunnel_Num}::LSP_Num

A1- {Global_ID :: NODE_ID :: Tunnel_Num} :: Z9- {Global_ID :: NODE_ID :: Tunnel_Num} :: LSP_Num

5.2.2. MPLS-TP Associated Bidirectional LSP Identifiers

5.2.2. MPLS-TP関連双方向LSP識別子

For an associated bidirectional LSP, each of the unidirectional LSPs from A1 to Z9 and Z9 to A1 require LSP_Nums. Each unidirectional LSP is uniquely identified by a single LSP number within the scope of the ingress's Tunnel_Num. Specifically, an "LSP Number" (LSP_Num) is a

関連する双方向LSPについては、A1からZ9とZ9にA1への単方向LSPの各々はLSP_Numsを必要とします。各一方向LSPを一意イングレスのTunnel_Numの範囲内の単一のLSP番号によって識別されます。具体的には、「LSP番号」（LSP_Num）であります

16-bit unsigned integer unique within the scope of the ingress's Tunnel_Num. Thus, the format of an MPLS-TP associated bidirectional LSP_ID is:

入口のTunnel_Numの範囲内で一意の16ビットの符号なし整数。したがって、MPLS-TP関連双方向LSP_IDの形式は次のとおりです。

A1-{Node_ID::Tunnel_Num::LSP_Num}:: Z9-{Node_ID::Tunnel_Num::LSP_Num}

A1- {NODE_ID :: Tunnel_Num :: LSP_Num} :: Z9- {NODE_ID :: Tunnel_Num :: LSP_Num}

At the data-plane level, an associated bidirectional LSP is composed of two unidirectional LSPs between two nodes in opposite directions. The unidirectional LSPs may be referenced by the identifiers:

データプレーンレベルでは、関連する双方向LSPは、反対方向に2つのノード間の2つの単方向のLSPから構成されています。単方向LSPは、識別子によって参照することができます。

A1-Node_ID::A1-Tunnel_Num::A1-LSP_Num::Z9-Node_ID and

A1-NODE_ID :: A1-Tunnel_Num :: A1-LSP_Num :: Z9-NODE_IDと

Z9-Node_ID::Z9-Tunnel_Num::Z9-LSP_Num::A1-Node_ID, respectively.

Z9-NODE_ID :: Z9-Tunnel_Num :: Z9-LSP_Num :: A1-NODE_ID、それぞれ。

Where the LSP_ID needs to be globally unique, this is accomplished by using globally unique Node_IDs as defined above. Thus, a globally unique LSP_ID becomes:

A1-{Global_ID::Node_ID::Tunnel_Num::LSP_Num}:: Z9-{Global_ID::Node_ID::Tunnel_Num::LSP_Num}

A1- {Global_ID :: NODE_ID :: Tunnel_Num :: LSP_Num} :: Z9- {Global_ID :: NODE_ID :: Tunnel_Num :: LSP_Num}

5.3. Mapping to RSVP Signaling

5.3. シグナリングをRSVPへのマッピング

This section is informative and exists to help understand the structure of the LSP IDs.

このセクションは参考情報で、LSP IDの構造を理解するために存在します。

GMPLS [5] is based on RSVP-TE [2]. This section defines the mapping from an MPLS-TP LSP_ID to RSVP-TE. At this time, RSVP-TE has yet to be extended to accommodate Global_IDs. Thus, a mapping is only made for the network unique form of the LSP_ID and assumes that the operator has chosen to derive its Node_IDs from valid IPv4 addresses.

GMPLSは、[5] RSVP-TE [2]に基づくものです。このセクションでは、RSVP-TEのためのMPLS-TPのLSP_IDからマッピングを定義します。このとき、RSVP-TEはGlobal_IDsに対応するために拡張するためには至っていません。したがって、マッピングは唯一LSP_IDのネットワークユニークな形のために作られたとオペレータが有効なIPv4アドレスからそのNode_IDsを導出することを選択したことを前提としています。

GMPLS and RSVP-TE signaling use a 5-tuple to uniquely identify an LSP within an operator's network. This tuple is composed of a Tunnel End-point Address, Tunnel_ID, Extended Tunnel ID, Tunnel Sender Address, and (RSVP) LSP_ID. RFC 3209 allows some flexibility in how the Extended Tunnel ID is chosen, and a direct mapping is not mandated. One convention that is often used, however, is to populate this field with the same value as the Tunnel Sender Address. The examples below follow that convention. Note that these are only examples.

一意オペレータのネットワーク内LSPを識別するために、5タプルを使用GMPLSシグナリングとRSVP-TE。このタプルは、トンネルエンドポイントアドレス、Tunnel_ID、拡張トンネルID、トンネル送信者アドレス、及び（RSVP）LSP_IDから構成されています。 RFC 3209は、拡張トンネルIDを選択する方法にいくつかの柔軟性を可能にし、ダイレクトマッピングが義務付けられていません。頻繁に使用されている一つの大会では、しかし、トンネルの送信者アドレスと同じ値で、このフィールドを移入することです。以下の例は、その慣習に従ってください。これらは単なる例であることに注意してください。

For a co-routed bidirectional LSP signaled from A1 to Z9, the mapping to the GMPLS 5-tuple is as follows:

共ルーティング双方向LSPのためにA1からZ9、次のように5タプルであるGMPLSへのマッピングにシグナリング。

* Tunnel End-point Address = Z9-Node_ID

*トンネルのエンドポイントアドレス= Z9-NODE_ID

* Tunnel_ID = A1-Tunnel_Num

* Extended Tunnel_ID = A1-Node_ID

*拡張Tunnel_ID = A1-NODE_ID

* Tunnel Sender Address = A1-Node_ID

*トンネルの送信者アドレス= A1-NODE_ID

* (RSVP) LSP_ID = LSP_Num

（RSVP）LSP_ID = LSP_Num

An associated bidirectional LSP between two nodes A1 and Z9 consists of two unidirectional LSPs, one from A1 to Z9 and one from Z9 to A1.

二つのノードA1とZ9との間の関連する双方向LSPは、2つの単方向のLSP、A1からZ9に1とZ9からA1への1つから成ります。

In situations where a mapping to the RSVP-TE 5-tuples is required, the following mappings are used. For the A1 to Z9 LSP, the mapping would be:

RSVP-TE 5タプルのマッピングが必要とされる状況では、以下のマッピングが使用されています。 Z9 LSPにA1の場合、マッピングは次のようになります。

* Tunnel End-point Address = Z9-Node_ID

*トンネルのエンドポイントアドレス= Z9-NODE_ID

* Tunnel_ID = A1-Tunnel_Num

* Extended Tunnel_ID = A1-Node_ID

*拡張Tunnel_ID = A1-NODE_ID

* Tunnel Sender Address = A1-Node_ID

*トンネルの送信者アドレス= A1-NODE_ID

* (RSVP) LSP_ID = A1-LSP_Num

*（Racivap）lespiit = A1-lespinum

Likewise, the Z9 to A1 LSP, the mapping would be:

同様に、A1 LSPにZ9は、マッピングは次のようになります。

* Tunnel End-point Address = A1-Node_ID

*トンネルのエンドポイントアドレス= A1-NODE_ID

* Tunnel_ID = Z9-Tunnel_Num

* Extended Tunnel_ID = Z9-Node_ID

*拡張Tunnel_ID = Z9-NODE_ID

* Tunnel Sender Address = Z9-Node_ID

*トンネルの送信者アドレス= Z9-NODE_ID

* (RSVP) LSP_ID = Z9-LSP_Num

（RSVP）LSP_ID = Z9-LSP_Num

6. Pseudowire Path Identifiers

6.疑似回線パス識別子

Pseudowire signaling (RFC 4447 [6]) defines two FECs used to signal pseudowires. Of these, the Generalized PWid FEC (type 129) along with AII Type 2 as defined in RFC 5003 [3] fits the identification requirements of MPLS-TP.

疑似回線シグナリング（RFC 4447 [6]）疑似回線を知らせるために使用される二つのFECを定義します。これらの中で、RFC 5003で定義されるようにAIIタイプ2と共に一般PWID FEC（タイプ129）[3] MPLS-TPの識別要件に適合する。

In an MPLS-TP environment, a PW is identified by a set of identifiers that can be mapped directly to the elements required by the Generalized PWid FEC (type 129) and AII Type 2. To distinguish this identifier from other Pseudowire Identifiers, we call this a Pseudowire Path Identifier (PW_Path_ID).

MPLS-TP環境では、PWは、他の疑似識別子から識別子を区別するために一般PWID FEC（タイプ129）とAIIタイプ2によって必要とされる要素に直接マッピングすることができる識別子のセットによって識別される、我々が呼びますこの疑似回線パス識別子（PW_Path_ID）。

The AII Type 2 is composed of three fields. These are the Global_ID, the Prefix, and the AC_ID. The Global_ID used in this document is identical to the Global_ID defined in RFC 5003. The Node_ID is used as the Prefix. The AC_ID is as defined in RFC 5003.

AIIタイプ2は、3つのフィールドから構成されています。これらはGlobal_ID、プレフィックス、およびAC_IDです。 Global_IDは、この文書で使用NODE_IDを接頭辞として使用されるRFC 5003で定義されてGlobal_IDと同一です。 RFC 5003で定義されてAC_IDです。

To complete the Generalized PWid FEC (type 129), all that is required is an Attachment Group Identifier (AGI). That field is exactly as specified in RFC 4447. A (bidirectional) pseudowire consists of a pair of unidirectional LSPs, one in each direction. Thus, for signaling, the Generalized PWid FEC (type 129) has a notion of Source AII (SAII) and Target AII (TAII). These terms are used relative to the direction of the LSP, i.e., the SAII is assigned to the end that allocates the PW label for a given direction, and the TAII to the other end.

一般PWID FEC（タイプ129）を完了するために、必要とされるすべての添付ファイルのグループ識別子（AGI）です。 RFCで指定され、そのフィールドは、4447. A（双方向）疑似回線が単方向LSPの組、各方向に1つずつで構成され、正確です。従って、シグナリングのために、一般PWID FEC（タイプ129）は、ソースAII（SAII）と目標AII（TAII）の概念を有しています。これらの用語はLSPの方向に対して使用されている、すなわち、SAIIは他端に所定の方向のためにPWラベル、およびTAIIを割り当てる端に割り当てられます。

In a purely configured environment, when referring to the entire PW, this distinction is not critical. That is, a Generalized PWid FEC (type 129) of AGIa::AIIb::AIIc is equivalent to AGIa::AIIc::AIIb.

全体PWを参照するときに、純粋に構成された環境では、この区別は重要ではありません。すなわち、アギアの一般PWID FEC（タイプ129）で:: AIIb :: AIIcはアギア:: AIIcに相当する:: AIIb。

We note that in a signaled environment, the required convention in RFC 4447 is that at a particular end point, the AII associated with that end point comes first. The complete PW_Path_ID is:

私たちは合図環境の中で、RFC 4447に必要な規則は、特定のエンドポイントで、そのエンドポイントに関連付けられたAIIが最初に来るということであることに注意してください。完全PW_Path_IDは以下のとおりです。

AGI::A1-{Global_ID::Node_ID::AC_ID}:: Z9-{Global_ID::Node_ID::AC_ID}.

AGI :: A1- {Global_ID :: NODE_ID :: AC_ID} :: Z9- {Global_ID :: NODE_ID :: AC_ID}。

In a signaled environment the LSP from A1 to Z9 would be initiated with a label request from A1 to Z9 with the fields of the Generalized PWid FEC (type 129) completed as follows:

シグナリング環境でZ9にA1からLSPは、以下のように完了一般PWID FEC（タイプ129）のフィールドを持つZ9にA1からラベル要求で開始されるであろう。

AGI = AGI SAII = A1-{Global_ID::Node_ID::AC_ID} TAII = Z9-{Global_ID::Node_ID::AC_ID}

M = M = A1にECID} {globalid :: :: TAIのNODEID = J9 ECID} {globalid :: :: NODEID

The LSP from Z9 to A1 would signaled with:

Z9からA1へのLSPは合図となります：

AGI = AGI SAII = Z9-{Global_ID::Node_ID::AC_ID} TAII = A1-{Global_ID::Node_ID::AC_ID}

ECIDにログインするため= = J9} {globalid :: :: TAI NODEID = A1 ECID} {globalid :: :: NODEID

7. Maintenance Identifiers

7.メンテナンス識別子

In MPLS-TP, a Maintenance Entity Group (MEG) represents an entity that requires management and defines a relationship between a set of maintenance points. A maintenance point is either a Maintenance Entity Group End Point (MEP), a Maintenance Entity Group Intermediate Point (MIP), or a Pseudowire Segment End Point. Within the context of a MEG, MEPs and MIPs must be uniquely identified. This section defines a means of uniquely identifying Maintenance Entity Groups and Maintenance Entities. It also uniquely defines MEPs and MIPs within the context of a Maintenance Entity Group.

MPLS-TPにおいて、保守エンティティグループ（MEG）は、管理を必要とし、メンテナンスの点の集合との間の関係を定義するエンティティを表します。メンテナンスポイントは、メンテナンスエンティティグループエンドポイント（MEP）、メンテナンスエンティティグループの中間点（MIP）、または疑似回線セグメントエンドポイントのいずれかです。 MEGのコンテキスト内で、のMEPおよびMIPは一意に識別されなければなりません。このセクションでは、一意の保守エンティティグループおよび保守エンティティを識別する手段を規定します。また、ユニークなメンテナンスエンティティグループのコンテキスト内のMEPとMIPを定義します。

7.1. Maintenance Entity Group Identifiers

7.1. メンテナンスエンティティグループ識別子

Maintenance Entity Group Identifiers (MEG_IDs) are required for MPLS-TP sections, LSPs, and Pseudowires. The formats were chosen to follow the IP-compatible identifiers defined above.

メンテナンスエンティティグループ識別子（MEG_IDs）はMPLS-TPのセクション、LSPを、およびスードワイヤのために必要とされます。フォーマットは、上記で定義されたIP互換識別子に従うことを選択しました。

7.1.1. MPLS-TP Section MEG_IDs

7.1.1. MPLS-TP節MEG_IDs

MPLS-TP allows a hierarchy of sections. See "MPLS-TP Data Plane Architecture" (RFC 5960 [10]). Sections above layer 0 are MPLS-TP LSPs. These use their MPLS-TP LSP MEG IDs defined in Section 7.1.2.

MPLS-TPは、セクションの階層を可能にします。 "MPLS-TPデータプレーンアーキテクチャ" を参照してください（RFC 5960 [10]）。層0上のセクションでは、MPLS-TP用のLSPです。これらは、7.1.2項で定義された彼らのMPLS-TP LSP MEG IDを使用します。

IP-compatible MEG_IDs for MPLS-TP sections at layer 0 are formed by concatenating the two IF_IDs of the corresponding section using the A1/Z9 ordering. For example:

レイヤー0におけるMPLS-TPセクションのIP互換MEG_IDsはA1 / Z9の順序を使用して、対応するセクションの2 IF_IDsを連結することによって形成されています。例えば：

A1-IF_ID::Z9-IF_ID

A1-IF_ID :: Z9-IF_ID

Where the Section_MEG_ID needs to be globally unique, this is accomplished by using globally unique Node_IDs as defined above. Thus, a globally unique Section_MEG_ID becomes:

Section_MEG_IDはグローバルに一意である必要がある場合、これは、上で定義したグローバルにユニークNode_IDsを使用することによって達成されます。このように、グローバルに一意Section_MEG_IDは次のようになります。

A1-{Global_ID::IF_ID}::Z9-{Global_ID::IF_ID}

A1- {Global_ID :: IF_ID} :: Z9- {Global_ID :: IF_ID}

7.1.2. MPLS-TP LSP MEG_IDs

A MEG pertains to a unique MPLS-TP LSP. IP compatible MEG_IDs for MPLS-TP LSPs are simply the corresponding LSP_IDs; however, the A1/Z9 ordering MUST be used. For bidirectional co-routed LSPs, the format of the LSP_ID is found in Section 5.2.1. For associated bidirectional LSPs, the format is in Section 5.2.2.

MEGは独自のMPLS-TP LSPに関係します。 MPLS-TP LSPのためのIP互換MEG_IDsは単に対応LSP_IDsあります。ただし、A1 / Z9の順序を使用しなければなりません。双方向の同時ルーティングされたLSPのために、LSP_IDのフォーマットは、5.2.1項で発見されました。関連する双方向のLSPの場合、フォーマットは5.2.2項です。

We note that while the two identifiers are syntactically identical, they have different semantics. This semantic difference needs to be made clear. For instance, if both an MPLS-TP LSP_ID and MPLS-TP LSP MEG_IDs are to be encoded in TLVs, different types need to be assigned for these two identifiers.

我々は2つの識別子が構文的に同じであるが、それらは異なる意味を持っていることに注意してください。この意味上の違いを明確にする必要があります。 MPLS-TP LSP_IDとMPLS-TP LSP両方MEG_IDsはのTLVでエンコードされる場合、例えば、異なる種類のは、これら二つの識別子のために割り当てられる必要があります。

7.1.3. Pseudowire MEG_IDs

7.1.3. スードワイヤMEG_IDs

For Pseudowires, a MEG pertains to a single PW. The IP-compatible MEG_ID for a PW is simply the corresponding PW_Path_ID; however, the A1/Z9 ordering MUST be used. The PW_Path_ID is described in Section 6. We note that while the two identifiers are syntactically identical, they have different semantics. This semantic difference needs to be made clear. For instance, if both a PW_Path_ID and a PW_MEG_ID are to be encoded in TLVs, different types need to be assigned for these two identifiers.

スードワイヤについて、MEGは、単一のPWに関連します。 PW用のIP互換MEG_IDは、単に対応するPW_Path_IDあります。ただし、A1 / Z9の順序を使用しなければなりません。 PW_Path_IDは、我々は2つの識別子が構文的に同じであるが、それらは異なる意味を持っていることに注意セクション6に記載されています。この意味上の違いを明確にする必要があります。 PW_Path_IDとPW_MEG_ID両方がのTLVでエンコードされる場合、例えば、異なる種類のは、これら二つの識別子のために割り当てられる必要があります。

7.2. Maintenance Entity Group End Point Identifiers

7.2. メンテナンスエンティティグループエンドポイント識別子

7.2.1. MPLS-TP Section MEP_IDs

7.2.1. MPLS-TP節MEP_IDs

IP-compatible MEP_IDs for MPLS-TP sections above layer 0 are their MPLS-TP LSP_MEP_IDs. See Section 7.2.2.

層0上MPLS-TPセクションのIP互換MEP_IDsは、それらのMPLS-TPのLSP_MEP_IDsあります。 7.2.2項を参照してください。

IP-compatible MEP_IDs for MPLS-TP sections at layer 0 are simply the IF_IDs of each end of the section. For example, for a section whose MEG_ID is:

レイヤー0におけるMPLS-TPセクションのIP互換MEP_IDsは単にセクションの各端部のIF_IDsあります。例えば、そのMEG_IDセクションのためのものです。

A1-IF_ID::Z9-IF_ID

A1-IF_ID :: Z9-IF_ID

the Section MEP_ID at A1 would be:

A1のセクションMEP_IDは次のようになります。

A1-IF_ID

and the Section MEP_ID at Z9 would be:

そしてZ9のセクションMEP_IDは次のようになります。

Z9-IF_ID.

Z9-IF_ID。

Where the Section MEP_ID needs to be globally unique, this is accomplished by using globally unique Node_IDs as defined above. Thus, a globally unique Section MEP_ID becomes:

第MEP_IDはグローバルに一意である必要がある場合、これは、上で定義したグローバルにユニークNode_IDsを使用することによって達成されます。このように、グローバルに一意のセクションMEP_IDは次のようになります。

Global_ID::IF_ID.

Global_ID :: IF_ID。

7.2.2. MPLS-TP LSP_MEP_ID

In order to automatically generate MEP_IDs for MPLS-TP LSPs, we use the elements of identification that are unique to an end point. This ensures that MEP_IDs are unique for all LSPs within an operator. When Tunnels or LSPs cross operator boundaries, these are made unique by pre-pending them with the operator's Global_ID.

自動的にMPLS-TP LSPのためMEP_IDsを生成するために、我々は、エンドポイントに固有の識別要素を使用します。これはMEP_IDsは、オペレータ内のすべてのLSPに対して一意であることを保証します。トンネルやのLSPは、オペレータの境界を越えた場合、これらは、オペレータのGlobal_IDでそれらを事前に保留中でユニーク作られています。

The MPLS-TP LSP_MEP_ID is:

MPLS-TP LSP_MEP_IDは以下のとおりです。

Node_ID::Tunnel_Num::LSP_Num

NODE_ID :: Tunnel_Num :: LSP_Num

where the Node_ID is the node in which the MEP is located and Tunnel_Num is the tunnel number unique to that node. In the case of co-routed bidirectional LSPs, the single LSP_Num is used at both ends. In the case of associated bidirectional LSPs, the LSP_Num is the one unique to where the MEP resides.

NODE_IDはMEPが配置されているノードであり、Tunnel_Numは、そのノードに固有のトンネルの数です。共ルーティング双方向LSPの場合には、単一LSP_Numは両端で使用されています。関連する双方向LSPの場合、LSP_NumはMEPが存在する場所に固有のものです。

In situations where global uniqueness is required, this becomes:

グローバル一意性が必要とされる状況では、これは次のようになります。

Global_ID::Node_ID::Tunnel_Num::LSP_Num

Global_ID :: NODE_ID :: Tunnel_Num :: LSP_Num

7.2.3. MEP_IDs for Pseudowires

7.2.3. スードワイヤ用MEP_IDs

Like MPLS-TP LSPs, Pseudowire end points (T-PEs) require MEP_IDs. In order to automatically generate MEP_IDs for PWs, we simply use the AGI plus the AII associated with that end of the PW. Thus, a MEP_ID for a Pseudowire T-PE takes the form:

MPLS-TP LSPのように、擬似回線のエンドポイント（T-PES）がMEP_IDsを必要とします。自動的PWのためのMEP_IDsを生成するために、我々は単にAGIプラスPWの端部に関連したAIIを使用しています。このように、疑似回線T-PE用MEP_IDの形式をとります。

AGI::Global_ID::Node_ID::AC_ID

AGI :: Global_ID :: NODE_ID :: AC_ID

where the Node_ID is the node in which the MEP is located and the AC_ID is the AC_ID of the Pseudowire at that node.

NODE_IDはMEPが配置されているノードであり、AC_IDは、そのノードにおける疑似回線のAC_IDあります。

7.3. Maintenance Entity Group Intermediate Point Identifiers

7.3. メンテナンスエンティティグループの中間点識別子

For a MIP that is associated with a particular interface, we simply use the IF_ID (see Section 4) of the interfaces that are cross-connected. This allows MIPs to be independently identified in one node where a per-interface MIP model is used. If only a per-node MIP model is used, then one MIP is configured. In this case, the MIP_ID is formed using the Node_ID and an IF_Num of 0.

特定のインターフェイスに関連付けられたMIPのために、我々は、単に相互接続されているインターフェースのIF_ID（セクション4）を使用します。これは、インターフェイス単位のMIPモデルが使用される場合のMIPは、独立して、一つのノードに識別することができます。ノードごとのMIPモデルが使用されている場合にのみ、そしてあるMIPが構成されています。この場合、MIP_IDはNODE_IDと0のIF_Numを用いて形成されています。

8. Security Considerations

8.セキュリティの考慮事項

This document describes an information model and, as such, does not introduce security concerns. Protocol specifications that describe use of this information model, however, may introduce security risks and concerns about authentication of participants. For this reason, the writers of protocol specifications for the purpose of describing implementation of this information model need to describe security and authentication concerns that may be raised by the particular mechanisms defined and how those concerns may be addressed.

この文書は、情報モデルを記述して、など、セキュリティ上の懸念を導入しません。この情報モデルの使用を記載するプロトコル仕様は、しかし、参加者の認証に関するセキュリティリスクや懸念を導入することができます。このため、この情報モデルの実装を説明するためのプロトコル仕様の作家は、特定の定義されたメカニズムとどのようにこれらの懸念に対処することができることで上昇させることができるセキュリティと認証の問題を記述する必要があります。

Uniqueness of the identifiers from this document is guaranteed by the assigner (e.g., a Global_ID is unique based on the assignment of ASNs from IANA and both a Node_ID and an IF_Num are unique based on the assignment by an operator). Failure by an assigner to use unique values within the specified scoping for any of the identifiers defined herein could result in operational problems. For example, a non-unique MEP value could result in failure to detect a mis-merged LSP.

この文書から識別子の一意性（例えば、Global_IDはIANAからAS番号の割り当てに基づいて、一意であり、NODE_IDとIF_Num両方がオペレータによって割り当てに基づいてユニークである）割当によって保証されています。本明細書に定義された識別子のいずれかに指定したスコープ内で一意の値を使用するには、割当によって失敗すると、操作上の問題につながる可能性があります。例えば、非ユニークMEP値は誤マージされたLSPを検出するために失敗につながる可能性があります。

Protocol specifications that utilize the identifiers defined herein need to consider the implications of guessable identifiers and, where there is a security implication, SHOULD give advice on how to make identifiers less guessable.

本明細書に定義された識別子を使用するプロトコルの仕様は、セキュリティの含意がある場合、識別子はあまり推測可能なようにする方法についてアドバイスを与えるべきで、推測可能な識別子の影響を考慮する必要があります。

9. References

9.参考文献

9.1. Normative References

9.1. 引用規格

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

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

[2] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.

[2] Awduche、D.、バーガー、L.、ガン、D.、李、T.、スリニヴァサン、V.、およびG.ツバメ、 "RSVP-TE：LSPトンネルのためのRSVPの拡張"、RFC 3209年12月2001。

[3] Metz, C., Martini, L., Balus, F., and J. Sugimoto, "Attachment Individual Identifier (AII) Types for Aggregation", RFC 5003, September 2007.

[3]メッツ、C.、マルティーニ、L.、Balus、F.、及びJ.杉本、 "集約のためのアタッチメント個体識別子（AII）タイプ"、RFC 5003、2007年9月。

[4] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003.

[4]バーガー、L.、 "一般化されたマルチプロトコルラベルスイッチング（GMPLS）機能説明シグナリング"、RFC 3471、2003年1月。

[5] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.

[5]バーガー、L.、 "一般化マルチプロトコルラベルスイッチング（GMPLS）シグナリング資源予約プロトコル - トラフィックエンジニアリング（RSVP-TE）を拡張"、RFC 3473、2003年1月を。

[6] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. Heron, "Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)", RFC 4447, April 2006.

[6]マティーニ、L.、ローゼン、E.、エル・Aawar、N.、スミス、T.、およびG.サギ、 "ラベル配布プロトコル（LDP）を使用して擬似回線の設定とメンテナンス"、RFC 4447、2006年4月。

9.2. Informative References

9.2. 参考文献

[7] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., and S. Ueno, "Requirements of an MPLS Transport Profile", RFC 5654, September 2009.

[7]ニーヴン、ジェンキンス、B.、Brungard、D.、ベッツ、M.、Sprecher、N.、およびS.上野、 "MPLSトランスポートプロファイルの要件"、RFC 5654、2009年9月。

[8] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000.

[8] McCloghrie、K.およびF. Kastenholzと、 "インターフェイスグループMIB"、RFC 2863、2000年6月。

[9] Bocci, M., Bryant, S., Frost, D., Levrau, L., and L. Berger, "A Framework for MPLS in Transport Networks", RFC 5921, July 2010.

[9]ボッチ、M.、ブライアント、S.、フロスト、D.、Levrau、L.、およびL.バーガー、 "トランスポートネットワークにおけるMPLSのための枠組み"、RFC 5921、2010年7月。

[10] Frost, D., Bryant, S., and M. Bocci, "MPLS Transport Profile Data Plane Architecture", RFC 5960, August 2010.

[10]フロスト、D.、ブライアント、S.、およびM.ボッチは、RFC 5960、2010年8月、 "MPLS交通は、データプレーンのアーキテクチャプロフィール"。

Authors' Addresses

著者のアドレス

Matthew Bocci Alcatel-Lucent Voyager Place, Shoppenhangers Road Maidenhead, Berks SL6 2PJ UK

マシューボッチアルカテル・ルーセントボイジャープレイス、Shoppenhangers道路メイデンヘッド、バークスSL6 2PJ英国

EMail: matthew.bocci@alcatel-lucent.com

メールアドレス：matthew.bocci@alcatel-lucent.com

George Swallow Cisco

ジョージ・ツバメシスコ

EMail: swallow@cisco.com

メールアドレス：swallow@cisco.com

Eric Gray Ericsson 900 Chelmsford Street Lowell, Massachussetts 01851-8100

エリック・グレー・エリクソン900チェルムズフォードストリートローウェル、マサチューセッツ州01851から8100

EMail: eric.gray@ericsson.com

メールアドレス：eric.gray@ericsson.com