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
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.
这是一份互联网标准跟踪文件。
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/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.
版权所有（c）2013 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信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
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
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传输和管理实体标识符，以支持双向（共路由和关联）点对点MPLS-TP标签交换路径（LSP），包括伪线（PW）和遵循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约定为运营商/服务提供商生成明确标识符的替代方法，并规定了如何使用这些运营商/服务提供商标识符为[RFC6370]中描述的现有可识别MPLS-TP实体集生成明确标识符。
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
抄送：国家代码
ICC: ITU Carrier Code
国际电联载波代码
ISO: International Organization for Standardization
ISO：国际标准化组织
ITU: International Telecommunication Union
国际电信联盟
ITU-T: ITU Telecommunication Standardization Sector
ITU-T：ITU电信标准化部门
LSP: Label Switched Path
标签交换路径
MEG: Maintenance Entity Group
MEG：维护实体组
MEP: Maintenance Entity Group End Point
MEP：维护实体组终点
MIP: Maintenance Entity Group Intermediate Point
MIP：维护实体组中间点
MPLS: Multiprotocol Label Switching
多协议标签交换
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].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[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.
所有多个单词原子标识符都在单词之间使用下划线（\）来连接单词。许多标识符由一组其他标识符组成。通过列出后一个标识符，并用双冒号“：”表示。
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 全球统一标识
o Node
o 节点
o Interface
o 界面
o Tunnel
o 地下通道
o LSP
o LSP
o PW
o 嗯
o MEG
o 梅格
o MEP
o 欧洲议会
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].
以下各节逐一介绍此标识符列表。本文件的结构与[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]中，操作员由全局_ID唯一标识，全局_ID基于操作员的自治系统（AS）编号。然而，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清单]。请注意，ICC（所有ICC均在[ICC列表]中引用）可分配给ITU-T成员和非成员。国家监管机构充当ITU/TSB和运营商/服务提供商之间的中介机构。在分配国际商会的过程中，国家当局负责的一件事是确保承运人代码在其国内是唯一的。此唯一性假设是创建基于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本身是一个由一到六个字符组成的字符串，每个字符可以是字母（即a-Z）或数字（即0-9）。ICC中的字母字符应使用大写字母表示。
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）表示。
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）建立了国际公认的代码，用于表示地理利益相关的国家、地区或地区及其分支的名称，作为ISO标准3166-1[ISO3166-1]中的CCs[CC列表]发布。
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运营商ID，如下所示：
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_操作员_ID用于替换[RFC6370]中规定的全局_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）被指定为节点ID（由运算符指定的唯一32位值）和接口号（IF_Num，由运算符指定的在节点ID范围内唯一的32位无符号整数）的串联。要使此IF_ID全局唯一，请在全局_ID前面加前缀。此备忘录将ICC_操作员_ID指定为一种替代格式，与全局_ID一样，它以IF_ID为前缀。使用RFC 6370[RFC6370]中的符号：
Global_ID::Node_ID::IF_Num
Global_ID::Node_ID::IF_Num
is functionally equivalent to:
在功能上等同于：
ICC_Operator_ID::Node_ID::IF_Num
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).
相同的替换程序适用于[RFC6370]中规定的所有标识符，但MEG ID、MEP ID和MIP ID除外。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）定义为操作员在全局_ID范围内分配的唯一32位值。未定义节点_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.
本文件不改变上述定义。但是，如果需要全局唯一性，则节点_ID以第3节中定义的ICC_运算符_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位无符号整数，该整数可由运算符自由分配，并且在各自节点的\u ID范围内必须是唯一的。IF_Num值0具有特殊含义，因此不得用于标识MPLS-TP接口。
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_运算符_ID的上下文中唯一地标识接口。它是通过将节点_ID与IF_Num连接起来形成的64位标识符，形成为节点_ID:：IF_Num。
Global uniqueness of the IF_ID, if needed, can be assured by prefixing the identifier with the ICC_Operator_ID.
如果需要，可以通过在标识符前面加上ICC_运算符_ID来确保IF_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（隧道ID）基于端点的节点ID和本地分配的隧道编号（隧道编号），用于标识每个端点处的隧道。隧道号是节点_ID上下文中唯一的16位无符号整数。完整的隧道ID由这两个端点特定标识符的串联表示。使用A1/Z9约定，隧道ID的格式为：
A1-{Node_ID::Tunnel_Num}::Z9-{Node_ID::Tunnel_Num}
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_操作员_ID作为隧道_ID的前缀。因此，全局唯一的隧道_ID变为：
A1-{ICC_Operator_ID::Node_ID::Tunnel_Num}::
Z9-{ICC_Operator_ID::Node_ID::Tunnel_Num}
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标识符（LSP_ID）通过向隧道ID添加16位无符号整数LSP编号（LSP_Num）形成。因此，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
[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
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:
全局唯一性是通过使用全局唯一的节点ID来实现的。因此，全局唯一的LSP_ID变为：
A1-{ICC_Operator_ID::Node_ID::Tunnel_Num}::
Z9-{ICC_Operator_ID::Node_ID::Tunnel_Num}::LSP_Num
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位无符号整数，需要在入口的隧道编号范围内唯一。因此，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}
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
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是使用前面定义的全局唯一节点_ID构造的。因此，全球唯一的LSP_ID表示为：
A1-{ICC_Operator_ID::Node_ID::Tunnel_Num::LSP_Num}::
Z9-{ICC_Operator_ID::Node_ID::Tunnel_Num::LSP_Num}
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]中使用的全局_ID不同，本文档使用ICC_运算符_ID使PW_路径_ID全局唯一。在本文档中，附件个人标识符（AII）由三个字段组成。这些是ICC_操作员_ID、节点_ID和AC_ID。AC_ID的定义见[RFC5003]。完整的全局唯一PW_路径_ID表示为：
A1-{ICC_Operator_ID::Node_ID::AC_ID}::
Z9-{ICC_Operator_ID::Node_ID::AC_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和PWs的MEG_ID基于全球唯一的ICC_操作员ID。在这种情况下，MEG_ID是一个最多15个字符的字符串，由三个子字段组成：国家代码（如第3节所述）和ICC（如第3节所述）--共同构成ICC_操作员_ID，后跟[Y.1731_cor1]中定义的唯一MEG ID代码（UMC）。
The resulting MEG_ID is:
由此产生的MEG_ID为：
CC::ICC::UMC
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.
为避免短ICC（即少于6个字符）与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_运营商_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_操作员_ID的MEP_ID通过向第7.1节中定义的MEG_ID附加16位索引形成。在特定MEG的上下文中，我们将与MEP关联的标识符称为MEP索引（MEP_索引）。MEP_索引是行政分配的。它被编码为16位无符号整数，并且在MEG中必须是唯一的。基于ICC_操作员_ID的MEP_ID的结构如下：
MEG_ID::MEP_Index
MEG_ID:：MEP_索引
An ICC_Operator_ID-based MEP ID is globally unique by construction given the ICC_Operator_ID-based MEG_ID's global uniqueness.
考虑到基于ICC_操作员ID的MEG_ID的全局唯一性，基于ICC_操作员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
MPLS-TP段、LSP和伪线的基于ICC_操作员_ID的MIP_ID由全局IF_ID构成，该ID通过在MIP所在接口的标识符前加前缀获得
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.
具有第3.1节所述的ICC操作员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模型，则配置一个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-12006。
[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，“聚合的附件个人标识符（AII）类型”，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传输配置文件（MPLS-TP）标识符”，RFC 63702011年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）（前国际字母表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功能和机制-勘误表1”，ITU-T建议G.8013/Y.1731勘误表1，2011年10月。
[CC-list] "List of Country Codes - ISO 3166 (CCs)", <http://www.iso.org/iso/country_codes.htm>.
[抄送清单]“国家代码清单-ISO 3166（CCs）”<http://www.iso.org/iso/country_codes.htm>.
[ICC-list] "List of ITU Carrier Codes (ICCs)", <http://www.itu.int/oth/T0201>.
[ICC列表]“国际电联载波代码（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.“基于MPLS的传输网络的操作、管理和维护框架”，RFC 63712011年9月。
Authors' Addresses
作者地址
Rolf Winter NEC
罗尔夫冬季NEC
EMail: rolf.winter@neclab.eu
EMail: rolf.winter@neclab.eu
Eric Gray Ericsson
埃里克·格雷·爱立信
EMail: eric.gray@ericsson.com
EMail: eric.gray@ericsson.com
Huub van Helvoort Huawei Technologies Co., Ltd.
Huub van Helvoort华为技术有限公司。
EMail: huub.van.helvoort@huawei.com
EMail: huub.van.helvoort@huawei.com
Malcolm Betts ZTE
Malcolm Betts中兴通讯
EMail: malcolm.betts@zte.com.cn
EMail: malcolm.betts@zte.com.cn