RFC 6107
Procedures for Dynamically Signaled Hierarchical Label Switched Paths
RFC 6107 💖 Procedures for Dynamically Signaled Hierarchical Label Switched Paths ✨
okay bestie, this one is Standards Track 👑 and it's from February 2011 🎀. It's written by K. Shiomoto (Ed.) from NTT and A. Farrel (Ed.) from Old Dog Consulting 🧚. The ISSN is 2070-1721 🌸. It updates RFC 3477 and RFC 4206 🦋, and no "Obsoletes" line appears in the header, so it doesn't replace anything. Let's go!! 💅
Abstract ✨
okay so the big idea is that Label Switched Paths (LSPs) set up in Multiprotocol Label Switching (MPLS) or Generalized MPLS (GMPLS) networks can act like links 🔗 that carry traffic in those networks or in other (client) networks 💜
The protocol mechanisms for setting up these LSPs and bundling traffic engineering (TE) links together to ease the load on routing protocols already exist 🫶 This document adds extensions to those mechanisms so that the LSP's purpose can be identified, and so the TE link endpoints can get addresses or unnumbered identifiers while signaling is happening 🦋
Also, the mechanisms in this document deprecate the technique in RFC 4206 for signaling LSPs that are used as numbered TE links 🙈 it's a whole glow-up moment 🌈
Status of This Memo ✨
This is an Internet Standards Track document 🎀
It's a product of the Internet Engineering Task Force (IETF) and it represents the consensus of the IETF community 💖 It got public review and was approved for publication by the Internet Engineering Steering Group (IESG) 👑 If you want more info on Internet Standards, check Section 2 of RFC 5741 🌸
For the current status, any errata, and how to give feedback, go to http://www.rfc-editor.org/info/rfc6107 ✨
Copyright Notice ✨
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. 💅
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents, which you can find at http://trustee.ietf.org/license-info as in effect on the date of publication 🧚 Please read these carefully, because they describe your rights and restrictions for this document 🙈 Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they're provided without warranty as described in the Simplified BSD License 🫶
Table of Contents ✨
1. Introduction and Problem Statement ..............................3
1.1. Background .................................................4
1.1.1. Hierarchical LSPs ...................................4
1.1.2. LSP Stitching Segments ..............................5
1.1.3. Private Links .......................................5
1.1.4. Routing Adjacencies .................................5
1.1.5. Forwarding Adjacencies ..............................5
1.1.6. Client/Server Networks ..............................6
1.1.7. Link Bundles ........................................6
1.2. Desired Function ...........................................7
1.3. Existing Mechanisms ........................................7
1.3.1. LSP Setup ...........................................7
1.3.2. Routing Adjacency Establishment and Link
State Advertisement .................................7
1.3.3. TE Link Advertisement ...............................7
1.3.4. Configuration and Management Techniques .............8
1.3.5. Signaled Unnumbered FAs .............................8
1.3.6. Establishing Numbered FAs through Signaling
and Routing .........................................9
1.4. Overview of Required Extensions ...........................10
1.4.1. Efficient Signaling of Numbered FAs ................10
1.4.2. LSPs for Use as Private Links ......................10
1.4.3. Signaling an LSP for Use in Another Network ........10
1.4.4. Signaling an LSP for Use in a Link Bundle ..........11
1.4.5. Support for IPv4 and IPv6 ..........................11
1.4.6. Backward Compatibility .............................11
2. Overview of Solution ...........................................11
2.1. Common Approach for Numbered and Unnumbered Links .........11
2.2. LSP Usage Indication ......................................12
2.3. IGP Instance Identification ...............................12
2.4. Link Bundle Identification ................................12
2.5. Backward Compatibility ....................................12
3. Mechanisms and Protocol Extensions .............................13
3.1. LSP_TUNNEL_INTERFACE_ID Object ............................13
3.1.1. Existing Definition and Usage ......................13
3.1.2. Unnumbered Links with Action Identification ........13
3.1.3. IPv4 Numbered Links with Action Identification .....16
3.1.4. IPv6 Numbered Links with Action Identification .....17
3.2. Target IGP Identification TLV .............................18
3.3. Component Link Identification TLV .........................19
3.3.1. Unnumbered Component Link Identification ...........20
3.3.2. IPv4 Numbered Component Link Identification ........20
3.3.3. IPv6 Numbered Component Link Identification ........21
3.4. Link State Advertisement ..................................21
3.5. Message Formats ...........................................22
3.6. Error Cases and Non-Acceptance ............................22
3.7. Backward Compatibility ....................................24
4. Security Considerations ........................................25
5. IANA Considerations ............................................25
5.1. New Class Types ...........................................25
5.2. Hierarchy Actions .........................................26
5.3. New Error Codes and Error Values ..........................26
6. Acknowledgements ...............................................27
7. References .....................................................27
7.1. Normative References ......................................27
7.2. Informative References ....................................281. Introduction and Problem Statement ✨
okay so TE links in a Multiprotocol Label Switching (MPLS) or a Generalized MPLS (GMPLS) network can be built out of Label Switched Paths (LSPs) [RFC4206] 🦋 When they are, those LSPs are called hierarchical LSPs (H-LSPs) 💖
LSPs set up in one network can be used as TE links in another network 🌸 This is especially handy when a server layer network (like an optical network) provides LSPs to act as TE links in a client network (like a packet network) ✨ That's what makes a multilayer network (MLN) possible [RFC5212] 👑
Here's the problem 😭 when a pair of nodes has a lot of TE links (whether they come from LSPs or not), advertising each one separately is inefficient 🙈 It can cause scaling problems in configuration and in the routing protocols that carry the advertisements 💀 The fix, described in [RFC4201], is to gather the TE links together and advertise them as one TE link called a link bundle 🧚
These mechanisms are seriously powerful for building dynamically provisioned networks 💅 But, as this document explains later, deployment has shown some issues with how LSPs get set up and made available as H-LSPs or as components of a link bundle 🫠 It also has issues with how those links get advertised in an interior gateway protocol (IGP) 🌈 At the heart of it, the LSP's endpoints need to coordinate two things: what the LSP is used for, and the identifiers of the endpoints 💜
This document fixes these issues by defining mechanisms so the ends of signaled LSPs can exchange information about:
- Whether the LSP is an ordinary LSP or an H-LSP.
- In which IGP instances the LSP should be advertised as a link.
- How the client networks should make use of the new links.
- Whether the link should form part of a bundle (and if so, which bundle).
- How the link endpoints should be identified when advertised.
It also deprecates one of the mechanisms in [RFC4206] for signaling LSPs that are used as numbered TE links (see Sections 1.3.6 and 1.4.6 for more details) 🙈 It adds extensions to the other [RFC4206] mechanisms so the purpose of the new LSP can be indicated during signaling 🎀 And it extends the mechanisms in [RFC3477] for signaling unnumbered TE links 🍓
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
1.1. Background ✨
1.1.1. Hierarchical LSPs 🧚
[RFC3031] explains how MPLS labels can be stacked so that one LSP is nested inside another 🦋 The idea of H-LSPs is formalized in [RFC4206], which has a set of protocol mechanisms for setting up an H-LSP that can carry one or more other LSPs 💖
[RFC4206] also explains that an H-LSP can only carry other LSPs according to their switching types 🌈 That depends on how labels are carried 🫶 In a packet switch capable (PSC) network, the H-LSP can carry other PSC LSPs using the MPLS label stack ✨ In non-packet networks, where the label is implicit, label stacks aren't possible, so H-LSPs rely on nesting switching technologies instead 💅 For example, a lambda switch capable (LSC) LSP can carry a time-division multiplexing (TDM) LSP, but it can't carry another LSC LSP 🙈
The signaling mechanisms in [RFC4206] let an H-LSP be treated as a single hop in the path of another LSP (i.e., one hop of the LSP carried by the H-LSP) 👑 This is called "non-adjacent signaling" 🌸
1.1.2. LSP Stitching Segments 🦋
LSP stitching is defined in [RFC5150] 💜 It lets LSPs of the same switching type be stitched in as hops of an end-to-end LSP ✨ The stitching LSP (S-LSP) is used in the control plane the same way an H-LSP is, but in the data plane the LSPs are stitched together, so there's no label stacking or nesting of technologies 🎀 That means an S-LSP must be of the same switching technology as the end-to-end LSP it helps build 💅
1.1.3. Private Links 🌈
An H-LSP or S-LSP can be used as a private link 🫶 These links are known by their endpoints, but they aren't widely known, and routing protocols don't advertise them 🙈 They can carry traffic between the endpoints, but they're not usually used to carry traffic beyond the egress of the LSP 🧚
1.1.4. Routing Adjacencies 💖
A routing adjacency forms between two IGP speakers that are logically adjacent 🌸 Here, "logically adjacent" means the routers have a protocol tunnel between them that they can use to exchange routing protocol messages 🦋 That tunnel is usually available for carrying IP data too, although in GMPLS networks a distinction should be made between data-plane traffic and control-plane traffic 💅
Routing adjacencies for forwarding data traffic are only relevant in PSC networks (i.e., IP/MPLS networks) 👑
1.1.5. Forwarding Adjacencies ✨
okay so a Forwarding Adjacency (FA) is defined in [RFC4206] as a data link that gets made from an LSP and then advertised in the same control plane instance that advertises the TE links the LSP is built from 🦋. The LSP itself is called an FA-LSP.
Thus, an H-LSP or S-LSP can form an FA, so it gets advertised as a TE link in the same routing protocol instance that was used to advertise the TE links the LSP travels over 💅.
As [RFC4206] points out, the nodes at the ends of an FA usually wouldn't have a routing adjacency 🙈.
1.1.6. Client/Server Networks 🌸
An LSP can be created in one network and then used as a link (sometimes called a virtual link) in another network [RFC5212]. In this case, people often call these the server and client networks, respectively.
The server network LSP gets used as an H-LSP or an S-LSP like we covered above, but it doesn't form an FA because the client and server networks run separate instances of the control-plane routing protocols 🧚.
The virtual link can be used in the client network as a private link, or it can be advertised in the client network IGP. The link can also be used in the client network to form a routing adjacency and/or as a TE link 💜.
1.1.7. Link Bundles 🎀
[RFC4201] notices that a pair of adjacent routers might have a huge number of TE links running between them. That's a real pain for the operator who has to configure all of them, and for the IGP that has to distribute info about each one 😭. [RFC4201] defines a TE link bundle as a TE link that's advertised as an aggregate of multiple TE links that could have been advertised in their own right. All TE links collected into a TE link bundle have the same TE properties 🌈.
Thus, a link bundle is basically a shortcut that makes the network scale better ✨.
Since a TE link can itself be an LSP (either an FA or a virtual link), a link bundle can be built from FA-LSPs or virtual links 👑.
1.2. Desired Function 💖
It should be possible to signal an LSP and automatically coordinate its use and advertisement in any of the ways described in Section 1.3 with minimum involvement from an operator. The mechanisms used should be applicable to numbered and unnumbered links and should not require implementation complexities 🫶.
1.3. Existing Mechanisms 🔥
This section gives a quick tour of the protocol mechanisms that already exist to get the desired function from Section 1.2 done 💅.
1.3.1. LSP Setup
Both unidirectional LSPs and bidirectional LSPs are signaled from the ingress label switching router (LSR) to the egress LSR. So the ingress LSR is the one who initiates it, and the egress finds out about the LSP through the signaling protocol [RFC3209] [RFC3473] 📣.
1.3.2. Routing Adjacency Establishment and Link State Advertisement 🌈
Hosts can discover routers (for example, through ICMP [RFC1256]), but routing adjacencies are usually configured at both ends. That means each router has to know who's on the other end of the link connecting them, and know that the IGP needs to run on that link 🍓.
Once a routing adjacency is up, the pair of routers can use the IGP to share info about the links that are available for carrying IP traffic in the network ✨.
Suitable routing protocols are OSPF version 2 [RFC2328], OSPF version 3 [RFC5340], and IS-IS [RFC1195] 🍓.
1.3.3. TE Link Advertisement 💜
IGPs have been extended to advertise TE link properties ([RFC3630], [RFC5329], [RFC5305], [RFC5308], and [ISIS-IPV6-TE]), and also to advertise link properties in GMPLS networks ([RFC4202], [RFC4203], and [RFC5307]) 🦋.
TE link advertisement can be done by the same IGP instance used for normal link state advertisement, or it can use a separate instance. Also, the ends of a TE link advertised in an IGP don't need to form a routing adjacency. That's especially true for FAs, as covered in Section 1.1.5 💅.
1.3.4. Configuration and Management Techniques 🎀
LSPs are usually created because of a management action. That's still true when a control plane is involved: the management action is a request to the control plane to signal the LSP 🧚.
If the LSP is going to be used as an H-LSP or S-LSP, management commands can install the LSP as a link. The link has to be defined, interface identifiers allocated, and the endpoints configured to know about (and advertise, if needed) the new link 🫶.
If the LSP is going to be part of a link bundle, the operator has to decide which bundle it belongs to and make sure the info is configured at the ingress and egress, along with the needed interface identifiers 💖.
These mechanisms work perfectly and are pretty common in MLNs, but they need configuration coordination and extra management. They're open to user error and misconfiguration, which might mean the LSP never gets used (a waste of resources) or gets made available the wrong way and messes with traffic engineering 💀.
1.3.5. Signaled Unnumbered FAs 🌸
[RFC3477] describes how to set up an LSP and automatically make it available as a TE link in the same instance of the routing protocol that advertises the TE links it traverses, using IPv4-based unnumbered identifiers for the new TE link. So basically, [RFC3477] tells you how to make an unnumbered FA ✨.
The mechanism, as defined in Section 3 of [RFC3477], goes roughly like this:
- The ingress of the LSP signals the LSP as normal using a
Pathmessage, and includes anLSP_TUNNEL_INTERFACE_IDobject. TheLSP_TUNNEL_INTERFACE_IDobject identifies:- The sender's LSR Router ID
- The sender's interface ID for the TE link being created
- The egress of the LSP responds as normal to accept the LSP and set it up, and includes an
LSP_TUNNEL_INTERFACE_IDobject. TheLSP_TUNNEL_INTERFACE_IDobject identifies:- The egress's LSR Router ID
- The egress's interface ID for the TE link being created.
- After the
PathandResvmessages have been exchanged, both the ingress and the egress know the LSP is going to be advertised as a TE link in the same instance of the routing protocol that was used to advertise the TE links it traverses, and they both know the unnumbered interface identifiers to use in the advertisement.
[RFC3477] does not include mechanisms to support IPv6-based unnumbered identifiers, nor IPv4 or IPv6 numbered identifiers 🥺.
1.3.6. Establishing Numbered FAs through Signaling and Routing 💅
[RFC4206] describes procedures to set up an LSP and automatically make it available as a TE link identified by IPv4 addresses, in the same routing protocol instance that advertises the TE links it traverses (basically a numbered FA) 🦋.
The mechanism, as defined in [RFC4206], goes roughly like this:
- The ingress of the LSP signals the LSP as normal using a
Pathmessage, and sets the IPv4 tunnel sender address to the IP address it will use to identify its interface for the TE link being created. This is one address from a/31pair. - The egress of the LSP responds as normal to accept the LSP and set it up. It infers the address that it must assign to identify its interface for the TE link being created as the partner address of the
/31pair. - The ingress decides whether the LSP is to be advertised as a TE link (i.e., as an FA). If so, it advertises the link in the IGP in the usual way.
- If the link is unidirectional, nothing more needs to be done. If the link is bidirectional, the egress must also advertise the link, but it does not know that advertisement is required as there is no indication in the signaling messages.
- When the ingress's advertisement of the link is received by the egress, it must check to see whether it is the egress of the LSP that formed the link. Typically, this means the egress:
- Checks to see if the link advertisement is new.
- Checks to see if the Link-ID address in the received advertisement matches its own TE Router ID.
- Checks the advertising router ID from the advertisement against the ingress address of each LSP for which it is the egress.
- Deduces the LSP that has been advertised as a TE link and issues the corresponding advertisement for the reverse direction.
It's possible to cut down on processing by mapping based on the /31 pairing, but honestly there's still a fair amount of processing required, and this doesn't scale well in large networks 😩.
Note that this document deprecates this procedure, as explained in Section 1.4.6.
No explanation is provided in [RFC4206] of how to create numbered IPv6 FAs ✨.
1.4. Overview of Required Extensions 🌈
This section gives a brief outline of the required protocol extensions.
1.4.1. Efficient Signaling of Numbered FAs ✨
The mechanism described in Section 1.3.6 is inefficient. The egress has to wait until it gets an advertisement from the ingress before it knows the LSP is supposed to be installed as a TE link and advertised as an FA. On top of that, it has to parse every received advertisement to figure out whether any of them is the trigger for it to advertise an FA 😩.
An efficient signaling mechanism is required so the egress is informed by the ingress during LSP establishment 🫶.
1.4.2. LSPs for Use as Private Links 🫣
There's currently no way for an ingress to say an LSP is set up for use as a private link. Any attempt to make it a link would currently get it advertised as an FA 🙈.
A signaling mechanism is needed to identify the use an LSP is going to be put to 💜.
1.4.3. Signaling an LSP for Use in Another Network 🦋
The existing signaling/routing mechanisms are designed for creating FAs. That means the TE link created gets advertised in the single IGP instance.
The numbered TE link mechanism (Section 1.3.6) could, in theory, be used in an MLN with multiple IGP instances if the addressing model is kept consistent across the networks and if the egress searches all advertisements in all IGP instances. But that's complicated, and it doesn't work for unnumbered interfaces 😵.
A signaling mechanism is required to indicate in which IGP instance the TE link should be advertised 👑.
1.4.4. Signaling an LSP for Use in a Link Bundle 🎀
A signaling mechanism is required to indicate that an LSP is intended to form a component link of a link bundle, and to identify the bundle and the IGP instance in which the bundle is advertised 💖.
1.4.5. Support for IPv4 and IPv6 🌸
The protocol mechanisms must support IPv4 and IPv6 numbered and unnumbered TE links 🧚.
1.4.6. Backward Compatibility 🍓
The existing protocol mechanisms for unnumbered FAs as defined in [RFC4206] and [RFC3477] must continue to be supported, and new mechanisms must be devised such that their introduction will not break existing implementations or deployments.
Note that an informal survey in the CCAMP working group established that there are no significant deployments of numbered FAs established using the technique described in [RFC4206] and set out in Section 1.3.6. Therefore, this document deprecates this procedure 🥺.
2. Overview of Solution ✨
This section gives an overview of the mechanisms and protocol extensions defined in this document. Details are presented in Section 3 💜.
2.1. Common Approach for Numbered and Unnumbered Links ✨
okay so the LSP_TUNNEL_INTERFACE_ID object from [RFC3477] is getting an upgrade so it works for all H-LSPs and S-LSPs, whether they make numbered or unnumbered IPv4 or IPv6 links. 🎀 The Class Type tells you which address type it's carrying. Iconic. 💅
2.2. LSP Usage Indication
the LSP_TUNNEL_INTERFACE_ID object gets some flags in a brand-new Actions field, and those flags say how the LSP should be used. 🦋 The supported categories are:
- The LSP is used as an advertised TE link.
- The LSP is used to form a routing adjacency.
- The LSP is used to form an advertised TE link and a routing adjacency.
- The LSP forms a private link and is not advertised.
- The LSP is used as part of a link bundle.
- The LSP is used as a hierarchical LSP or a stitching segment.
2.3. IGP Instance Identification
there's an optional TLV added to the LSP_TUNNEL_INTERFACE_ID object that says which IGP instance the link should be advertised into. 🧚 If that TLV isn't there and the Actions field says the link should be advertised, the link goes into the same IGP instance that was used to advertise the TE links it goes over. no drama, just consistency 💖
2.4. Link Bundle Identification
when an LSP is a component link of a link bundle, the LSP_TUNNEL_INTERFACE_ID object points at the bundle and says how that bundle is addressed and used. 🌈 A new TLV then gives the component link identifier for the link the LSP creates. bundle goals 🫶
2.5. Backward Compatibility
backward compatibility has three sides, and each one matters 👑
- Existing mechanisms for unnumbered FAs described in [RFC3477] and [RFC4206] must continue to work, so that ingress nodes do not have to be updated when egresses are updated.
- Existing mechanisms for establishing numbered FAs described in [RFC4206] are safely deprecated by this document, as they are not significantly deployed. 🙈
- New mechanisms must be gracefully rejected by existing egress implementations so that egress nodes do not have to be updated when ingresses are updated.
3. Mechanisms and Protocol Extensions ✨
this section is where the actual protocol mechanisms and extensions live, the stuff that makes the function from the last section actually happen. 🔥
3.1. LSP_TUNNEL_INTERFACE_ID Object
the main signaling element doing all the required jobs is the LSP_TUNNEL_INTERFACE_ID object defined in [RFC3477]. 💜 the existing definition and usage keeps being supported, as the next section explains. after that, the later sections introduce new variants (new Class Types) and extra info carried in the object through extensions. layers on layers, honestly iconic 🎀
3.1.1. Existing Definition and Usage
this document does not deprecate the mechanisms in [RFC3477] and [RFC4206]. those procedures must continue to operate as described in Section 3.7. 🌸
so the LSP_TUNNEL_INTERFACE_ID object with Class Type 1 stays exactly the same, and it can still set up an LSP that gets advertised as an unnumbered TE link in the same IGP instance as the TE links the LSP traverses (aka, as an FA). no changes there. it works the way Section 1.3.5 summarizes ✨
[RFC3477] doesn't say where the LSP_TUNNEL_INTERFACE_ID object should go in Path or Resv messages. for the recommended placement in new implementations, see Section 3.5. 🧚
3.1.2. Unnumbered Links with Action Identification
a new C-Type variant of the LSP_TUNNEL_INTERFACE_ID object carries an unnumbered interface identifier and says which IGP instance the resulting TE link should be advertised into. this does not deprecate C-Type 1, so both can coexist 🦋
the format of the object looks like this:
C-NUM = 193, C-Type = 4
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSR's Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface ID (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Actions | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ TLVs ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+LSR's Router ID
unchanged from the definition in [RFC3477]. 🌷
Interface ID
unchanged from the definition in [RFC3477]. 🌷
Actions
this field says how the LSP being set up should be treated. 🎀
it only means something on a Path message. on a Resv message, the field SHOULD be set to reflect the value received on the corresponding Path message, and it MUST be ignored on receipt. 💅
the field is made of bit flags like this:
-+-+-+-+-+-+-+-
| | | |H|B|R|T|P|
-+-+-+-+-+-+-+-P-flag (Private)
- 0 means the LSP is to be advertised as a link according to the settings of the other flags.
- 1 means the LSP is to form a private link and is not to be advertised in the IGP, but is still used according to the settings of the other flags. 🔒
T-flag (TE link)
- 0 means the LSP is to be used as a TE link.
- 1 means the LSP is not to be used as a TE link. It may still be used as an IP link providing a routing adjacency, as defined by the
R-flag. 🫶
R-flag (Routing adjacency)
- 0 means the link is not to be used as a routing adjacency.
- 1 means the link is to be used to form a routing adjacency.
B-flag (Bundle)
- 0 means the LSP will not form part of a link bundle.
- 1 means the LSP will form part of a bundle. See Section 3.3 for more details. 🌈
H-flag (Hierarchy/stitching)
- The use of an LSP as an H-LSP or as an S-LSP is usually implicit from the network technologies of the networks and the LSP, but this is not always the case (for example, in PSC networks). 🤷♀️
- 0 means the LSP is to be used as a hierarchical LSP.
- 1 means the LSP is to be used as a stitching segment.
other bits are reserved for future use. they MUST be set to zero on transmission and SHOULD be ignored on receipt. 🙏
note that all defined bit flags have meaning at the same time. an LSP that is to form an FA would carry the Actions field set to 0x00. that is:
P=0 (advertised)
T=0 (TE link)
R=0 (not a routing adjacency)
B=0 (not a bundle)
H=0 (hierarchical LSP)Reserved
the Reserved bits MUST be set to zero on transmission and SHOULD be ignored on receipt. 🌸
TLVs
zero, one, or more TLVs may be present. each TLV is encoded like this:
Type (16 bits)
The identifier of the TLV. Two type values are defined in
this document:
1 IGP Instance Identifier TLV
2 Unnumbered Component Link Identifier TLV
3 IPv4 Numbered Component Link Identifier TLV
4 IPv6 Numbered Component Link Identifier TLV
Length (16 bits)
Indicates the total length of the TLV in octets, i.e., 4 +
the length of the value field in octets. A value field
whose length is not a multiple of four MUST be zero-padded
so that the TLV is four-octet aligned.
Value
The data for the TLV padded as described above.if this object is carried in a Path message, it's called the "Forward Interface ID" for the LSP being set up. on a Resv message, it's called the "Reverse Interface ID" for the LSP. 💖
3.1.3. IPv4 Numbered Links with Action Identification
a new C-Type variant of the LSP_TUNNEL_INTERFACE_ID object carries an IPv4 numbered interface address. 🍓
the format looks like this:
C-NUM = 193, C-Type = 2
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Interface Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Actions | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ TLVs ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+IPv4 Interface Address
the address assigned to the interface that the sender applies to this LSP. 🌐
Actions
see Section 3.1.2. 👀
Reserved
see Section 3.1.2. 👀
TLVs
see Section 3.1.2. 👀
if this object is carried in a Path message, it's the "Forward Interface ID" for the LSP being set up. on a Resv message, it's the "Reverse Interface ID" for the LSP. ✨
3.1.4. IPv6 Numbered Links with Action Identification
a new C-Type variant of the LSP_TUNNEL_INTERFACE_ID object carries an IPv6 numbered interface address. 🧚
the format looks like this:
C-NUM = 193, C-Type = 3
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Interface Address (128 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Interface Address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Interface Address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Interface Address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Actions | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ TLVs ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+IPv6 Interface Address
the address assigned to the interface the sender applies to this LSP. 🌐
Actions
see Section 3.1.2. 👀
Reserved
see Section 3.1.2. 👀
TLVs
see Section 3.1.2. 👀
if this object is carried in a Path message, it's the "Forward Interface ID" for the LSP being set up. on a Resv message, it's the "Reverse Interface ID" for the LSP. 💜
3.2. Target IGP Identification TLV ✨
okay so, if the LSP being set up is going to be advertised as a link, the egress needs to know which IGP instance to make that advertisement in 🧚. The default in [RFC4206] and [RFC3477] is that the LSP gets advertised as an FA, which means the same IGP instance that was used to advertise the TE links the LSP travels over 🦋.
To let the ingress tell the egress which IGP instance to use, the IGP Identification TLV is defined for the new variants of the LSP_TUNNEL_INTERFACE_ID object from this document 💖.
This TLV only means something in a Path message 🎀. It SHOULD NOT be included in the LSP_TUNNEL_INTERFACE_ID object in a Resv message, and if it shows up there anyway, it MUST be ignored 🙈.
If the P-flag in the Actions field of the LSP_TUNNEL_INTERFACE_ID object in a Path message is clear (i.e., zero), this TLV tells you which IGP instance to use for the advertisement 🌸. If the TLV is absent, the same instance of the IGP should be used as is used to advertise the TE links that the LSP traverses. So for an FA, the TLV can be omitted. Or the IGP Instance TLV may be present and either identify an instance or carry the reserved value 0xffffffff 💅.
If the P-flag in the Actions field of the LSP_TUNNEL_INTERFACE_ID object in a Resv message is set (i.e., one), which means the LSP is not to be advertised as a link, this TLV SHOULD NOT be present and MUST be ignored if encountered 😭.
The TLV is formatted as described in Section 3.1.2. The Type field has the value 1, and the Value field looks like this 🧁:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IGP Instance Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+IGP Instance Identifier 🍓: a 32-bit ID given to each IGP instance in a network, so the ingress and egress LSRs are on the same page about what each number means. Setting these up is a management configuration job, and it's out of scope for this document.
Note that the IGP Instance Identifier might be mapped from an instance identifier the IGP already uses (like section 2.4 of [RFC5340] for OSPFv3, or [OSPFv2-MI] for OSPFv2) as a matter of network policy. If you want the deep dive on this in OSPF, check [OSPF-TI], and for IS-IS, see [ISIS-GENAP] 🤓.
The value 0xffffffff is reserved to mean that the LSP is advertised in the same IGP instance used to advertise the TE links it traverses 🌈.
3.3. Component Link Identification TLV 🦄
okay, so if the LSP you're setting up is going to be a component link in a link bundle [RFC4201], you have to say two things: who the component link is, and which bundle it belongs to 🔗. You also need to say how that bundle (which might get auto-created when this LSP comes up) is supposed to be used and advertised 💜.
If the B-flag in the Actions field of the LSP_TUNNEL_INTERFACE_ID object is set, the other fields of the object apply to the link bundle itself. That means the interface identifiers (numbered or unnumbered) and the other flags in the Actions field are about the bundle, not the component link the LSP will form ✨.
The IGP Instance Identifier TLV (if it's there) also applies to the bundle and not the component link 🎀.
To swap the identity of the component link, we've got the Component Link Identifier TLVs, which are covered in the next sections 🫶. If the B-flag is set in the Actions field of the LSP_TUNNEL_INTERFACE_ID object in the Path message, exactly one of these TLVs MUST be present in the LSP_TUNNEL_INTERFACE_ID object in both the Path and Resv objects 💅.
3.3.1. Unnumbered Component Link Identification
If the component link is unnumbered, you use the Unnumbered Component Link Identifier TLV. It's formatted as described in Section 3.1.2. The Type field has the value 2, and the Value field looks like this 🌸:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Component Link Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Component Link Identifier 🔢: an unnumbered identifier given to this component link inside the bundle [RFC4201].
3.3.2. IPv4 Numbered Component Link Identification
If the component link is identified with an IPv4 address, use the IPv4 Numbered Component Link Identifier TLV. It's formatted as described in Section 3.1.2. The Type field has the value 3, and the Value field looks like this 🦋:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+IPv4 Address 🌐: the IPv4 address assigned to this component link within the bundle.
3.3.3. IPv6 Numbered Component Link Identification
If the component link is identified with an IPv6 address, use the IPv6 Numbered Component Link Identifier TLV. It's formatted as described in Section 3.1.2. The Type field has the value 4, and the Value field looks like this 🧚:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+IPv6 Address 💜: the IPv6 address assigned to this component link within the bundle.
3.4. Link State Advertisement 📣
okay, this part is the big one for who gets to advertise what 👑. The ingress and egress of an LSP that's set up using the LSP_TUNNEL_INTERFACE_ID object MUST advertise the LSP exactly as agreed in the object's parameters 💅.
When a TE link gets created from the LSP, the TE link SHOULD inherit the TE properties of the LSP as described in [RFC5212]. But this is all subject to local and network-wide policy, so no auto-pilot 🙃.
It's possible that one LSP gets used to offer capacity and connectivity to several other networks 🌍. In that case, you're allowed to have multiple instances of the LSP_TUNNEL_INTERFACE_ID object in the same Path and Resv messages. Each instance MUST have a different IGP Instance Identifier 🫶.
Note, however, that a Path or Resv message MUST NOT contain more than one instance of the LSP_TUNNEL_INTERFACE_ID object with C-Type 1. And if one of those is there, every other instance of the LSP_TUNNEL_INTERFACE_ID object MUST include an IGP Instance Identifier TLV, set to a value that identifies some other IGP instance. In particular, that value can't be 0xffffffff 😭.
If the link created from an LSP is advertised in the same IGP instance that was used to advertise the TE links the LSP traverses, the addresses for the new link and for the links it's built from MUST come from the same address space 🧠.
If the link is advertised into a different IGP instance, the addresses MAY be drawn from overlapping address spaces. That means some addresses can mean different things in each IGP instance 🌀.
In the IGP, the TE Router ID of the ingress LSR is taken from the Tunnel Sender Address in the Sender Template object signaled in the Path message. It's assumed that the ingress LSR already knows the TE Router ID of the egress LSR, since it chose to set up an LSP to that LSR and plans to use the LSP as a TE link 🔍.
The link interface addresses or link interface identifiers for the forward and reverse direction links come from the LSP_TUNNEL_INTERFACE_ID object in the Path and Resv messages, respectively 🎯.
When an LSP gets torn down through explicit action (a PathTear message, or a PathErr message with the Path_State_Removed flag set), the ingress and egress LSRs SHOULD withdraw the advertisement of any link that the LSP created and that was previously advertised 🧹. The link state advertisement MAY be kept around as a virtual link in another layer network, according to network-wide policy [PCE-LAYER] 🦋.
3.5. Message Formats 📨
[RFC3477] doesn't say where in the Path message or Resv message the LSP_TUNNEL_INTERFACE_ID object should be placed. Um, rude 🙄.
It is RECOMMENDED that new implementations place the LSP_TUNNEL_INTERFACE_ID objects in the Path message immediately after the SENDER_TSPEC object, and in the Resv message immediately after the FILTER_SPEC object 🎀.
All implementations SHOULD be able to handle received messages with objects in any order, as described in [RFC3209]. That's the kind of flexibility I'm obsessed with 💖✨
3.6. Error Cases and Non-Acceptance 💅
Error cases and non-acceptance of new object variants caused by back-level implementations are covered in Section 3.7, so peek there too 👀
An egress LSR that gets an LSP_TUNNEL_INTERFACE_ID object might have cause to reject the parameters in it, and there are a bunch of reasons that can happen 🫶 In every case, the egress SHOULD respond with a PathErr message using the error code from the list below. Usually the error pops up during LSP setup, so no Resv state exists yet, and the PathErr clears out the Path state. But if the error shows up after the LSP is already set up, the PathErr SHOULD be sent with the Path_State_Removed flag [RFC3473] clear, so the LSP stays alive and kicking ✨
The error cases are reported with the brand new error code LSP Hierarchy Issue (code 38), plus the error values below 🎀
Error | Error | Error-case
code | value |
------+-------+------------------------------------------------------
38 1 Link advertisement not supported
38 2 Link advertisement not allowed by policy
38 3 TE link creation not supported
38 4 TE link creation not allowed by policy
38 5 Routing adjacency creation not supported
38 6 Routing adjacency creation not allowed by policy
38 7 Bundle creation not supported
38 8 Bundle creation not allowed by policy
38 9 Hierarchical LSP not supported
38 10 LSP stitching not supported
38 11 Link address type or family not supported
38 12 IGP instance unknown
38 13 IGP instance advertisement not allowed by policy
38 14 Component link identifier not valid
38 15 Unsupported component link identifier address familyNow the ingress side 👑 When an ingress LSR gets an LSP_TUNNEL_INTERFACE_ID object on a Resv message, it might need to reject it because of certain parameter settings. These are all errors, not mismatches of negotiable parameters, so the ingress SHOULD respond with a PathTear to remove the LSP. The ingress MAY use a ResvErr with one of the error codes below, which gives the egress a chance to fix things in a new Resv message, or to tear the LSP down with a PathErr that has the Path_State_Removed flag set. But here's the catch: an ingress that uses the ResvErr MUST take precautions against a protocol loop, in case the egress keeps sending back the same LSP_TUNNEL_INTERFACE_ID object with the same (or different) issues 🔁😭
Error | Error | Error-case
code | value |
------+-------+------------------------------------------------------
38 11 Link address type or family not supported
38 14 Component link identifier not valid
38 15 Unsupported component link identifier address family
38 16 Component link identifier missing3.7. Backward Compatibility 🦋
The LSP_TUNNEL_INTERFACE_ID object defined in [RFC3477] has a class number of 193. According to [RFC2205], a node that doesn't understand the object SHOULD ignore it but forward it, unexamined and unmodified. So transit LSRs are totally fine no matter whether they support the old or new Class Types of this object. No drama 🌸
Here's how a back-level ingress node acts:
- It will not issue Path messages containing
LSP_TUNNEL_INTERFACE_IDobjects with the new Class Types defined in this document. - It will reject Resv messages containing
LSP_TUNNEL_INTERFACE_IDobjects with the new Class Types defined in this document, as described in [RFC2205]. Either way, that situation would be an error by the egress, not the ingress 🙅♀️ - It will keep using the
LSP_TUNNEL_INTERFACE_IDobject with Class Type 1 as defined in [RFC3477]. Back-level egresses support this, and so do egresses that follow this document ✨ - According to an informal survey, numbered FA establishment following the procedures in [RFC4206] and set out in Section 1.3.6 of this document isn't really deployed in any significant way. So it's safe to assume back-level ingress LSRs won't use this mechanism 💅
And here's how a back-level egress node acts:
- It will keep supporting the
LSP_TUNNEL_INTERFACE_IDobject with Class Type 1, as defined in [RFC3477], if an ingress sends it 🎀 - It will reject a Path message carrying an
LSP_TUNNEL_INTERFACE_IDobject with any of the new Class Types defined in this document, using the procedures of [RFC2205]. That tells the ingress the egress is a back-level LSR 🫶 - It will not expect to use the numbered FA establishment procedures defined in [RFC4206] and set out in Section 1.3.6 of this document 🙈
Lowkey the big takeaway: the new mechanisms here don't mess with the way unnumbered FA information gets exchanged in [RFC3477]. That method can be safely used alongside the new mechanisms, and it's functionally equivalent to using the new C-Type for an unnumbered link with target IGP instance identifier, with the Target IGP Instance value set to 0xffffffff 🌈
The mechanisms in this document also obsolete the method for exchanging numbered FA information described in [RFC4206], as explained in Section 1.4.6. Bye bye, old method 👋
4. Security Considerations 🔐
[RFC3477] points out that you could argue the extra interface identifier it provides makes an RSVP message harder to spoof. The tiny protocol extensions in this document don't add any extra security risk, and honestly, you could even say they make things safer ✨
Here's the serious part, bestie 🚨 The ability of an ingress LSR to ask an egress LSR to advertise an LSP as a TE link MUST be subject to appropriate policy checks at the egress LSR. In other words, the egress LSR MUST NOT automatically accept what the ingress says unless it's been configured with such a policy. Do NOT just trust the vibes 💀
For more on security for MPLS-TE and GMPLS, check out [RFC5920] 🦋
5. IANA Considerations 📋
5.1. New Class Types 💜
IANA maintains a registry of RSVP parameters called "Resource Reservation Protocol (RSVP) Parameters," and there's a sub-registry in it called "Class Names, Class Numbers, and Class Types." The LSP_TUNNEL_INTERFACE_ID object defined in [RFC3477] has an entry in this registry, with one Class Type defined so far.
IANA has allocated three new Class Types for this object, as defined in Sections 3.1.2, 3.1.3, and 3.1.4:
C-Type Meaning Reference
---------------------------------------------------------------
2 IPv4 interface identifier with target [RFC6107]
3 IPv6 interface identifier with target [RFC6107]
4 Unnumbered interface with target [RFC6107]5.2. Hierarchy Actions 🌷
Section 3.1.2 defines an 8-bit flags field in the LSP_TUNNEL_INTERFACE_ID object. IANA has made a new sub-registry called "Hierarchy Actions" inside the "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Parameters" registry, like so:
Registry Name: Hierarchy Actions
Reference: [RFC6107]
Registration Procedures: Standards Action
Registry:
Bit Number Hex Value Name Reference
---------- ----------- ----------------------- ---------
0-2 Unassigned
3 0x10 Hierarchy/stitching (H) [RFC6107]
4 0x08 Bundle (B) [RFC6107]
5 0x04 Routing adjacency (R) [RFC6107]
6 0x02 TE link (T) [RFC6107]
7 0x01 Private (P) [RFC6107]5.3. New Error Codes and Error Values 🚫
IANA maintains a registry of RSVP error codes and error values, called the "Error Codes and Globally-Defined Error Value Sub-Codes" sub-registry of the "Resource Reservation Protocol (RSVP) Parameters" registry.
IANA has defined a new error code with value 38, as shown below (see also Section 3.6):
Error Code Meaning
38 LSP Hierarchy Issue [RFC6107]IANA has listed the following error values for this error code (see also Section 3.6):
This Error Code has the following globally-defined Error
Value sub-codes:
1 = Link advertisement not supported [RFC6107]
2 = Link advertisement not allowed by policy [RFC6107]
3 = TE link creation not supported [RFC6107]
4 = TE link creation not allowed by policy [RFC6107]
5 = Routing adjacency creation not supported [RFC6107]
6 = Routing adjacency creation not allowed by policy [RFC6107]
7 = Bundle creation not supported [RFC6107]
8 = Bundle creation not allowed by policy [RFC6107]
9 = Hierarchical LSP not supported [RFC6107]
10 = LSP stitching not supported [RFC6107]
11 = Link address type or family not supported [RFC6107]
12 = IGP instance unknown [RFC6107]
13 = IGP instance advertisement not allowed by policy [RFC6107]
14 = Component link identifier not valid [RFC6107]
15 = Unsupported component link identifier address [RFC6107]
family
16 = Component link identifier missing [RFC6107]6. Acknowledgements 🫶
The authors would like to thank Lou Berger, Deborah Brungard, John Drake, Yakov Rekhter, Igor Bryskin, and Lucy Yong for their valuable discussions and comments 💖
7. References 📚
7.1. Normative References 🔥
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
- [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.
- [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
- [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.
- [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.
- [RFC4201] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling in MPLS Traffic Engineering (TE)", RFC 4201, October 2005.
- [RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005.
- [RFC5150] Ayyangar, A., Kompella, K., Vasseur, JP., and A. Farrel, "Label Switched Path Stitching with Generalized Multiprotocol Label Switching Traffic Engineering (GMPLS TE)", RFC 5150, February 2008.
7.2. Informative References 📚
These are the extra-credit reads 💅 Nothing here is required to get the main vibe, but they're the receipts for the background stuff.
[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, December 1990.
[RFC1256] Deering, S., Ed., "ICMP Router Discovery Messages", RFC 1256, September 1991.
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, September 2003.
[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 (GMPLS)", RFC 4203, October 2005.
[RFC5212] Shiomoto, K., Papadimitriou, D., Le Roux, JL., Vigoureux, M., and D. Brungard, "Requirements for GMPLS-Based Multi-Region and Multi-Layer Networks (MRN/MLN)", RFC 5212, July 2008.
[RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic Engineering", RFC 5305, October 2008.
[RFC5307] Kompella, K., Ed., and Y. Rekhter, Ed., "IS-IS Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 5307, October 2008.
[RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, October 2008.
[RFC5329] Ishiguro, K., Manral, V., Davey, A., and A. Lindem, Ed., "Traffic Engineering Extensions to OSPF Version 3", RFC 5329, September 2008.
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for IPv6", RFC 5340, July 2008.
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", RFC 5920, July 2010.
[ISIS-GENAP] Ginsberg, L., Previdi, S., and M. Shand, "Advertising Generic Information in IS-IS", Work in Progress, November 2010.
[ISIS-IPV6-TE] Harrison, J., Berger, J., and M. Bartlett, "IPv6 Traffic Engineering in IS-IS", Work in Progress, September 2010.
[OSPF-TI] Lindem, A., Roy, A., and S. Mirtorabi, "OSPF Transport Instance Extensions", Work in Progress, October 2010.
[OSPFv2-MI] Lindem, A., Roy, A., and S. Mirtorabi, "OSPF Multi-Instance Extensions", Work in Progress, October 2010.
[PCE-LAYER] Takeda, T., Ed., and A. Farrel, "PCC-PCE Communication and PCE Discovery Requirements for Inter-Layer Traffic Engineering", Work in Progress, December 2010.
Authors' Addresses 🎀
The people who wrote this, with their contact details:
Richard Rabbat
Google Inc.
1600 Amphitheatre Pkwy
Mountain View, CA 94043
United States of America
EMail: rabbat@alum.mit.edu
Arthi Ayyangar
Juniper Networks
1194 N. Mathilda Ave.
Sunnyvale, CA 94089
United States of America
EMail: arthi@juniper.net
Zafar Ali
Cisco Systems, Inc.
2000 Innovation Drive
Kanata, Ontario, K2K 3E8
Canada
EMail: zali@cisco.comEditors' Addresses 🦋
And the editors, who kept everything organised:
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
Adrian Farrel
Old Dog Consulting
EMail: adrian@olddog.co.uk📦 where this page comes from
- ietf: rfc6107 2011-02
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms