RFC 6370

RFC 6370: MPLS Transport Profile (MPLS-TP) Identifiers 🎀

Okay bestie, the title block first 💅 This is RFC 6370, MPLS Transport Profile (MPLS-TP) Identifiers, from the IETF. The authors are M. Bocci (Alcatel-Lucent), G. Swallow (Cisco), and E. Gray (Ericsson). It's a Standards Track doc, ISSN 2070-1721, dated September 2011 📅 The title block doesn't list anything it obsoletes or updates 🙈

Abstract 🌸

This doc lays out a starter set of identifiers for the Transport Profile of Multiprotocol Label Switching (MPLS-TP) ✨ The MPLS-TP requirements (RFC 5654) say that everything in an MPLS-TP setup has to be configurable and manageable without a control plane 🫶 There are loads of ways you could name identifiers in that world, so this doc picks the ones for MPLS-TP management and Operations, Administration, and Maintenance (OAM) functions that play nicely with IP/MPLS conventions 💜

It's also a joint effort between the IETF and the International Telecommunication Union Telecommunication Standardization Sector (ITU-T) 🌈 The goal is to bring an MPLS Transport Profile into the IETF MPLS and Pseudowire Emulation Edge-to-Edge (PWE3) architectures so they can support the capabilities of a packet transport network as the ITU-T defines it. Iconic teamwork 👑

Status of This Memo 📜

This is an Internet Standards Track document.

This doc is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community 🫶 It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). For more on Internet Standards, see Section 2 of RFC 5741.

For the current status, any errata, and how to send feedback, go to http://www.rfc-editor.org/info/rfc6370 🔗

Copyright Notice ©️

Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.

This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the publication date. Please read these carefully, because they spell out your rights and restrictions for this doc 📖 Code Components pulled from this doc must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come with no 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

1. Introduction ✨

This doc lays out a starter set of identifiers for the Transport Profile of Multiprotocol Label Switching (MPLS-TP) 💖 The MPLS-TP requirements (RFC 5654 [7]) say that everything in an MPLS-TP environment has to be configurable and manageable without a control plane. There are lots of possible conventions for naming identifiers in that world, so this doc defines identifiers for MPLS-TP management and OAM functions that are compatible with IP/MPLS conventions. Basically, the identifiers were picked to fit with the existing IP, MPLS, GMPLS, and Pseudowire definitions 🦋

Same story as the abstract: it's a joint IETF / ITU-T effort to put an MPLS Transport Profile inside the IETF MPLS and Pseudowire Emulation Edge-to-Edge (PWE3) architectures, so a packet transport network can do what the ITU-T says it should 🌸

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
• 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 🎯

Here's the key bit: the words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this doc are to be read as described in RFC 2119 [1]. Those capitals are doing serious work, so don't ignore them 👑

1.3. Notational Conventions 🧩

Every identifier made of multiple words uses underscores (_) between the words to join them. A lot of identifiers are built out of other identifiers, and those get written by listing the parts joined with the double-colon :: notation.

When the same identifier type shows up more than once in a concatenation, a prefix gets added with a dash (-) to tell them apart. For example, A1-Node_ID is the Node_ID of the node called A1 💅

The notation sets a preferred ordering for fields. A1 marks the lower sort order of a field or group of fields, and Z9 marks the higher sort order. The sort is alphanumeric or numeric depending on how the field is defined. When a sort applies to a group of fields, the group is wrapped in {...}.

Important nuance, though: uniqueness of an identifier doesn't depend on the ordering. It depends on the uniqueness and scoping of the fields that make it up. And the preferred ordering doesn't restrict protocol designs by forcing one field sequence (see Section 5.2.1 for an example), or even dictating which fields show up in which objects (see Section 5.3) 🙈

2. Named Entities 🏷️

To configure, operate, and manage a transport network based on the MPLS Transport Profile, a bunch of entities need identifiers. This doc defines identifiers for these entities:

• Global_ID
• Node
• Interface
• Tunnel
• LSP
• PW
• MEG
• MEP
• MIP

Quick side note: we borrowed the term "tunnel" from RSVP-TE (RFC 3209 [2]), where it describes an entity that gives a logical association between a source and destination LSR. The tunnel is then set up by one or more LSPs, and the extra LSPs are used for protection or re-grooming of the tunnel 🦋

3. Uniquely Identifying an Operator - the Global_ID 🌍

