RFC 3473
Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions
RFC 3473 🎀 Part 1 of 8
Title: Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions ✨
- Network Working Group · Request for Comments: 3473 💖
- Editor: L. Berger, Movaz Networks 🧚
- Category: Standards Track 👑
- Date: January 2003 📅
- Obsoletes/Updates: this title block doesn't list any, so nothing is marked as obsoleted or updated here 🙈
Status of this Memo 📝
okay so this document is an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 🫶 For the standardization state and status, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited 🌸
Copyright Notice ©️
Copyright (C) The Internet Society (2003). All Rights Reserved. 💜
Abstract 🦋
bestie, this one is about extensions to the Resource ReserVation Protocol - Traffic Engineering (RSVP-TE) signaling for Multi-Protocol Label Switching (MPLS), and those extensions are required to support Generalized MPLS ✨ Generalized MPLS stretches the MPLS control plane to cover time-division (e.g., Synchronous Optical Network and Synchronous Digital Hierarchy, SONET/SDH), wavelength (optical lambdas) and spatial switching (e.g., incoming port or fiber to outgoing port or fiber) 🌈 This document gives the RSVP-TE specific version of those extensions. A generic functional description lives in separate documents 💅
Table of Contents 📚
1. Introduction .............................................. 2
2. Label Related Formats .................................... 3
2.1 Generalized Label Request Object ........................ 3
2.2 Bandwidth Encoding ...................................... 4
2.3 Generalized Label Object ................................ 5
2.4 Waveband Switching ...................................... 5
2.5 Suggested Label ......................................... 6
2.6 Label Set ............................................... 7
3. Bidirectional LSPs ........................................ 8
3.1 Procedures .............................................. 9
3.2 Contention Resolution ................................... 9
4. Notification .............................................. 9
4.1 Acceptable Label Set Object ............................. 10
4.2 Notify Request Objects .................................. 10
4.3 Notify Message .......................................... 12
4.4 Removing State with a PathErr message ................... 14
5. Explicit Label Control .................................... 15
5.1 Label ERO subobject ..................................... 15
5.2 Label RRO subobject ..................................... 16
6. Protection Object ......................................... 17
6.1 Procedures .............................................. 18
7. Administrative Status Information ......................... 18
7.1 Admin Status Object ..................................... 18
7.2 Path and Resv Message Procedures ........................ 18
7.3 Notify Message Procedures ............................... 20
8. Control Channel Separation ................................ 21
8.1 Interface Identification ................................ 21
8.2 Errored Interface Identification ........................ 23
9. Fault Handling ............................................ 25
9.1 Restart_Cap Object ...................................... 25
9.2 Processing of Restart_Cap Object ........................ 26
9.3 Modification to Hello Processing to Support
State Recovery .......................................... 26
9.4 Control Channel Faults .................................. 27
9.5 Nodal Faults ............................................ 27
10. RSVP Message Formats and Handling ......................... 30
10.1 RSVP Message Formats ................................... 30
10.2 Addressing Path and PathTear Messages ................. 32
11. Acknowledgments ........................................... 32
12. Security Considerations ................................... 33
13. IANA Considerations ....................................... 34
13.1 IANA Assignments ....................................... 35
14. Intellectual Property Considerations ...................... 36
15. References ................................................ 37
15.1 Normative References ................................... 37
15.2 Informative References ................................. 38
16. Contributors .............................................. 38
17. Editor's Address .......................................... 41
18. Full Copyright Statement .................................. 421. Introduction ✨
okay so Generalized MPLS takes MPLS beyond packet (PSC) interfaces and switching and adds three brand new classes: Time-Division Multiplex (TDM), Lambda Switch (LSC) and Fiber-Switch (FSC) 🦋 The functional description of the MPLS signaling extensions needed for those new classes is in [RFC3471]. This document is the RSVP-TE specific version with the formats and mechanisms needed to support all four classes of interfaces 💖
[RFC3471] should be viewed as a companion document to this document. The format of this document parallels [RFC3471]. On top of the other Generalized MPLS features, this document also defines RSVP-TE specific features for rapid failure notification, see Sections 4.2 and 4.3 🔥
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] 🎀
2. Label Related Formats 🌸
this section defines formats for a generalized label request, a generalized label, support for waveband switching, suggested label and label sets 🧚
2.1. Generalized Label Request Object 💅
A Path message SHOULD contain as specific an LSP (Label Switched Path) Encoding Type as possible, so transit LSRs get the maximum flexibility when switching 🫶 A Generalized Label Request object is set by the ingress node, transparently passed along by transit nodes, and used by the egress node. The Switching Type field may also be updated hop-by-hop 💜
The format of a Generalized Label Request object is:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num (19)| C-Type (4) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSP Enc. Type |Switching Type | G-PID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+See [RFC3471] for a description of parameters 🍓
2.1.1. Procedures 🍓
A node processing a Path message containing a Generalized Label Request must verify that the requested parameters can be satisfied by the interface where the incoming label is to be allocated, by the node itself, and by the interface where the traffic will be transmitted 👑 The node may either directly support the LSP or use a tunnel (FA), i.e., another class of switching. Either way, each parameter must be checked ✨
Note that local node policy decides when tunnels may be used and when they may be created. Local policy may allow tunnels to be established dynamically, or they may be solely administratively controlled 🌈 For more on tunnels and on processing ER hops when using tunnels, see [MPLS-HIERARCHY] 🧚
Transit and egress nodes MUST verify that the node itself and, where appropriate, the interface or tunnel where the traffic will be transmitted can support the requested LSP Encoding Type. If the encoding can't be supported, the node MUST generate a PathErr message, with a "Routing problem/Unsupported Encoding" indication. 😭
Nodes MUST verify that the type indicated in the Switching Type parameter is supported on the corresponding incoming interface. If the type can't be supported, the node MUST generate a PathErr message with a "Routing problem/Switching Type" indication 💀
The G-PID parameter is normally only examined at the egress. If the indicated G-PID can't be supported, the egress MUST generate a PathErr message, with a "Routing problem/Unsupported L3PID" indication 🙈 In the case of PSC and when penultimate hop popping (PHP) is requested, the penultimate hop also examines the (stored) G-PID while processing the Resv message. If the G-PID isn't supported in this case, the penultimate hop MUST generate a ResvErr message with a "Routing problem/Unacceptable label value" indication. The generated ResvErr message MAY include an Acceptable Label Set, see Section 4.1 💖
When no error message is generated, normal processing happens. In the transit case this typically results in a Path message being propagated. In the egress case and the PHP special case this typically results in a Resv message being generated 🦋
2.2. Bandwidth Encoding 🌊
Bandwidth encodings are carried in the SENDER_TSPEC and FLOWSPEC objects. See [RFC3471] for the definition of values to use for specific signal types. These values are set in the Peak Data Rate field of Int-Serv objects, see [RFC2210]. Other bandwidth/service related parameters in the object are ignored and carried transparently 💅
2.3. Generalized Label Object 🎀
The format of a Generalized Label object is:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num (16)| C-Type (2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+See [RFC3471] for a description of parameters and the encoding of labels 🧚
2.3.1. Procedures ✨
The Generalized Label travels in the upstream direction in Resv messages 🌈
The presence of both a generalized label object and a normal label object in a Resv message is a protocol error, and it should treated as a malformed message by the recipient 😭
The recipient of a Resv message containing a Generalized Label checks that the values passed are acceptable. If the label is unacceptable, the recipient MUST generate a ResvErr message with a "Routing problem/MPLS label allocation failure" indication 🫶
2.4. Waveband Switching Object ✨
okay so waveband switching literally reuses the generalized label format from section 2.2 🎀, and the Waveband Label uses C-Type (3) 💖
In the waveband context, the generalized label 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num (16)| C-Type (3) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Waveband Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Start Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| End Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+If you want the full scoop on the parameters, go peek at [RFC3471] 🧚
2.4.1. Procedures
The procedures in Section 2.3.1 apply to waveband switching too ✨ This includes generating a ResvErr message with a "Routing problem/MPLS label allocation failure" indication if any of the label fields are unrecognized or unacceptable 💀
Also, when a waveband gets switched to another waveband, the wavelengths inside it can end up mirrored around a center frequency 🌈 When this kind of switching is in play, the start and end label in the waveband label object MUST be flipped before you forward the label object with the new waveband Id 👑 That way, an egress/ingress LSR that gets a waveband label with those values inverted knows it has to invert its own egress association too, so it grabs the right wavelengths 🫶
This operation MUST be performed in both directions when a bidirectional waveband tunnel is being established 🔥
2.5. Suggested Label Object
the Suggested_Label object has the same format as a generalized label 💅 It shows up in Path messages, and it uses Class-Number 129 (of form 10bbbbbb) with the C-Type of the label being suggested 🍓
Errors in received Suggested_Label objects MUST be ignored 🙈 That includes any inconsistent or unacceptable values that come in 😭
Per [RFC3471], if a downstream node hands back a label value that's different from the suggested one, the upstream LSR MUST either reconfigure itself to use the label the downstream node sent, or generate a ResvErr message with a "Routing problem/Unacceptable label value" indication ✨ Also, an ingress node SHOULD NOT send data traffic using a suggested label until the downstream node passes a matching label back upstream 🦋
2.6. Label Set Object
The Label_Set object uses Class-Number 36 (of form 0bbbbbbb) and the C-Type of 1 🌸 It rides along in Path messages 💜
Here's how a Label_Set is laid out 🎀
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num (36)| C-Type (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Action | Reserved | Label Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subchannel 1 |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: : :
: : :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subchannel N |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Label Type (14 bits): this tells you the type and format of the labels carried in the object 🧁 The values match the C-Type of the right RSVP_LABEL object, and only the low order 8 bits get used in this field 🔢
See [RFC3471] for the rest of the parameters 🧚
2.6.1. Procedures
A Label Set is built from one or more Label_Set objects 🍓 You can add specific labels/subchannels to a Label Set, or exclude them, using Action zero (0) and one (1) objects respectively 💅 For ranges of labels/subchannels, Action two (2) adds them and Action three (3) excludes them 🌈 If the Label_Set objects only list labels/subchannels to exclude, then all the other labels count as acceptable ✨
No Label_Set objects at all? That means every label is acceptable 💖 A Label Set only shows up when a node wants to restrict which labels can be used downstream 🫶
When a Path message comes in, the receiving node has to narrow its label choice down to one that's in the Label Set 👑 Nodes that can do label conversion are allowed to strip the Label Set before they forward the Path message 🦋 If the node can't pick a label from the Label Set, or if there's a problem parsing the Label_Set objects, then the request gets terminated and a PathErr message with a "Routing problem/Label Set" indication MUST be generated 💀 Whether the Label Set gets stored for later, to pick from on the Resv, or whether the selection happens right away and gets passed along in the Resv, is a local decision 🎀
Also on a Path message, the Label Set in the message gets compared against the labels available on the downstream interface, and the intersection is what gets forwarded in a Path message 🌸 If that resulting Label Set comes out empty, the Path must be terminated, and a PathErr message, and a "Routing problem/Label Set" indication MUST be generated 😭 Heads up that the intersection is based on physical labels (the actual wavelength/band values), and those can have different logical values on different links 🔥 So the node is responsible for mapping these values so they mean the same physical thing, or for dropping any values that don't have a suitable logical label on that link 🧚
When a Resv message is processed at an intermediate node, the label propagated upstream MUST fall within the Label Set 💜
Note: a node that can't do label conversion, on receiving a Resv message, has no choice but to use the same physical label (wavelength/band) that came in the Resv message 🙈 In that case, using and propagating a Label Set will significantly reduce the chances that the allocation fails 🫶
3. Bidirectional LSPs ✨
Bidirectional LSP setup is signalled by an Upstream Label being present in the Path message 💖 An Upstream_Label object has the same format as the generalized label, see Section 2.3 🎀 It uses Class-Number 35 (of form 0bbbbbbb) and the C-Type of the label being used 🦋
3.1. Procedures
Setting up a bidirectional LSP is basically the same as setting up a unidirectional one, plus a few extras 💅 To support bidirectional LSPs, an Upstream_Label object gets added to the Path message 🌈 The Upstream_Label object MUST indicate a label that's valid for forwarding at the time the Path message is sent 👑
When a Path message with an Upstream_Label object shows up, the receiver first checks that the upstream label is acceptable 🧐 If it isn't, the receiver MUST issue a PathErr message with a "Routing problem/Unacceptable label value" indication 💀 That generated PathErr message MAY include an Acceptable Label Set, see Section 4.1 🌸
An intermediate node also has to allocate a label on the outgoing interface and set up its internal data paths before it fills in an outgoing upstream label and propagates the Path message 🔥 If an intermediate node can't allocate a label or internal resources, then it MUST issue a PathErr message with a "Routing problem/MPLS label allocation failure" indication 😭
Terminator nodes handle Path messages as usual, with one twist: the upstream label can be used right away to carry data traffic for the LSP heading back upstream toward the initiator 🫶
When a bidirectional LSP gets removed, both the upstream and downstream labels are invalidated, so it's no longer valid to send data using those labels 🙈
3.2. Contention Resolution
There are two extra contention resolution considerations when you're controlling bidirectional LSP setup via RSVP-TE 🧠 First, for RSVP contention resolution purposes, the node ID is the IP address used in the RSVP_HOP object 🍓 Second, a neighbor's node ID might not be known yet when an initial Path message gets sent 🤔 When that happens, a node should suggest a label picked at random from the available label space 🎲
4. Notification ✨
This section covers a few notification related extensions 🔔 The first one defines the Acceptable Label Set object, which supports Notification on Label Error, per [RFC3471] 💖 The second and third extensions make it possible to send expedited notification of failures and other events to the nodes responsible for restoring failed LSPs 🚨 (The second one is the Notify Request object, which says where event notifications should be sent 📬 The third one is the Notify message, which handles general event notification 📣) The last notification related extension lets you remove Path state when PathErr messages get handled 🧹
4.1. Acceptable Label Set Object
Acceptable_Label_Set objects use Class-Number 130 (of form 10bbbbbb) 🌈 Everything else in the object, including the C-Type, has the same format as the Label_Set object, see Section 2.6 💅
Acceptable_Label_Set objects can be carried in PathErr and ResvErr messages 💌 The procedures for defining an Acceptable Label Set follow the ones for defining a Label Set, see Section 2.6.1 🦋 So an Acceptable Label Set gets defined via one or more Acceptable_Label_Set objects 🎀 You add specific labels/subchannels to it, or exclude them, using Action zero (0) and one (1) objects, and you handle ranges with Action two (2) and three (3) objects 🌸 When the Acceptable_Label_Set objects only list labels/subchannels to exclude, that means all the other labels are acceptable 💜
Including Acceptable_Label_Set objects is optional 🫶 If you do include them, the PathErr or ResvErr message SHOULD contain a "Routing problem/Unacceptable label value" indication 💀 Leaving them out doesn't have any specific meaning 🙈
4.2. Notify Request Objects
Notifications can be sent via the Notify message defined below 📣 The Notify Request object is what asks for notifications to be generated 🔔 Notifications (aka sending a Notify message) can be requested in both the upstream and downstream directions 🧚
4.2.1. Required Information
okay bestie, the Notify Request Object can ride along in Path or Resv Messages (see Section 7 🎀). Its Class-Number is 195, in the 11bbbbbb form ✨. Here's how each version is laid out 💅
- IPv4 Notify Request Object
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num (1) | C-Type (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Notify Node Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The IPv4 Notify Node Address is 32 bits 🦋 It's the IP address of the node that should be notified when an error message gets generated.
- IPv6 Notify Request Object
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num (2) | C-Type (2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IPv6 Notify Node Address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The IPv6 Notify Node Address is 16 bytes 🌸 Same deal: it's the IP address of the node that should be notified when an error message gets generated.
If a message has multiple Notify_Request objects, only the first one is meaningful. The later ones MAY be ignored and SHOULD NOT be propagated 🙈
4.2.2. Procedures
okay so a Notify Request object can be slipped into Path or Resv messages to say "hey, tell this node if an LSP fails" 📬 Like we said earlier, notifications can be asked for both upstream and downstream. Upstream notification is requested by putting a Notify Request Object in the matching Path message 🌈 Downstream notification is requested by putting one in the matching Resv message ✨
When a node gets a message with a Notify Request object, it SHOULD store the Notify Node Address in the matching state block 💜 If that node is a transit node, it SHOULD also include a Notify Request object in the outgoing Path or Resv message. The outgoing Notify Node Address MAY be updated based on local policy 🧚
Also, putting a Notify Request object in a message does NOT guarantee a Notify message will ever get sent. Just so we're clear 💀
4.3. Notify Message
the Notify message is how you tell non-adjacent nodes about LSP-related events 🦋 Notify messages are normally only generated after a Notify Request object has shown up. What makes it different from PathErr and ResvErr is that it can be "targeted" at a node that isn't your immediate upstream or downstream neighbor, and it's a generalized notification mechanism 💅 It does not replace the existing error messages, though 🎀
The Notify message can be sent in one of two ways: (a) normally, where non-target nodes just forward it on to the target node (kinda like ResvConf processing in [RFC2205]), or (b) encapsulated in a new IP header whose destination equals the target IP address. Either way, any node that gets a Notify message not meant for itself forwards it, unmodified, towards the target 🫶
To make delivery reliable, an Ack Message [RFC2961] is used to acknowledge that a Notify Message was received. For more on reliable RSVP message delivery, check [RFC2961] 📚
4.3.1. Required Information
the Notify message is a generalized notification message 🌸 The IP destination address is set to the IP address of the intended receiver. It gets sent without the router alert option. One Notify message can carry notifications for each listed session, both upstream and downstream 👑
The Notify message has a Message Type of 21 ✨ Here's the format:
<Notify message> ::= <Common Header> [<INTEGRITY>]
[ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ... ]
[ <MESSAGE_ID> ]
<ERROR_SPEC> <notify session list>
<notify session list> ::= [ <notify session list> ]
<upstream notify session> |
<downstream notify session>
<upstream notify session> ::= <SESSION> [ <ADMIN_STATUS> ]
[<POLICY_DATA>...]
<sender descriptor>
<downstream notify session> ::= <SESSION> [<POLICY_DATA>...]
<flow descriptor list>The ERROR_SPEC object says what went wrong and includes the IP address of either the node that detected the error or the link that failed 🔥 Check [RFC2205] for the ERROR_SPEC definition. MESSAGE_ID and its friends are defined in [RFC2961], and they're used when [RFC2961] is supported 🙈
4.3.2. Procedures
Notify messages are most commonly generated at nodes that detect an error which is going to trigger a PathErr or ResvErr message 💖 If a PathErr is about to get generated and a Notify Request object was received in the matching Path message, then a Notify message destined for the recorded node SHOULD be generated. Same vibe for ResvErr: if one's about to go out and a Notify Request object came in on the matching Resv message, a Notify message destined for the recorded node SHOULD be generated 🦋 As we said before, one error can make a Notify message go both upstream and downstream. And a Notify message MUST NOT be generated unless an appropriate Notify Request object has been received 🚫
When a node is generating Notify messages, it SHOULD try to combine notifications going to the same Notify Node and sharing the same ERROR_SPEC into one Notify message 🫶 How a node decides what can be combined is implementation dependent. Implementations may use event-based, timer-based, or other approaches. If someone goes timer-based, the implementation SHOULD let the user configure the interval over which notifications get combined 💅 With a timer-based approach, a default "notification interval" of 1 ms SHOULD be used ⏱️ Notify messages SHOULD be delivered using the reliable message delivery mechanisms defined in [RFC2961] 🌈
When a Notify message comes in, the Notify Node SHOULD send back a corresponding Ack message 💌
4.4. Removing State with a PathErr message
the PathErr message from [RFC2205] gets sent hop-by-hop to the source of the associated Path message 🧚 Intermediate nodes can peek at it, but they don't take any action on it. When Path messages are routed by an IGP and that route can change on the fly, this behavior is a totally fine design choice 👑
BUT, when RSVP is used with explicit routes, errors can often only be fixed at the source node or some node further upstream 😭 To clean up resources, the source has to receive the PathErr and then send a PathTear (or wait for the messages to time out). That means idle resources stay held longer than they need to be and control message load goes up 💀 When the control plane is trying to recover from a serious outage, both the extra load and the delay in freeing resources make it way harder to reconverge quickly 🙈
It gets way better if intermediate nodes are allowed to remove state on certain error conditions 🎀 To make that happen, a new flag is defined in the ERROR_SPEC object. The two ERROR_SPEC objects that already exist (IPv4 and IPv6 error spec objects) each have a one-byte flag field, and two flags are defined in it. This specification defines a third flag, 0x04, called Path_State_Removed ✨
The Path_State_Removed flag simply means the node forwarding the error message has removed the Path state associated with the PathErr 🦋 By default, Path_State_Removed is always set to zero when a PathErr is generated or forwarded. A node that runs into an error MAY set this flag if the error means the associated Path state is being discarded. If the node setting the flag is not the session endpoint, the node SHOULD generate a corresponding PathTear 🌸 A node that receives a PathErr with an ERROR_SPEC object that has Path_State_Removed set MAY also remove the associated Path state. If the Path state does get removed, Path_State_Removed SHOULD be set in the outgoing PathErr message 💜 A node that does NOT remove the associated Path state MUST NOT set Path_State_Removed 🚫 And a node that receives an error with Path_State_Removed set to zero MUST NOT set this flag unless it also generates a corresponding PathTear message 🙅♀️
Note that using this flag doesn't cause any interoperability incompatibilities. 🥰
5. Explicit Label Control 🧚
the Label ERO (Explicit Route Object) and RRO (Record Route Object) subobjects are defined to support Explicit Label Control ✨ Heads up: the Label RRO subobject was originally defined in [RFC3209], and this document extends it to support bidirectional LSPs 🌈
5.1. Label ERO subobject
the Label ERO subobject 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| Type | Length |U| Reserved | C-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+For what L, U, and Label mean, see [RFC3471] 🦋
Type 🎀
- The value is 3, which means Label.
Length 🌸
- This is the total length of the subobject in bytes, including the Type and Length fields. It's always divisible by 4 ✨
C-Type 💜
- This is the C-Type of the included Label Object, copied from the Label Object 👑
5.1.1. Procedures ✨
Okay so the Label subobject shows up right after the subobject with the IP address, or the interface identifier [RFC3477], for the link it's gonna be used on 🔗 Up to two label subobjects can be there, one for the downstream label and one for the upstream label 🦋 These things SHOULD result in "Bad EXPLICIT_ROUTE object" errors:
- If the first label subobject is not preceded by a subobject containing an IP address, or an interface identifier [RFC3477], associated with an output link.
- For a label subobject to follow a subobject that has the L-bit set
- On unidirectional LSP setup, for there to be a label subobject with the U-bit set
- For there to be two label subobjects with the same U-bit values
To support the label subobject, a node has to check whether the subobject right after its associated address or interface is a label subobject 👀 If it is, one subobject gets examined for unidirectional LSPs, and two get examined for bidirectional LSPs. If the U-bit of the subobject being examined is clear (0), the label value gets copied into a new Label_Set object. This Label_Set object MUST be included on the corresponding outgoing Path message 💅
If the U-bit of the subobject being examined is set (1), then the label value is the label to be used for upstream traffic associated with the bidirectional LSP 🌸 If this label is not acceptable, a "Bad EXPLICIT_ROUTE object" error SHOULD be generated. If the label is acceptable, it gets copied into a new Upstream_Label object. This Upstream_Label object MUST be included on the corresponding outgoing Path message.
After processing, the label subobjects are removed from the ERO 🧹
Note an implication of the above procedures is that the label subobject should never be the first subobject in a newly received message 🙈 If the label subobject is the the first subobject an a received ERO, then it SHOULD be treated as a "Bad strict node" error. Lowkey iconic, no cap 💀
Procedures by which an LSR at the head-end of an LSP obtains the information needed to construct the Label subobject are outside the scope of this document 🧚
5.2. Label RRO subobject 🎀
The Label RRO subobject 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |U| Flags | C-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+See [RFC3471] for a description of U and Label parameters 📖
Type is 3, which means Label 🏷️
Length: See [RFC3209].
Flags: See [RFC3209].
C-Type: The C-Type of the included Label Object. Copied from the Label Object.
5.2.1. Procedures 💖
Label RRO subobjects are included in RROs as described in [RFC3209]. The only change to usage and processing from [RFC3209] is that when labels get recorded for bidirectional LSPs, label ERO subobjects for both downstream and upstream labels MUST be included 🫶
6. Protection Object 🛡️
The use of the Protection Object is optional. The object is included to show specific protection attributes of an LSP ✨ The Protection Object uses Class-Number 37 (of form 0bbbbbbb).
The format of the Protection Object is:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num (37)| C-Type (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| Reserved | Link Flags|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+See [RFC3471] for a description of parameters 📖
6.1. Procedures 🔥
Transit nodes processing a Path message containing a Protection Object MUST verify that the requested protection can be satisfied by the outgoing interface or tunnel (FA). If it cannot, the node MUST generate a PathErr message, with a "Routing problem/Unsupported Link Protection" indication 🚨
7. Administrative Status Information 🌈
Administrative Status Information is carried in the Admin_Status object. The object gives info about the administrative state of a particular LSP 💜 It gets used in two ways. In the first, the object rides along in Path and Resv messages to show the administrative state of an LSP. In the second, the object is carried in a Notification message to ask the ingress node to change the administrative state of an LSP 🦋
7.1. Admin Status Object 💅
The use of the Admin_Status Object is optional. It uses Class-Number 196 (of form 11bbbbbb).
The format of the Admin_Status Object is:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num(196)| C-Type (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R| Reserved |T|A|D|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+See [RFC3471] for a description of parameters 📖
7.2. Path and Resv Message Procedures 🌸
The Admin_Status object is used to tell each node along the path what the status of the LSP is 🗺️ Each node processes the status info based on local policy, then passes it along in the matching outgoing messages. The object may be inserted in either Path or Resv messages, at the discretion of the ingress (for Path messages) or egress (for Resv messages) nodes. If the object is absent, it's the same as getting an object with all values set to zero (0). Main character energy 👑
Transit nodes receiving a non-refresh Path or Resv message containing an Admin_Status object update their local state, take any appropriate local action based on the indicated status, and then propagate the received Admin_Status object in the corresponding outgoing Path or Resv message ✨ If the values of an Admin_Status object received in a Resv message differ from the values received in a Path message, then, with one exception, no local action should be taken but the values should still be propagated. The one case where values received in the Resv message should result in local action is when both the received R and D bits are set, i.e., are one (1) 💥
Edge nodes receiving a non-refresh Path or Resv message containing an Admin_Status object also update their local state and take any appropriate local action based on the indicated status 🧁 When an Admin Status object is received with the R bit set, the receiving edge node should reflect the received values in a corresponding outgoing message. Specifically, if an egress node receives a Path message with the R bit of the Admin_Status object set, and the node has previously issued a Resv message corresponding to the Path message, the node SHOULD send an updated Resv message containing an Admin_Status object with the same values set, except for the R bit, as received in the corresponding Path message. Furthermore, the egress node SHOULD also ensure that subsequent Resv messages sent by the node contain the same Admin Status Object 🫶
Additionally, if an ingress node receives a Resv message with the R bit of the Admin_Status object set, the node SHOULD send an updated Path message containing an Admin_Status object with the same values set, except for the R bit, as received in the corresponding Resv message. Furthermore, the ingress node SHOULD also ensure that subsequent Path messages sent by the node contain the same Admin Status Object 🙌
7.2.1. Deletion procedure 🗑️
In some situations, especially in optical networks, it's useful to set the administrative status of an LSP before tearing it down 🔦 In those situations, the procedure SHOULD be followed when deleting an LSP from the ingress:
- The ingress node precedes an LSP deletion by inserting an Admin Status Object in a Path message and setting the Reflect (R) and Delete (D) bits.
- Transit and egress nodes process the Admin Status Object as described above. (Alternatively, the egress MAY respond with a PathErr message with the Path_State_Removed flag set, see section 4.4.)
- Upon receiving the Admin Status Object with the Delete (D) bit set in the Resv message, the ingress node sends a PathTear message downstream to remove the LSP, and normal RSVP processing takes place.
In those situations, the procedure SHOULD be followed when deleting an LSP from the egress:
- The egress node indicates its desire for deletion by inserting an Admin Status Object in a Resv message and setting the Reflect (R) and Delete (D) bits.
- Transit nodes process the Admin Status Object as described above.
- Upon receiving the Admin Status Object with the Delete (D) bit set in the Resv message, the ingress node sends a PathTear message downstream to remove the LSP, and normal RSVP processing takes place.
7.2.2. Compatibility and Error Procedures 🧯
It's possible that some nodes along an LSP won't support the Admin Status Object 🥺 For a non-supporting transit node, the object passes through the node unmodified and normal processing can continue. For a non-supporting egress node, the Admin Status Object won't be reflected back in the Resv Message. To handle the case of a non-supporting egress node, the ingress SHOULD only wait a configurable period of time for the updated Admin Status Object in a Resv message. Once that period has elapsed, the ingress node sends a PathTear message. By default this period of time SHOULD be 30 seconds ⏰
7.3. Notify Message Procedures 📨
Intermediate and egress nodes can trigger the setting of administrative status using Notify messages 💌 To do this, an intermediate or egress node generates a Notify message with the corresponding upstream notify session information. The Admin Status Object MUST be included in the session information, with the appropriate bit or bits set. The Reflect (R) bit MUST NOT be set. The Notify message may be, but is not required to be, encapsulated, see Section 4.3 🎀
An ingress node receiving a Notify message containing an Admin Status Object with the Delete (D) bit set SHOULD initiate the deletion procedure described in the previous section. Other bits SHOULD be propagated in an outgoing Path message as normal 🦋
7.3.1. Compatibility and Error Procedures 🫠
Some special processing is needed to cover the case of nodes that don't support the Admin Status Object, plus other error conditions 🔧 Specifically, a node that sends a Notify message containing an Admin Status Object with the Down (D) bit set MUST verify that it receives a corresponding Path message with the Down (D) bit set within a configurable period of time. By default this period of time SHOULD be 30 seconds. If the node doesn't receive such a Path message, it SHOULD send a PathTear message downstream, and either a ResvTear message or a PathErr message with the Path_State_Removed flag set upstream. Literally the most dramatic handoff in the whole doc 😭
8. Control Channel Separation 🎀
okay so this section is where we get the protocol-specific formats and procedures needed to support a control channel that is not in-band with a data channel 🫶
8.1. Interface Identification 🦋
the sender of the Path message is always the one who picks the data interface 👑 it tells everyone its choice by putting the data channel's interface identifier in the message, using a new RSVP_HOP object sub-type. for bidirectional LSPs, the sender picks the data interface in each direction. in every case except bundling, the upstream interface is implied by the downstream interface. for bundling, the path sender explicitly names the component interface used in each direction. the new RSVP_HOP object shows up in Resv messages too, to show the downstream node's usage of the indicated interface(s) ✨
8.1.1. IF_ID RSVP_HOP Objects 💅
the IPv4 IF_ID RSVP_HOP Object 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num (3) | C-Type (3) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Next/Previous Hop Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Logical Interface Handle |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ TLVs ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+and the IPv6 IF_ID RSVP_HOP Object 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num (3) | C-Type (4) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IPv6 Next/Previous Hop Address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Logical Interface Handle |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ TLVs ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+for the hop address and handle fields, see [RFC2205]. for the parameters and how TLVs are encoded, see [RFC3471] 🧚
8.1.2. Procedures ✨
an IF_ID RSVP_HOP object is used in place of the RSVP_HOP objects defined earlier 🍓 it's for links where a control channel and a data channel aren't in a one-to-one relationship, see [RFC3471]. the Hop Address and Logical Interface Handle fields work the standard RSVP [RFC2205] way.
TLVs are how we identify the data channel(s) for an LSP. for a unidirectional LSP, a downstream data channel MUST be indicated. for bidirectional LSPs, a common downstream and upstream data channel is normally indicated. there's one special case, a bidirectional LSP crossing a bundled link, where you can specify a downstream data channel that's different from the upstream one 🌈 data channels are always specified from the viewpoint of the sender of the Path message. the IF_ID RSVP_HOP object SHOULD NOT be used when no TLVs are needed.
when a node gets one or more TLVs in a Path message, it saves their values and sends them back in the HOP objects of later Resv messages to the node that originated the TLVs 💜
Note, the node originating an IF_ID object MUST ensure that the selected outgoing interface, as specified in the IF_ID object, is consistent with an ERO. a node that receives an IF_ID object SHOULD check whether the information in this object is consistent with the information in a received ERO, and if not it MUST send a PathErr Message with the error code "Routing Error" and error value of "Bad Explicit Route Object" toward the sender. this check CANNOT be performed when the initial ERO subobject is not the incoming interface. 🙈
8.2. Errored Interface Identification ✨
sometimes it's really useful to point at one specific interface that's tied to an error 🔥 to make that possible, the IF_ID ERROR_SPEC Objects are defined.
8.2.1. IF_ID ERROR_SPEC Objects 🦋
the IPv4 IF_ID ERROR_SPEC Object 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num (6) | C-Type (3) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Error Node Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Error Code | Error Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ TLVs ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+and the IPv6 IF_ID ERROR_SPEC Object 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num (6) | C-Type (4) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IPv6 Error Node Address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Error Code | Error Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ TLVs ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+for the address, flags, error code and error value fields, see [RFC2205]. for the parameters and how TLVs are encoded, see [RFC3471] 🧚
8.2.2. Procedures ✨
nodes that want to say an error is tied to a specific interface SHOULD use the matching IF_ID ERROR_SPEC Object in the PathErr or ResvErr message they send back 💖 IF_ID ERROR_SPEC Objects SHOULD be generated and processed like any other ERROR_SPEC Object, see [RFC2205].
9. Fault Handling 🧯
this section covers two kinds of control communication faults 👀 the first is nodal faults, where a node loses its control state (say, after a restart) but keeps its data forwarding state. the second is control channel faults, where control communication gets lost between two nodes. both are handled using the Restart_Cap object defined below, and both need Hello messages.
Note, the Restart_Cap object MUST NOT be sent when there is no mechanism to detect data channel failures independent of control channel failures. 🚨
Please note this section is derived from [PAN-RESTART] 🌸
9.1. Restart_Cap Object 💜
the Restart_Cap Object is carried in Hello messages ✨
the Restart_Cap Object 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num(131)| C-Type (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Restart Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Recovery Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Restart Time: 32 bits 🕰️
Restart Time is measured in milliseconds. Restart Time SHOULD be set to the sum of the time it takes the sender of the object to restart its RSVP-TE component (to the point where it can exchange RSVP Hello with its neighbors) and the communication channel that is used for RSVP communication. a value of 0xffffffff means the restart of the sender's control plane may take an indeterminate amount of time, and its data plane is unaffected by control plane failures. the method used to keep the data plane running is outside the scope of this document 🦋
Recovery Time: 32 bits 🔄
this is the period of time, in milliseconds, that the sender wants the recipient to use to re-synchronize RSVP and MPLS forwarding state with the sender after Hello synchronization is re-established. a value of zero (0) means MPLS forwarding state was not preserved across a particular reboot 💅
9.2. Processing of Restart_Cap Object 🎀
nodes that support state recovery advertise this capability by carrying the Restart_Cap object in Hello messages. those nodes MUST include the Restart_Cap object in all Hello messages. (this includes Hello messages containing ACK objects, fyi 🫶) the special case Recovery Time values are explained in more detail below ✨
when a node receives a Hello message with the Restart_Cap object, it SHOULD record the values of the parameters it received 💖
9.3. Modification to Hello Processing to Support State Recovery
okay so this is where the Hello game gets a glow-up 🦋 when a node figures out that RSVP communication with a neighbor is lost, AND it already learned that neighbor supports state recovery, the node SHOULD wait at least the amount of time in the Restart Time the neighbor gave it before it starts the communication-loss stuff 💅 it's giving patience 🫶 A node MAY wait a different amount based on local policy or configuration info, so it can pick its own vibe 🌸
During that waiting period, every Hello MUST go out with Dst_Instance set to zero (0), and Src_Instance should stay unchanged 🎀 While it waits, the node SHOULD also keep the RSVP and MPLS forwarding state for LSPs that are already established and go over the link(s) between the node and the neighbor ✨ For established LSPs, the node acts like it's still getting regular RSVP refreshes from the neighbor, periodt 💖 The node MAY clear RSVP and forwarding state for LSPs that are still being set up when their refresh timers run out 🧚 Refreshing of Resv and Path state SHOULD be suppressed during this wait 🙈
Also during the wait, the node MAY tell upstream nodes about the communication loss with a PathErr and/or upstream Notify message that uses the "Control Channel Degraded State" indication 📣 If it sent that notification, then once the control channel is back, the node MUST tell other nodes about the restoration with a PathErr and/or upstream Notify message that uses the "Control Channel Active State" indication 🌈 (Specific error codes have been assigned by IANA.)
When a new Hello arrives from the neighbor, the node has to figure out if the fault was just the control channel or an actual nodal fault 👀 That call is based on the Src_Instance it gets from the neighbor. If the value is different from the one it had before the fault, the neighbor should be treated as if it has restarted 🔄 Otherwise, the fault was limited to the control channel. How to handle each case is described below 💜
9.4. Control Channel Faults
okay so for control channel faults 🛠️ the node SHOULD refresh all state it shares with the neighbor. Summary Refreshes [RFC2961] with the ACK_Desired flag set SHOULD be used, if supported 🍓 ngl, if a large number of messages are needed, some pacing should be applied 🌊 All state SHOULD be refreshed within the Recovery time the neighbor advertised ⏰
9.5. Nodal Faults
nodal faults are the big leagues 👑 Recovering from them uses one new object plus other existing protocol messages and objects 💅
9.5.1. Recovery Label
The Recovery_Label object is used during the nodal fault recovery process 🏷️ It's formatted exactly like a generalized label. A Recovery_Label object uses Class-Number 34 (of form 0bbbbbbb) and the C-Type of the label being suggested ✨
9.5.2. Procedures for the Restarting node
After a node restarts its control plane, a node that supports state recovery SHOULD check whether it was able to preserve its MPLS forwarding state 🔍 If no forwarding state from before the restart was preserved, the node MUST set the Recovery Time to 0 in the Hello message it sends to its neighbors 🙅♀️
If forwarding state was preserved, the node starts the state recovery process 🚀 The period when a node is ready to support recovery is called the Recovery Period. The total duration of the Recovery Period is advertised by the recovering node in the Recovery Time parameter of the Restart_Cap object. The Recovery Time MUST be set to the duration of the Recovery Period in all Hello messages sent during the Recovery Period. State that is not resynchronized during the Recovery Period SHOULD be removed at the end of the Period 🧹
Note that if, during Hello synchronization, the restarting node determines that a neighbor doesn't support state recovery, and the restarting node keeps its MPLS forwarding state on a per neighbor basis, the restarting node should immediately consider the Recovery Period with that neighbor completed 🏁 Forwarding state may be considered to be maintained on a per neighbor basis when per interface labels are used on point-to-point interfaces 🤓
When a node receives a Path message during the Recovery Period, it first checks if it has RSVP state associated with the message ✅ If the state is found, it handles the message according to previously defined procedures.
If the RSVP state is not found, and the message does not carry a Recovery_Label object, the node treats this as a setup for a new LSP, and handles it according to previously defined procedures 🆕
If the RSVP state is not found, and the message carries a Recovery_Label object, the node searches its MPLS forwarding table (the one that was preserved across the restart) for an entry whose incoming interface matches the Path message and whose incoming label is equal to the label carried in the Recovery_Label object 🔎
If the MPLS forwarding table entry is not found, the node treats this as a setup for a new LSP, and handles it according to previously defined procedures.
If the MPLS forwarding table entry is found, the appropriate RSVP state is created, the entry is bound to the LSP associated with the message, and related forwarding state should be considered as valid and refreshed 🎉 Normal Path message processing should also be conducted. When sending the corresponding outgoing Path message, the node SHOULD include a Suggested_Label object with a label value matching the outgoing label from the now restored forwarding entry. The outgoing interface SHOULD also be selected based on the forwarding entry. In the special case where a restarting node also has a restarting downstream neighbor, a Recovery_Label object should be used instead of a Suggested_Label object 🧩
Additionally, for bidirectional LSPs, the node extracts the label from the UPSTREAM_LABEL object carried in the received Path message, and searches its MPLS forwarding table for an entry whose outgoing label is equal to the label carried in the object. In the case of link bundling, this may also involve first identifying the appropriate incoming component link 🔗
If the MPLS forwarding table entry is not found, the node treats this as a setup for a new LSP, and handles it according to previously defined procedures.
If the MPLS forwarding table entry is found, the entry is bound to the LSP associated with the Path message, and the entry should be considered to be re-synchronized 🫶 In addition, if the node is not the tail-end of the LSP, the corresponding outgoing Path messages are sent with the incoming label from that entry carried in the UPSTREAM_LABEL object.
During the Recovery Period, Resv messages are processed normally with two exceptions. In the case that a forwarding entry is recovered, no new label or resource allocation is required while processing the Resv message. The second exception is that ResvErr messages SHOULD NOT be generated when a Resv message with no matching Path state is received. In this case, the Resv message SHOULD just be silently discarded 🤫
9.5.3. Procedures for the Neighbor of a Restarting node
The following specifies the procedures that apply when the node re-establishes communication with the neighbor's control plane within the Restart Time, the node determines (using the procedures defined in Section 5 of [RFC3209]) that the neighbor's control plane has restarted, and the neighbor was able to preserve its forwarding state across the restart. This was indicated by a non-zero Recovery Time carried in the Restart_Cap object of the RSVP Hello messages received from the neighbor 💫 Note, a Restart Time value of 0xffffffff indicates an infinite Restart Time interval ♾️
Upon detecting a restart with a neighbor that supports state recovery, a node SHOULD refresh all Path state shared with that neighbor. The outgoing Path messages MUST include a Recovery_Label object containing a label value corresponding to the label value received in the most recently received corresponding Resv message. All Path state SHOULD be refreshed within approximately 1/2 of the Recovery time advertised by the restarted neighbor. If there are many LSPs going through the restarting node, the neighbor node should avoid sending Path messages in a short time interval, so it doesn't unnecessarily stress the restarting node's CPU. Instead, it should spread the messages across 1/2 the Recovery Time interval 🌬️
After detecting a restart of a neighbor that supports state recovery, all Resv state shared with the restarting node MUST NOT be refreshed until a corresponding Path message is received. This requires suppression of normal Resv and Summary Refresh processing to the neighbor during the Recovery Time advertised by the restarted neighbor. As soon as a corresponding Path message is received, a Resv message SHOULD be generated and normal state processing SHOULD be re-enabled 💖
10. RSVP Message Formats and Handling
This message summarizes RSVP message formats and handling as modified by GMPLS 🎀
10.1. RSVP Message Formats
This section presents the RSVP message related formats as modified by this document. Where they differ, formats for unidirectional LSPs are presented separately from bidirectional LSPs. Unmodified formats are not listed. Again, MESSAGE_ID and related objects are defined in [RFC2961] 📚
The format of a Path message is as follows:
<Path Message> ::= <Common Header> [ <INTEGRITY> ]
[ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ... ]
[ <MESSAGE_ID> ]
<SESSION> <RSVP_HOP>
<TIME_VALUES>
[ <EXPLICIT_ROUTE> ]
<LABEL_REQUEST>
[ <PROTECTION> ]
[ <LABEL_SET> ... ]
[ <SESSION_ATTRIBUTE> ]
[ <NOTIFY_REQUEST> ]
[ <ADMIN_STATUS> ]
[ <POLICY_DATA> ... ]
<sender descriptor>The format of the sender description for unidirectional LSPs is:
<sender descriptor> ::= <SENDER_TEMPLATE> <SENDER_TSPEC>
[ <ADSPEC> ]
[ <RECORD_ROUTE> ]
[ <SUGGESTED_LABEL> ]
[ <RECOVERY_LABEL> ]The format of the sender description for bidirectional LSPs is:
[ <ADSPEC> ]
[ <RECORD_ROUTE> ]
[ <SUGGESTED_LABEL> ]
[ <RECOVERY_LABEL> ]
<UPSTREAM_LABEL>okay so the PathErr message is built like this, bestie 🎀
<PathErr Message> ::= <Common Header> [ <INTEGRITY> ]
[ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ... ]
[ <MESSAGE_ID> ]
<SESSION> <ERROR_SPEC>
[ <ACCEPTABLE_LABEL_SET> ... ]
[ <POLICY_DATA> ... ]
<sender descriptor>and the Resv message is giving just as much structure 💅✨
<Resv Message> ::= <Common Header> [ <INTEGRITY> ]
[ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ... ]
[ <MESSAGE_ID> ]
<SESSION> <RSVP_HOP>
<TIME_VALUES>
[ <RESV_CONFIRM> ] [ <SCOPE> ]
[ <NOTIFY_REQUEST> ]
[ <ADMIN_STATUS> ]
[ <POLICY_DATA> ... ]
<STYLE> <flow descriptor list><flow descriptor list> is not modified by this document 🦋 so we just leave it alone, no notes.
And ResvErr looks like this 🥺
<ResvErr Message> ::= <Common Header> [ <INTEGRITY> ]
[ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ... ]
[ <MESSAGE_ID> ]
<SESSION> <RSVP_HOP>
<ERROR_SPEC> [ <SCOPE> ]
[ <ACCEPTABLE_LABEL_SET> ... ]
[ <POLICY_DATA> ... ]
<STYLE> <error flow descriptor>The modified Hello message is the last one in this batch 🌸
<Hello Message> ::= <Common Header> [ <INTEGRITY> ] <HELLO>
[ <RESTART_CAP> ]10.2. Addressing Path, PathTear and ResvConf Messages 🧚
RSVP was originally built to handle dynamic (non-explicit) path changes and non-RSVP hops along the path 💜 So the Path, PathTear and ResvConf messages carry the destination address of the session in the IP header. In generalized signaling, routes are usually explicitly signaled, which is a whole different vibe 👑 Also, hops that can't allocate labels literally cannot exist in the path of an LSP. And here's the twist: sometimes an RSVP message travels out of band with respect to an LSP's data channel 😭
When a node is sending a Path, PathTear or ResvConf message to a node that it knows to be adjacent at the data plane (so, along the path of the LSP), it SHOULD address the message directly to an address associated with the adjacent node's control plane 🫶 In this case the router-alert option SHOULD not be included 🙈
11. Acknowledgments 🍓
This document is the work of numerous authors and is a composition of a bunch of previous documents in this area. Bestie, so much teamwork ✨
Valuable comments and input came from a number of people, including Igor Bryskin, Adrian Farrel and Dimitrios Pendarakis 💖 Portions of Section 4 are based on suggestions and text proposed by Adrian Farrel 🔥
The security considerations section is based on text provided by Steven Bellovin 🌈
12. Security Considerations 🔐
RSVP message security is described in [RFC2747] and it provides message integrity and node authentication 💅 For hop-by-hop messages, this document introduces no other new security considerations. Phew 🙏
Okay but this part is kind of a big deal 😭 This document introduces the ability to send a Notify message in a non-hop-by-hop fashion. That precludes RSVP's hop-by-hop integrity and authentication model, so it's a real plot twist 💀 If RSVP is generating end-to-end messages and you want the same level of security that [RFC2747] provides, the standard IPSEC based integrity and authentication can be used. Or, alternatively, you can disable sending no-hop-by-hop Notify messages altogether 🛑
When using IPSEC to provide message authentication, the following apply:
Selectors
The selector is identified by RSVP messages exchanged between a pair of non-adjacent nodes 🦋 The nodes are identified by the source and destination IP address of the inner IP header used on Notify messages.
Mode
In this application, transport mode is the proper choice 💜 The information being communicated is generally not confidential, so encryption need not be used. Either AH [RFC2402] or ESP [RFC2406] MAY be used. If ESP is used, the sender's IP address MUST be checked against the IP address asserted in the key management exchange 🎀
Key Management
To permit replay detection, an automated key management system SHOULD be used, most likely IKE [RFC2409] 🔑 Configured keys MAY be used too.
Security Policy
Messages MUST NOT be accepted except from nodes that are not known to the recipient to be authorized to make such requests. Not me being strict about this 🙅♀️
Identification
Shared keys mechanisms should be adequate for initial deployments and smaller networks 🌸 For larger-scale deployments, certificate-based IKE should be supported. Whatever scheme is used, it must tie back to a source IP address in some fashion. iykyk 🧚
Availability
Many routers and switches already support IPSEC ✨ For cases where IPSEC is unavailable and security is required, Notify messages MUST be sent hop-by-hop. No exceptions, periodt 💅
13. IANA Considerations 🌈
IANA assigns values to RSVP protocol parameters 👑 This document defines multiple objects, and each of these objects contains C-Types. This section sets the rules for assigning the related C-Type values. It uses the terminology of BCP 26 "Guidelines for Writing an IANA Considerations Section in RFCs" [BCP26], so bookmark that one 🔖
As per [RFC2205], C-Type is an 8-bit number that identifies the function of an object. All possible values except zero are available for assignment 🦋
The C-Type values of the objects defined in this document fall into three categories. The first category inherits C-Types from the Label object, i.e., object class number 16 [RFC3209] 🧚 IANA is requested to institute a policy whereby all C-Type values assigned for the Label object are also assigned for the following objects:
o Suggested_Label (Class-Num 129)
o Upstream_Label (Class-Num 35)
o Recovery_Label (Class-Num 34)The second category of objects follows independent policies 💖 Specifically, following the policies outlined in [BCP26], C-Type values in the range 0x00 - 0x3F are allocated through an IETF Consensus action, values in the range 00x40 - 0x5F are allocated as First Come First Served, and values in the range 0x60 - 0x7F are reserved for Private Use. This policy applies to the following objects:
o Label_Set (Class-Num 36)
o Notify_Request (Class-Num 195)
o Protection (Class-Num 37)
o Admin Status (Class-Num 196)
o Restart_Cap (Class-Num 131)The assignment of C-Type values for the remaining object, the Acceptable_Label_Set object, follows the assignment of C-Type values of the Label_Set object 🎀 IANA will institute a policy whereby all C-Type values assigned for the Label_Set object are also assigned for the Acceptable_Label_Set object. Consistency is everything ✨
13.1. IANA Assignments 📋
This section summarizes values used in this document that have been assigned by IANA 💅
---------------------------------------------------------------------
Message Types
o Notify message (Message type = 21)
---------------------------------------------------------------------
Class Types
o RSVP_HOP (C-Num 3)
- IPv4 IF_ID RSVP_HOP (C-type = 3)
- IPv6 IF_ID RSVP_HOP (C-type = 4)
o ERROR_SPEC (C-Num 6)
- IPv4 IF_ID ERROR_SPEC (C-type = 3)
- IPv6 IF_ID ERROR_SPEC (C-type = 4)
o LABEL_REQUEST (Class-Num 19)
- Generalized_Label_Request (C-Type = 4)
o RSVP_LABEL (Class-Num = 16)
- Generalized_Label (C-Type = 2)
- Waveband_Switching_Label C-Type (C-Type = 3)
---------------------------------------------------------------------
New Class-Nums, C-Types inherited from Label object (same as CNum16)
o RECOVERY_LABEL Class-Num of form 0bbbbbbb (= 34)
o SUGGESTED_LABEL Class-Num of form 10bbbbbb (= 129)
o UPSTREAM_LABEL Class-Num of form 0bbbbbbb (= 35)
---------------------------------------------------------------------
New Class-Nums
o LABEL_SET Class-Num of form 0bbbbbbb (= 36)
- Type 1 (C-Type = 1)
o ACCEPTABLE_LABEL_SET Class-Num of form 10bbbbbb (= 130)
- Type 1 Acceptable_Label_Set (C-type from label_set cnum)
o NOTIFY_REQUEST Class-Num of form 11bbbbbb (= 195)
- IPv4 Notify Request (C-Type = 1)
- IPv6 Notify Request (C-Type = 2)
o PROTECTION Class-Num of form 0bbbbbbb (= 37)
- Type 1 (C-Type = 1)
o ADMIN STATUS Class-Num of form 11bbbbbb (= 196)
- Type 1 (C-Type = 1)
o RESTART_CAP Class-Num of form 10bbbbbb (= 131)
- Type 1 (C-Type = 1)
---------------------------------------------------------------------
ERO/RRO subobject types
o Label ERO subobject
Type 3 - Label
o Label RRO subobject
Type 3 - Label
---------------------------------------------------------------------
Error codes
o "Routing problem/Label Set" (value = 11)
o "Routing problem/Switching Type" (value = 12)
(duplicate code 13 dropped)
o "Routing problem/Unsupported Encoding" (value = 14)
o "Routing problem/Unsupported Link Protection" (value = 15)
o "Notify Error/Control Channel Active State" (value = 4)
o "Notify Error/Control Channel Degraded State" (value = 5)
---------------------------------------------------------------------14. Intellectual Property Considerations ⚖️
This section is taken from Section 10.4 of [RFC2026] 📜
The IETF takes no position on whether any intellectual property or other rights that might be claimed to apply to the implementation or use of the technology in this document are valid or in scope, or whether any license under such rights would or wouldn't be available. It also doesn't claim it has tried to find any such rights. Info on the IETF's procedures for rights in standards-track and standards-related documents is in BCP-11. Copies of claims of rights made available for publication, and any assurances of licenses to be made available, or the results of an attempt to get a general license or permission for implementers or users to use such proprietary rights, can be obtained from the IETF Secretariat 💼
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please send that information to the IETF Executive Director 🫶
15. References 📚
15.1. Normative References
okay bestie, these are the must-read docs everything else leans on 📚✨
[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 --
Version 1 Functional Specification", RFC 2205,
September 1997.
[RFC2210] Wroclawski, J., "The Use of RSVP with IETF
Integrated Services", RFC 2210, September 1997.
[RFC2402] Kent, S. and R. Atkinson, "IP Authentication
Header", RFC 2401, November 1998.
[RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security
Payload (ESP)", RFC 2401, November 1998.
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key
Exchange (IKE)", RFC 2409, November 1998.
[RFC2747] Baker, F., Lindell, B. and M. Talwar, "RSVP
Cryptographic Authentication", RFC 2747, January
2000.
[RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi,
F. and S. Molendini, "RSVP Refresh Overhead
Reduction Extensions", RFC 2961, April 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.
[RFC3471] Berger, L., Editor, "Generalized Multi-Protocol
Label Switching (GMPLS) Signaling Functional
Description", RFC 3471, January 2003.
[RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered
Links in Resource Reservation Protocol - Traffic
Engineering (RSVP-TE)", RFC 3477, January 2003.15.2. Informative References
these ones are good to know, not strictly required 🌸
[BCP26] Narten, T. and H. Alvestrand, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP
26, RFC 2434, October 1998.
[MPLS-HIERARCHY] Kompella, K. and Y. Rekhter, "LSP Hierarchy with
MPLS TE", Work in Progress.
[PAN-RESTART] Pan, P., et. al., "Graceful Restart Mechanism for
RSVP-TE", Work in Progress.
[RFC2026] Bradner, S., "The Internet Standards Process --
Revision 3", BCP 9, RFC 2026, October 1996.16. Contributors ✨
the people who helped make this happen, the whole squad 🫶
Peter Ashwood-Smith
Nortel Networks Corp.
P.O. Box 3511 Station C,
Ottawa, ON K1Y 4H7
Canada
Phone: +1 613 763 4534
EMail: petera@nortelnetworks.com
Ayan Banerjee
Calient Networks
5853 Rue Ferrari
San Jose, CA 95138
Phone: +1 408 972-3645
EMail: abanerjee@calient.net
Lou Berger
Movaz Networks, Inc.
7926 Jones Branch Drive
Suite 615
McLean VA, 22102
Phone: +1 703 847-1801
EMail: lberger@movaz.com
Greg Bernstein
EMail: gregb@grotto-networking.com
John Drake
Calient Networks
5853 Rue Ferrari
San Jose, CA 95138
Phone: +1 408 972 3720
EMail: jdrake@calient.net
Yanhe Fan
Axiowave Networks, Inc.
200 Nickerson Road
Marlborough, MA 01752
Phone: + 1 774 348 4627
EMail: yfan@axiowave.com
Kireeti Kompella
Juniper Networks, Inc.
1194 N. Mathilda Ave.
Sunnyvale, CA 94089
EMail: kireeti@juniper.net
Jonathan P. Lang
EMail: jplang@ieee.org
Fong Liaw
Solas Research, LLC
EMail: fongliaw@yahoo.com
Eric Mannie
Independent Consultant
2 Avenue de la Folle Chanson
1050 Brussels
Belgium
EMail: eric_mannie@hotmail.com
Ping Pan
Ciena
10480 Ridgeview Court
Cupertino, CA 95014
Phone: 408-366-4700
EMail: ppan@ciena.com
Bala Rajagopalan
Tellium, Inc.
2 Crescent Place
P.O. Box 901
Oceanport, NJ 07757-0901
Phone: +1 732 923 4237
Fax: +1 732 923 9804
EMail: braja@tellium.com
Yakov Rekhter
Juniper Networks, Inc.
EMail: yakov@juniper.net
Debanjan Saha
EMail: debanjan@acm.org
Vishal Sharma
Metanoia, Inc.
1600 Villa Street, Unit 352
Mountain View, CA 94041-1174
Phone: +1 650-386-6723
EMail: v.sharma@ieee.org
George Swallow
Cisco Systems, Inc.
250 Apollo Drive
Chelmsford, MA 01824
Phone: +1 978 244 8143
EMail: swallow@cisco.com
Z. Bo Tang
EMail: botang01@yahoo.com17. Editor's Address 💌
and this is who to message if you have questions about the doc 💜
Lou Berger
Movaz Networks, Inc.
7926 Jones Branch Drive
Suite 615
McLean VA, 22102
Phone: +1 703 847-1801
EMail: lberger@movaz.com18. Full Copyright Statement 🎀
okay, the legal stuff, but it's important so read it 🙈
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement 🌈
huge thanks to everyone keeping the RFC Editor lights on ✨
Funding for the RFC Editor function is currently provided by the Internet Society. 💖
📦 where this page comes from
- ietf: rfc3473 2003-02
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms