RFC 4783

GMPLS - Communication of Alarm Information

📅 published December 2006, from ietf

RFC 4783 📡 GMPLS - Communication of Alarm Information

okay bestie, the header facts first 🎀 This doc was written by L. Berger, Ed. from LabN 💖, it's a Standards Track thing, and it was dated December 2006 📅. It updates RFC 3473 ✨. The header doesn't list anything it obsoletes.

Status of This Memo 🧾

This is an Internet standards track protocol for the Internet community, and the authors are asking for discussion and suggestions for improvements 🫶. To find out where this protocol stands in standardization, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited 💅.

Copyright Notice ©️

Abstract 🦋

so this doc adds an extension to Generalized MPLS (Multi-Protocol Label Switching) signaling so alarm information can actually be communicated 😭 GMPLS signaling already handles controlling alarm reporting, but it doesn't do communicating alarm information. This doc gives a functional description and the GMPLS-RSVP specifics of that extension. It also proposes a modification to the RSVP ERROR_SPEC object 🔥.

This document updates RFC 3473, "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", by adding new, optional protocol elements 🌸. It doesn't change the procedures in RFC 3473, and it's fully backward compatible with them 💜.

Table of Contents 🗂️

1. Introduction ....................................................3
   1.1. Background .................................................3
2. Alarm Information Communication .................................4
3. GMPLS-RSVP Details ..............................................5
   3.1. ALARM_SPEC Objects .........................................5
        3.1.1. IF_ID ALARM_SPEC (and ERROR_SPEC) TLVs ..............5
        3.1.2. Procedures ..........................................9
        3.1.3. Error Codes and Values .............................10
        3.1.4. Backwards Compatibility ............................11
   3.2. Controlling Alarm Communication ...........................11
        3.2.1. Updated Admin_Status Object ........................11
        3.2.2. Procedures .........................................11
   3.3. Message Formats ...........................................12
   3.4. Relationship to GMPLS UNI .................................13
   3.5. Relationship to GMPLS E-NNI ...............................14
4. Security Considerations ........................................14
5. IANA Considerations ............................................15
   5.1. New RSVP Object ...........................................15
   5.2. New Interface ID Types ....................................16
   5.3. New Registry for Admin-Status Object Bit Fields ...........16
   5.4. New RSVP Error Code .......................................16
6. References .....................................................17
   6.1. Normative References ......................................17
   6.2. Informative References ....................................17
7. Acknowledgments ................................................18
8. Contributors ...................................................18

1. Introduction ✨

okay so GMPLS signaling has mechanisms to control alarm reporting for a label switched path (LSP) 💅 You get that through Administrative Status Information [RFC3471] and the Admin_Status object [RFC3473]. The catch is that these mechanisms only decide whether alarm reporting gets inhibited. Nothing in GMPLS provides for communicating alarm information 💀.

The extension in this document defines how alarm information tied to a GMPLS LSP can be communicated along the LSP's path. It works both upstream and downstream 🔥. The point is that the alarm info is then available at every node along the LSP for display and diagnostics, which is iconic 👑. Alarm information might also be useful in certain traffic protection scenarios, but those uses are out of scope for this document 🙈. The communication is supported through a new object, new error/alarm information TLVs, and a new Administrative Status Information bit 🎀.

Alarm communication, as described here, is controllable on a per-LSP basis 🧚. This can be handy in network configurations where not all nodes support communicating alarms to a user for reporting, or where communication is needed for specific applications 🌈. The support of this functionality is optional ✨.

Communicating alarms within GMPLS doesn't change how alarms are processed, and it doesn't change how alarms get communicated outside of GMPLS either 💜. This extension also isn't meant to replace any existing data plane fault propagation techniques 🫶.

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 🌷

Problems with data plane state can usually be detected by the associated data plane hardware components 🔧. Those problems are typically filtered based on elapsed time and local policy 🫧. Problems that make it through the filter are normally raised as alarms 🚨. The alarms are available for operators to display, and they may also be collected centrally through means that are out of scope for this document 🌸.

