RFC 4990

Use of Addresses in Generalized Multiprotocol Label Switching (GMPLS) Networks

📅 published September 2007, from ietf

RFC 4990: Use of Addresses in Generalized Multiprotocol Label Switching (GMPLS) Networks ✨

Okay bestie 🎀 this is RFC 4990, published in September 2007 by the Network Working Group. It's an Informational doc, so it's sharing good advice, not an official standard 💅 The authors are K. Shiomoto (NTT), R. Papneja (Isocore), and R. Rabbat (Google). Its header doesn't list any RFCs it obsoletes or updates, so it's standing on its own 🦋

Status of This Memo

This memo is for the Internet community as information 📚 It is not an Internet standard of any kind. You can distribute it freely, with no limits 🌈

Abstract

This doc clarifies how addresses get used in Generalized Multiprotocol Label Switching (GMPLS) networks 🧚 The goal is to help GMPLS-capable Label Switching Routers (LSRs) work together smoothly. It's based on real experience from implementation, interoperability testing, and deployment 💖

It explains how to read the address and identifier fields inside GMPLS protocols, and how to pick which addresses go in those fields for different control plane usage models 🍓 It also talks about handling IPv6 sources and destinations in the MPLS and GMPLS Traffic Engineering (TE) Management Information Base (MIB) modules 💜

Here's the important bit: this doc does not create new procedures or processes 🙈 Any requirements or recommendations it makes come straight from the normative text in the RFCs it references ✨

Table of Contents

   1. Introduction ....................................................3
   2. Terminology .....................................................3
   3. Support of Numbered and Unnumbered Links ........................5
   4. Numbered Addressing .............................................6
      4.1. Numbered Addresses in IGPs .................................6
           4.1.1. Router Address and TE Router ID .....................6
           4.1.2. Link ID and Remote Router ID ........................6
           4.1.3. Local Interface IP Address ..........................7
           4.1.4. Remote Interface IP Address .........................7
      4.2. Numbered Addresses in RSVP-TE ..............................7
           4.2.1. IP Tunnel End Point Address in Session Object .......7
           4.2.2. IP Tunnel Sender Address in Sender Template Object ..8
           4.2.3. IF_ID RSVP_HOP Object for Numbered Interfaces .......8
           4.2.4. Explicit Route Object (ERO) .........................9
           4.2.5. Record Route Object (RRO) ...........................9
           4.2.6. IP Packet Source Address ............................9
           4.2.7. IP Packet Destination Address .......................9
   5. Unnumbered Addressing ..........................................10
      5.1. Unnumbered Addresses in IGPs ..............................10
           5.1.1. Link Local/Remote Identifiers in OSPF-TE ...........10
           5.1.2. Link Local/Remote Identifiers in IS-IS-TE ..........11
      5.2. Unnumbered Addresses in RSVP-TE ...........................11
           5.2.1. Sender and End Point Addresses .....................11
           5.2.2. IF_ID RSVP_HOP Object for Unnumbered Interfaces ....11
           5.2.3. Explicit Route Object (ERO) ........................11
           5.2.4. Record Route Object (RRO) ..........................11
           5.2.5. LSP_Tunnel Interface ID Object .....................12
           5.2.6. IP Packet Addresses ................................12
   6. RSVP-TE Message Content ........................................12
      6.1. ERO and RRO Addresses .....................................12
           6.1.1. Strict Subobject in ERO ............................12
           6.1.2. Loose Subobject in ERO .............................14
           6.1.3. RRO ................................................14
           6.1.4. Label Record Subobject in RRO ......................15
      6.2. Component Link Identification .............................15
      6.3. Forwarding Destination of Path Messages with ERO ..........16
   7. Topics Related to the GMPLS Control Plane ......................16
      7.1. Control Channel Separation ................................16
           7.1.1. Native and Tunneled Control Plane ..................16
      7.2. Separation of Control and Data Plane Traffic ..............17
   8. Addresses in the MPLS and GMPLS TE MIB Modules .................17
      8.1. Handling IPv6 Source and Destination Addresses ............18
           8.1.1. Identifying LSRs ...................................18
           8.1.2. Configuring GMPLS Tunnels ..........................18
      8.2. Managing and Monitoring Tunnel Table Entries ..............19
   9. Security Considerations ........................................19
   10. Acknowledgments ...............................................20
   11. References ....................................................20
      11.1. Normative References .....................................20
      11.2. Informative References ...................................21

1. Introduction 🌸

This doc is all about how addresses work in Generalized Multiprotocol Label Switching (GMPLS) [RFC3945] networks 💖 The whole point is to help GMPLS-capable Label Switching Routers (LSRs) play nicely together. It's built on hands-on experience from implementation, interop testing, and deployment 🫶

