[要約] RFC 6370は、MPLS-TP（MPLS Transport Profile）の識別子に関する標準化された仕様です。このRFCの目的は、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
MPLS輸送プロファイル（MPLS-TP）識別子
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の管理と運用、管理、およびメンテナンス（OAM）関数のIP/ MPLS規則の識別子を定義します。
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およびPSEUDOWIREエミュレーションエッジ（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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc6370で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2011 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ドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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
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環境の要素とオブジェクトを制御プレーンなしで構成および管理できることが必要です。このような環境では、識別子を定義するための多くの規則が可能です。このドキュメントでは、MPLS-TP管理およびIP/MPLSコンベンションと互換性のあるOAM関数の識別子を定義します。つまり、識別子は、既存のIP、MPLS、GMPLS、および擬似意図定義と互換性があるように選択されています。
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およびPSEUDOWIREエミュレーションエッジ（PWE3）アーキテクチャ内にMPLS輸送プロファイルを含めるための共同インターネットエンジニアリングタスクフォース（IETF） /国際電気通信連合電気通信標準化セクター（ITU-T）の製品です。ITU-Tで定義されているパケット輸送ネットワークの機能と機能をサポートする。
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
PW：Pseudowire
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
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].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、RFC 2119 [1]に記載されているように解釈される。
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.
同じ識別子タイプが連結で複数回使用される場合、それらはDash（ - ）によって識別子に結合されたプレフィックスによって適格です。たとえば、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を参照）に表示されるフィールドを指示することにより、プロトコル設計を制約することを意図していません。
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
* Global_id
* Node
* ノード
* Interface
* インターフェース
* Tunnel
* トンネル
* LSP
* LSP
* PW
* pw
* MEG
* メグ
* MEP
* MEP
* MIP
* 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の間の論理的関連を提供するエンティティを記述するために使用されます。トンネルは、1つ以上のLSPによってインスタンス化され、追加のLSPがトンネルの保護または再groomingに使用されます。
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）を定義します。AIIは3つの部分で構成されています。オペレーター、プレフィックス、そして最後に、アタッチメント回路識別子を一意に識別するGlobal_id。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
グローバルIDには、プロバイダーの自律システム番号（ASN）の2-OCTETまたは4-OCTET値を含めることができます。グローバルIDは、
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.
実際のAIIを含むPEをホストする自律システム。オペレーターの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-OCTETから導出する必要があります。2-OCTETを低次のオクテットに配置し、2つの高次オクテットをゼロに設定することにより、2-OCTETとしての2-OCTETが4-OCTETに組み込まれていることに注意してください。
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の使用とは関係ありません。
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のIPv4ループバックアドレスをnode_idとして使用すると便利な場合があります。ただし、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 [8]で定義されているIFNumオブジェクトとの関係がないことに注意してください。さらに、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のコンテキスト内でインターフェイスを一意に識別します。node_idをif_numと連結することにより形成されます。つまり、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.
この条約は、GMPLとの互換性を可能にするために選択されました。GMPLSシグナル伝達機能説明[4]には、インターフェイス識別が必要です。GMPLSを使用すると、interface_idに3つの形式が許可されます。3番目の形式は、IPv4アドレスと、特定のインターフェイスの32ビットの符号なし整数で構成されています。MPLS-TPで定義された形式はこの形式と一致していますが、IPv4アドレスの代わりにnode_idを使用します。
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が必要です。
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は、保護および修復イベントのために時間とともに変化する場合があります。サービスを明確に識別するために、（たとえば）作業LSPが提供し、保護LSPによって保護されているサービスに「MPLS-TPトンネル」という用語または単に「トンネル」という用語を使用します。「トンネル識別子」（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.
複数のLSP（たとえば）を使用して、共通のエンドポイントセットを持つ単一のサービスをサポートする場合、Tunnel_IDを使用すると、サーバーレイヤーとクライアントレイヤー間の些細なマッピングが可能になり、定義されている共通のサービス識別子が提供されます。クライアントによってまたは使用されます。
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.
この使用法は保護スキームを制約することを意図しておらず、クライアントに単一のサービス添付ファイルポイントとして表示される可能性のあるサービス（保護または保護されていない）を特定するために使用される場合があることに注意してください。Tunnel_idを動作および保護全体にわたって一貫性を保つことは、LSPSで現在GMPLS内で使用されている有用な構成要素です。ただし、保護LSPのTunnel_idは、対応する作業LSPによって使用されるものとは異なる場合があります。
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:
2つのエンドポイント識別子の連結は、完全な識別子として機能します。A1/Z9コンベンションを使用すると、Tunnel_IDの形式は次のとおりです。
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}
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で構成されています。
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 [9]で定義されているMPLS-TPサブパスメンテナンスエンティティ（SPME）も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
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
is synonymous with the one above.
上記のものと同義です。
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
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
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から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:
16ビットの署名されていない整数は、イングレスのtunnel_numの範囲内で一意です。したがって、MPLS-TP関連の双方向LSP_IDの形式は次のとおりです。
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
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:
LSP_IDがグローバルに一意である必要がある場合、これは上記のようにグローバルに一意のnode_idsを使用することによって達成されます。したがって、グローバルに一意のLSP_IDは次のとおりです。
A1-{Global_ID::Node_ID::Tunnel_Num::LSP_Num}::
Z9-{Global_ID::Node_ID::Tunnel_Num::LSP_Num}
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]に基づいています。このセクションでは、MPLS-TP LSP_IDからRSVP-TEへのマッピングを定義します。現時点では、RSVP-TEはGlobal_idsに対応するためにまだ拡張されていません。したがって、マッピングはLSP_IDのネットワーク一意の形式に対してのみ作成され、オペレーターが有効なIPv4アドレスからnode_idを導出することを選択したと想定しています。
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.
GMPLSとRSVP-TEシグナル伝達は、5タプルを使用して、オペレーターのネットワーク内のLSPを一意に識別します。このタプルは、トンネルエンドポイントアドレス、トンネル_ID、拡張トンネルID、トンネル送信者アドレス、および（RSVP）LSP_IDで構成されています。RFC 3209は、拡張トンネルIDがどのように選択されるかを柔軟にすることができ、直接マッピングは義務付けられていません。ただし、よく使用される規則の1つは、トンネルセンダーアドレスと同じ値でこのフィールドに入力することです。以下の例は、その条約に従っています。これらは単なる例であることに注意してください。
For a co-routed bidirectional LSP signaled from A1 to Z9, the mapping to the GMPLS 5-tuple is as follows:
A1からZ9に合図された共同双方向LSPの場合、GMPLS 5タプルへのマッピングは次のとおりです。
* Tunnel End-point Address = Z9-Node_ID
* トンネルエンドポイントアドレス= z9-node_id
* Tunnel_ID = A1-Tunnel_Num
* 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.
2つのノードA1とZ9の間の関連する双方向LSPは、2つの単方向LSPで構成されます。1つはA1からZ9、もう1つはZ9からA1です。
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タプルへのマッピングが必要な状況では、次のマッピングが使用されます。A1からZ9 LSPの場合、マッピングは次のとおりです。
* Tunnel End-point Address = Z9-Node_ID
* トンネルエンドポイントアドレス= z9-node_id
* Tunnel_ID = A1-Tunnel_Num
* 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
* （rsvp）lsp_id = a1-lsp_num
Likewise, the Z9 to A1 LSP, the mapping would be:
同様に、Z9からA1 LSP、マッピングは次のとおりです。
* Tunnel End-point Address = A1-Node_ID
* トンネルエンドポイントアドレス= a1-node_id
* Tunnel_ID = Z9-Tunnel_Num
* 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
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.
Pseudowireシグナル伝達（RFC 4447 [6]）は、擬似動物のシグナルに使用される2つのFECを定義します。これらのうち、RFC 5003 [3]で定義されているAIIタイプ2とともに、一般化されたPWID FEC（タイプ129）は、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は、RFC 5003で定義されているGlobal_idと同一です。Node_IDはプレフィックスとして使用されます。AC_IDは、RFC 5003で定義されています。
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（双方向）擬似ワイヤーは、各方向に1つの単方向LSPのペアで構成されています。したがって、シグナル伝達の場合、一般化された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全体を参照する場合、この区別は重要ではありません。つまり、AGIAの一般化されたPWID FEC（タイプ129）:: AIIB :: AIICは、AGIA :: 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:
信号環境では、A1からZ9へのLSPは、一般化されたPWID FEC（タイプ129）のフィールドが次のように完了し、A1からZ9へのラベル要求で開始されます。
AGI = AGI
SAII = A1-{Global_ID::Node_ID::AC_ID}
TAII = Z9-{Global_ID::Node_ID::AC_ID}
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}
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のコンテキスト内では、MEPSとMIPSを一意に識別する必要があります。このセクションでは、メンテナンスエンティティグループとメンテナンスエンティティを一意に識別する手段を定義します。また、メンテナンスエンティティグループのコンテキスト内でMEPとMIPを一意に定義します。
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互換性のある識別子に従うように選択されました。
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_IDを連結することにより形成されます。例えば：
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}
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の順序を使用する必要があります。双方向Co-Routed 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_IDの両方がTLVでエンコードされる場合、これら2つの識別子に異なるタイプを割り当てる必要があります。
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については、セクション6で説明しています。2つの識別子は構文的に同一であるが、セマンティクスが異なることに注意してください。このセマンティックな違いを明確にする必要があります。たとえば、PW_PATH_IDとPW_MEG_IDの両方がTLVでエンコードされる場合、これら2つの識別子に異なるタイプを割り当てる必要があります。
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
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。
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にとって一意であることが保証されます。トンネルまたはLSPSクロスオペレーターの境界線の場合、これらはオペレーターのGlobal_idでプリを保留することによりユニークになります。
The MPLS-TP LSP_MEP_ID is:
MPLS-TP LSP_MEP_IDは次のとおりです。
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
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 LSPSと同様に、Pseudowire End Points（T-PES）がMEP_IDSを必要とします。PWS用のMEP_IDSを自動的に生成するために、AGIとPWのその端に関連付けられたAIIを使用するだけです。したがって、pseudowire t-peのmep_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です。
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を参照）を使用するだけです。これにより、MIPSは、インターフェイスごとのMIPモデルが使用される1つのノードで独立して識別できます。ノードごとのMIPモデルのみを使用する場合、1つのMIPが構成されます。この場合、mip_idはnode_idと0のif_numを使用して形成されます。
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からのASNの割り当てに基づいて一意であり、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.
本明細書に定義されている識別子を利用するプロトコル仕様は、推測可能な識別子の意味を考慮する必要があり、セキュリティの意味がある場合、識別子を推測を控えない方法についてアドバイスを与える必要があります。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[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.、Berger、L.、Gan、D.、Li、T.、Srinivasan、V。、およびG. Swallow、「RSVP-TE：LSPトンネルのRSVPへの拡張」、RFC 3209、2001年12月。
[3] Metz, C., Martini, L., Balus, F., and J. Sugimoto, "Attachment Individual Identifier (AII) Types for Aggregation", RFC 5003, September 2007.
[3] Metz、C.、Martini、L.、Balus、F。、およびJ. Sugimoto、「集約のためのアタッチメント個別識別子（AII）タイプ」、RFC 5003、2007年9月。
[4] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003.
[4] Berger、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] Berger、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] Martini、L.、Rosen、E.、El-Aawar、N.、Smith、T。、およびG. Heron、「ラベル分布プロトコル（LDP）を使用した擬似ワイヤーのセットアップとメンテナンス」、RFC 4447、2006年4月。
[7] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., and S. Ueno, "Requirements of an MPLS Transport Profile", RFC 5654, September 2009.
[7] Niven-Jenkins、B.、Brungard、D.、Betts、M.、Sprecher、N。、およびS. Ueno、「MPLS輸送プロファイルの要件」、RFC 5654、2009年9月。
[8] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000.
[8] McCloghrie、K。およびF. Kastenholz、「The Interfaces Group 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] Bocci、M.、Bryant、S.、Frost、D.、Levrau、L。、およびL. Berger、「輸送ネットワークにおけるMPLSのフレームワーク」、RFC 5921、2010年7月。
[10] Frost, D., Bryant, S., and M. Bocci, "MPLS Transport Profile Data Plane Architecture", RFC 5960, August 2010.
[10] Frost、D.、Bryant、S。、およびM. Bocci、「MPLS輸送プロファイルデータプレーンアーキテクチャ」、RFC 5960、2010年8月。
Authors' Addresses
著者のアドレス
Matthew Bocci Alcatel-Lucent Voyager Place, Shoppenhangers Road Maidenhead, Berks SL6 2PJ UK
Matthew Bocci Alcatel-Lucent Voyager Place、Shoppenhangers Road Maidenhead、Berks SL6 2PJ UK
EMail: matthew.bocci@alcatel-lucent.com
George Swallow Cisco
ジョージはシスコを飲み込みます
EMail: swallow@cisco.com
Eric Gray Ericsson 900 Chelmsford Street Lowell, Massachussetts 01851-8100
エリック・グレイ・エリクソン900チェルムスフォード・ストリート・ローウェル、マサチューセッツ01851-8100
EMail: eric.gray@ericsson.com