Not every data plane problem causes the LSP to be torn down right away 🙌. Also, especially in optical transport networks, there may be a desire to keep an LSP and still communicate relevant alarm information even after the data plane state has failed completely 🦋.

Error information can be reported using PathErr, ResvErr, and Notify messages. but those messages usually point to a problem in signaling state, and they can only report one problem at a time 😭 That makes it hard to correlate all the problems tied to a single LSP, and it makes it hard for an operator checking an LSP's status to see a full list of current problems 💀. It doesn't help that there's no way to say a problem has been resolved and its alarm cleared 🙈.

The extensions in this document let an operator or a software component get a full list of current alarms for all the resources used to support an LSP 💖. They also keep that list up-to-date and synchronized with the real alarm status in the network ✨. Finally, the list is made available at every node an LSP traverses 👑.

2. Alarm Information Communication 💌

A new object is introduced to carry alarm information details 🎀. The details look a lot like the error information in the existing ERROR_SPEC objects, so the communication of alarm information uses a format based on the communication of error information 🧁.

The new object is called an ALARM_SPEC object. It has the same format as the ERROR_SPEC object, but it uses a new C-Num so it doesn't trigger error processing semantics 🔥. Additional TLVs are also defined for the IF_ID ALARM_SPEC objects, so they can support communicating info about a specific alarm 🌟. These TLVs might also be useful inside ERROR_SPEC objects, for example when an ERROR_SPEC object is carried within a Notify message 🫶.

the details are similar, but the processing is totally different 💅 Alarm information typically relates to changes in data plane state, without changes in control state 🧠. It's always associated with in-place LSPs 📌. It's also usually most useful to operators and to applications other than control plane protocol processing 💻. Last but not least, error information travels in PathErr, ResvErr, and Notify messages [RFC3473], while alarm information rides in Path and Resv messages 🛤️.

Path messages carry alarm information to downstream nodes, and Resv messages carry alarm information to upstream nodes 🌊. Sending alarm info both ways gives the same visibility into alarm information at any point along an LSP, which is main character energy 👑. Multiple alarms associated with an LSP are supported too. In that case, multiple ALARM_SPEC objects get carried in the Path or Resv messages 🍓.

Adding alarm information to Path and Resv messages is controlled by a new Administrative Status Information bit 🔐. That Administrative Status Information is carried in the Admin_Status object 📦.

3. GMPLS-RSVP Details 🛠️

This section gives the GMPLS-RSVP [RFC3473] specification for communicating alarm information 💖. the communication of alarm information is OPTIONAL 🌱 This section applies to nodes that support communicating alarm information ✨.

3.1. ALARM_SPEC Objects 🎀

The ALARM_SPEC objects use the same format as the ERROR_SPEC object. The difference is their class number, which is 198 and was assigned by IANA in the form 11bbbbbb, per Section 3.1.4 🧚.

