GMPLS - Communication of Alarm Information
RFC 4783
| Document | Type |
RFC - Proposed Standard
(December 2006; Errata)
Updates RFC 3473
|
|
|---|---|---|---|
| Last updated | 2015-10-14 | ||
| Replaces | draft-berger-ccamp-gmpls-alarm-spec | ||
| Stream | IETF | ||
| Formats | plain text pdf html 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
Show full document text