GMPLS - Communication of Alarm Information
RFC 4783
Document | Type |
RFC - Proposed Standard
(December 2006; Errata)
Updates RFC 3473
|
|
---|---|---|---|
Last updated | 2018-12-20 | ||
Replaces | draft-berger-ccamp-gmpls-alarm-spec | ||
Stream | IETF | ||
Formats | plain text html pdf htmlized with errata bibtex | ||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 4783 (Proposed Standard) | |
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | Ross Callon | ||
Send notices to | (None) |
Network Working Group L. Berger, Ed. Request for Comments: 4783 LabN Updates: 3473 December 2006 Category: Standards Track GMPLS - Communication of Alarm Information Status of This Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The IETF Trust (2006). Abstract This document describes an extension to Generalized MPLS (Multi- Protocol Label Switching) signaling to support communication of alarm information. GMPLS signaling already supports the control of alarm reporting, but not the communication of alarm information. This document presents both a functional description and GMPLS-RSVP specifics of such an extension. This document also proposes modification of 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", through the addition of new, optional protocol elements. It does not change, and is fully backward compatible with, the procedures specified in RFC 3473. Berger Standards Track [Page 1] RFC 4783 GMPLS - Communication of Alarm Information December 2006 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 Berger Standards Track [Page 2] RFC 4783 GMPLS - Communication of Alarm Information December 2006 1. Introduction GMPLS signaling provides mechanisms that can be used to control the reporting of alarms associated with a label switched path (LSP). This support is provided via Administrative Status Information [RFC3471] and the Admin_Status object [RFC3473]. These mechanisms only control if alarm reporting is inhibited. No provision is made for communication of alarm information within GMPLS. The extension described in this document defines how the alarm information associated with a GMPLS LSP may be communicated along the path of the LSP. Communication both upstream and downstream is supported. The value in communicating such alarm information is that this information is then available at every node along the LSP for display and diagnostic purposes. Alarm information may also be useful in certain traffic protection scenarios, but such uses are out of the scope of this document. Alarm communication is supported via a new object, new error/alarm information TLVs, and a new Administrative Status Information bit. The communication of alarms, as described in this document, is controllable on a per-LSP basis. Such communication may be usefulShow full document text