Class = 198, C-Type = 1: Reserved. (This C-Type value is defined for ERROR_SPEC, but it isn't defined for use with ALARM_SPEC 🙈.)
Class = 198, C-Type = 2: Reserved. (This C-Type value is defined for ERROR_SPEC, but it isn't defined for use with ALARM_SPEC 🙈.)
IPv4 IF_ID ALARM_SPEC object: Class = 198, C-Type = 3: Definition is the same as the IPv4 IF_ID ERROR_SPEC [RFC3473] 💜.
IPv6 IF_ID ALARM_SPEC object: Class = 198, C-Type = 4: Definition is the same as the IPv6 IF_ID ERROR_SPEC [RFC3473] 🦋.

3.1.1. IF_ID ALARM_SPEC (and ERROR_SPEC) TLVs ✨

okay bestie, this part defines some brand new TLVs (type-length-value bits) for the IPv4 and IPv6 IF_ID ALARM_SPEC objects 💖. They can also be used with the IPv4 and IPv6 IF_ID ERROR_SPEC objects. If you want the original backstory on these values, peep [RFC3471] Section 9.1.1 🧚. Heads up: the length listed below is for the whole TLV, not just the value part. And every TLV in this section is OPTIONAL, so no pressure 🫶.

The defined TLVs MUST follow any interface identifying TLVs. No rules apply to the relative ordering of the TLVs defined in this section. 🎀

Type    Length     Description
----------------------------------
512       8        REFERENCE_COUNT
513       8        SEVERITY
514       8        GLOBAL_TIMESTAMP
515       8        LOCAL_TIMESTAMP
516    variable    ERROR_STRING

The Reference Count TLV 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            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        Reference Count                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Reference Count: 32 bits. This is how many times the reporting node has seen this alarm repeat. This field MUST NOT be set to zero, and TLVs received with this field set to zero MUST be ignored. 🙈

Only one Reference Count TLV may be included in an object.

The Severity TLV 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            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            Reserved                   |Impact |   Severity    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Reserved: 20 bits. This field is reserved, so it's basically a "do not touch" zone 🚫. It MUST be set to zero on generation, MUST be ignored on receipt, and MUST be forwarded unchanged and unexamined by transit nodes.

Impact: 4 bits. This tells you how much the alarm hurts 😭. See [M.20] for a general discussion on classification of failures. The following values are defined in this document, and the details of the semantics may be found in [M.20]:

Value     Definition
-----     ---------------------
  0       Unspecified impact
  1       Non-Service Affecting (Data traffic not interrupted)
  2       Service Affecting (Data traffic is interrupted)

Severity: 8 bits. This one also says how bad the alarm is 🔥. See [RFC3877] and [M.3100] for more information on severity. The following values are defined in this document, and the details of the semantics may be found in [RFC3877] and [M.3100]:

Value     Definition
-----     ----------
  0       Cleared
  1       Indeterminate
  2       Critical
  3       Major
  4       Minor
  5       Warning

Only one Severity TLV may be included in an object.

The Global Timestamp TLV 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            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        Global Timestamp                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Global Timestamp: 32 bits. This is an unsigned fixed-point integer counting the seconds since 00:00:00 UT on 1 January 1970, going by the clock on the node that originates this TLV ⏰. This time MAY include leap seconds if they are used by the local clock, and it SHOULD contain the same time value the node uses when it reports the alarm through other systems (such as within the Management Plane), if global time is used in those reports.

Only one Global Timestamp TLV may be included in an object.

The Local Timestamp TLV 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            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        Local Timestamp                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Local Timestamp: 32 bits. This is the number of seconds on the local system clock at the moment the alarm was detected on the node that originates this TLV. It's only really meaningful in the context of that originating node. For example, it may indicate the number of seconds since the node rebooted, or it may be a local representation of an unsynchronized real-time clock 🕰️.

Only one Local Timestamp TLV may be included in an object.

The Error String TLV 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            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
//          Error String      (NULL padded display string)      //
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Error String: 32 bits minimum (variable). This is a US-ASCII string describing the type of error or alarm 📝. It gets padded out to the next largest 4-byte boundary with null characters. Null padding isn't needed when the string is already 32-bit aligned. The contents of the error string are implementation dependent. See the condition types listed in Appendices of [GR833] for a list of example strings. Note that length includes padding.

Multiple Error String TLVs may be included in an object.

3.1.2. Procedures

This section applies to nodes that support the communication of alarm information 📡. ALARM_SPEC objects are carried in Path and Resv messages. Multiple ALARM_SPEC objects MAY be present.

Nodes that support the extensions in this document SHOULD store any alarm information from received ALARM_SPEC objects for future use 🗂️. All ALARM_SPEC objects received in Path messages SHOULD be passed unmodified downstream in the corresponding Path messages. All ALARM_SPEC objects received in Resv messages SHOULD be passed unmodified upstream in the corresponding Resv messages. ALARM_SPEC objects get merged into transmitted Resv messages by including a copy of all ALARM_SPEC objects received in corresponding Resv Messages.

To advertise local alarm information, a node generates an ALARM_SPEC object for each alarm and adds it to both the Path and Resv messages for the impacted LSP 📣.

In all cases, appropriate Error Node Address, Error Code, and Error Values MUST be set (see below for a discussion on Error Code and Error Values) ✅. The InPlace and NotGuilty flags only mean something in ERROR_SPEC objects, so they SHOULD NOT be set. TLVs SHOULD be included in the ALARM_SPEC object to identify the interface, if any, associated with the alarm. The TLVs defined in [RFC3471] for identifying interfaces in the IF_ID ERROR_SPEC object [RFC3473] SHOULD be used for this purpose. Be careful though: TLVs type 4 and 5 (component interfaces) are deprecated by [RFC4201] and SHOULD NOT be used 🚨. TLVs SHOULD also be included to indicate the severity (Severity TLV), the time (Global Timestamp and/or Local Timestamp TLVs), and a (brief) string (Error String TLV) associated with the alarm. The reference count TLV MAY also be included to indicate the number of times an alarm has been repeated at the reporting node. ALARM_SPEC objects received from other nodes are not impacted by the addition of local ALARM_SPEC objects, i.e., they keep being processed as described above. Which alarm or alarms get advertised and which get left out is a local policy matter, and it may be configurable by the user 🎛️.

There are two ways to indicate time ⏳. A global timestamp TLV gives an absolute time reference for when an alarm happened. A local timestamp TLV gives a time reference for when an alarm happened that's relative to other information the node advertises. The global timestamp SHOULD be used on nodes that maintain an absolute time reference. Both timestamp TLVs MAY be used simultaneously.

Note, ALARM_SPEC objects SHOULD NOT be added to the Path and Resv states of LSPs that are in an "alarm communication inhibited" state 🙅. ALARM_SPEC objects MAY be added to the state of LSPs that are in an "administratively down" state. These states are indicated by the I and A bits of the Admin_Status object; see Section 3.2.

To remove local alarm information, a node simply takes the matching locally generated ALARM_SPEC objects out of the outgoing Path and Resv messages 🧹. A node MAY modify a locally generated ALARM_SPEC object.

Normal refresh and trigger message processing applies to Path or Resv messages that contain ALARM_SPEC objects 🔄. Changes in ALARM_SPEC objects from one message to the next may include a modification in the contents of a specific ALARM_SPEC object, or a change in the number of ALARM_SPEC objects present. All changes in ALARM_SPEC objects SHOULD be processed as trigger messages.

Failure to follow the above directives, in particular the ones labeled "SHOULD" and "SHOULD NOT", may result in the alarm information not being properly or fully communicated 💀. Don't skip those ones, bestie!

3.1.3. Error Codes and Values

The Error Codes and Values used in ALARM_SPEC objects are the same as the ones used in ERROR_SPEC objects 🔁. New Error Code values for use with both ERROR_SPEC and ALARM_SPEC objects may be assigned to support alarm types defined by other standards.

In this document we define one new Error Code 🎉. The Error Code uses the value 31 and is referred to as "Alarms". The values used in the Error Values field when the Error Code is "Alarms" are the same as the values defined in the IANAItuProbableCause Textual Convention of IANA-ITU-ALARM-TC-MIB in the Alarm MIB [RFC3877]. Note that these values are managed by IANA; see http://www.iana.org. 👑

3.1.4. Backwards Compatibility 🎀

okay so supporting ALARM_SPEC objects is totally OPTIONAL 🫶 nodes that don't support them still do the right thing. Per [RFC2205], they just pass the objects straight through, unmodified 🦋, because the ALARM_SPEC object has a C-Num of the form 11bbbbbb.

This means alarm info can be collected and examined in a network that's a mix of nodes, some that understand alarms and some that don't. Iconic for compatibility 💅

3.2. Controlling Alarm Communication 🌸

okay this is the bit where we control alarm comms 👑 It's all handled through the Administrative Status Information carried in the Admin_Status object. We're adding a new bit called the I bit, which says when alarm communication should be inhibited ✨ Defining this bit doesn't change the procedures from Section 7 of [RFC3473], so nothing else gets rewritten.

3.2.1. Updated Admin_Status Object 💖

the Admin_Status object gets a glow-up to include the I bit 🧚

       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                   |I| |T|A|D|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Inhibit Alarm Communication (I): 1 bit 🔥 When set, it means alarm communication is disabled for the LSP, and nodes SHOULD NOT add local alarm information.

see Section 7.1 of [RFC3473] for the rest of the bits 🎀

3.2.2. Procedures 💅

the I bit can be set and cleared using the procedures in Sections 7.2 and 7.3 of [RFC3473] 🦋 A node that receives (or generates) an Admin_Status object with the A or I bits set (1) SHOULD remove all locally generated alarm information from the matching LSP's outgoing Path and Resv messages 🧹 And when a node receives (or generates) an Admin_Status object with the A and I bits clear (0) and there's local alarm info around, it SHOULD add that local alarm info to the matching LSP's outgoing Path and Resv messages ✨

the processing of non-locally generated ALARM_SPEC objects MUST NOT be impacted by the Admin_Status object's contents 😭 literally, received ALARM_SPEC objects MUST be forwarded unchanged, no matter what the I and A bits are set to, whether received or transmitted 🫶 Also, per [RFC3473], if the Admin_Status object is missing, that's the same as receiving an object with all values set to zero (0) 💜

I bit related processing behavior MAY be overridden locally based on configuration 🌈

when generating Notify messages for LSPs with the I bit set, the TLVs described in this document MAY be added to the ERROR_SPEC object sent in the Notify message ⭐

3.3. Message Formats 🧚

this section shows the RSVP message formats as modified by this document 💖 The formats in [RFC3473] were the starting point, and the objects are listed in suggested ordering 🎀

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> ... ]
                          [ <ALARM_SPEC> ... ]
                          <sender descriptor>

<sender descriptor> is not modified by this document 🍓

the format of a Resv message is as follows:

 <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> ... ]
                          [ <ALARM_SPEC> ... ]
                          <STYLE> <flow descriptor list>