The Global_ID exists to uniquely identify an operator ✨ RFC 5003 [3] defines a globally unique Attachment Interface Identifier (AII). That AII has three parts: a Global_ID that uniquely identifies an operator, a prefix, and an attachment circuit identifier. We decided to use that same Global ID for MPLS-TP 💖 Here's what RFC 5003, Section 3.2 says:

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 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.

Now the rules 👀 A Global_ID is an unsigned 32-bit value and it MUST be derived from a 4-octet AS number assigned to the operator. Also, 2-octet AS numbers fit inside the 4-octet form: you put the 2-octet AS number in the low-order octets and set the two high-order octets to zero 🧚

ASN 0 is reserved, so it can't be assigned to an operator. An identifier with a Global_ID of zero means no Global_ID is specified. A Global_ID of zero is limited to entities inside a single operator, and it MUST NOT be used across an NNI 💀

The Global_ID's only job is to give other MPLS-TP identifiers a globally unique context. The AS number in the Global_ID MUST be one the operator is entitled to use, but using the Global_ID has nothing to do with how the ASN gets used in protocols like BGP 🫶

4. Node and Interface Identifiers ✨

okay so an LSR (bestie, that's a Label Switching Router 🦋) needs to know who itself is, and also who each of its interfaces are. An interface is the attachment point to a server (sub-)layer, like an MPLS-TP section or an MPLS-TP tunnel 🔌

We call the identifier for a node a "Node Identifier" (Node_ID) 💖 It's a unique 32-bit value that the operator assigns within the scope of a Global_ID. How the Node_ID is structured is totally up to the operator, and that's outside this doc 🤷‍♀️ But the value zero is reserved, so it MUST NOT be used 🚫 Just don't 💀

If you're using IPv4 addresses, it may be convenient to use the Node's IPv4 loopback address as the Node_ID 🌸 Still, the Node_ID does not need to have any connection to the IPv4 address space the operator uses in their IGP or EGP. Like, it's its own thing 💅 And if you're using IPv6 addresses exclusively, a 32-bit value that's unique within the scope of a Global_ID gets assigned instead ✨

An LSR can support multiple layers (hierarchical LSPs, for example) 🧚 and the Node_ID belongs to that whole multiple-layer context. So it applies to all the LSPs or PWs that start on the node, have an intermediate point on it, or end on it. Main character energy 👑

If a Node_ID needs to be globally unique, you get that by putting the operator's Global_ID in front of it 🌍

Now, "interface" is the word used for the attachment point to an MPLS-TP section 🎀 Within a particular node, the identifier for an interface is called an "Interface Number" (IF_Num) 🍓 It's a 32-bit unsigned integer that the operator assigns, and it MUST be unique within the scope of a Node_ID 🔒 The IF_Num value 0 has a special meaning (see Section 7.3, MIP Identifiers) 👀 so it MUST NOT be used to identify an MPLS-TP interface. Hard no 🙅‍♀️

Note that IF_Num has no relation to the ifNum object defined in RFC 2863 [8] 🙃 And no mapping between IF_Num and ifIndex in RFC 2863 is mandated either. Not the same vibe at all 😭

An "Interface Identifier" (IF_ID) identifies an interface uniquely within the context of a Global_ID 💜 You make it by concatenating the Node_ID with the IF_Num. So an IF_ID is a 64-bit identifier formed as:

Node_ID::IF_Num

This convention was picked so it stays compatible with GMPLS 🤝 The GMPLS signaling functional description [4] requires interface identification. GMPLS allows three formats for the Interface_ID, and the third one is an IPv4 address plus a 32-bit unsigned integer for the specific interface. The MPLS-TP format is consistent with that third one, but it uses the Node_ID instead of an IPv4 address. It's giving compatible-but-make-it-ours 🌈

If an IF_ID needs to be globally unique, you prefix it with the operator's Global_ID 🌏

One more thing 👀 MPLS-TP supports hierarchical sections. So the attachment point to an MPLS-TP section at any (sub-)layer needs a node-unique IF_Num 🫶

5. MPLS-TP Tunnel and LSP Identifiers 🦋

okay so in MPLS, the actual transport of packets is done by Label Switched Paths (LSPs) 🛤️ A transport service might be made of multiple LSPs. And the LSPs providing a service can change over time because of protection and restoration events, which is so dramatic 😭 So to clearly identify the service, we use the term "MPLS-TP Tunnel" (or just "tunnel") for a service provided by, for example, a working LSP that's protected by a protection LSP 🛡️ The "Tunnel Identifier" (Tunnel_ID) names the transport service and gives a stable binding to the client, even when the data-plane LSPs change because of protection or restoration events 💖 This section defines an MPLS-TP Tunnel_ID to uniquely identify a tunnel, plus an MPLS-TP LSP Identifier (LSP_ID) to uniquely identify an LSP associated with a tunnel. Two IDs, one vibe ✨

When multiple LSPs (for example) support one single service with a common set of end points, using the Tunnel_ID gives you a trivial mapping between the server and client layers 🧩 It's a common service identifier that can be either defined by or used by the client. Clean 💅

Note that this usage doesn't constrain protection schemes 🙌 It can identify any service, protected or unprotected, that might look like a single service attachment point to the client. Keeping the Tunnel_ID consistent across working and protection LSPs is a useful construct that GMPLS already uses 🌸 But the Tunnel_ID for a protection LSP MAY differ from the one its corresponding working LSP uses. So it's optional, which is kinda iconic 🫠

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 that's unique within the context of the Node_ID. Why does each end point get its own tunnel number? To allow a compact form for the MEP_ID 🍬 See Section 7.2.2.

Having two tunnel numbers also helps simplify other signaling, like setting up associated bidirectional tunnels (as described in Section 5.3) 🤓

The full identifier is the two end point identifiers put together 🧷 Using the A1/Z9 convention, the format of a Tunnel_ID is:

A1-{Node_ID::Tunnel_Num}::Z9-{Node_ID::Tunnel_Num}

If the Tunnel_ID needs to be globally unique, you get there by using globally unique Node_IDs, as defined above 🌐 So 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 the local Node_ID concatenated with a 32-bit IF_Num. Easy peasy 🍓

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 they use these same forms of identifiers. Everything's family 👯‍♀️

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 that's unique within the Tunnel_ID. So the format of an MPLS-TP co-routed bidirectional LSP_ID is:

A1-{Node_ID::Tunnel_Num}::Z9-{Node_ID::Tunnel_Num}::LSP_Num

The uniqueness of identifiers does not depend on the A1/Z9 sort ordering 🙃 So this identifier:

Z9-{Node_ID::Tunnel_Num}::A1-{Node_ID::Tunnel_Num}::LSP_Num

is synonymous with the one above. Same thing, different order 💫

At the data-plane level, a co-routed bidirectional LSP is made of two unidirectional LSPs traversing the same links in opposite directions 🔄 Since it's provisioned or signaled as a single entity, a single LSP_Num is used for both unidirectional LSPs. The unidirectional LSPs can be referenced by these 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.

If the LSP_ID needs to be globally unique, you use globally unique Node_IDs, as defined above 🌍 So 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 (A1 to Z9, and Z9 to A1) needs its own LSP_Num 🙋‍♀️ 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 16-bit unsigned integer that's unique within the scope of the ingress's Tunnel_Num. So 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 made of two unidirectional LSPs between two nodes, going in opposite directions 🔀 The unidirectional LSPs may be referenced by these 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.

If the LSP_ID needs to be globally unique, you use globally unique Node_IDs, as defined above 🌏 So 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 you understand the structure of the LSP IDs 🧠 It's not a requirement, just a helpful little guide 🫶

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 hasn't been extended to accommodate Global_IDs yet 😤 So a mapping is only made for the network unique form of the LSP_ID, and it assumes the operator chose 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 🔍 That tuple is made up of a Tunnel End-point Address, Tunnel_ID, Extended Tunnel ID, Tunnel Sender Address, and the (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's often used is to fill this field with the same value as the Tunnel Sender Address 🧁 The examples below follow that convention. Note that these are only examples, bestie 💜

For a co-routed bidirectional LSP signaled from A1 to Z9, the mapping to the GMPLS 5-tuple looks like this:

• 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, is made of two unidirectional LSPs: one from A1 to Z9 and one from Z9 to A1 🔁

When you need a mapping to the RSVP-TE 5-tuples, these 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

And for 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 ✨

okay so pseudowire signaling (RFC 4447 [6]) defines two FECs used to signal pseudowires 🎀 and honestly? Only one of them is the main character here. The Generalized PWid FEC (type 129), together with AII Type 2 as defined in RFC 5003 [3], fits the identification requirements of MPLS-TP 💅

In an MPLS-TP environment, a PW is identified by a set of identifiers that map directly onto the elements needed by the Generalized PWid FEC (type 129) and AII Type 2 🦋 To tell this identifier apart from other Pseudowire Identifiers, we call it a Pseudowire Path Identifier (PW_Path_ID) 💖

AII Type 2 has three fields: 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 gets used as the Prefix, and the AC_ID is exactly as defined in RFC 5003 ✨

To complete the Generalized PWid FEC (type 129), all you need is an Attachment Group Identifier (AGI) 🧚 That field is exactly as specified in RFC 4447. Now here's the fun part 🙈 A (bidirectional) pseudowire is actually a pair of unidirectional LSPs, one in each direction. So for signaling, the Generalized PWid FEC (type 129) has a notion of Source AII (SAII) and Target AII (TAII). These terms are relative to the direction of the LSP. The SAII gets assigned to the end that allocates the PW label for a given direction, and the TAII goes to the other end 👑

In a purely configured environment, when you're talking about the entire PW, this distinction isn't critical. A Generalized PWid FEC (type 129) of AGIa::AIIb::AIIc is equivalent to AGIa::AIIc::AIIb 🍓

We do need to note that in a signaled environment, RFC 4447 requires that at a particular end point, the AII associated with that end point comes first 🔥 The complete PW_Path_ID looks like this:

   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 gets initiated with a label request from A1 to Z9, and the fields of the Generalized PWid FEC (type 129) get completed like this 😭

   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 be signaled with:

   AGI = AGI
   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) is an entity that needs management, and it 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 gives a way to uniquely identify Maintenance Entity Groups and Maintenance Entities, and it 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. Check out "MPLS-TP Data Plane Architecture" (RFC 5960 [10]) for the deets 🧚 Sections above layer 0 are MPLS-TP LSPs, so they use their MPLS-TP LSP MEG IDs, which are 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

