idnits 2.17.1 draft-ietf-mpls-tp-identifiers-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 24, 2011) is 4661 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 4447 (ref. '6') (Obsoleted by RFC 8077) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MPLS Working Group M. Bocci 3 Internet-Draft Alcatel-Lucent 4 Intended status: Standards Track G. Swallow 5 Expires: December 26, 2011 Cisco 6 E. Gray 7 Ericsson 8 June 24, 2011 10 MPLS-TP Identifiers 11 draft-ietf-mpls-tp-identifiers-06 13 Abstract 15 This document specifies an initial set of identifiers to be used in 16 the Transport Profile of Multiprotocol Label Switching (MPLS-TP). 17 The MPLS-TP requirements (RFC 5654) require that the elements and 18 objects in an MPLS-TP environment are able to be configured and 19 managed without a control plane. In such an environment many 20 conventions for defining identifiers are possible. This document 21 defines identifiers for MPLS-TP management and OAM functions suitable 22 to IP/MPLS conventions. 24 This document is a product of a joint Internet Engineering Task Force 25 (IETF) / International Telecommunication Union Telecommunication 26 Standardization Sector (ITU-T) effort to include an MPLS Transport 27 Profile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge 28 (PWE3) architectures to support the capabilities and functionalities 29 of a packet transport network as defined by the ITU-T. 31 Status of this Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on December 26, 2011. 48 Copyright Notice 49 Copyright (c) 2011 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 66 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 4 67 1.3. Notational Conventions . . . . . . . . . . . . . . . . . . 4 68 2. Named Entities . . . . . . . . . . . . . . . . . . . . . . . . 4 69 3. Uniquely Identifying an Operator - the Global_ID . . . . . . . 5 70 4. Node and Interface Identifiers . . . . . . . . . . . . . . . . 6 71 5. MPLS-TP Tunnel and LSP Identifiers . . . . . . . . . . . . . . 7 72 5.1. MPLS-TP Point to Point Tunnel Identifiers . . . . . . . . 8 73 5.2. MPLS-TP LSP Identifiers . . . . . . . . . . . . . . . . . 8 74 5.2.1. MPLS-TP Co-Routed Bidirectional LSP Identifiers . . . 8 75 5.2.2. MPLS-TP Associated Bidirectional LSP Identifiers . . . 9 76 5.3. Mapping to RSVP Signaling . . . . . . . . . . . . . . . . 9 77 6. Pseudowire Path Identifiers . . . . . . . . . . . . . . . . . 11 78 7. Maintenance Identifiers . . . . . . . . . . . . . . . . . . . 12 79 7.1. Maintenance Entity Group Identifiers . . . . . . . . . . . 12 80 7.1.1. MPLS-TP Section MEG_IDs . . . . . . . . . . . . . . . 12 81 7.1.2. MPLS-TP LSP MEG_IDs . . . . . . . . . . . . . . . . . 12 82 7.1.3. Pseudowire MEG_IDs . . . . . . . . . . . . . . . . . . 13 83 7.2. MEP_IDs . . . . . . . . . . . . . . . . . . . . . . . . . 13 84 7.2.1. MPLS-TP LSP_MEP_ID . . . . . . . . . . . . . . . . . . 13 85 7.2.2. MEP_IDs for Pseudowires . . . . . . . . . . . . . . . 14 86 7.3. Pseudowire Segment Endpoint IDs . . . . . . . . . . . . . 14 87 7.4. MIP Identifiers . . . . . . . . . . . . . . . . . . . . . 15 88 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 89 9. Security Considerations . . . . . . . . . . . . . . . . . . . 15 90 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 91 10.1. Normative References . . . . . . . . . . . . . . . . . . . 16 92 10.2. Informative References . . . . . . . . . . . . . . . . . . 16 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 95 1. Introduction 97 This document specifies an initial set of identifiers to be used in 98 the Transport Profile of Multiprotocol Label Switching (MPLS-TP). 99 The MPLS-TP requirements (RFC 5654) [7] require that the elements and 100 objects in an MPLS-TP environment are able to be configured and 101 managed without a control plane. In such an environment many 102 conventions for defining identifiers are possible. This document 103 defines identifiers for MPLS-TP management and OAM functions suitable 104 to IP/MPLS conventions. The identifiers have been chosen to be 105 compatible with existing IP, MPLS, GMPLS, and Pseudowire definitions. 107 This document is a product of a joint Internet Engineering Task Force 108 (IETF) / International Telecommunication Union Telecommunication 109 Standardization Sector (ITU-T) effort to include an MPLS Transport 110 Profile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge 111 (PWE3) architectures to support the capabilities and functionalities 112 of a packet transport network as defined by the ITU-T. 114 1.1. Terminology 116 AII: Attachment Interface Identifier 118 ASN: Autonomous System Number 120 EGP: Exterior Gateway Protocol 122 FEC: Forwarding Equivalence Class 124 GMPLS: Generalized Multi-Protocol Label Switching 126 IGP: Interior Gateway Protocol 128 LSP: Label Switched Path 130 LSR: Label Switching Router 132 MEG: Maintenance Entity Group 134 MEP: Maintenance Entity Group End Point 136 MIP: Maintenance Entity Group Intermediate Point 138 MPLS: Multi-Protocol Label Switching 140 NNI: Network-to-Network Interface 142 OAM: Operations, Administration and Maintenance 143 P2P: Point to Point 145 PW: Pseudowire 147 RSVP: Resource Reservation Protocol 149 RSVP-TE: RSVP Traffic Engineering 151 S-PE: Switching Provider Edge 153 T-PE: Terminating Provider Edge 155 1.2. Requirements Language 157 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 158 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 159 document are to be interpreted as described in RFC 2119 [1]. 161 1.3. Notational Conventions 163 All multiple-word atomic identifiers use underscores (_) between the 164 words to join the words. Many of the identifiers are composed of a 165 set of other identifiers. These are expressed by listing the latter 166 identifiers joined with double-colon, "::", notation. 168 Where the same identifier type is used multiple times in a 169 concatenation, they are qualified by a prefix joined to the 170 identifier by a dash (-). For example A1-Node_ID is the Node_ID of a 171 node referred to as A1. 173 The notation does define a preferred ordering of the fields. 174 Specifically the designation A1 is used to indicate the lower sort 175 order of a field or set of fields and Z9 is used to indicated the 176 higher sort order of the same. The sort is either alphanumeric or 177 numeric depending on the field's definition. Where the sort applies 178 to a group of fields, those fields are grouped with {...}. 180 Note, however, that the uniqueness of an identifier does not depend 181 on the ordering, but rather, upon the uniqueness and scoping of the 182 fields that compose the identifier. Further the preferred ordering 183 is not intended to constrain protocol designs by dictating a 184 particular field sequence (for example see Section 5.2.1) or even 185 what fields appear in which objects (for example see Section 5.3). 187 2. Named Entities 189 In order to configure, operate and manage a transport network based 190 on the MPLS Transport Profile, a number of entities require 191 identification. Identifiers for the following entities are defined 192 in this document: 194 * Global_ID 196 * Node 198 * Interface 200 * Tunnel 202 * LSP 204 * PW 206 * MEG 208 * MEP 210 * MIP 212 Note that we have borrowed the term tunnel from RSVP-TE (RFC 3209) 213 [2] where it is used to describe an entity that provides a logical 214 association between a source and destination LSR. The tunnel in turn 215 is instantiated by one or more LSPs, where the additional LSPs are 216 used for protection or re-grooming of the tunnel. 218 3. Uniquely Identifying an Operator - the Global_ID 220 The Global_ID is defined to uniquely identify an operator. RFC 5003 221 [3] defines a globally unique Attachment Interface Identifier (AII). 222 That AII is composed of three parts, a Global_ID which uniquely 223 identifies an operator, a prefix, and finally, an attachment circuit 224 identifier. We have chosen to use that Global ID for MPLS-TP. 225 Quoting from RFC 5003, section 3.2, "The global ID can contain the 226 2-octet or 4-octet value of the operator's Autonomous System Number 227 (ASN). It is expected that the global ID will be derived from the 228 globally unique ASN of the autonomous system hosting the PEs 229 containing the actual AIIs. The presence of a global ID based on the 230 operator's ASN ensures that the AII will be globally unique." 232 A Global_ID must be derived from a 4-octet AS number assigned to the 233 operator. Note that 2-octet AS numbers have been incorporated in the 234 4-octet by placing the 2-octet AS number, in the low-order octets and 235 setting the two high-order octets to zero. 237 ASN 0 is reserved and cannot be assigned. A Global_ID of zero means 238 that no Global_ID is specified. Note that a Global_ID of zero is 239 limited to entities contained within a single operator and MUST NOT 240 be used across an NNI. 242 The Global_ID is used solely to provide a globally unique context for 243 other MPLS-TP identifiers. While the AS Number used in the Global_ID 244 MUST be one which the operator is entitled to use, the use of the 245 Global_ID is not related to the use of the ASN in protocols such as 246 BGP. 248 4. Node and Interface Identifiers 250 An LSR requires identification of the node itself and of its 251 interfaces. An interface is the attachment point to a server 252 (sub-)layer, e.g., MPLS-TP section or MPLS-TP tunnel. 254 We call the identifier associated with a node a Node Identifier 255 (Node_ID). The Node_ID is a unique 32-bit value assigned by the 256 operator within the scope of a Global_ID. The structure of the 257 Node_ID is operator specific and is outside the scope of this 258 document. However, the value zero is reserved and MUST NOT be used. 259 Where IPv4 addresses are used, it may be convenient to use the Node's 260 IPv4 loopback address as the Node_ID, however the Node_ID does not 261 need to have any association with the IPv4 address space used in the 262 operator's IGP or EGP. Where IPv6 addresses are used exclusively, a 263 32-bit value unique within the scope of a Global_ID is assigned. 265 An LSR can support multiple layers (e.g. hierarchical LSPs) and the 266 Node_ID belongs to the multiple layer context i.e. it is applicable 267 to all LSPs or PWs that originate on, have a intermediate point on, 268 or terminate on the node. 270 In situations where a Node_ID needs to be globally unique, this is 271 accomplished by prefixing the identifier with the operator's 272 Global_ID. 274 Within the context of a particular node, we call the identifier 275 associated with an interface an Interface Number (IF_Num). The 276 IF_Num is a 32-bit unsigned integer assigned by the operator and MUST 277 be unique within the scope of a Node_ID. The IF_Num value 0 has 278 special meaning (see Section 7.4, MIP Identifiers) and MUST NOT be 279 used to identify an MPLS-TP interface. 281 An Interface Identifier (IF_ID) identifies an interface uniquely 282 within the context of a Global_ID. It is formed by concatenating the 283 Node_ID with the IF_Num. That is, an IF_ID is a 64-bit identifier 284 formed as Node_ID::IF_Num. 286 This convention was chosen to allow compatibility with GMPLS. The 287 GMPLS signaling functional description [4] requires interface 288 identification. GMPLS allows three formats for the Interface_ID. 289 The third format consists of an IPv4 Address plus a 32-bit unsigned 290 integer for the specific interface. The format defined for MPLS-TP 291 is consistent with this format, but uses the Node_ID instead of an 292 IPv4 Address. 294 If an IF_ID needs to be globally unique, this is accomplished by 295 prefixing the identifier with the operator's Global_ID. 297 The attachment point to an MPLS-TP Tunnel (see Section 5.1) also 298 needs an interface identifier. Note that MPLS-TP supports 299 hierarchical tunnels. The attachment point to a MPLS-TP Tunnel at 300 any (sub-)layer requires a node-unique IF_Num. 302 5. MPLS-TP Tunnel and LSP Identifiers 304 In MPLS the actual transport of packets is provided by label switched 305 paths (LSPs). A transport service may be composed of multiple LSPs. 306 Further the LSPs providing a service may change over time due to 307 protection and restoration events. In order to clearly identify the 308 service we use the term "MPLS-TP Tunnel" or simply "tunnel" for a 309 service provided by (for example) a working LSP and protected by a 310 protection LSP. The Tunnel_ID identifies the transport service and 311 provides a stable binding to the client in the face of changes in the 312 the data plane LSPs used to provide the service due to protection or 313 restoration events. This section defines an MPLS-TP Tunnel_ID to 314 uniquely identify a tunnel, and an MPLS-TP LSP_ID to uniquely 315 identify an LSP associated with a tunnel. 317 For the case where multiple LSPs (for example) are used to support a 318 single service with a common set of end-points, using the Tunnel_ID 319 allows for a trivial mapping between the server and client layers, 320 providing a common service identifier which may be either defined by, 321 or used by, the client. 323 Note that this usage is not intended to constrain protection schemes, 324 and may be used to identify any service (protected or unprotected) 325 that may appear to the client as a single service attachment point. 326 Keeping the Tunnel_ID consistent across working and protection LSPs 327 is a useful construct currently employed within GMPLS. However, the 328 Tunnel_ID for a protection LSP MAY differ from that used by its 329 corresponding working LSP. 331 5.1. MPLS-TP Point to Point Tunnel Identifiers 333 At each endpoint a tunnel is uniquely identified by the endpoint's 334 Node_ID and a locally assigned tunnel number. Specifically a 335 Tunnel_Num is a 16-bit unsigned integer unique within the context of 336 the Node_ID. The motivation for each endpoint having its own tunnel 337 number is to allow a compact form for the MEP-ID. See Section 7.2.1. 339 Having two tunnel numbers also serves to simplify other signaling 340 (e.g., setup of associated bidirectional tunnels as described in 341 Section 5.3). 343 The concatenation of the two endpoint identifiers serves as the full 344 identifier. Using the A1/Z9 convention the format of a Tunnel_ID is: 346 A1-{Node_ID::Tunnel_Num}::Z9-{Node_ID::Tunnel_Num} 348 Where the Tunnel_ID needs to be globally unique, this is accomplished 349 by using globally unique Node_IDs as defined above. Thus a globally 350 unique Tunnel_ID becomes: 352 A1-{Global_ID::Node_ID::Tunnel_Num}::Z9-{Global_Id::Node_ID:: 353 Tunnel_Num} 355 When an MPLS-TP Tunnel is configured, it MUST be assigned a unique 356 IF_ID at each endpoint. As usual, the IF_ID is composed of the local 357 Node_ID concatenated with a 32-bit IF_Num. 359 5.2. MPLS-TP LSP Identifiers 361 5.2.1. MPLS-TP Co-Routed Bidirectional LSP Identifiers 363 A co-routed bidirectional LSP can be uniquely identified by a single 364 LSP number within the scope of an MPLS-TP Tunnel_ID. Specifically an 365 LSP_Num is a 16-bit unsigned integer unique within the Tunnel_ID. 366 Thus the format of an MPLS-TP co-routed bidirectional LSP_ID is: 368 A1-{Node_ID::Tunnel_Num}::Z9-{Node_ID::Tunnel_Num}::LSP_Num 370 Note that the uniqueness of identifiers does not depend on the A1/Z9 371 sort ordering. Thus the identifier 373 Z9-{Node_ID::Tunnel_Num}::A1-{Node_ID::Tunnel_Num}::LSP_Num 375 is synonymous with the one above. 377 At the dataplane level, a co-routed bidirectional LSP is composed of 378 two unidirectional LSPs traversing the same links in opposite 379 directions. Since a co-routed bidirectional LSP is provisioned or 380 signaled as a single entity, a single LSP_Num is used for both 381 unidirectional LSPs. The unidirectional LSPs can be referenced by 382 the identifiers: 384 A1-Node_ID::A1-Tunnel_Num::LSP_Num::Z9-Node_ID and 386 Z9-Node_ID::Z9-Tunnel_Num::LSP_Num::A1-Node_ID respectively. 388 Where the LSP_ID needs to be globally unique, this is accomplished by 389 using globally unique Node_IDs as defined above. Thus a globally 390 unique LSP_ID becomes: 392 A1-{Global_ID::Node_ID::Tunnel_Num}::Z9-{Global_Id:: 393 Node_ID::Tunnel_Num}::LSP_Num 395 5.2.2. MPLS-TP Associated Bidirectional LSP Identifiers 397 For an associated bidirectional LSP each of the unidirectional LSPs 398 from A1 to Z9 and Z9 to A1 require LSP_Nums. Each unidirectional LSP 399 is uniquely identified by a single LSP number within the scope of the 400 ingress's Tunnel_Num. Specifically an LSP_Num is a 16-bit unsigned 401 integer unique within the scope of the ingress's Tunnel_Num. Thus the 402 format of an MPLS-TP associated bidirectional LSP_ID is: 404 A1-{Node_ID::Tunnel_Num::LSP_Num}:: 405 Z9-{Node_ID::Tunnel_Num::LSP_Num} 407 At the dataplane level, an associated bidirectional LSP is composed 408 of two unidirectional LSPs between two nodes in opposite directions. 409 The unidirectional LSPs may be referenced by the identifiers: 411 A1-Node_ID::A1-Tunnel_Num::A1-LSP_Num::Z9-Node_ID and 413 Z9-Node_ID::Z9-Tunnel_Num::Z9-LSP_Num::A1-Node_ID respectively. 415 Where the LSP_ID needs to be globally unique, this is accomplished by 416 using globally unique Node_IDs as defined above. Thus a globally 417 unique LSP_ID becomes: 419 A1-{Global_ID::Node_ID::Tunnel_Num::LSP_Num}:: 420 Z9-{Global_Id::Node_ID::Tunnel_Num::LSP_Num} 422 5.3. Mapping to RSVP Signaling 424 This section is informative and exists to help understand the 425 structure of the LSP IDs. 427 GMPLS [5] is based on RSVP-TE [2]. This section defines the mapping 428 from an MPLS-TP LSP_ID to RSVP-TE. At this time, RSVP-TE has yet to 429 be extended to accommodate Global_IDs. Thus a mapping is only made 430 for the network unique form of the LSP_ID. 432 GMPLS and RSVP-TE signaling use a 5-tuple to uniquely identify an LSP 433 within a operator's network. This tuple is composed of a Tunnel 434 Endpoint Address, Tunnel_ID, Extended Tunnel ID, and Tunnel Sender 435 Address and (RSVP) LSP_ID. 437 For a co-routed bidirectional LSP signaled from A1 to Z9, the mapping 438 to the GMPLS 5-tuple is as follows: 440 * Tunnel Endpoint Address = Z9-Node_ID 442 * Tunnel_ID = A1-Tunnel_Num 444 * Extended Tunnel_ID = A1-Node_ID 446 * Tunnel Sender Address = A1-Node_ID 448 * (RSVP) LSP_ID = LSP_Num 450 An associated bidirectional LSP between two nodes A1 and Z9 consists 451 of two unidirectional LSPs, one from A1 to Z9 and one from Z9 to A1. 453 In situations where a mapping to the RSVP-TE 5-tuples is required, 454 the following mappings are used. For the A1 to Z9 LSP the mapping 455 would be: 457 * Tunnel Endpoint Address = Z9-Node_ID 459 * Tunnel_ID = A1-Tunnel_Num 461 * Extended Tunnel_ID = A1-Node_ID 463 * Tunnel Sender Address = A1-Node_ID 465 * (RSVP) LSP_ID = A1-LSP_Num 467 Likewise, the Z9 to A1 LSP, the mapping would be: 469 * Tunnel Endpoint Address = A1-Node_ID 471 * Tunnel_ID = Z9-Tunnel_Num 472 * Extended Tunnel_ID = Z9-Node_ID 474 * Tunnel Sender Address = Z9-Node_ID 476 * (RSVP) LSP_ID = Z9-LSP_Num 478 6. Pseudowire Path Identifiers 480 Pseudowire signaling (RFC 4447 [6]) defines two FECs used to signal 481 pseudowires. Of these, FEC Type 129 along with AII Type 2 as defined 482 in RFC 5003 [3] fits the identification requirements of MPLS-TP. 484 In an MPLS-TP environment, a PW is identified by a set of identifiers 485 which can be mapped directly to the elements required by FEC 129 and 486 AII Type 2. To distinguish this identifier from other Pseudowire 487 Identifiers, we call this a Pseudowire Path Identifier (PW_Path_ID). 489 The AII Type 2 is composed of three fields. These are the Global_ID, 490 the Prefix, and the AC_ID. The Global_ID used in this document is 491 identical to the Global_ID defined in RFC 5003. The Node_ID is used 492 as the Prefix. The AC_ID is as defined in RFC 5003. 494 To complete the FEC 129, all that is required is an Attachment Group 495 Identifier (AGI). That field is exactly as specified in RFC 4447. A 496 (bidirectional) pseudowire consists of a pair of unidirectional LSPs, 497 one in each direction. Thus for signaling, FEC 129 has a notion of 498 Source AII (SAII) and Target AII (TAII). These terms are used 499 relative to the direction of the LSP. 501 In a purely configured environment when referring to the entire PW, 502 this distinction is not critical. That is a FEC 129 of AGIa::AIIb:: 503 AIIc is equivalent to AGIa::AIIc::AIIb. 505 We note that in a signaled environment, the required convention in 506 RFC 4447 is that at a particular endpoint, the AII associated with 507 that endpoint comes first. The complete PW_Path_ID is: 509 AGI::A1-{Global_ID::Node_ID::AC_ID}:: 510 Z9-{Global_ID::Node_ID::AC_ID}. 512 In a signaled environment the LSP from A1 to Z9 would be initiated 513 with a label request from A1 to Z9 with the fields of the FEC 129 514 completed as follows: 516 AGI = AGI 517 SAAI = A1-{Global_ID::Node_ID::AC_ID} 518 TAII = Z9-{Global_ID::Node_ID::AC_ID} 520 The LSP from Z9 to A1 would signaled with: 522 AGI = AGI 523 SAAI = Z9-{Global_ID::Node_ID::AC_ID} 524 TAII = A1-{Global_ID::Node_ID::AC_ID} 526 7. Maintenance Identifiers 528 In MPLS-TP a Maintenance Entity Group (MEG) represents an Entity that 529 requires management and defines a relationship between a set of 530 maintenance points. A maintenance point is either a Maintenance 531 Entity Group End-point (MEP) or a Maintenance Entity Group 532 Intermediate Point (MIP). Maintenance points are uniquely associated 533 with a MEG. Within the context of a MEG, MEPs and MIPs must be 534 uniquely identified. This section defines a means of uniquely 535 identifying Maintenance Entity Groups, Maintenance Entities and 536 uniquely defining MEPs and MIPs within the context of a Maintenance 537 Entity Group. 539 7.1. Maintenance Entity Group Identifiers 541 Maintenance Entity Group Identifiers (MEG_IDs) are required for 542 MPLS-TP sections, LSPs and Pseudowires. The formats were chosen to 543 follow the IP compatible identifiers defined above. 545 7.1.1. MPLS-TP Section MEG_IDs 547 IP compatible MEG_IDs for MPLS-TP sections are formed by 548 concatenating the two IF_IDs of the corresponding section using the 549 A1/Z9 ordering. For example: 551 A1-IF_ID::Z9-IF_ID 553 Where the Section_MEG_ID needs to be globally unique, this is 554 accomplished by using globally unique Node_IDs as defined above. 555 Thus a globally unique Section_MEG_ID becomes: 557 A1-{Global_ID::IF_ID}::Z9-{Global_ID::IF_ID} 559 7.1.2. MPLS-TP LSP MEG_IDs 561 A MEG pertains to a unique MPLS-TP LSP. IP compatible MEG_IDs for 562 MPLS-TP LSPs are simply the corresponding LSP_IDs, however, the the 563 A1/Z9 ordering MUST be used. For bidirectional co-routed LSPs the 564 format of the LSP_ID is found in Section 5.2.1. For associated 565 bidirectional LSPs the format is in Section 5.2.2. 567 We note that while the two identifiers are syntactically identical, 568 they have different semantics. This semantic difference needs to be 569 made clear. For instance if both a MPLS-TP LSP_ID and MPLS-TP LSP 570 MEG_IDs are to be encoded in TLVs, different types need to be 571 assigned for these two identifiers. 573 7.1.3. Pseudowire MEG_IDs 575 For Pseudowires a MEG pertains to a single PW. The IP compatible 576 MEG_ID for a PW is simply the corresponding PW_Path_ID, however, the 577 the A1/Z9 ordering MUST be used. The PW_Path_ID is described in 578 Section 6. We note that while the two identifiers are syntactically 579 identical, they have different semantics. This semantic difference 580 needs to be made clear. For instance if both a PW_Path_ID and a 581 PW_MEG_ID are to be encoded in TLVs, different types need to be 582 assigned for these two identifiers. 584 7.2. MEP_IDs 586 7.2.1. MPLS-TP LSP_MEP_ID 588 In order to automatically generate MEP_IDs for MPLS-TP LSPs, we use 589 the elements of identification that are unique to an endpoint. This 590 ensures that MEP_IDs are unique for all LSPs within a operator. When 591 Tunnels or LSPs cross operator boundaries, these are made unique by 592 pre-pending them with the operator's Global_ID. 594 The MPLS-TP LSP_MEP_ID is 596 Node_ID::Tunnel_Num::LSP_Num 598 where the Node_ID is the node in which the MEP is located and 599 Tunnel_Num is the tunnel number unique to that node. In the case of 600 co-routed bidirectional LSPs, the single LSP_Num is used at both 601 ends. In the case of associated bidirectional LSPs, the LSP_Num is 602 the one unique to where the MEP resides. 604 In situations where global uniqueness is required this becomes: 606 Global_ID::Node_ID::Tunnel_Num::LSP_Num 608 7.2.2. MEP_IDs for Pseudowires 610 Like MPLS-TP LSPs, Pseudowire endpoints (T-PEs) require MEP_IDs. In 611 order to automatically generate MEP_IDs for PWs, we simply use the 612 AGI plus the AII associated with that end of the PW. Thus a MEP_ID 613 used in end-to-end for a Pseudowire T-PE takes the form 615 AGI::Global_ID::Node_ID::AC_ID 617 where the Node_ID is the node in which the MEP is located and the 618 AC_ID is the AC_ID of the Pseudowire at that node. 620 7.3. Pseudowire Segment Endpoint IDs 622 In some OAM communications, messages are originated by the node at 623 one end of a PW segment and relayed to the other end of that same 624 segment by setting the TTL of the PW label to one (1). For a multi- 625 segment pseudowire, TTL could be set to any value that would cause 626 OAM messages to reach the target segment end-point (up to and 627 including 255). In such communications an identifier for the 628 pseudowire segment endpoint is needed. We call this a Pseudowire 629 Segments Endpoint ID or PW_SE_ID. 631 The PW_SE_ID is formed by a combination of a PW MEP_ID and the 632 identification of the local node. At an S-PE, there are two PW 633 segments. We distinguish the segments by using the MEP_ID which is 634 upstream of the PW segment in question. To complete the 635 identification we suffix this with the identification of the local 636 node. 638 +-------+ +-------+ +-------+ +-------+ 639 | | | | | | | | 640 | A|---------|B C|---------|D E|---------|F | 641 | | | | | | | | 642 +-------+ +-------+ +-------+ +-------+ 643 (T)PE1 (S)PE2 (S)PE3 (T)PE4 645 Pseudowire Maintenance Points 647 For example, suppose that in the above figure all of the nodes have 648 Global_ID GID1; the node are represented as named in the figure; and 649 The identification for the Pseudowire is: 651 AGI = AGI1 652 A1-Global_ID = GID1 653 A1-Node_ID = PE1 654 A1-AC_ID = AII1 655 Z9-Global_ID = GID1 656 Z9-Node_ID = PE4 657 Z9-AC_ID = AII4 659 The MEP_ID at point A would be - 661 AGI1::GID1::PE1::AII1 663 The PW_SE_ID at point B would be - 665 AGI1::GID1::PE4::AII4::GID1::PE2 667 The PW_SE_ID at point C would be - 669 AGI1::GID1::PE1::AII1::GID1::PE2 671 7.4. MIP Identifiers 673 At a cross-connect point, in order to automatically generate MIP_IDs 674 for MPLS-TP, we simply use the IF_IDs of the two interfaces which are 675 cross-connected via the label bindings of the MPLS-TP LSP or PW. 676 This allows, two MIPs to be independently identified in one node 677 where a per-interface MIP model is used. If only a per node MIP 678 model is used then one MIP is configured. In this case the MIP_ID is 679 formed using the Node_ID and an IF_Num of 0. 681 8. IANA Considerations 683 There are no IANA actions resulting from this document. 685 9. Security Considerations 687 This document describes an information model and, as such, does not 688 introduce security concerns. Protocol specifications that describe 689 use of this information model, however, may introduce security risks 690 and concerns about authentication of participants. For this reason, 691 the writers of protocol specifications for the purpose of describing 692 implementation of this information model need to describe security 693 and authentication concerns that may be raised by the particular 694 mechanisms defined and how those concerns may be addressed. 696 10. References 698 10.1. Normative References 700 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 701 Levels", BCP 14, RFC 2119, March 1997. 703 [2] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. 704 Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", 705 RFC 3209, December 2001. 707 [3] Metz, C., Martini, L., Balus, F., and J. Sugimoto, "Attachment 708 Individual Identifier (AII) Types for Aggregation", RFC 5003, 709 September 2007. 711 [4] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) 712 Signaling Functional Description", RFC 3471, January 2003. 714 [5] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) 715 Signaling Resource ReserVation Protocol-Traffic Engineering 716 (RSVP-TE) Extensions", RFC 3473, January 2003. 718 [6] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. Heron, 719 "Pseudowire Setup and Maintenance Using the Label Distribution 720 Protocol (LDP)", RFC 4447, April 2006. 722 10.2. Informative References 724 [7] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., and S. 725 Ueno, "Requirements of an MPLS Transport Profile", RFC 5654, 726 September 2009. 728 Authors' Addresses 730 Matthew Bocci 731 Alcatel-Lucent 732 Voyager Place, Shoppenhangers Road 733 Maidenhead, Berks SL6 2PJ 734 UK 736 Email: matthew.bocci@alcatel-lucent.com 737 George Swallow 738 Cisco 740 Email: swallow@cisco.com 742 Eric Gray 743 Ericsson 744 900 Chelmsford Street 745 Lowell, Massachussetts 01851-8100 747 Email: eric.gray@ericsson.com