<flow descriptor list> is not modified by this document 🌸

3.4. Relationship to GMPLS UNI 🦋

okay so [RFC4208] explains how GMPLS can be used in an overlay model to give us a user-to-network interface (UNI) 🫶 In this setup, you can put restrictions on the info signaled between an edge-node and a core-node 🔒 That lets the core network limit what's visible outside the core. You might do this for confidentiality, privacy, or security, or just for operational reasons, like if the info only matters inside the core network 👑

the extensions here are candidates for filtering as described in [RFC4208]. specifically:

An ingress or egress core-node MAY filter alarms from the GMPLS core to a client-node UNI LSP. That might protect info about the core network, or show that the core is doing or has finished recovery actions for the GMPLS LSP 🛡️
An ingress or egress core-node MAY modify alarms from the GMPLS core when sending to a client-node UNI LSP. This can help the UNI client understand the failure and its effect on the data plane, so it can take corrective action in a more appropriate way 💅
Similarly, an egress core-node MAY choose not to request alarm reporting on Path messages it sends downstream to the overlay network 🌈

3.5. Relationship to GMPLS E-NNI 🧚

GMPLS may be used at the external network-to-network interface (E-NNI), see [ASON-APPL] 💖 At this interface, restrictions can be placed on the info signaled between an egress and an ingress core-node 🔐

this restriction lets the ingress core network limit what's visible outside its core. Again, that can be for confidentiality, privacy, or security, or for operational reasons if the info only applies inside the core network ✨

the extensions here are candidates for filtering as described in [ASON-APPL]. the key points:

An ingress or egress core-node MAY filter internal core network alarms. This can protect info about the internal network, or show the core is doing or has finished recovery actions for this LSP 🎀
An ingress or egress core-node MAY modify internal core network alarms. That can help the peering E-NNI (i.e., the egress core-node) understand the failure and its effect on the data plane, and take corrective actions in a more appropriate manner, or prolong the generated alarms upstream/downstream as appropriated 🦋
Similarly, an egress/ingress core-node MAY choose not to request alarm reporting on Path messages it sends downstream 🫶

4. Security Considerations 🔐

some operators think alarm info is sensitive 😭 To support those environments, implementations SHOULD allow the user to disable the generation of ALARM_SPEC objects, or to filter or correlate them at domain boundaries 🛡️

this document introduces no additional security considerations 💅 See [RFC3473] for the relevant ones.

It's worth noting that if the security considerations of [RFC3473] get breached, alarm info may be spoofed 👀 That would be at most annoying and cause slight degradation of control plane performance, since the details are just for information and don't trigger protocol actions beyond exchanging messages to convey the info 🙈 But if protocol security can be broken enough to spoof alarm info, then way more interesting and exciting damage could happen by spoofing other elements of the protocol messages 💀🔥

5. IANA Considerations 🧚

IANA handles assignment of new values for the namespaces defined in this document and reviewed in this section 🌸

5.1. New RSVP Object ✨

IANA made the following assignments in the "Class Names, Class Numbers, and Class Types" section of the "RSVP PARAMETERS" registry, located at http://www.iana.org/assignments/rsvp-parameters 💖

a new class named ALARM_SPEC (198) was created in the 11bbbbbb range with the following values:

Class = 198, C-Type = 1 RFC 4783 Reserved. (C-Type value defined for ERROR_SPEC, but is not defined for use with ALARM_SPEC.)
Class = 198, C-Type = 2 RFC 4783 Reserved. (C-Type value defined for ERROR_SPEC, but is not defined for use with ALARM_SPEC.)
IPv4 IF_ID ALARM_SPEC object: Class = 198, C-Type = 3 RFC 4783 Definition same as IPv4 IF_ID ERROR_SPEC [RFC3473].
IPv6 IF_ID ALARM_SPEC object: Class = 198, C-Type = 4 RFC 4783 Definition same as IPv6 IF_ID ERROR_SPEC [RFC3473].

the ALARM_SPEC object uses the Error Code and Error Values from the ERROR_SPEC object 🎀

5.2. New Interface ID Types 🦋

IANA made these assignments in the "Interface_ID Types" section of the "GMPLS Signaling Parameters" registry, located at http://www.iana.org/assignments/gmpls-sig-parameters 🫶

   512 8 REFERENCE_COUNT     RFC 4783
   513 8 SEVERITY            RFC 4783
   514 8 GLOBAL_TIMESTAMP    RFC 4783
   515 8 LOCAL_TIMESTAMP     RFC 4783
   516 variable ERROR_STRING RFC 4783

5.3. New Registry for Admin-Status Object Bit Fields 🌈

IANA created a brand new section titled "Administrative Status Information Flags" in the "GMPLS Signaling Parameters" registry, located at http://www.iana.org/assignments/gmpls-sig-parameters, and made these assignments 🧚

   Value       Name                              Reference
   ----------- -------------------------------- -----------------
   0x80000000  Reflect (R)                      [RFC3473/RFC3471]
   0x00000010  Inhibit Alarm Communication (I)  RFC 4783
   0x00000004  Testing (T)                      [RFC3473/RFC3471]
   0x00000002  Administratively down (A)        [RFC3473/RFC3471]
   0x00000001  Deletion in progress (D)         [RFC3473/RFC3471]

5.4. New RSVP Error Code ⭐

IANA made these assignments in the "Error Codes and Values" section of the "RSVP PARAMETERS" registry, located at http://www.iana.org/assignments/rsvp-parameters 💜

31 Alarms RFC 4783

the Error Value sub-codes for this Error Code have values and meanings identical to the values and meanings defined in the IANAItuProbableCause Textual Convention of IANA-ITU-ALARM-TC-MIB in the Alarm MIB [RFC3877] 🫶 Note that these values are already managed the IANA.

6. References 📚

6.1. Normative References