When the Section_MEG_ID needs to be globally unique, that's handled by using globally unique Node_IDs as defined above 🌸 So 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, but the A1/Z9 ordering MUST be used 🔥 For bidirectional co-routed LSPs, the format of the LSP_ID is in Section 5.2.1. For associated bidirectional LSPs, it's in Section 5.2.2 ✨

Here's the tea ☕ The two identifiers are syntactically identical, but they have different semantics, and that difference needs to be made clear 🙈 For example, if both an MPLS-TP LSP_ID and an MPLS-TP LSP MEG_ID are going to be encoded in TLVs, they need different types assigned 👑

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, but the A1/Z9 ordering MUST be used 💖 The PW_Path_ID is described in Section 6. Same energy as before: the two identifiers are syntactically identical with different semantics, and that needs to be made clear 😭 If both a PW_Path_ID and a PW_MEG_ID get encoded in TLVs, different types need to be assigned for each one 🌈

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

When the Section MEP_ID needs to be globally unique, that's accomplished by using globally unique Node_IDs as defined above 🌸 So a globally unique Section MEP_ID becomes:

   Global_ID::IF_ID

7.2.2. MPLS-TP LSP_MEP_ID

To automatically generate MEP_IDs for MPLS-TP LSPs, we use the elements of identification that are unique to an end point 🍓 This makes sure MEP_IDs are unique for all LSPs within an operator 🔥 When Tunnels or LSPs cross operator boundaries, they get 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

Here, the Node_ID is the node where the MEP is located, and Tunnel_Num is the tunnel number unique to that node ✨ For co-routed bidirectional LSPs, the single LSP_Num is used at both ends 🦋 For associated bidirectional LSPs, the LSP_Num is the one unique to where the MEP resides 👑

When global uniqueness is required, it 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) need MEP_IDs 💖 To automatically generate MEP_IDs for PWs, we just use the AGI plus the AII associated with that end of the PW 🧚 So 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 where 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's associated with a particular interface, we simply use the IF_ID (see Section 4) of the interfaces that are cross-connected 🌈 This lets MIPs 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 that 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 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 the security and authentication concerns raised by the particular mechanisms they define, and how those concerns may be addressed 🔥

Uniqueness is the whole ballgame here 💀 Uniqueness of the identifiers from this document is guaranteed by the assigner. For example, 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 assignment by an operator. If an assigner fails to use unique values within the specified scoping for any of the identifiers defined here, it could result in operational problems. For example, a non-unique MEP value could result in failure to detect a mis-merged LSP. That is a full-on disaster 😭

Protocol specifications that use the identifiers defined here 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.

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