--- 1/draft-ietf-mpls-tp-identifiers-06.txt 2011-07-22 16:15:49.000000000 +0200 +++ 2/draft-ietf-mpls-tp-identifiers-07.txt 2011-07-22 16:15:49.000000000 +0200 @@ -1,32 +1,32 @@ MPLS Working Group M. Bocci Internet-Draft Alcatel-Lucent Intended status: Standards Track G. Swallow -Expires: December 26, 2011 Cisco +Expires: January 22, 2012 Cisco E. Gray Ericsson - June 24, 2011 + July 21, 2011 MPLS-TP Identifiers - draft-ietf-mpls-tp-identifiers-06 + draft-ietf-mpls-tp-identifiers-07 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 OAM functions suitable - to IP/MPLS conventions. + defines identifiers for MPLS-TP management and 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 @@ -36,21 +36,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on December 26, 2011. + This Internet-Draft will expire on January 22, 2012. 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 @@ -58,58 +58,59 @@ 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 . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . 8 - 5.2.1. MPLS-TP Co-Routed Bidirectional LSP Identifiers . . . 8 + 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 . . . . . . . . . . . . . . . . 9 + 5.3. Mapping to RSVP Signaling . . . . . . . . . . . . . . . . 10 6. Pseudowire Path Identifiers . . . . . . . . . . . . . . . . . 11 7. Maintenance Identifiers . . . . . . . . . . . . . . . . . . . 12 - 7.1. Maintenance Entity Group Identifiers . . . . . . . . . . . 12 - 7.1.1. MPLS-TP Section MEG_IDs . . . . . . . . . . . . . . . 12 - 7.1.2. MPLS-TP LSP MEG_IDs . . . . . . . . . . . . . . . . . 12 + 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 . . . . . . . . . . . . . . . . . . 13 - 7.2. MEP_IDs . . . . . . . . . . . . . . . . . . . . . . . . . 13 - 7.2.1. MPLS-TP LSP_MEP_ID . . . . . . . . . . . . . . . . . . 13 - 7.2.2. MEP_IDs for Pseudowires . . . . . . . . . . . . . . . 14 - 7.3. Pseudowire Segment Endpoint IDs . . . . . . . . . . . . . 14 - 7.4. MIP Identifiers . . . . . . . . . . . . . . . . . . . . . 15 + 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 . . . . . . . . . . . . . . . . . . 14 + 7.2.3. MEP_IDs for Pseudowires . . . . . . . . . . . . . . . 15 + 7.3. Maintenance Entity Group Intermediate Point Identifiers . 15 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 9. Security Considerations . . . . . . . . . . . . . . . . . . . 15 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 10.1. Normative References . . . . . . . . . . . . . . . . . . . 16 10.2. Informative References . . . . . . . . . . . . . . . . . . 16 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 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 suitable - to IP/MPLS conventions. The identifiers have been chosen to be - compatible with existing IP, MPLS, GMPLS, and Pseudowire definitions. + 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 @@ -131,30 +132,32 @@ MEG: Maintenance Entity Group MEP: Maintenance Entity Group End Point MIP: Maintenance Entity Group Intermediate Point MPLS: Multi-Protocol Label Switching NNI: Network-to-Network Interface - OAM: Operations, Administration and Maintenance + P2P: Point to Point PW: Pseudowire RSVP: Resource Reservation Protocol RSVP-TE: RSVP Traffic Engineering + SPME: Sub Path Maintenance Entities + S-PE: Switching Provider Edge T-PE: Terminating Provider Edge 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]. @@ -163,23 +166,23 @@ 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 does define a preferred ordering of the fields. + 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 indicated the + 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 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). @@ -222,29 +225,31 @@ That AII is composed of three parts, a Global_ID which 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 operator's Autonomous System Number (ASN). It is expected that the global ID will be derived from the globally unique ASN of the autonomous system hosting the PEs containing the actual AIIs. The presence of a global ID based on the operator's ASN ensures that the AII will be globally unique." - A Global_ID 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. + 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. 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 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 which 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 @@ -264,113 +269,125 @@ 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 a 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. - 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.4, MIP Identifiers) and MUST NOT be + 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. - The attachment point to an MPLS-TP Tunnel (see Section 5.1) also - needs an interface identifier. Note that MPLS-TP supports - hierarchical tunnels. The attachment point to a MPLS-TP Tunnel at - any (sub-)layer requires a node-unique IF_Num. + Note that MPLS-TP supports hierarchical sections. The attachment + point to a 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_ID identifies the transport service and - provides a stable binding to the client in the face of changes in the - 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_ID to uniquely - identify an LSP associated with a tunnel. + 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. 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 which 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 endpoint a tunnel is uniquely identified by the endpoint's - Node_ID and a locally assigned tunnel number. Specifically a - Tunnel_Num is a 16-bit unsigned integer unique within the context of - the Node_ID. The motivation for each endpoint having its own tunnel - number is to allow a compact form for the MEP-ID. See Section 7.2.1. + 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 endpoint 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 endpoint 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:: + 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 endpoint. As usual, the IF_ID is composed of the local Node_ID concatenated with a 32-bit IF_Num. 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_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 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. @@ -382,33 +399,35 @@ 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:: + 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_Num is a 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: + ingress's Tunnel_Num. Specifically an LSP Number (LSP_Num) is a 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 dataplane 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. @@ -410,46 +429,51 @@ 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} + 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. + 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 a operator's network. This tuple is composed of a Tunnel Endpoint Address, Tunnel_ID, Extended Tunnel ID, and Tunnel Sender - Address and (RSVP) LSP_ID. + 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. For a co-routed bidirectional LSP signaled from A1 to Z9, the mapping to the GMPLS 5-tuple is as follows: * Tunnel Endpoint 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: @@ -507,90 +532,118 @@ that endpoint 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 FEC 129 completed as follows: AGI = AGI - SAAI = A1-{Global_ID::Node_ID::AC_ID} + 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 - SAAI = Z9-{Global_ID::Node_ID::AC_ID} + SAII = Z9-{Global_ID::Node_ID::AC_ID} TAII = A1-{Global_ID::Node_ID::AC_ID} 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) or a Maintenance Entity Group - Intermediate Point (MIP). Maintenance points are uniquely associated - with a MEG. Within the context of a MEG, MEPs and MIPs must be - uniquely identified. This section defines a means of uniquely - identifying Maintenance Entity Groups, Maintenance Entities and - uniquely defining MEPs and MIPs within the context of a Maintenance - Entity Group. + Entity Group End-point (MEP), a Maintenance Entity Group Intermediate + Point (MIP), or a Pseudowire Segment Endpoint. Within the context of + a MEG, MEPs and MIPs must be uniquely identified. This section + defines a means of uniquely identifying Maintenance Entity Groups, + Maintenance Entities and uniquely defining 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 - IP compatible MEG_IDs for MPLS-TP sections are formed by + 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 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 + 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. 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 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 - the A1/Z9 ordering MUST be used. The PW_Path_ID is described in + 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. MEP_IDs +7.2. Maintenance Entity Group End Point Identifiers -7.2.1. MPLS-TP LSP_MEP_ID +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. + +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 endpoint. This ensures that MEP_IDs are unique for all LSPs within a 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 @@ -598,149 +651,121 @@ 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.2. MEP_IDs for Pseudowires +7.2.3. MEP_IDs for Pseudowires Like MPLS-TP LSPs, Pseudowire endpoints (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 - used in end-to-end for a Pseudowire T-PE takes the form + 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. Pseudowire Segment Endpoint IDs - - In some OAM communications, messages are originated by the node at - one end of a PW segment and relayed to the other end of that same - segment by setting the TTL of the PW label to one (1). For a multi- - segment pseudowire, TTL could be set to any value that would cause - OAM messages to reach the target segment end-point (up to and - including 255). In such communications an identifier for the - pseudowire segment endpoint is needed. We call this a Pseudowire - Segments Endpoint ID or PW_SE_ID. - - The PW_SE_ID is formed by a combination of a PW MEP_ID and the - identification of the local node. At an S-PE, there are two PW - segments. We distinguish the segments by using the MEP_ID which is - upstream of the PW segment in question. To complete the - identification we suffix this with the identification of the local - node. - - +-------+ +-------+ +-------+ +-------+ - | | | | | | | | - | A|---------|B C|---------|D E|---------|F | - | | | | | | | | - +-------+ +-------+ +-------+ +-------+ - (T)PE1 (S)PE2 (S)PE3 (T)PE4 - - Pseudowire Maintenance Points - - For example, suppose that in the above figure all of the nodes have - Global_ID GID1; the node are represented as named in the figure; and - The identification for the Pseudowire is: - - AGI = AGI1 - A1-Global_ID = GID1 - A1-Node_ID = PE1 - A1-AC_ID = AII1 - Z9-Global_ID = GID1 - Z9-Node_ID = PE4 - Z9-AC_ID = AII4 - - The MEP_ID at point A would be - - - AGI1::GID1::PE1::AII1 - - The PW_SE_ID at point B would be - - - AGI1::GID1::PE4::AII4::GID1::PE2 - - The PW_SE_ID at point C would be - - - AGI1::GID1::PE1::AII1::GID1::PE2 - -7.4. MIP Identifiers +7.3. Maintenance Entity Group Intermediate Point Identifiers - At a cross-connect point, in order to automatically generate MIP_IDs - for MPLS-TP, we simply use the IF_IDs of the two interfaces which are - cross-connected via the label bindings of the MPLS-TP LSP or PW. - This allows, two MIPs to be independently identified in one node - where a per-interface MIP model is used. If only a per node MIP + For a MIP which is associated with particular interface, we simply + use the IF_ID (see Section 4) of the interfaces which 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. IANA Considerations There are no IANA actions resulting from this document. 9. 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 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 a 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 and + 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. + 10. References 10.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", + [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. 10.2. Informative References - [7] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., and S. - Ueno, "Requirements of an MPLS Transport Profile", RFC 5654, + [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