okay so these are the must-read docs 📚 the spec leans on, so you need them to really get it 🎀

[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.
[RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003.
[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC3877] Chisholm, S. and D. Romascanu, "Alarm Management Information Base (MIB)", RFC 3877, September 2004.
[M.3100] ITU Recommendation M.3100, "Generic Network Information Model", 1995.

6.2. Informative References

these ones are extra reading 🦋 nice to have, not strictly needed to build the thing ✨

[RFC4201] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling in MPLS Traffic Engineering (TE)", RFC 4201, October 2005.
[M.20] ITU-T, "MAINTENANCE PHILOSOPHY FOR TELECOMMUNICATION NETWORKS", Recommendation M.20, October 1992.
[GR833] Bellcore, "Network Maintenance: Network Element and Transport Surveillance Messages" (GR-833-CORE), Issue 3, February 1999.
[RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter, "Generalized Multiprotocol Label Switching (GMPLS) User-Network Interface (UNI): Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Support for the Overlay Model", RFC 4208, October 2005.
[ASON-APPL] Papadimitriou, D., et al., "Generalized MPLS (GMPLS) RSVP-TE signaling usage in support of Automatically Switched Optical Network (ASON)", Work in Progress, July 2005.

7. Acknowledgments 🌸

big thank-yous 🫶 to everyone who gave comments and input 💖 that includes Wes Doonan, Bert Wijnen (for the DISMAN reference), and Tom Petch (for getting the DISMAN WG chat going) 🧚 and also David Black, Lars Eggert, Russ Housley, Dan Romascanu, and Magnus Westerlund for their super valuable notes 👑

8. Contributors 💜

the contributors are listed alphabetically, bestie, and this is the whole squad 🎀

   Contributors are listed in alphabetical order:

   Deborah Brungard
   AT&T Labs, Room MT D1-3C22
   200 Laurel Avenue
   Middletown, NJ 07748, USA
   Phone:  (732) 420-1573
   EMail:  dbrungard@att.com


   Igor Bryskin                               Adrian Farrel
   Movaz Networks, Inc.                       Old Dog Consulting
   7926 Jones Branch Drive
   Suite 615
   McLean VA, 22102, USA                      Phone: +44 (0) 1978 860944
   EMail:  ibryskin@movaz.com                 EMail: adrian@olddog.co.uk


   Dimitri Papadimitriou (Alcatel)            Arun Satyanarayana
   Francis Wellesplein 1                      Cisco Systems, Inc
   B-2018 Antwerpen, Belgium                  170 West Tasman Dr.
                                              San Jose, CA  95134 USA
   Phone:  +32 3 240-8491                     Phone: +1 408 853-3206
   EMail:  dimitri.papadimitriou@alcatel.be   EMail: asatyana@cisco.com

Editor's Address 🦋

the editor is Lou Berger from LabN Consulting, L.L.C. 💅

   Lou Berger
   LabN Consulting, L.L.C.

   Phone:  +1 301-468-9228
   EMail:  lberger@labn.net

Full Copyright Statement 📜

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST, AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.

Intellectual Property ⚖️

the IETF takes no position on whether any IPR claims cover the tech in this doc, or whether licenses are available, and it hasn't done its own digging for those rights 🙈 info about the procedures for rights in RFCs lives in BCP 78 and BCP 79.

copies of IPR disclosures sent to the IETF Secretariat, any licence assurances, or the results of an attempt to get a general licence for implementers or users can be found in the IETF online IPR repository at http://www.ietf.org/ipr.

the IETF also invites anyone to flag any copyrights, patents, patent applications, or other proprietary rights that might cover tech needed to implement this standard. send that info to the IETF at ietf-ipr@ietf.org 💌

Acknowledgement 🌈

funding for the RFC Editor function is currently provided by the Internet Society 🫶

📦 where this page comes from

ietf: rfc4783 2006-12
💖 girlified by claude-haiku-5-5 on 2026-10-16: a language model's rewrite of the original, under its terms