[要約] 要約： RFC 6923は、MPLS-TP（MPLS Transport Profile）の識別子に関するITU-Tの規則に従うことを目的としています。目的： このRFCの目的は、MPLS-TPの識別子の一貫性と相互運用性を確保するために、ITU-Tの規則を適用することです。
Internet Engineering Task Force (IETF) R. Winter
Request for Comments: 6923 NEC
Category: Standards Track E. Gray
ISSN: 2070-1721 Ericsson
H. van Helvoort
Huawei Technologies Co., Ltd.
M. Betts
ZTE
May 2013
MPLS Transport Profile (MPLS-TP) Identifiers Following ITU-T Conventions
ITU-T規則に従ったMPLSトランスポートプロファイル（MPLS-TP）識別子
Abstract
概要
This document specifies an extension to the identifiers to be used in the Transport Profile of Multiprotocol Label Switching (MPLS-TP). Identifiers that follow IP/MPLS conventions have already been defined. This memo augments that set of identifiers for MPLS-TP management and Operations, Administration, and Maintenance (OAM) functions to include identifier information in a format typically used by the International Telecommunication Union Telecommunication Standardization Sector (ITU-T).
このドキュメントでは、マルチプロトコルラベルスイッチング（MPLS-TP）のトランスポートプロファイルで使用される識別子の拡張について説明します。 IP / MPLS規則に従う識別子はすでに定義されています。このメモは、MPLS-TPの管理と運用、管理、および保守（OAM）機能の識別子のセットを補強して、国際電気通信連合電気通信標準化部門（ITU-T）で通常使用される形式で識別子情報を含めます。
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/rfc6923.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6923で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2013 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に記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................2
1.1. Terminology ................................................3
1.2. Requirements Notation ......................................4
1.3. Notational Conventions .....................................4
2. Named Entities ..................................................4
3. Uniquely Identifying an Operator -- the ICC_Operator_ID .........5
3.1. Use of the ICC_Operator_ID .................................6
4. Node and Interface Identifiers ..................................7
5. MPLS-TP Tunnel and LSP Identifiers ..............................7
5.1. MPLS-TP Point-to-Point Tunnel Identifiers ..................7
5.2. MPLS-TP LSP Identifiers ....................................8
5.2.1. MPLS-TP Co-Routed Bidirectional LSP Identifiers .....8
5.2.2. MPLS-TP Associated Bidirectional LSP Identifiers ....9
6. Pseudowire Path Identifiers .....................................9
7. Maintenance Identifiers .........................................9
7.1. MEG Identifiers ...........................................10
7.2. MEP Identifiers ...........................................10
7.3. MIP Identifiers ...........................................10
8. Security Considerations ........................................11
9. References .....................................................11
9.1. Normative References ......................................11
9.2. Informative References ....................................12
This document augments the initial set of identifiers to be used in the Transport Profile of Multiprotocol Label Switching (MPLS-TP) defined in [RFC6370] by adding new identifiers based on ITU-T conventions. It is not intended that both types of identifiers will be used at the same time in the same domain.
このドキュメントは、ITU-T規則に基づいて新しい識別子を追加することにより、[RFC6370]で定義されたマルチプロトコルラベルスイッチング（MPLS-TP）のトランスポートプロファイルで使用される識別子の初期セットを補強します。両方のタイプの識別子が同じドメインで同時に使用されることは意図されていません。
[RFC6370] defines a set of MPLS-TP transport and management entity identifiers to support bidirectional (co-routed and associated) point-to-point MPLS-TP Label Switched Paths (LSPs), including Pseudowires (PWs) and Sections that follow the IP/MPLS conventions.
[RFC6370]は、一連のMPLS-TPトランスポートおよび管理エンティティIDを定義して、疑似配線（PW）とそれに続くセクションを含む、双方向（共経路および関連）ポイントツーポイントMPLS-TPラベルスイッチドパス（LSP）をサポートします。 IP / MPLS規則。
This document specifies an alternative way to generate unambiguous identifiers for operators/service providers based on ITU-T conventions and specifies how these operator/service provider identifiers can be used to generate unambiguous identifiers for the existing set of identifiable MPLS-TP entities described in [RFC6370].
このドキュメントでは、ITU-T規則に基づいてオペレーター/サービスプロバイダーの明確な識別子を生成する別の方法を指定し、これらのオペレーター/サービスプロバイダーの識別子を使用して、[で説明する既存の識別可能なMPLS-TPエンティティセットの明確な識別子を生成する方法を指定します。 RFC6370]。
This document solely defines those identifiers. Their use and possible protocol extensions to carry them are out of the scope of this document.
このドキュメントでは、これらの識別子のみを定義しています。それらの使用およびそれらを実行するための可能なプロトコル拡張は、このドキュメントの範囲外です。
In this document, we follow the notational convention laid out in [RFC6370], which is included in this document for convenience in Section 1.3.
このドキュメントでは、[RFC6370]で規定されている表記規則に従います。これは、セクション1.3の便宜上、このドキュメントに含まれています。
CC: Country Code
CC：国コード
ICC: ITU Carrier Code
ICC：ITUキャリアコード
ISO: International Organization for Standardization
ISO：国際標準化機構
ITU: International Telecommunication Union
ITU：国際電気通信連合
ITU-T: ITU Telecommunication Standardization Sector
ITU-T：ITU Telecommunication Standardization Sector
LSP: Label Switched Path
LSP：ラベルスイッチドパス
MEG: Maintenance Entity Group
MEG：メンテナンスエンティティグループ
MEP: Maintenance Entity Group End Point
MEP：メンテナンスエンティティグループのエンドポイント
MIP: Maintenance Entity Group Intermediate Point
MIP：メンテナンスエンティティグループ中間ポイント
MPLS: Multiprotocol Label Switching
MPLS：マルチプロトコルラベルスイッチング
PW: Pseudowire
説明：シュードビル
TSB: (ITU-T) Telecommunication Standardization Bureau
TSB：（ITU-T）電気通信標準化局
UMC: Unique MEG ID Code
UMC：一意のMEG IDコード
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
This document uses the notational conventions laid out in [RFC6370]:
このドキュメントでは、[RFC6370]で規定されている表記規則を使用しています。
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.
すべての複数単語のアトミックIDは、単語を結合するために単語間にアンダースコア（_）を使用します。識別子の多くは、他の識別子のセットで構成されています。これらは、二重コロン「::」表記で結合された後者の識別子をリストすることによって表されます。
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 ... or even what fields appear in which objects.
ただし、識別子の一意性は順序に依存せず、識別子を構成するフィールドの一意性とスコープに依存することに注意してください。さらに、好ましい順序付けは、特定のフィールドシーケンスを指示することでプロトコル設計を制約することを意図したものではなく、どのオブジェクトがどのオブジェクトに現れるかさえも意図していません。
This document provides additional identifiers supplementing those defined in [RFC6370]. The identifiers in [RFC6370] are composed of a set of atomic identifiers, and this document defines some new atomic identifiers that can be substituted for some of those that have already been defined, to create new identifiers. The set of identifiers defined in [RFC6370] is:
このドキュメントは[RFC6370]で定義されたものを補足する追加の識別子を提供します。 [RFC6370]の識別子は、アトミック識別子のセットで構成されており、このドキュメントでは、新しい識別子を作成するために、すでに定義されているものの代わりに使用できる新しいアトミック識別子をいくつか定義しています。 [RFC6370]で定義されている識別子のセットは次のとおりです。
o Global_ID
o Global_ID
o Node o Interface
お ので お いんてｒふぁせ
o Tunnel
o トンネル
o LSP
o LSP
o PW
o PW
o MEG
o MEG
o MEP
o MEP
o MIP
o MIP
The following sections go through this list of identifiers one by one. The structure of this document is loosely aligned with the structure of [RFC6370].
次のセクションでは、この識別子のリストを1つずつ見ていきます。このドキュメントの構造は[RFC6370]の構造と大まかに整合しています。
In [RFC6370], an operator is uniquely identified by the Global_ID, which is based on the Autonomous System (AS) number of the operator. The ITU-T, however, traditionally identifies operators and service providers based on the ITU Carrier Code (ICC) as specified in [M1400].
[RFC6370]では、オペレーターは、オペレーターの自律システム（AS）番号に基づくGlobal_IDによって一意に識別されます。ただし、ITU-Tは従来、[M1400]で指定されているITUキャリアコード（ICC）に基づいて事業者とサービスプロバイダーを識別しています。
The ITU-T Telecommunication Standardization Bureau (TSB) maintains a list of assigned ICCs [ICC-list]. Note that ICCs, all of which are referenced at [ICC-list], can be assigned to ITU-T members as well as non-members. The national regulatory authorities act as an intermediary between the ITU/TSB and operators/service providers. One of the things that the national authorities are responsible for in the process of assigning an ICC is to ensure that the Carrier Codes are unique within their country. This uniqueness assumption is the basis for creating a globally unique ICC-based operator ID.
ITU-T電気通信標準化局（TSB）は、割り当てられたICCのリスト[ICC-list]を維持しています。 [ICC-list]で参照されるICCは、ITU-Tメンバーだけでなく非ITU-Tメンバーにも割り当てることができることに注意してください。国内の規制当局は、ITU / TSBとオペレーター/サービスプロバイダーの間の仲介者として機能します。 ICCを割り当てるプロセスにおいて各国当局が責任を持つことの1つは、キャリアコードが国内で一意であることを確認することです。この一意性の前提は、グローバルに一意のICCベースのオペレーターIDを作成するための基礎です。
The ICC itself is a string of one to six characters, each character being either alphabetic (i.e., A-Z) or numeric (i.e., 0-9). Alphabetic characters in the ICC SHOULD be represented with uppercase letters.
ICC自体は1〜6文字の文字列であり、各文字はアルファベット（つまりA〜Z）または数字（つまり0〜9）のいずれかです。 ICCのアルファベット文字は大文字で表現する必要があります（SHOULD）。
Global uniqueness is assured by concatenating the ICC with a Country Code (CC). The Country Code (alpha-2) is a string of two alphabetic characters represented with uppercase letters (i.e., A-Z).
ICCと国コード（CC）を連結することにより、グローバルな一意性が保証されます。国コード（alpha-2）は、大文字（A-Z）で表される2つのアルファベット文字の文字列です。
The International Organization for Standardization (ISO) establishes internationally recognized codes for the representation of names of countries, territories or areas of geographical interest, and their subdivisions, published as a list of CCs [CC-list] in ISO Standard 3166-1 [ISO3166-1].
国際標準化機構（ISO）は、国、地域、または地理的に関心のある地域、およびそれらの下位区分の名前を表すための国際的に認められたコードを確立し、CCのリスト[CC-list]としてISO Standard 3166-1 [ISO3166 -1]。
The ICC and CC characters are coded according to ITU-T Recommendation T.50 [T.50].
ICCおよびCC文字は、ITU-T勧告T.50 [T.50]に従ってコード化されています。
Together, the CC and the ICC form the ICC_Operator_ID as:
CCとICCは一緒に、ICC_Operator_IDを次のように形成します。
CC::ICC
CC :: ICC
The ICC_Operator_ID is used as a replacement for the Global_ID as specified in [RFC6370], i.e., its purpose is to provide a globally unique context for other MPLS-TP identifiers.
ICC_Operator_IDは、[RFC6370]で指定されているGlobal_IDの代わりとして使用されます。つまり、その目的は、他のMPLS-TP識別子にグローバルに一意のコンテキストを提供することです。
As an example, an Interface Identifier (IF_ID) in [RFC6370] is specified as the concatenation of the Node_ID (a unique 32-bit value assigned by the operator) and the Interface Number (IF_Num, a 32-bit unsigned integer assigned by the operator that is unique within the scope of a Node_ID). To make this IF_ID globally unique, the Global_ID is prefixed. This memo specifies the ICC_Operator_ID as an alternative format that, just like the Global_ID, is prefixed to the IF_ID. Using the notation from RFC 6370 [RFC6370]:
例として、[RFC6370]のインターフェイス識別子（IF_ID）は、Node_ID（オペレーターによって割り当てられた一意の32ビット値）とインターフェイス番号（IF_Num、32ビットの符号なし整数、 Node_IDのスコープ内で一意の演算子）。このIF_IDをグローバルに一意にするには、Global_IDをプレフィックスとして付けます。このメモは、ICC_Operator_IDを、Global_IDと同様にIF_IDの前に付加される代替フォーマットとして指定します。 RFC 6370 [RFC6370]の表記法を使用：
Global_ID::Node_ID::IF_Num
is functionally equivalent to:
機能的には以下と同等です。
ICC_Operator_ID::Node_ID::IF_Num
The same substitution procedure applies to all identifiers specified in [RFC6370] with the exception of the MEG ID, MEP ID, and MIP ID. MEG, MEP, and MIP Identifiers are redefined in this document (see Sections 7.1, 7.2, and 7.3, respectively).
MEG ID、MEP ID、およびMIP IDを除いて、同じ置換手順が[RFC6370]で指定されたすべての識別子に適用されます。 MEG、MEP、およびMIP識別子は、このドキュメントで再定義されています（それぞれセクション7.1、7.2、および7.3を参照）。
The format of the Node and Interface Identifiers are not changed by this memo except for the case when global uniqueness is required.
グローバルおよび一意性が必要な場合を除いて、ノードおよびインターフェース識別子のフォーマットはこのメモによって変更されません。
[RFC6370] defines the Node Identifier (Node_ID) as a unique 32-bit value assigned by the operator within the scope of a Global_ID. The structure of the Node_ID itself is not defined as it is left to the operator to choose an appropriate value. The value zero, however, is reserved and MUST NOT be used.
[RFC6370]は、ノード識別子（Node_ID）を、Global_IDのスコープ内でオペレーターによって割り当てられた一意の32ビット値として定義します。 Node_ID自体の構造は定義されていません。適切な値を選択するのはオペレーターに任されているためです。ただし、値0は予約されており、使用してはなりません。
This document does not change the above definition. However, in case global uniqueness is required, the Node_ID is prefixed with the ICC_Operator_ID as defined in Section 3.
このドキュメントは上記の定義を変更しません。ただし、グローバルな一意性が必要な場合は、セクション3で定義されているように、Node_IDの前にICC_Operator_IDが付けられます。
[RFC6370] further defines interface numbers (IF_Num) as 32-bit unsigned integers that can be freely assigned by the operator and must be unique in the scope of the respective Node_ID. The IF_Num value 0 has a special meaning, and therefore, it MUST NOT be used to identify an MPLS-TP interface.
[RFC6370]はさらに、インターフェイス番号（IF_Num）を、オペレーターが自由に割り当てることができる32ビットの符号なし整数として定義し、それぞれのNode_IDのスコープ内で一意でなければなりません。 IF_Num値0には特別な意味があるため、MPLS-TPインターフェイスを識別するために使用してはなりません（MUST NOT）。
An Interface Identifier (IF_ID) identifies an interface uniquely within the context of an ICC_Operator_ID. It is formed by concatenating the Node_ID with the IF_Num to result in a 64-bit identifier formed as Node_ID::IF_Num.
インターフェイス識別子（IF_ID）は、ICC_Operator_IDのコンテキスト内でインターフェイスを一意に識別します。これは、Node_IDをIF_Numと連結して、Node_ID :: IF_Numとして形成される64ビットの識別子を生成することによって形成されます。
Global uniqueness of the IF_ID, if needed, can be assured by prefixing the identifier with the ICC_Operator_ID.
IF_IDのグローバルな一意性は、必要に応じて、識別子の前にICC_Operator_IDを付けることで保証できます。
This document does not change the definition for local Tunnel and LSP IDs. When global uniqueness is needed, the format of these identifiers is as described in Sections 5.1 and 5.2.
このドキュメントでは、ローカルトンネルおよびLSP IDの定義は変更されません。グローバルな一意性が必要な場合、これらの識別子の形式は、セクション5.1および5.2で説明されています。
Tunnel IDs (Tunnel_ID) are based on the end points' Node_IDs and locally assigned tunnel numbers (Tunnel_Num), which identify the tunnel at each end point. The tunnel number is a 16-bit unsigned integer unique within the context of the Node_ID. A full Tunnel ID is represented by the concatenation of these two end-point-specific identifiers. Using the A1/Z9 convention, the format of a Tunnel_ID is:
トンネルID（Tunnel_ID）は、エンドポイントのNode_IDと、各エンドポイントのトンネルを識別するローカルに割り当てられたトンネル番号（Tunnel_Num）に基づいています。トンネル番号は、Node_IDのコンテキスト内で一意の16ビットの符号なし整数です。完全なトンネルIDは、これら2つのエンドポイント固有の識別子の連結によって表されます。 A1 / Z9規則を使用すると、Tunnel_IDの形式は次のようになります。
A1-{Node_ID::Tunnel_Num}::Z9-{Node_ID::Tunnel_Num}
Where global uniqueness is required, using ITU-T conventions, the ICC_Operator_ID is prefixed to the Tunnel_ID. Thus, a globally unique Tunnel_ID becomes:
グローバルな一意性が必要な場合は、ITU-T規則を使用して、ICC_Operator_IDがTunnel_IDの前に付加されます。したがって、グローバルに一意のTunnel_IDは次のようになります。
A1-{ICC_Operator_ID::Node_ID::Tunnel_Num}::
Z9-{ICC_Operator_ID::Node_ID::Tunnel_Num}
As per [RFC6370], when an MPLS-TP tunnel is configured, it MUST be assigned a unique IF_ID at each end point as defined in Section 4.
[RFC6370]によると、MPLS-TPトンネルが構成されている場合、セクション4で定義されているように、各エンドポイントで一意のIF_IDを割り当てる必要があります。
The following subsections define identifiers for MPLS-TP co-routed bidirectional and associated bidirectional LSPs. Since MPLS-TP Sub-Path Maintenance Entities (SPMEs) are also LSPs, they use the same form of IDs.
次のサブセクションでは、MPLS-TPコルーテッド双方向および関連する双方向LSPの識別子を定義します。 MPLS-TPサブパスメンテナンスエンティティ（SPME）もLSPなので、同じ形式のIDを使用します。
The LSP Identifier (LSP_ID) for a co-routed bidirectional LSP is formed by adding a 16-bit unsigned integer LSP number (LSP_Num) to the Tunnel ID. Consequently, the format of an MPLS-TP co-routed bidirectional LSP_ID is:
共同ルーティングされた双方向LSPのLSP ID（LSP_ID）は、トンネルIDに16ビットの符号なし整数LSP番号（LSP_Num）を追加することによって形成されます。したがって、MPLS-TP共ルーティング双方向LSP_IDの形式は次のとおりです。
A1-{Node_ID::Tunnel_Num}::Z9-{Node_ID::Tunnel_Num}::LSP_Num
[RFC6370] notes that the "uniqueness of identifiers does not depend on the A1/Z9 sort ordering".
[RFC6370]は、「識別子の一意性はA1 / Z9の並べ替え順序に依存しない」と述べています。
A co-routed bidirectional LSP is provisioned or signaled as a single entity, and therefore, a single LSP_Num is used for both unidirectional LSPs. These can be referenced by the following identifiers:
コルーテッド双方向LSPは単一のエンティティとしてプロビジョニングまたはシグナリングされるため、単一のLSP_Numが両方の単方向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、それぞれ。
Global uniqueness is accomplished by using globally unique Node_IDs. A globally unique LSP_ID consequently becomes:
グローバルな一意性は、グローバルに一意なNode_IDを使用して実現されます。その結果、グローバルに一意のLSP_IDは次のようになります。
A1-{ICC_Operator_ID::Node_ID::Tunnel_Num}::
Z9-{ICC_Operator_ID::Node_ID::Tunnel_Num}::LSP_Num
An associated bidirectional LSP needs a separate LSP_Num for both of its unidirectional LSPs. The LSP number is again a 16-bit unsigned integer that needs to be unique within the scope of the ingress's Tunnel_Num. Consequently, the format of an MPLS-TP associated bidirectional LSP_ID is:
関連する双方向LSPには、その単方向LSPの両方に個別のLSP_Numが必要です。 LSP番号も、16ビットの符号なし整数であり、入力のTunnel_Numのスコープ内で一意である必要があります。したがって、MPLS-TPに関連付けられた双方向LSP_IDの形式は次のとおりです。
A1-{Node_ID::Tunnel_Num::LSP_Num}::
Z9-{Node_ID::Tunnel_Num::LSP_Num}
Each of the unidirectional LSPs of which the associated bidirectional LSP is composed may be referenced by one of the following identifiers:
関連する双方向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、それぞれ。
A globally unique LSP_ID is constructed using the globally unique Node_IDs as defined before. Consequently, a globally unique LSP_ID is formulated as:
グローバルに一意のLSP_IDは、前に定義したグローバルに一意のNode_IDを使用して構築されます。したがって、グローバルに一意のLSP_IDは次のように定式化されます。
A1-{ICC_Operator_ID::Node_ID::Tunnel_Num::LSP_Num}::
Z9-{ICC_Operator_ID::Node_ID::Tunnel_Num::LSP_Num}
The PW Path Identifier (PW_Path_ID) is structured in a similar manner as the PW_Path_ID described in Section 6 of [RFC6370]. Instead of the Global_ID used in [RFC6370], this document uses the ICC_Operator_ID to make the PW_Path_ID globally unique. In this document, the Attachment Individual Identifier (AII) is composed of three fields. These are the ICC_Operator_ID, the Node_ID, and the AC_ID. The AC_ID is as defined in [RFC5003]. The complete globally unique PW_Path_ID is formulated as:
PWパス識別子（PW_Path_ID）は、[RFC6370]のセクション6で説明されているPW_Path_IDと同様の方法で構成されています。 [RFC6370]で使用されているGlobal_IDの代わりに、このドキュメントではICC_Operator_IDを使用してPW_Path_IDをグローバルに一意にしています。このドキュメントでは、添付ファイル個別識別子（AII）は3つのフィールドで構成されています。これらは、ICC_Operator_ID、Node_ID、およびAC_IDです。 AC_IDは[RFC5003]で定義されています。完全にグローバルに一意のPW_Path_IDは、次のように定式化されます。
A1-{ICC_Operator_ID::Node_ID::AC_ID}::
Z9-{ICC_Operator_ID::Node_ID::AC_ID}
The following subsections define the identifiers for the various maintenance-related groups and entities as defined in [RFC6371]. In contrast to the IDs defined in [RFC6370], this document does not define separate maintenance identifiers for Sections, PWs, and LSPs.
以下のサブセクションでは、[RFC6371]で定義されているさまざまなメンテナンス関連のグループとエンティティの識別子を定義します。 [RFC6370]で定義されているIDとは対照的に、このドキュメントではセクション、PW、LSPの個別のメンテナンス識別子を定義していません。
MEG_IDs for MPLS-TP Sections, LSPs, and PWs following ITU-T conventions are based on the globally unique ICC_Operator_ID. In this case, the MEG_ID is a string of up to 15 characters and consists of three subfields: the Country Code (as described in Section 3) and the ICC (as described in Section 3) -- which together form the ICC_Operator_ID -- followed by a Unique MEG ID Code (UMC) as defined in [Y.1731_cor1].
ITU-T規則に従うMPLS-TPセクション、LSP、およびPWのMEG_IDは、グローバルに一意のICC_Operator_IDに基づいています。この場合、MEG_IDは最大15文字の文字列であり、3つのサブフィールドで構成されています。国コード（セクション3で説明）とICC（セクション3で説明）-ICC_Operator_IDを形成する-に続きます[Y.1731_cor1]で定義されている一意のMEG IDコード（UMC）。
The resulting MEG_ID is:
結果のMEG_IDは次のとおりです。
CC::ICC::UMC
To avoid the potential for the concatenation of a short (i.e., less than 6 characters) ICC with a UMC not being unique, the UMC MUST start with the "/" character, which is not allowed in the ICC itself. This way, the MEG_ID can also be easily decomposed into its individual components by a receiver.
短い（つまり、6文字未満の）ICCとUMCが一意でない可能性を回避するために、UMCは「/」文字で開始する必要があります。これは、ICC自体では許可されていません。このように、MEG_IDは、レシーバーによって個々のコンポーネントに簡単に分解することもできます。
The UMC MUST be unique within the organization identified by the combination of CC and ICC.
UMCは、CCとICCの組み合わせによって識別される組織内で一意である必要があります。
The ICC_Operator_ID-based MEG_ID may be applied equally to a single MPLS-TP Section, LSP, or Pseudowire.
ICC_Operator_IDベースのMEG_IDは、単一のMPLS-TPセクション、LSP、または疑似配線に等しく適用できます。
ICC_Operator_ID-based MEP_IDs for MPLS-TP Sections, LSPs, and Pseudowires are formed by appending a 16-bit index to the MEG_ID defined in Section 7.1. Within the context of a particular MEG, we call the identifier associated with a MEP the MEP Index (MEP_Index). The MEP_Index is administratively assigned. It is encoded as a 16-bit unsigned integer and MUST be unique within the MEG. An ICC_Operator_ID-based MEP_ID is structured as:
MPLS-TPセクション、LSP、および疑似配線のICC_Operator_IDベースのMEP_IDは、セクション7.1で定義されたMEG_IDに16ビットのインデックスを追加することによって形成されます。特定のMEGのコンテキスト内では、MEPに関連付けられた識別子をMEPインデックス（MEP_Index）と呼びます。 MEP_Indexは管理上割り当てられます。これは、16ビットの符号なし整数としてエンコードされ、MEG内で一意である必要があります。 ICC_Operator_IDベースのMEP_IDは、次のように構成されています。
MEG_ID::MEP_Index
MEG_ID :: MEP_Index
An ICC_Operator_ID-based MEP ID is globally unique by construction given the ICC_Operator_ID-based MEG_ID's global uniqueness.
ICC_Operator_IDベースのMEP_IDのグローバルな一意性を考えると、ICC_Operator_IDベースのMEP IDは、構築によってグローバルに一意です。
ICC_Operator_ID-based MIP_IDs for MPLS-TP Sections, LSPs, and Pseudowires are formed by a global IF_ID that is obtained by prefixing the identifier of the interface on which the MIP resides with the ICC_Operator_ID as described in Section 3.1. This allows MIPs to be independently identified in nodes where a per-interface MIP model is used.
MPLS-TPセクション、LSP、および疑似配線のICC_Operator_IDベースのMIP_IDは、セクション3.1で説明されているように、MIPが存在するインターフェイスのIDにICC_Operator_IDをプレフィックスとして付加することによって取得されるグローバルIF_IDによって形成されます。これにより、インターフェイスごとのMIPモデルが使用されるノードでMIPを個別に識別できます。
If only a per-node MIP model is used, one MIP is configured. In this case, the MIP_ID is formed by using the Node_ID and an IF_Num of 0.
ノードごとのMIPモデルのみが使用される場合、1つのMIPが構成されます。この場合、MIP_IDは、Node_IDとIF_Numの0を使用して形成されます。
This document extends an existing naming scheme and does not introduce new security concerns. However, as mentioned in the Security Considerations section of [RFC6370], protocol specifications that describe the use of this naming scheme may introduce security risks and concerns about authentication of participants. For this reason, these protocol specifications need to describe security and authentication concerns that may be raised by the particular mechanisms defined and how those concerns may be addressed.
このドキュメントは、既存の命名方式を拡張したものであり、新しいセキュリティ上の懸念は紹介していません。ただし、[RFC6370]のセキュリティに関する考慮事項のセクションで述べたように、この命名方式の使用を説明するプロトコル仕様は、セキュリティリスクと参加者の認証に関する懸念をもたらす可能性があります。このため、これらのプロトコル仕様では、定義された特定のメカニズムによって引き起こされる可能性のあるセキュリティと認証の懸念事項、およびそれらの懸念事項への対処方法を記述する必要があります。
[ISO3166-1] "Codes for the representation of names of countries and their subdivisions -- Part 1: Country codes", ISO 3166-1, 2006.
[ISO3166-1]「国とその下位区分の名前を表すコード-パート1：国コード」、ISO 3166-1、2006年。
[M1400] "Designations for interconnections among operators' networks", ITU-T Recommendation M.1400, July 2006.
[M1400]「事業者のネットワーク間の相互接続の指定」、ITU-T勧告M.1400、2006年7月。
[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月。
[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月。
[RFC6370] Bocci, M., Swallow, G., and E. Gray, "MPLS Transport Profile (MPLS-TP) Identifiers", RFC 6370, September 2011.
[RFC6370] Bocci、M.、Swallow、G。、およびE. Gray、「MPLS Transport Profile（MPLS-TP）Identifiers」、RFC 6370、2011年9月。
[T.50] "International Reference Alphabet (IRA) (Formerly International Alphabet No. 5 or IA5) - Information technology - 7-bit coded character set for information exchange", ITU-T Recommendation T.50, September 1992.
[T.50]「国際参照アルファベット（IRA）（旧国際アルファベットNo. 5またはIA5）-情報技術-情報交換用の7ビットコード化文字セット」、ITU-T勧告T.50、1992年9月。
[Y.1731_cor1] "OAM functions and mechanisms for Ethernet based networks - Corrigendum 1", ITU-T Recommendation G.8013/Y.1731 Corrigendum 1, October 2011.
[Y.1731_cor1]「イーサネットベースのネットワークのOAM機能とメカニズム-Corrigendum 1」、ITU-T勧告G.8013 / Y.1731 Corrigendum 1、2011年10月。
[CC-list] "List of Country Codes - ISO 3166 (CCs)", <http://www.iso.org/iso/country_codes.htm>.
[CC-list]「国コードのリスト-ISO 3166（CC）」、<http://www.iso.org/iso/country_codes.htm>。
[ICC-list] "List of ITU Carrier Codes (ICCs)", <http://www.itu.int/oth/T0201>.
[ICC-list]「ITUキャリアコード（ICC）のリスト」、<http://www.itu.int/oth/T0201>。
[RFC6371] Busi, I., Ed., and D. Allan, Ed., "Operations, Administration, and Maintenance Framework for MPLS-Based Transport Networks", RFC 6371, September 2011.
[RFC6371] Busi、I.、Ed。およびD. Allan、Ed。、「Operations、Administration、and Maintenance Framework for MPLS-Based Transport Networks」、RFC 6371、2011年9月。
Authors' Addresses
著者のアドレス
Rolf Winter NEC
ロルフウィンターNEC
EMail: rolf.winter@neclab.eu
Eric Gray Ericsson
エリック・グレイ・エリクソン
EMail: eric.gray@ericsson.com
Huub van Helvoort Huawei Technologies Co., Ltd.
Huub van Helvoort Huawei Technologies Co.、Ltd.
EMail: huub.van.helvoort@huawei.com
Malcolm Betts ZTE
マルコム・ベッツZTE
EMail: malcolm.betts@zte.com.cn