It walks through how to read the address and identifier fields inside GMPLS protocols (that's RSVP-TE [RFC3473], GMPLS OSPF [RFC4203], and GMPLS ISIS [RFC4205]) and how to choose which addresses to put in those fields for different control plane usage models 🧚

Heads up 💅 This doc does not create new procedures or processes, and the protocol specs listed above are the definitive source. Any requirements or recommendations here are pulled from the normative text in the referenced RFCs, so nothing in this document should be considered normative. Shocking, I know 😭

It also covers handling IPv6 sources and destinations in the MPLS and GMPLS Traffic Engineering (TE) Management Information Base (MIB) modules [RFC3812], [RFC4802] 🦋

2. Terminology 🎀

As [RFC3945] lays out, a GMPLS network can be split into a data plane and a control plane. The control plane can also be split again, into signaling components and routing components 🧠

A data plane switch or router is called a data plane entity. It's a node on the data plane topology graph. A data plane resource is any facility in the data plane, like a data plane entity (node), a data link (edge), or a data label (such as a lambda) ✨

Over on the control plane side, you've got protocol speakers. These are software implementations that talk using signaling or routing protocols. They're control plane entities, and they can be physically located apart from the data plane entities they control. There can also be separate routing entities and signaling entities 💜

GMPLS supports a control plane entity that's responsible for one or more data plane entities, and it also supports separating signaling and routing control plane entities. For this doc, we assume a one-to-one correspondence between control plane and data plane entities. So each data plane switch has a unique control plane entity handling GMPLS signaling and routing protocols, and each control plane presence is responsible for a single data plane switch 🍓

When you put a control plane and a data plane entity together, that combo is called a Label Switching Router (LSR) 🌈

Watch out, though 👀 The term 'Router ID' gets used in two different contexts within GMPLS. It can mean an identifier for a participant in a routing protocol, or an identifier for an LSR that takes part in TE routing. These can be thought of as the control plane and data plane contexts 💖

So this doc distinguishes the contexts with these definitions:

  • Loopback address: A loopback address is a stable IP address of the advertising router that is always reachable if there is any IP connectivity to it [RFC3477], [RFC3630]. For example, an IPv4 127/24 address is excluded from this definition.
  • TE Router ID: A stable IP address of an LSR that is always reachable in the control plane if there is any IP connectivity to the LSR, e.g., a loopback address. The most important requirement is that the address does not become unusable if an interface on the LSR is down [RFC3477], [RFC3630].
  • Router ID: The OSPF protocol version 2 [RFC2328] defines the Router ID to be a 32-bit network-unique number assigned to each router running OSPF. IS-IS [RFC1195] includes a similar concept in the System ID. This document describes both concepts as the "Router ID" of the router running the routing protocol. The Router ID is not required to be a reachable IP address, although an operator may set it to a reachable IP address on the same node.
  • TE link: "A TE link is a representation in the IS-IS/OSPF Link State advertisements and in the link state database of certain physical resources, and their properties, between two GMPLS nodes" [RFC3945].
  • Data plane node: A vertex on the TE graph. It's a data plane switch or router. Data plane nodes are connected by TE links that are built from physical data links. A data plane node is controlled through some mix of management and control plane actions. A data plane node may be under full or partial control of a control plane node.
  • Control plane node: A GMPLS protocol speaker. It may be part of a data plane switch or may be a separate computer. Control plane nodes are connected by control channels, which are logical connection-less or connection-oriented paths in the control plane. A control plane node is responsible for controlling zero, one, or more data plane nodes.
  • Interface ID: The Interface ID is defined in [RFC3477] and in Section 9.1 of [RFC3471].
  • Data Plane Address: This document refers to a data plane address in the context of GMPLS. It does not refer to addresses such as E.164 SAPI in Synchronous Digital Hierarchy (SDH).
  • Control Plane Address: An address used to identify a control plane resource including, and restricted to, control plane nodes and control channels.
  • IP Time to Live (TTL): The IPv4 TTL field or the IPv6 Hop Limit field, whichever is applicable.
  • TED: Traffic Engineering Database.
  • LSR: Label Switching Router.
  • FA: Forwarding Adjacency.
  • IGP: Interior Gateway Protocol.

That's the first chunk, bestie 🫶 Keep going for the good stuff: numbered addressing, unnumbered addressing, and the RSVP-TE message details 💅🔥

okay so the links in the control and data planes can be numbered or unnumbered [RFC3945] 🦋 that means their end points might get IP addresses, OR they get link IDs that belong only to the control plane or data plane entity sitting at the end of the link. implementations get to pick whether they support numbered and/or unnumbered addressing. your call, bestie 💅

the case for numbered addressing is that it makes troubleshooting way easier 🔍 and the case for unnumbered addressing is that it saves on IP address resources 🌸

an LSR can decide that it only wants its own links configured as numbered, OR that it only wants them configured as unnumbered. BUT an LSR must not restrict what other LSRs get to pick, because that could lead to interoperablity issues 😭 so a node should be able to accept and process link advertisements that have both numbered and unnumbered addresses. main character energy for flexibility 👑

numbered and unnumbered addressing get the full breakdown in Sections 4 and 5 of this document, respectively 🧚

4. Numbered Addressing 💜

when numbered addressing is in use, addresses get assigned to each node and each link in both the control and data planes of the GMPLS network 🌈

a numbered link is identified by a network-unique identifier (e.g., an IP address) ✨

4.1. Numbered Addresses in IGPs

okay so in this section we talk about numbered addressing across two Interior Gateway Protocols (IGPs) that got GMPLS extensions: OSPF-TE and IS-IS-TE 🎀 the routing enhancements for GMPLS are defined in [RFC3630], [RFC3784], [RFC4202], [RFC4203], and [RFC4205] 📚

4.1.1. Router Address and TE Router ID

the IGPs define a field called the Router Address. it's used to advertise the TE Router ID 🫶

in OSPF-TE, the Router Address gets advertised using the Router Address TLV structure of the TE Link State Advertisement (LSA) [RFC3630] 💅

in IS-IS-TE, it's referred to as the Traffic Engineering router ID, and it gets carried in the advertised Traffic Engineering router ID TLV [RFC3784] 🦋

in OSPF-TE [RFC3630], the Router ID of the remote end of a TE link is carried in the Link ID sub-TLV. this applies for point-to-point TE links ONLY 🙈 multi-access links are for further study 🔮

in IS-IS-TE [RFC3784], the Extended IS Reachability TLV is used to carry the System ID. this corresponds to the Router ID as described in Section 2 🌸

4.1.3. Local Interface IP Address

the Local Interface IP Address gets advertised in:

  • the Local Interface IP Address sub-TLV in OSPF-TE [RFC3630]
  • the IPv4 Interface Address sub-TLV in IS-IS-TE [RFC3784]

this is the ID of the local end of the numbered TE link ✨ it must be a network-unique number (since this section is all about numbered addressing), but it does not need to be a routable address in the control plane 🍓

4.1.4. Remote Interface IP Address

the Remote Interface IP Address gets advertised in:

  • the Remote Interface IP Address sub-TLV in OSPF-TE [RFC3630]
  • the IPv4 Neighbor Address sub-TLV in IS-IS-TE [RFC3784]

this is the ID of the remote end of the numbered TE link 🫶 it must be a network-unique number (since this section is all about numbered addressing), but it does not need to be a routable address in the control plane

4.2. Numbered Addresses in RSVP-TE

the following subsections describe how addresses get used in the GMPLS signaling protocol [RFC3209], [RFC3473] 🎀

4.2.1. IP Tunnel End Point Address in Session Object

the IP tunnel end point address of the Session Object [RFC3209] is either an IPv4 or IPv6 address 🌈

the Session Object stays invariant for all messages about the same Label Switched Path (LSP) 🔒 the initiator of a Path message sets the IP tunnel end point address in the Session Object to one of:

  • The TE Router ID of the egress, since the TE Router ID is routable and uniquely identifies the egress node 👑
  • The destination data plane address, to precisely identify the interface that should be used for the final hop of the LSP. that's the Remote Interface IP Address of the final TE link, if the ingress knows that address 🎯

the IP tunnel end point address in the Session Object is not required to be routable in the control plane, but it should be present in the TED ✨

4.2.2. IP Tunnel Sender Address in Sender Template Object

the IP tunnel sender address of the Sender Template Object [RFC3209] is either an IPv4 or IPv6 address 💖

when an LSP is being set up to support an IPv4-numbered FA, [RFC4206] recommends that the IP tunnel sender address be set to the head-end address of the TE link that's about to be created, so the tail-end address can be inferred as the /31 partner address 🧚

when an LSP is being set up that will NOT be used to form an FA, the IP tunnel sender address in the Sender Template Object may be set to one of:

  • The TE Router ID of the ingress LSR, since the TE Router ID is a unique, routable ID per node 🌸
  • The sender data plane address (i.e., the Local Interface IP Address) 🦋

4.2.3. IF_ID RSVP_HOP Object for Numbered Interfaces

there are two addresses used in the IF_ID RSVP_HOP object 👀

  1. The IPv4/IPv6 Next/Previous Hop Address [RFC3473]

when it shows up in Path or Resv messages, this address specifies the IP reachable address of the control plane interface used to send the messages, or the TE Router ID of the node that sends the message. basically it's a routable control plane address of the sender of the message, and it can be used to send return messages 📬 note that because of data plane / control plane separation (see Section 7.1) and data plane robustness in the face of control plane faults, it may be advisable to use the TE Router ID, since it's a more stable address 🫶

  1. The IPv4/IPv6 address in the Value Field of the Interface_ID TLV [RFC3471]

this address identifies the data channel associated with the signaling message. in all cases, the data channel is indicated by the data plane local interface address at the upstream LSR, which is to say, at the sender of the Path message 🌊

see Section 6.2 for a description of these fields when bundled links are used 🎀

4.2.4. Explicit Route Object (ERO)

the IPv4/IPv6 address in the ERO gives a data-plane identifier of an abstract node, TE node, or TE link to be part of the signaled LSP ✨

see Section 6 for a description of how addresses get used in the ERO 🧚

4.2.5. Record Route Object (RRO)

the IPv4/IPv6 address in the RRO gives a data-plane identifier of either a TE node or a TE link that is part of an LSP that has been established or is being established 🌈

see Section 6 for a description of how addresses get used in the RRO 💜

4.2.6. IP Packet Source Address

GMPLS signaling messages get encapsulated in IP 📦 the IP packet source address is either an IPv4 or IPv6 address, and it must be a reachable control plane address of the node sending the TE message. to provide control plane robustness, a stable IPv4 or IPv6 control plane address (for example, the TE Router ID) can be used 💖

some implementations may use the IP source address of a received IP packet containing a Path message as the destination IP address of a packet containing the corresponding Resv message (see Section 4.2.7) 🔁 using a stable IPv4 or IPv6 address in the IP packet containing the Path message supports this situation robustly when one of the control plane interfaces is down 🛟

4.2.7. IP Packet Destination Address

the IP packet destination address for an IP packet carrying a GMPLS signaling message is either an IPv4 or IPv6 address, and it must be reachable in the control plane if the message is going to be delivered. it must be an address of the intended next-hop recipient of the message 🎯 that's the big difference from RSVP: the IP packet is NOT addressed to the ultimate destination (the egress) 🙅‍♀️

for a Path message, a stable IPv4 or IPv6 address of the next-hop node may be used. this may be the TE Router ID of the next-hop node. a suitable address may be determined by examining the TE advertisements for the TE link that will form the next-hop data link 🔍

a Resv message is sent to the previous-hop node. the IPv4 or IPv6 destination of an IP packet carrying a Resv message may be any of the following:

  • The IPv4 or IPv6 source address of the received IP packet containing the Path message.
  • A stable IPv4 or IPv6 address of the previous node, found by examining the TE advertisements for the upstream data plane interface.
  • The value in the received Next/Previous Hop Address field of the RSVP_HOP (PHOP) Object [RFC2205].

5. Unnumbered Addressing 🌙

an unnumbered address is the combination of a network-unique node identifier and a node-unique interface identifier ✨

an unnumbered link is identified by the combination of the TE Router ID (which is a reachable address in the control plane) and a node-unique Interface ID [RFC3477] 🫶

5.1. Unnumbered Addresses in IGPs

in this section, we look at unnumbered address advertisement using OSPF-TE and IS-IS-TE 🎀

Link Local and Link Remote Identifiers get carried in OSPF using a single sub-TLV of the Link TLV [RFC4203]. they advertise the IDs of an unnumbered TE link's local and remote ends, respectively. Link Local/Remote Identifiers are numbers unique within the scopes of the advertising LSR and the LSR managing the remote end of the link, respectively [RFC3477] 🔢

note that these numbers are NOT network-unique, so they can't be used as TE link end identifiers on their own 🙈 an unnumbered TE link end network-wide identifier is made of two elements, as defined in [RFC3477]:

  • A TE Router ID that is associated with the link local end
  • The link local identifier.

the Link Local and Link Remote Identifiers get carried in IS-IS using a single sub-TLV of the Extended IS Reachability TLV. link identifiers are exchanged in the Extended Local Circuit ID field of the "Point-to-Point Three-Way Adjacency" IS-IS Option type [RFC4205] 🌸

the same discussion of unique identification from Section 5.1.1 applies here too 💖

5.2. Unnumbered Addresses in RSVP-TE

we consider the interface ID fields of objects used in RSVP-TE in the case of unnumbered addressing in this section 🧚

5.2.1. Sender and End Point Addresses

the IP Tunnel End Point Address in the RSVP Session Object and the IP Tunnel Sender Address in the RSVP Sender Template Object CANNOT use unnumbered addresses [RFC3209], [RFC3473] 🚫

5.2.2. IF_ID RSVP_HOP Object for Unnumbered Interfaces

the interface ID field in the IF_INDEX TLV specifies the interface of the data channel for an unnumbered interface 🌈

in both Path and Resv messages, the value of the interface ID in the IF_INDEX TLV specifies the local interface ID of the associated data channel at the upstream node (the node sending the Path message and receiving the Resv message) 🔁

see Section 6.2 for a description of the use of bundled links 🎀

5.2.3. Explicit Route Object (ERO)

the ERO may use an unnumbered identifier of a TE link to be part of the signaled LSP ✨

see Section 6 for a description of how addresses get used in the ERO 💅

5.2.4. Record Route Object (RRO) 🍞

okay so the RRO is basically a breadcrumb trail 🍞 It records the data-plane identifiers of the TE nodes and TE links that are part of an LSP, whether that LSP is already set up or still being set up. And TE links can be identified with unnumbered addressing too 🦋

see Section 6 for the deets on how addresses show up in the RRO 💅

5.2.5. LSP_Tunnel Interface ID Object 🎀

this one's giving identity card 🪪 The LSP_TUNNEL_INTERFACE_ID Object carries the LSR's Router ID and Interface ID, as described in [RFC3477], to point at an unnumbered Forward Adjacency Interface ID. The Router ID of the GMPLS-capable LSR must be set to the TE Router ID. no exceptions, bestie 🙅‍♀️

5.2.6. IP Packet Addresses 🌸

IP packets can only be addressed to numbered addresses. so unnumbered addresses are a no-go for IP packets, periodt 💀

6. RSVP-TE Message Content 🧚

this section looks at how addresses are used in RSVP EROs and RROs, how component links get identified, and which forwarding addresses RSVP messages use ✨

6.1. ERO and RRO Addresses 🍓

EROs may contain strict or loose hop subobjects. we'll talk about each one separately below. there's also a separate section on how addresses show up in the RRO 💖

implementations that make limited assumptions about what's inside an ERO or RRO when they process a received RSVP message may cause or run into interoperability issues 😭 so if an implementation wants full interoperability, it needs to support the receipt for processing of all ERO and RRO options that fit its hardware capabilities. 🫶

quick clarification: "receipt for processing" just means that an LSR isn't expected to look ahead in an ERO, or to process any subobjects that don't refer to the LSR itself or to the next hop in the ERO. 👀 and an LSR generally isn't expected to process an RRO, except by adding its own info.

also, implementations don't need to support the ERO options that contain Component Link IDs if they don't support link bundling [RFC4201]. ERO processing at region boundaries is described in [RFC4206]. 🌈

6.1.1. Strict Subobject in ERO 🦋

depending on how much control you need, a subobject in the ERO can include an address that specifies an abstract node (a group of nodes), a simple abstract node (a specific node), or a specific interface of a TE link in the data plane [RFC3209]. 🧩

a hop can be flagged as strict (meaning the LSP must go directly to the identified next hop without any intervening nodes), or loose.

if a hop is strict, the ERO may contain any of the following:

  1. Address prefix or AS number specifying a group of nodes.
  2. TE Router ID identifying a specific node.
  3. Link ID identifying an incoming TE link.
  4. Link ID identifying an outgoing TE link, optionally followed by a Component Interface ID and/or one or two Labels.
  5. Link ID identifying an incoming TE link, followed by a Link ID identifying an outgoing TE link, optionally followed by a Component Interface ID and/or one or two Labels.
  6. TE Router ID identifying a specific node, followed by a Link ID identifying an outgoing TE link, optionally followed by a Component Interface ID and/or one or two Labels.
  7. Link ID identifying an incoming TE link, followed by a TE Router ID identifying a specific node, followed by a Link ID identifying an outgoing TE link, optionally followed by Component Interface ID and/or one or two Labels.

ok this part is so iconic 👑 the label value that identifies a single unidirectional resource between two nodes can look different from the upstream side versus the downstream side. this is typically the case in fiber switching, since the label value is a number indicating the port or fiber. it can also happen with lambda switching, because the label value is an index for the lambda in the hardware and isn't necessarily a globally defined value like the wavelength in nanometers. 🌈

the value of a label in any RSVP-TE object shows the value from the perspective of the sender of the object/TLV [RFC3471]. so any label in an ERO is given using the upstream node's identification of the resource. 💜

6.1.2. Loose Subobject in ERO 🌸

there are two differences between Loose and Strict subobjects 💅

  • a subobject marked as a loose hop in an ERO must not be followed by a subobject indicating a label value [RFC3473].
  • a subobject marked as a loose hop in an ERO should never include an identifier (i.e., address or ID) of the outgoing interface.

there's no way to specify in an ERO whether a subobject identifies an incoming or outgoing TE link 🙈 so path computation has to be done by an LSR when it hits a loose hop, to work out the LSP route to the identified next hop. if an interface is specified as a loose hop and is treated as an incoming interface, the path computation will pick a path that enters an LSR through that interface. but if the interface was meant to be an outgoing one, the computed path might be unsatisfactory, and the explicit route in the ERO might be impossible to resolve 😬 so a loose hop that identifies an interface should always identify the incoming TE link in the data plane. 🫶

6.1.3. RRO 🧚

the RRO is used on Path and Resv messages to record the path of an LSP. each LSR adds subobjects to the RRO to record info. the info a node adds to an RRO should be the same in the Path and the Resv message, although some info might not be available yet during LSP setup. ✨

one use of the RRO is letting the operator view the path of the LSP 👀 at any transit node, it should be possible to build the path of the LSP by joining the RRO from the Path message and the RRO from the Resv message.

it's also important that a whole RRO on a Resv message received at an ingress LSR can be used as an ERO on a later Path message to completely recreate the LSP. main character energy 👑

so when a node adds one or more subobjects to an RRO, any of the following options is valid:

  1. TE Router ID identifying the LSR.
  2. Link ID identifying the incoming (upstream) TE link.
  3. Link ID identifying the outgoing (downstream) TE link, optionally followed by a Component Interface ID and/or one or two Labels.
  4. Link ID identifying the incoming (upstream) TE link, followed by a Link ID identifying the outgoing (downstream) TE link, optionally followed by a Component Interface ID and/or one or two Labels.
  5. TE Router ID identifying the LSR, followed by a Link ID identifying the outgoing (downstream) TE link, optionally followed by a Component Interface ID and/or one or two Labels.
  6. Link ID identifying the incoming (upstream) TE link, followed by the TE Router ID identifying the LSR, followed by a Link ID identifying the outgoing (downstream) TE link, optionally followed by a Component Interface ID and/or one or two Labels.

an implementation may choose any of these options, and it must be prepared to receive an RRO that contains any of them 🫶

6.1.4. Label Record Subobject in RRO 🦋

RRO Label recording is requested by an ingress node. it does this by setting the Label Recording flag in the SESSION_ATTRIBUTE object and including an RRO in the Path message, as described in [RFC3209]. when that's the case, each LSR along the LSP should include label information in the RRO in the Path message if it's available. 💖

as [RFC3209] describes, processing for a Resv message "mirrors that of the Path," and "The only difference is that the RRO in a Resv message records the path information in the reverse direction." this means hops get added to the RRO in reverse order, but the info added at each LSR stays in the same order (see Sections 6.1.1, 6.1.2, and 6.1.3). so when label recording is requested, labels show up in the RROs in both the Path and Resv messages 🌈

when a bundled link [RFC4201] is used to provide a data channel, a component link identifier is specified in the Interface Identification TLV in the IF_ID RSVP_HOP Object. this tells you which data channel from inside the bundle is the one to use 🧩 The Interface Identification TLV is IF_INDEX TLV (Type 3) for an unnumbered component link, and IPv4 TLV (Type 1) or IPv6 TLV (Type 2) for a numbered component link.

the component link for the upstream data channel can be different from the one for the downstream data channel in a bidirectional LSP. in that case, the Interface Identification TLV that specifies a downstream interface is followed by another Interface Identification TLV that specifies an upstream interface. 🌸

note that identifiers in TLVs for upstream and downstream data channels, in both Path and Resv messages, are specified from the viewpoint of the upstream node (the node sending the Path message and receiving the Resv message), using identifiers that belong to that node. 👀

an LSR building an ERO may include a Link ID that identifies a bundled link. if the LSR knows the identities of the component links and wants to exert control, it may also include component link identifiers in the ERO. otherwise, the component link identifiers aren't included in the ERO. 💜

when a bundled link is in use, the RRO may include the Link ID that identifies the link bundle. it may also include a component link identifier. ✨

6.3. Forwarding Destination of Path Messages with ERO 🍓

the final destination of the Path message is the Egress node, which is specified by the tunnel end point address in the Session object. 💖

the Egress node must not forward the corresponding Path message downstream, even if the ERO includes the outgoing interface ID of the Egress node for Egress control [RFC4003]. 🙅‍♀️

7.1. Control Channel Separation ✨

in GMPLS, a control channel can be separated from the data channel, and there isn't necessarily a one-to-one association between a control channel and a data channel 🦋 two nodes that are adjacent in the data plane may have multiple IP hops between them in the control plane. wild, right? 🤯

there are two broad types of separated control planes: native and tunneled. they differ mainly in the kind of encapsulation used for signaling messages, which also leads to slightly different address handling with respect to the control plane address. 🧚

7.1.1. Native and Tunneled Control Plane 🦋

okay so a native control plane is the simple, clean one 💅 It just uses regular IP forwarding to deliver RSVP-TE messages between protocol speakers, and the message doesn't get wrapped in any extra encapsulation. no cap, so chic ✨

IP forwarding follows the normal rules for the IP header. but here's the tea 🫖: an IP hop MUST NOT decrement the TTL of the received RSVP-TE message. so the TTL stays exactly as it arrived 🙈

for the case where two adjacent nodes have multiple IP hops between them in the control plane, then as stated in Section 9 of [RFC3945], implementations SHOULD use the mechanisms of Section 6.1.1 of [RFC4206] whether or not they use LSP Hierarchy. it's giving main character energy 👑 Note that Section 6.1.1 of [RFC4206] applies to an "FA-LSP" as stated in that section, but also to a "TE link" for the case where a normal TE link is used.

now the tunneled control plane 🧚 Here the RSVP-TE message gets packaged in an IP packet, and that packet is dropped into a tunnel so it traverses exactly one IP hop. Various tunneling techniques can be used, including (but not limited to) IP-in-IP, Generic Routing Encapsulation (GRE), and IP in MPLS. so many options, bestie 🌈

where the tunneling mechanism includes a TTL, it SHOULD be treated as for any network message sent on that network. and implementations receiving RSVP-TE messages on the tunnel interface MUST NOT compare the RSVP-TE TTL to any other TTL (whether the IP TTL or the tunnel TTL). do NOT mix up the TTLs, periodt 💀

it has been observed that some implementations don't support the tunneled control plane features, so to keep interoperability working, all implementations SHOULD support at least a native control plane 🫶

7.2. Separation of Control and Data Plane Traffic

Data traffic MUST NOT be transmitted through the control plane. this is crucial when attempting PSC (Packet-Switching Capable) GMPLS with separated control and data channels 🚨

8. Addresses in the MPLS and GMPLS TE MIB Modules 🍓

this section describes a method of defining or monitoring an LSP tunnel using the MPLS-TE-STD-MIB module [RFC3812] and GMPLS-TE-STD-MIB module [RFC4802], where the ingress and/or egress routers are identified using 128-bit IPv6 addresses. that's the case when the mplsTunnelIngressLSRId and mplsTunnelEgressLSRId objects in the mplsTunnelTable [RFC3812] can't carry the tunnel end point address and Extended Tunnel Id fields from the signaled Session Object, because the IPv6 variant (LSP_TUNNEL_IPv6_SESSION object) is in use 😭

the normative text for MIB objects for controlling and monitoring MPLS and GMPLS nodes lives in the RFCs referenced above. this section makes no changes to those objects, but it does explain how they can be used to provide the necessary function ✨

8.1. Handling IPv6 Source and Destination Addresses

8.1.1. Identifying LSRs

for this feature to be used, all LSRs in the network MUST advertise a 32-bit value that can be used to identify the LSR. in this document, this is called the 32-bit LSR ID. the 32-bit LSR ID is the OSPFv3 router ID [RFC2740] or the ISIS IPv4 TE Router ID [RFC3784]. Note that these are different from TE router ID (see Section 2). don't mix them up, iykyk 🙈

8.1.2. Configuring GMPLS Tunnels

when setting up RSVP TE tunnels, it's common practice to copy the values of the mplsTunnelIngressLSRId and mplsTunnelEgressLSRId fields in the MPLS TE MIB mplsTunnelTable [RFC3812] into the Extended Tunnel ID and IPv4 tunnel end point address fields, respectively, in the RSVP-TE LSP_TUNNEL_IPv4 SESSION object [RFC3209].

this approach can't be used when the ingress and egress routers are identified by 128-bit IPv6 addresses, because the mplsTunnelIngressLSRId and mplsTunnelEgressLSRId fields are defined to be 32-bit values [RFC3811], [RFC3812] 🥺

instead, the IPv6 addresses SHOULD be configured in the mplsHopTable as the first and last hops of the mplsTunnelHopTable entries defining the explicit route for the tunnel. Note that this implies a tunnel with IPv6 source and destination addresses MUST have an explicit route configured. it's worth noting, though, that configuring an explicit route this way does NOT mean an explicit route will be signaled 🎀

more detail, bestie 🧐 the tunnel gets configured at the ingress router like this. See [RFC3812] for definitions of MIB table objects and for default (that is, "normal") behavior.

the mplsTunnelIndex and mplsTunnelInstance fields are set as normal.

the mplsTunnelIngressLSRId and mplsTunnelEgressLSRId fields SHOULD be set to 32-bit LSR IDs for the ingress and egress LSRs, respectively.

the mplsTunnelHopTableIndex MUST be set to a non-zero value. that means an explicit route MUST be specified 💅

the first hop of the explicit route MUST have the mplsTunnelHopAddrType field set to ipv6(2) and SHOULD have the mplsTunnelHopIpAddr field set to a global scope IPv6 address of the ingress router that is reachable in the control plane.

the last hop of the explicit route MUST have the mplsTunnelHopAddrType field set to ipv6(2) and SHOULD have the mplsTunnelHopIpAddr field set to a global scope IPv6 address of the egress router that is reachable in the control plane.

the ingress router SHOULD set the signaled values of the Extended Tunnel ID and IPv6 tunnel end point address fields, respectively, of the RSVP-TE LSP_TUNNEL_IPv6 SESSION object [RFC3209] from the mplsTunnelHopIpAddr object of the first and last hops in the configured explicit route. ✨ the route config is the source of truth, no cap 🔥

8.2. Managing and Monitoring Tunnel Table Entries

on top of configuring LSPs as described in Section 8.1, the TE MIB modules (MPLS-TE-STD-MIB and GMPLS-TE-STD-MIB) can be used for managing and monitoring MPLS and GMPLS TE LSPs, respectively. this is super important at egress and transit LSRs 👑

for a tunnel with IPv6 source and destination addresses, an LSR implementation SHOULD return values in the mplsTunnelTable as follows (where "normal" behavior is the default taken from [RFC3812]).

the mplsTunnelIndex and mplsTunnelInstance fields are set as normal.

the mplsTunnelIngressLSRId and mplsTunnelEgressLSRId fields are set to 32-bit LSR IDs. that means each transit and egress router maps from the IPv6 address in the Extended Tunnel ID field to the 32-bit LSR ID of the ingress LSR. each transit router also maps from the IPv6 address in the IPv6 tunnel end point address field to the 32-bit LSR ID of the egress LSR 🦋

9. Security Considerations 🚨

in the interoperability testing we did, the major issue we found was the use of control channels for forwarding data. this happened because both the control and data plane addresses were set to the same value in PSC (Packet-Switching Capable) equipment. it showed up when we tried to test PSC GMPLS with separated control and data channels. what we got instead were parallel interfaces with the same addresses 😱 this could be avoided simply by keeping the addresses for the control and data plane separate. bestie, this one is serious, so keep those addresses apart 🫶

10. Acknowledgments 🌸

The following people made textual contributions to this document:

Alan Davey, Yumiko Kawashima, Kaori Shimizu, Thomas D. Nadeau, Ashok Narayanan, Eiji Oki, Lyndon Ong, Vijay Pandian, Hari Rakotoranto, and Adrian Farrel.

The authors would like to thank Adrian Farrel for the helpful discussions and the feedback he gave on the document. In addition, Jari Arkko, Arthi Ayyangar, Deborah Brungard, Diego Caviglia, Lisa Dusseault, Dimitri Papadimitriou, Jonathan Sadler, Hidetsugu Sugiyama, and Julien Meuric provided helpful comments and suggestions. the real MVPs 💖

Adrian Farrel edited the final revisions of this document before and after working group last call. 👑

11. References 📚

11.1. Normative References

[RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.

[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.

[RFC3209] 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.

[RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003.

[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.

[RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links in Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE)", RFC 3477, January 2003.

[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, September 2003.

[RFC3811] Nadeau, T., Ed., and J. Cucchiara, Ed., "Definitions of Textual Conventions (TCs) for Multiprotocol Label Switching (MPLS) Management", RFC 3811, June 2004.

[RFC3812] Srinivasan, C., Viswanathan, A., and T. Nadeau, "Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Management Information Base (MIB)", RFC 3812, June 2004.

[RFC3945] Mannie, E., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", RFC 3945, October 2004.

[RFC4003] Berger, L., "GMPLS Signaling Procedure for Egress Control", RFC 4003, February 2005.

[RFC4201] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling in MPLS Traffic Engineering (TE)", RFC 4201, October 2005.

[RFC4202] Kompella, K., Ed., and Y. Rekhter, Ed., "Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4202, October 2005.

[RFC4203] Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF Extensions in Support of Generalized Multi-protocol Label Switching", RFC 4203, October 2005.

[RFC4206] Kompella, K. and Y. Rekhter, "LSP Hierarchy with Generalized MPLS TE", RFC 4206, October 2005.

11.2. Informative References

[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, December 1990.

[RFC2740] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6", RFC 2740, December 1999.

[RFC3784] Smit, H. and T. Li, "Intermediate System to Intermediate System (IS-IS) Extensions for Traffic Engineering (TE)", RFC 3784, June 2004.

[RFC4205] Kompella, K., Ed., and Y. Rekhter, Ed., "Intermediate System to Intermediate System (IS-IS) Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4205, October 2005.

[RFC4802] Nadeau, T., Ed., and A. Farrel, Ed., "Generalized Multiprotocol Label Switching (GMPLS) Traffic Engineering Management Information Base", RFC 4802, February 2007.

Authors' Addresses 🖊️

Kohei Shiomoto
NTT Network Service Systems Laboratories
3-9-11 Midori
Musashino, Tokyo 180-8585
Japan

Phone: +81 422 59 4402
EMail: shiomoto.kohei@lab.ntt.co.jp


Richard Rabbat
Google Inc.
1600 Amphitheatre Parkway
Mountain View, CA 94043

Phone: +1 650-714-7618
EMail: rabbat@alum.mit.edu


Rajiv Papneja
Isocore Corporation
12359 Sunrise Valley Drive, Suite 100
Reston, Virginia 20191
United States of America

Phone: +1 703-860-9273
EMail: rpapneja@isocore.com

Okay, legal bit, but make it cute 🎀. The copyright is Copyright (C) The IETF Trust (2007) 💅. This document is subject to the rights, licenses and restrictions in BCP 78, and except for what's in there, the authors keep all their rights 🦋.

The doc and everything in it is given "AS IS" 🫶. The contributor, the org they represent or who sponsors them (if any), the Internet Society, the IETF Trust, and the IETF all disclaim every warranty, express or implied 😭. That includes no infringement of rights, plus any implied warranty of merchantability or fitness for a particular purpose 💀.

Intellectual Property 🌈

Okay, so the IETF takes no position on whether any IP rights claimed around this tech are valid or how far they reach, and it doesn't claim to have searched for them either 🙈. If you want the rules on rights in RFCs, check BCP 78 and BCP 79 📚.

Any IPR disclosures sent to the IETF Secretariat, plus any licence assurances, or the results of trying to get a general licence for implementers or users, can be found in the IETF's online IPR repository at http://www.ietf.org/ipr 🔍.

And the IETF totally invites anyone to flag copyrights, patents, patent applications, or other proprietary rights that might cover tech needed to implement this standard 🧚. Send that info to the IETF at ietf-ipr@ietf.org 💜. Main character energy, honestly 👑.

📦 where this page comes from