diff options
Diffstat (limited to 'doc/rfc/rfc6370.txt')
| -rw-r--r-- | doc/rfc/rfc6370.txt | 955 |
1 files changed, 955 insertions, 0 deletions
diff --git a/doc/rfc/rfc6370.txt b/doc/rfc/rfc6370.txt new file mode 100644 index 0000000..7ab2b41 --- /dev/null +++ b/doc/rfc/rfc6370.txt @@ -0,0 +1,955 @@ + + + + + + +Internet Engineering Task Force (IETF) M. Bocci +Request for Comments: 6370 Alcatel-Lucent +Category: Standards Track G. Swallow +ISSN: 2070-1721 Cisco + E. Gray + Ericsson + September 2011 + + + MPLS Transport Profile (MPLS-TP) Identifiers + +Abstract + + This document specifies an initial set of identifiers to be used in + the Transport Profile of Multiprotocol Label Switching (MPLS-TP). + The MPLS-TP requirements (RFC 5654) require that the elements and + objects in an MPLS-TP environment are able to be configured and + managed without a control plane. In such an environment, many + conventions for defining identifiers are possible. This document + defines identifiers for MPLS-TP management and Operations, + Administration, and Maintenance (OAM) functions compatible with IP/ + MPLS conventions. + + 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. + +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. + + 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. + + + + + + + + +Bocci, et al. Standards Track [Page 1] + +RFC 6370 MPLS-TP Identifiers September 2011 + + +Copyright Notice + + Copyright (c) 2011 IETF Trust and the persons identified as the + document authors. All rights reserved. + + 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. + +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 + + + + + + +Bocci, et al. Standards Track [Page 2] + +RFC 6370 MPLS-TP Identifiers September 2011 + + +1. Introduction + + 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. + + 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. + +1.1. Terminology + + AGI: Attachment Group Identifier + + AII: Attachment Interface Identifier + + AS: Autonomous System + + ASN: Autonomous System Number + + EGP: Exterior Gateway Protocol + + FEC: Forwarding Equivalence Class + + GMPLS: Generalized Multiprotocol Label Switching + + IGP: Interior Gateway Protocol + + LSP: Label Switched Path + + LSR: Label Switching Router + + MEG: Maintenance Entity Group + + MEP: Maintenance Entity Group End Point + + MIP: Maintenance Entity Group Intermediate Point + + + + +Bocci, et al. Standards Track [Page 3] + +RFC 6370 MPLS-TP Identifiers September 2011 + + + MPLS: Multiprotocol Label Switching + + NNI: Network-to-Network Interface + + OAM: Operations, Administration, and Maintenance + + PW: Pseudowire + + RSVP: Resource Reservation Protocol + + RSVP-TE: RSVP Traffic Engineering + + SAII: Source AII + + SPME: Sub-Path Maintenance Entity + + T-PE: Terminating Provider Edge + + TAII: Target AII + +1.2. Requirements Language + + 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]. + +1.3. Notational Conventions + + 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. + + 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 {...}. + + 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 + + + +Bocci, et al. Standards Track [Page 4] + +RFC 6370 MPLS-TP Identifiers September 2011 + + + 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). + +2. Named Entities + + 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: + + * Global_ID + + * Node + + * Interface + + * Tunnel + + * LSP + + * PW + + * MEG + + * MEP + + * MIP + + Note that we have borrowed the term "tunnel" from RSVP-TE (RFC 3209 + [2]) where it is used to describe an entity that provides a logical + association between a source and destination LSR. The tunnel, in + turn, is instantiated by one or more LSPs, where the additional LSPs + are used for protection or re-grooming of the tunnel. + +3. Uniquely Identifying an Operator - the Global_ID + + The Global_ID is defined to uniquely identify an operator. RFC 5003 + [3] defines a globally unique Attachment Interface Identifier (AII). + That AII is composed of three parts: a Global_ID that uniquely + identifies an operator, a prefix, and, finally, an attachment circuit + identifier. We have chosen to use that Global ID for MPLS-TP. + Quoting from RFC 5003, Section 3.2: + + 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 + + + + +Bocci, et al. Standards Track [Page 5] + +RFC 6370 MPLS-TP Identifiers September 2011 + + + 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. + + 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. + + 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. + + 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. + +4. Node and Interface Identifiers + + 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. + + 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. + + 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. + + In situations where a Node_ID needs to be globally unique, this is + accomplished by prefixing the identifier with the operator's + Global_ID. + + + + +Bocci, et al. Standards Track [Page 6] + +RFC 6370 MPLS-TP Identifiers September 2011 + + + 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. + + 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. + + 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. + + 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. + + If an IF_ID needs to be globally unique, this is accomplished by + prefixing the identifier with the operator's 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. + +5. MPLS-TP Tunnel and LSP Identifiers + + 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. + + + + +Bocci, et al. Standards Track [Page 7] + +RFC 6370 MPLS-TP Identifiers September 2011 + + + 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. + + 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. + +5.1. MPLS-TP Point-to-Point Tunnel Identifiers + + 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. + + Having two tunnel numbers also serves to simplify other signaling + (e.g., setup of associated bidirectional tunnels as described in + Section 5.3). + + The concatenation of the two end point identifiers serves as the full + identifier. Using the A1/Z9 convention, the format of a Tunnel_ID + is: + + A1-{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: + + 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. + + + + + + + + +Bocci, et al. Standards Track [Page 8] + +RFC 6370 MPLS-TP Identifiers September 2011 + + +5.2. MPLS-TP LSP Identifiers + + 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. + +5.2.1. MPLS-TP Co-Routed Bidirectional LSP Identifiers + + 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: + + 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: + + 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: + + A1-Node_ID::A1-Tunnel_Num::LSP_Num::Z9-Node_ID and + + Z9-Node_ID::Z9-Tunnel_Num::LSP_Num::A1-Node_ID, respectively. + + Where the LSP_ID needs to be globally unique, this is accomplished by + using globally unique Node_IDs as defined above. Thus, a globally + unique LSP_ID becomes: + + A1-{Global_ID::Node_ID::Tunnel_Num}::Z9-{Global_ID:: + Node_ID::Tunnel_Num}::LSP_Num + +5.2.2. MPLS-TP Associated Bidirectional LSP Identifiers + + 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 + + + +Bocci, et al. Standards Track [Page 9] + +RFC 6370 MPLS-TP Identifiers September 2011 + + + 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: + + 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: + + 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. + + Where the LSP_ID needs to be globally unique, this is accomplished by + using globally unique Node_IDs as defined above. Thus, a globally + unique LSP_ID becomes: + + A1-{Global_ID::Node_ID::Tunnel_Num::LSP_Num}:: + Z9-{Global_ID::Node_ID::Tunnel_Num::LSP_Num} + +5.3. Mapping to RSVP Signaling + + This section is informative and exists to help understand the + structure of the LSP IDs. + + 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 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. + + + + + + + + + +Bocci, et al. Standards Track [Page 10] + +RFC 6370 MPLS-TP Identifiers September 2011 + + + For a co-routed bidirectional LSP signaled from A1 to Z9, the mapping + to the GMPLS 5-tuple is as follows: + + * Tunnel End-point Address = Z9-Node_ID + + * Tunnel_ID = A1-Tunnel_Num + + * Extended Tunnel_ID = A1-Node_ID + + * Tunnel Sender Address = A1-Node_ID + + * (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. + + 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: + + * Tunnel End-point Address = Z9-Node_ID + + * Tunnel_ID = A1-Tunnel_Num + + * Extended Tunnel_ID = A1-Node_ID + + * Tunnel Sender Address = A1-Node_ID + + * (RSVP) LSP_ID = A1-LSP_Num + + Likewise, the Z9 to A1 LSP, the mapping would be: + + * Tunnel End-point Address = A1-Node_ID + + * Tunnel_ID = Z9-Tunnel_Num + + * Extended Tunnel_ID = Z9-Node_ID + + * Tunnel Sender Address = Z9-Node_ID + + * (RSVP) LSP_ID = Z9-LSP_Num + +6. Pseudowire Path Identifiers + + 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. + + + +Bocci, et al. Standards Track [Page 11] + +RFC 6370 MPLS-TP Identifiers September 2011 + + + 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). + + 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. + + 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. + + 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. + + 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: + + 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: + + 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: + + AGI = AGI + SAII = Z9-{Global_ID::Node_ID::AC_ID} + TAII = A1-{Global_ID::Node_ID::AC_ID} + + + + + + +Bocci, et al. Standards Track [Page 12] + +RFC 6370 MPLS-TP Identifiers September 2011 + + +7. Maintenance Identifiers + + 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. + +7.1. Maintenance Entity Group Identifiers + + 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. + +7.1.1. MPLS-TP Section MEG_IDs + + MPLS-TP allows a hierarchy of sections. See "MPLS-TP Data Plane + Architecture" (RFC 5960 [10]). Sections above layer 0 are MPLS-TP + LSPs. These use their MPLS-TP LSP MEG IDs defined in Section 7.1.2. + + 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: + + 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: + + A1-{Global_ID::IF_ID}::Z9-{Global_ID::IF_ID} + +7.1.2. MPLS-TP LSP MEG_IDs + + A MEG pertains to a unique MPLS-TP LSP. IP compatible MEG_IDs for + MPLS-TP LSPs are simply the corresponding LSP_IDs; however, the A1/Z9 + ordering MUST be used. For bidirectional co-routed LSPs, the format + of the LSP_ID is found in Section 5.2.1. For associated + bidirectional LSPs, the format is in Section 5.2.2. + + + + + + + + +Bocci, et al. Standards Track [Page 13] + +RFC 6370 MPLS-TP Identifiers September 2011 + + + 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. + +7.1.3. Pseudowire MEG_IDs + + For Pseudowires, a MEG pertains to a single PW. The IP-compatible + MEG_ID for a PW is simply the corresponding PW_Path_ID; however, the + A1/Z9 ordering MUST be used. The PW_Path_ID is described in + Section 6. We note that while the two identifiers are syntactically + identical, they have different semantics. This semantic difference + needs to be made clear. For instance, if both a PW_Path_ID and a + PW_MEG_ID are to be encoded in TLVs, different types need to be + assigned for these two identifiers. + +7.2. Maintenance Entity Group End Point Identifiers + +7.2.1. MPLS-TP Section MEP_IDs + + IP-compatible MEP_IDs for MPLS-TP sections above layer 0 are their + MPLS-TP LSP_MEP_IDs. See Section 7.2.2. + + 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: + + A1-IF_ID::Z9-IF_ID + + the Section MEP_ID at A1 would be: + + A1-IF_ID + + and the Section MEP_ID at Z9 would be: + + 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: + + Global_ID::IF_ID. + + + + + + + + +Bocci, et al. Standards Track [Page 14] + +RFC 6370 MPLS-TP Identifiers September 2011 + + +7.2.2. MPLS-TP LSP_MEP_ID + + In order to automatically generate MEP_IDs for MPLS-TP LSPs, we use + the elements of identification that are unique to an end point. This + ensures that MEP_IDs are unique for all LSPs within an operator. + When Tunnels or LSPs cross operator boundaries, these are made unique + by pre-pending them with the operator's Global_ID. + + The MPLS-TP LSP_MEP_ID is: + + 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. + + In situations where global uniqueness is required, this becomes: + + Global_ID::Node_ID::Tunnel_Num::LSP_Num + +7.2.3. MEP_IDs for Pseudowires + + 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: + + 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. + +7.3. Maintenance Entity Group Intermediate Point Identifiers + + 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. + +8. Security Considerations + + 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 + + + +Bocci, et al. Standards Track [Page 15] + +RFC 6370 MPLS-TP Identifiers September 2011 + + + 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. + + Protocol specifications that utilize the identifiers defined herein + need to consider the implications of guessable identifiers and, where + there is a security implication, SHOULD give advice on how to make + identifiers less guessable. + +9. References + +9.1. Normative References + + [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + [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. + + [3] Metz, C., Martini, L., Balus, F., and J. Sugimoto, "Attachment + Individual Identifier (AII) Types for Aggregation", RFC 5003, + September 2007. + + [4] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) + Signaling Functional Description", RFC 3471, January 2003. + + [5] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) + Signaling Resource ReserVation Protocol-Traffic Engineering + (RSVP-TE) Extensions", RFC 3473, January 2003. + + [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. + + + + + + +Bocci, et al. Standards Track [Page 16] + +RFC 6370 MPLS-TP Identifiers September 2011 + + +9.2. Informative References + + [7] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., and + S. Ueno, "Requirements of an MPLS Transport Profile", RFC 5654, + September 2009. + + [8] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", + RFC 2863, June 2000. + + [9] Bocci, M., Bryant, S., Frost, D., Levrau, L., and L. Berger, "A + Framework for MPLS in Transport Networks", RFC 5921, July 2010. + + [10] Frost, D., Bryant, S., and M. Bocci, "MPLS Transport Profile + Data Plane Architecture", RFC 5960, August 2010. + +Authors' Addresses + + 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 + + EMail: eric.gray@ericsson.com + + + + + + + + + + + + + +Bocci, et al. Standards Track [Page 17] + |