draft-ietf-ccamp-gmpls-alarm-spec-06.txt | rfc4783.txt | |||
---|---|---|---|---|
Internet Draft Lou Berger - Editor (LabN) | ||||
Updates: 3473 | Network Working Group L. Berger, Ed. | |||
Request for Comments: 4783 LabN | ||||
Updates: 3473 December 2006 | ||||
Category: Standards Track | Category: Standards Track | |||
September 2006 | ||||
GMPLS - Communication of Alarm Information | GMPLS - Communication of Alarm Information | |||
draft-ietf-ccamp-gmpls-alarm-spec-06.txt | Status of This Memo | |||
Status of this Memo | ||||
By submitting this Internet-Draft, each author represents that any | ||||
applicable patent or other IPR claims of which he or she is aware | ||||
have been or will be disclosed, and any of which he or she becomes | ||||
aware will be disclosed, in accordance with Section 6 of BCP 79. | ||||
Internet-Drafts are working documents of the Internet Engineering | ||||
Task Force (IETF), its areas, and its working groups. Note that | ||||
other groups may also distribute working documents as Internet- | ||||
Drafts. | ||||
Internet-Drafts are draft documents valid for a maximum of six months | This document specifies an Internet standards track protocol for the | |||
and may be updated, replaced, or obsoleted by other documents at any | Internet community, and requests discussion and suggestions for | |||
time. It is inappropriate to use Internet-Drafts as reference | improvements. Please refer to the current edition of the "Internet | |||
material or to cite them other than as "work in progress." | Official Protocol Standards" (STD 1) for the standardization state | |||
and status of this protocol. Distribution of this memo is unlimited. | ||||
The list of current Internet-Drafts can be accessed at | Copyright Notice | |||
http://www.ietf.org/1id-abstracts.html | ||||
The list of Internet-Draft Shadow Directories can be accessed at | Copyright (C) The IETF Trust (2006). | |||
http://www.ietf.org/shadow.html | ||||
Abstract | Abstract | |||
This document describes an extension to Generalized MPLS (Multi- | This document describes an extension to Generalized MPLS (Multi- | |||
Protocol Label Switching) signaling to support communication of alarm | Protocol Label Switching) signaling to support communication of alarm | |||
information. GMPLS signaling already supports the control of alarm | information. GMPLS signaling already supports the control of alarm | |||
reporting, but not the communication of alarm information. This | reporting, but not the communication of alarm information. This | |||
document presents both a functional description and GMPLS-RSVP | document presents both a functional description and GMPLS-RSVP | |||
specifics of such an extension. This document also proposes | specifics of such an extension. This document also proposes | |||
modification of the RSVP ERROR_SPEC object. | modification of the RSVP ERROR_SPEC object. | |||
This document updates RFC 3473 "Generalized Multi-Protocol Label | This document updates RFC 3473, "Generalized Multi-Protocol Label | |||
Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic | Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic | |||
Engineering (RSVP-TE) Extensions" through the addition of new, | Engineering (RSVP-TE) Extensions", through the addition of new, | |||
optional protocol elements. It does not change, and is fully backward | optional protocol elements. It does not change, and is fully | |||
compatible with the procedures specified in RFC 3473. | backward compatible with, the procedures specified in RFC 3473. | |||
Contents | Table of Contents | |||
1 Introduction .............................................. 3 | 1. Introduction ....................................................3 | |||
1.1 Background ................................................ 3 | 1.1. Background .................................................3 | |||
2 Alarm Information Communication ........................... 4 | 2. Alarm Information Communication .................................4 | |||
3 GMPLS-RSVP Details ........................................ 5 | 3. GMPLS-RSVP Details ..............................................5 | |||
3.1 ALARM_SPEC Objects ........................................ 5 | 3.1. ALARM_SPEC Objects .........................................5 | |||
3.1.1 IF_ID ALARM_SPEC (and ERROR_SPEC) TLVs .................... 6 | 3.1.1. IF_ID ALARM_SPEC (and ERROR_SPEC) TLVs ..............5 | |||
3.1.2 Procedures ................................................ 9 | 3.1.2. Procedures ..........................................9 | |||
3.1.3 Error Codes and Values .................................... 11 | 3.1.3. Error Codes and Values .............................10 | |||
3.1.4 Backwards Compatibility ................................... 11 | 3.1.4. Backwards Compatibility ............................11 | |||
3.2 Controlling Alarm Communication ........................... 11 | 3.2. Controlling Alarm Communication ...........................11 | |||
3.2.1 Updated Admin Status Object ............................... 12 | 3.2.1. Updated Admin_Status Object ........................11 | |||
3.2.2 Procedures ................................................ 12 | 3.2.2. Procedures .........................................11 | |||
3.3 Message Formats ........................................... 13 | 3.3. Message Formats ...........................................12 | |||
3.4 Relationship to GMPLS UNI ................................. 14 | 3.4. Relationship to GMPLS UNI .................................13 | |||
3.5 Relationship to GMPLS E-NNI .............................. 14 | 3.5. Relationship to GMPLS E-NNI ...............................14 | |||
4 Acknowledgments ........................................... 15 | 4. Security Considerations ........................................14 | |||
5 Security Considerations ................................... 15 | 5. IANA Considerations ............................................15 | |||
6 IANA Considerations ....................................... 16 | 5.1. New RSVP Object ...........................................15 | |||
6.1 New RSVP Object ........................................... 16 | 5.2. New Interface ID Types ....................................16 | |||
6.2 New Interface ID Types .................................... 16 | 5.3. New Registry for Admin-Status Object Bit Fields ...........16 | |||
6.3 New Registry for Admin-Status Object Bit Fields ........... 17 | 5.4. New RSVP Error Code .......................................16 | |||
6.4 New RSVP Error Code ....................................... 17 | 6. References .....................................................17 | |||
7 References ................................................ 18 | 6.1. Normative References ......................................17 | |||
7.1 Normative References ...................................... 18 | 6.2. Informative References ....................................17 | |||
7.2 Informative References .................................... 18 | 7. Acknowledgments ................................................18 | |||
8 Contributors .............................................. 19 | 8. Contributors ...................................................18 | |||
9 Contact Address ........................................... 19 | ||||
10 Full Copyright Statement .................................. 20 | ||||
11 Intellectual Property ..................................... 20 | ||||
1. Introduction | 1. Introduction | |||
GMPLS Signaling provides mechanisms that can be used to control the | GMPLS signaling provides mechanisms that can be used to control the | |||
reporting of alarms associated with an LSP. This support is provided | reporting of alarms associated with a label switched path (LSP). | |||
via Administrative Status Information [RFC3471] and the Admin_Status | This support is provided via Administrative Status Information | |||
object [RFC3473]. These mechanisms only control if alarm reporting | [RFC3471] and the Admin_Status object [RFC3473]. These mechanisms | |||
is inhibited. No provision is made for communication of alarm | only control if alarm reporting is inhibited. No provision is made | |||
information within GMPLS. | for communication of alarm information within GMPLS. | |||
The extension described in this document defines how the alarm | The extension described in this document defines how the alarm | |||
information associated with a GMPLS label-switched path (LSP) may be | information associated with a GMPLS LSP may be communicated along the | |||
communicated along the path of the LSP. Communication both upstream | path of the LSP. Communication both upstream and downstream is | |||
and downstream is supported. The value in communicating such alarm | supported. The value in communicating such alarm information is that | |||
information is that this information is then available at every node | this information is then available at every node along the LSP for | |||
along the LSP for display and diagnostic purposes. Alarm information | display and diagnostic purposes. Alarm information may also be | |||
may also be useful in certain traffic protection scenarios, but such | useful in certain traffic protection scenarios, but such uses are out | |||
uses are out of scope of this document. Alarm communication is | of the scope of this document. Alarm communication is supported via | |||
supported via a new object, new error/alarm information TLVs, and a | a new object, new error/alarm information TLVs, and a new | |||
new Administrative Status Information bit. | Administrative Status Information bit. | |||
The communication of alarms, as described in this document, is | The communication of alarms, as described in this document, is | |||
controllable on a per LSP basis. Such communication may be useful | controllable on a per-LSP basis. Such communication may be useful | |||
within network configurations where not all nodes support | within network configurations where not all nodes support | |||
communication to a user for reporting of alarms and/or communication | communication to a user for reporting of alarms and/or communication | |||
is needed to support specific applications. The support of this | is needed to support specific applications. The support of this | |||
functionality is optional. | functionality is optional. | |||
The communication of alarms within GMPLS does not imply any | The communication of alarms within GMPLS does not imply any | |||
modification in behavior of processing of alarms, or for the | modification in behavior of processing of alarms, or for the | |||
communication of alarms outside of GMPLS. Additionally, the | communication of alarms outside of GMPLS. Additionally, the | |||
extension described in this document is not intended to replace any | extension described in this document is not intended to replace any | |||
(existing) data plane fault propagation techniques. | (existing) data plane fault propagation techniques. | |||
skipping to change at page 4, line 10 | skipping to change at page 4, line 10 | |||
that pass the filtering process are normally raised as alarms. These | that pass the filtering process are normally raised as alarms. These | |||
alarms are available for display to operators. They also may be | alarms are available for display to operators. They also may be | |||
collected centrally through means that are out of the scope of this | collected centrally through means that are out of the scope of this | |||
document. | document. | |||
Not all data plane problems cause the LSP to be immediately torn | Not all data plane problems cause the LSP to be immediately torn | |||
down. Further, there may be a desire, particularly in optical | down. Further, there may be a desire, particularly in optical | |||
transport networks, to retain an LSP and communicate relevant alarm | transport networks, to retain an LSP and communicate relevant alarm | |||
information even when the data plane state has failed completely. | information even when the data plane state has failed completely. | |||
Although error information can be reported using PathErr, ResvErr and | Although error information can be reported using PathErr, ResvErr, | |||
Notify messages, these messages typically indicate a problem in | and Notify messages, these messages typically indicate a problem in | |||
signaling state and can only report one problem at at a time. This | signaling state and can only report one problem at a time. This | |||
makes it hard to correlate all of the problems that may be associated | makes it hard to correlate all of the problems that may be associated | |||
with a single LSP and to allow an operator examining the status of an | with a single LSP and to allow an operator examining the status of an | |||
LSP to view a full list of current problems. This situation is | LSP to view a full list of current problems. This situation is | |||
exacerbated by the absence of any way to communicate that a problem | exacerbated by the absence of any way to communicate that a problem | |||
has been resolved and a corresponding alarm cleared. | has been resolved and a corresponding alarm cleared. | |||
The extensions defined in this document allow an operator or a | The extensions defined in this document allow an operator or a | |||
software component to obtain a full list of current alarms associated | software component to obtain a full list of current alarms associated | |||
with all of the resources used to support an LSP. The extensions | with all of the resources used to support an LSP. The extensions | |||
also ensure that this list is kept up-to-date and synchronized with | also ensure that this list is kept up-to-date and synchronized with | |||
skipping to change at page 4, line 50 | skipping to change at page 4, line 50 | |||
included in ERROR_SPEC objects, e.g., when the ERROR_SPEC object is | included in ERROR_SPEC objects, e.g., when the ERROR_SPEC object is | |||
carried within a Notify message. | carried within a Notify message. | |||
While the details of alarm information are like the details of | While the details of alarm information are like the details of | |||
existing error communication, the semantics of processing differ. | existing error communication, the semantics of processing differ. | |||
Alarm information will typically relate to changes in data plane | Alarm information will typically relate to changes in data plane | |||
state, without changes in control state. Alarm information will | state, without changes in control state. Alarm information will | |||
always be associated with in-place LSPs. Such information will also | always be associated with in-place LSPs. Such information will also | |||
typically be most useful to operators and applications other than | typically be most useful to operators and applications other than | |||
control plane protocol processing. Finally, while error information | control plane protocol processing. Finally, while error information | |||
is communicated within PathErr, ResvErr and Notify messages | is communicated within PathErr, ResvErr, and Notify messages | |||
[RFC3473], alarm information will be carried within Path and Resv | [RFC3473], alarm information will be carried within Path and Resv | |||
messages. | messages. | |||
Path messages are used to carry alarm information to downstream nodes | Path messages are used to carry alarm information to downstream | |||
and Resv messages are used to carry alarm information to upstream | nodes, and Resv messages are used to carry alarm information to | |||
nodes. The intent of sending alarm information both upstream and | upstream nodes. The intent of sending alarm information both | |||
downstream is to provide the same visibility to alarm information at | upstream and downstream is to provide the same visibility to alarm | |||
any point along an LSP. The communication of multiple alarms | information at any point along an LSP. The communication of multiple | |||
associated with an LSP is supported. In this case, multiple | alarms associated with an LSP is supported. In this case, multiple | |||
ALARM_SPEC objects will be carried in the Path or Resv messages. | ALARM_SPEC objects will be carried in the Path or Resv messages. | |||
The addition of alarm information to Path and Resv messages is | The addition of alarm information to Path and Resv messages is | |||
controlled via a new Administrative Status Information bit. | controlled via a new Administrative Status Information bit. | |||
Administrative Status Information is carried in the Admin_Status | Administrative Status Information is carried in the Admin_Status | |||
object. | object. | |||
3. GMPLS-RSVP Details | 3. GMPLS-RSVP Details | |||
This section provides the GMPLS-RSVP [RFC3473] specification for | This section provides the GMPLS-RSVP [RFC3473] specification for | |||
communication of alarm information. The communication of alarm | communication of alarm information. The communication of alarm | |||
information is OPTIONAL. This section applies to nodes that support | information is OPTIONAL. This section applies to nodes that support | |||
communication of alarm information. | communication of alarm information. | |||
3.1. ALARM_SPEC Objects | 3.1. ALARM_SPEC Objects | |||
The ALARM_SPEC objects use the same format as the ERROR_SPEC object, | The ALARM_SPEC objects use the same format as the ERROR_SPEC object, | |||
but with class number of TBA (to be assigned by IANA in the form | but with class number of 198 (assigned by IANA in the form 11bbbbbb, | |||
11bbbbbb, per Section 3.1.4). | per Section 3.1.4). | |||
o Class = TBA, C-Type = 1 | o Class = 198, C-Type = 1 | |||
Reserved. (C-Type value defined for ERROR_SPEC, but is not defined | Reserved. (C-Type value defined for ERROR_SPEC, but is not | |||
for use with ALARM_SPEC.) | defined for use with ALARM_SPEC.) | |||
o Class = TBA, C-Type = 2 | o Class = 198, C-Type = 2 | |||
Reserved. (C-Type value defined for ERROR_SPEC, but is not defined | Reserved. (C-Type value defined for ERROR_SPEC, but is not | |||
for use with ALARM_SPEC.) | defined for use with ALARM_SPEC.) | |||
o IPv4 IF_ID ALARM_SPEC object: Class = TBA, C-Type = 3 | o IPv4 IF_ID ALARM_SPEC object: Class = 198, C-Type = 3 | |||
Definition same as IPv4 IF_ID ERROR_SPEC [RFC3473]. | Definition same as IPv4 IF_ID ERROR_SPEC [RFC3473]. | |||
o IPv6 IF_ID ALARM_SPEC object: Class = TBA, C-Type = 4 | o IPv6 IF_ID ALARM_SPEC object: Class = 198, C-Type = 4 | |||
Definition same as IPv6 IF_ID ERROR_SPEC [RFC3473]. | Definition same as IPv6 IF_ID ERROR_SPEC [RFC3473]. | |||
3.1.1. IF_ID ALARM_SPEC (and ERROR_SPEC) TLVs | 3.1.1. IF_ID ALARM_SPEC (and ERROR_SPEC) TLVs | |||
The following new TLVs are defined for use with the IPv4 and IPv6 | The following new TLVs are defined for use with the IPv4 and IPv6 | |||
IF_ID ALARM_SPEC objects. They may also be used with the IPv4 and | IF_ID ALARM_SPEC objects. They may also be used with the IPv4 and | |||
IPv6 IF_ID ERROR_SPEC objects. See [RFC3471] section 9.1.1 for the | IPv6 IF_ID ERROR_SPEC objects. See [RFC3471] Section 9.1.1 for the | |||
original definition of these values. Note the length provided below | original definition of these values. Note the length provided below | |||
is for the total TLV. All TLVs defined in this section are OPTIONAL. | is for the total TLV. All TLVs defined in this section are OPTIONAL. | |||
The defined TLVs MUST follow any interface identifying TLVs. No | The defined TLVs MUST follow any interface identifying TLVs. No | |||
rules apply to the relative ordering of the TLVs defined in this | rules apply to the relative ordering of the TLVs defined in this | |||
section. | section. | |||
[Note: Type values are TBA (to be assigned) by IANA] | ||||
Type Length Description | Type Length Description | |||
---------------------------------- | ---------------------------------- | |||
512 8 REFERENCE_COUNT | 512 8 REFERENCE_COUNT | |||
513 8 SEVERITY | 513 8 SEVERITY | |||
514 8 GLOBAL_TIMESTAMP | 514 8 GLOBAL_TIMESTAMP | |||
515 8 LOCAL_TIMESTAMP | 515 8 LOCAL_TIMESTAMP | |||
516 variable ERROR_STRING | 516 variable ERROR_STRING | |||
The Reference Count TLV has the following format: | The Reference Count TLV has the following format: | |||
skipping to change at page 6, line 39 | skipping to change at page 6, line 30 | |||
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 | 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 | | | Type | Length | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Reference Count | | | Reference Count | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
Reference Count: 32 bits | Reference Count: 32 bits | |||
The number of times this alarm has been repeated as determined | The number of times this alarm has been repeated as determined | |||
by the reporting node. This field MUST NOT be set to zero and | by the reporting node. This field MUST NOT be set to zero, and | |||
TLVs received with this field set to zero MUST be ignored. | TLVs received with this field set to zero MUST be ignored. | |||
Only one Reference Count TLV may be included in an object. | Only one Reference Count TLV may be included in an object. | |||
The Severity TLV has the following format: | The Severity TLV has the following format: | |||
0 1 2 3 | 0 1 2 3 | |||
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | 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 | | | Type | Length | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Reserved |Impact | Severity | | | Reserved |Impact | Severity | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
Reserved: 20 bits | Reserved: 20 bits | |||
This field is reserved. It MUST be set to zero on generation, | This field is reserved. It MUST be set to zero on generation, | |||
MUST be ignored on receipt and MUST be forwarded unchanged and | MUST be ignored on receipt, and MUST be forwarded unchanged and | |||
unexamined by transit nodes. | unexamined by transit nodes. | |||
Impact: 4 bits | Impact: 4 bits | |||
Indicates the impact of the alarm indicated in the TLV. See | Indicates the impact of the alarm indicated in the TLV. See | |||
[M.20] for a general discussion on classification of failures. | [M.20] for a general discussion on classification of failures. | |||
The following values are defined in this document. The details | The following values are defined in this document. The details | |||
of the semantics may be found in [M.20]. | of the semantics may be found in [M.20]. | |||
Value Definition | Value Definition | |||
skipping to change at page 9, line 16 | skipping to change at page 9, line 4 | |||
0 1 2 3 | 0 1 2 3 | |||
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | 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 | | | Type | Length | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | | | | | |||
// Error String (NULL padded display string) // | // Error String (NULL padded display string) // | |||
| | | | | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
Error String: 32 bits minimum (variable) | Error String: 32 bits minimum (variable) | |||
A string of characters in US-ASCII, representing the type of | A string of characters in US-ASCII, representing the type of | |||
error/alarm. This string is padded to the next largest 4 byte | error/alarm. This string is padded to the next largest 4-byte | |||
boundary using null characters. Null padding is not required | boundary using null characters. Null padding is not required | |||
when the string is 32-bit aligned. The contents of error | when the string is 32-bit aligned. The contents of error | |||
string are implementation dependent. See the condition types | string are implementation dependent. See the condition types | |||
listed in Appendices of [GR833] for a list of example strings. | listed in Appendices of [GR833] for a list of example strings. | |||
Note length includes padding. | Note length includes padding. | |||
Multiple Error String TLVs may be included in an object. | Multiple Error String TLVs may be included in an object. | |||
3.1.2. Procedures | 3.1.2. Procedures | |||
skipping to change at page 9, line 46 | skipping to change at page 9, line 33 | |||
store any alarm information from received ALARM_SPEC objects for | store any alarm information from received ALARM_SPEC objects for | |||
future use. All ALARM_SPEC objects received in Path messages SHOULD | future use. All ALARM_SPEC objects received in Path messages SHOULD | |||
be passed unmodified downstream in the corresponding Path messages. | be passed unmodified downstream in the corresponding Path messages. | |||
All ALARM_SPEC objects received in Resv messages SHOULD be passed | All ALARM_SPEC objects received in Resv messages SHOULD be passed | |||
unmodified upstream in the corresponding Resv messages. ALARM_SPEC | unmodified upstream in the corresponding Resv messages. ALARM_SPEC | |||
objects are merged in transmitted Resv messages by including a copy | objects are merged in transmitted Resv messages by including a copy | |||
of all ALARM_SPEC objects received in corresponding Resv Messages. | of all ALARM_SPEC objects received in corresponding Resv Messages. | |||
To advertise local alarm information, a node generates an ALARM_SPEC | 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 | object for each alarm and adds it to both the Path and Resv messages | |||
for the effected LSP. In all cases, appropriate Error Node Address, | for the impacted LSP. | |||
Error Code and Error Values MUST be set, see below for a discussion | ||||
on Error Code and Error Values. As the InPlace and NotGuilty flags | In all cases, appropriate Error Node Address, Error Code, and Error | |||
only have meaning in ERROR_SPEC objects, they SHOULD NOT be set. | Values MUST be set (see below for a discussion on Error Code and | |||
TLVs SHOULD be included in the ALARM_SPEC object to identify the | Error Values). As the InPlace and NotGuilty flags only have meaning | |||
interface, if any, associated with the alarm - the TLVs defined in | in ERROR_SPEC objects, they SHOULD NOT be set. TLVs SHOULD be | |||
[RFC3471] for identifying interfaces in the IF_ID ERROR_SPEC object | included in the ALARM_SPEC object to identify the interface, if any, | |||
[RFC3473] SHOULD be used for this purpose, but note that TLVs type 4 | associated with the alarm. The TLVs defined in [RFC3471] for | |||
and 5 (component interfaces) are deprecated by [RFC4201] and SHOULD | identifying interfaces in the IF_ID ERROR_SPEC object [RFC3473] | |||
NOT be used. TLVs SHOULD also be included to indicate the severity | SHOULD be used for this purpose, but note that 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 | (Severity TLV), the time (Global Timestamp and/or Local Timestamp | |||
TLVs), and a (brief) string (Error String TLV) associated with the | TLVs), and a (brief) string (Error String TLV) associated with the | |||
alarm. The reference count TLV MAY also be included to indicate 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. | number of times an alarm has been repeated at the reporting node. | |||
ALARM_SPEC objects received from other nodes are not effected by the | ALARM_SPEC objects received from other nodes are not impacted by the | |||
addition of local ALARM_SPEC objects, i.e., they continue to be | addition of local ALARM_SPEC objects, i.e., they continue to be | |||
processed as described above. The choice of which alarm or alarms to | processed as described above. The choice of which alarm or alarms to | |||
advertise and which to omit is a local policy matter, and may | advertise and which to omit is a local policy matter, and may be | |||
configurable by the user. | configurable by the user. | |||
There are two ways to indicate time. A global timestamp TLV is used | There are two ways to indicate time. A global timestamp TLV is used | |||
to provide an absolute time reference for the occurrence of an alarm. | to provide an absolute time reference for the occurrence of an alarm. | |||
The local timestamp TLV is used to provide time reference for the | The local timestamp TLV is used to provide time reference for the | |||
occurrence of an alarm that is relative to other information | occurrence of an alarm that is relative to other information | |||
advertised by the node. The global timestamp SHOULD be used on nodes | advertised by the node. The global timestamp SHOULD be used on nodes | |||
that maintain an absolute time reference. Both timestamp TLVs MAY be | that maintain an absolute time reference. Both timestamp TLVs MAY be | |||
used simultaneously. | used simultaneously. | |||
Note, ALARM_SPEC objects SHOULD NOT be added to the Path and Resv | Note, ALARM_SPEC objects SHOULD NOT be added to the Path and Resv | |||
states of LSPs that are in "alarm communication inhibited state." | states of LSPs that are in "alarm communication inhibited" state. | |||
ALARM_SPEC objects MAY be added to the state of LSPs that are in an | 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 | "administratively down" state. These states are indicated by the I | |||
and A bits of the Admin_Status object, see Section 3.2. | and A bits of the Admin_Status object; see Section 3.2. | |||
To remove local alarm information, a node simply removes the matching | To remove local alarm information, a node simply removes the matching | |||
locally generated ALARM_SPEC objects from the outgoing Path and Resv | locally generated ALARM_SPEC objects from the outgoing Path and Resv | |||
messages. A node MAY modify a locally generated ALARM_SPEC object. | messages. A node MAY modify a locally generated ALARM_SPEC object. | |||
Normal refresh and trigger message processing applies to Path or Resv | Normal refresh and trigger message processing applies to Path or Resv | |||
messages that contain ALARM_SPEC objects. Note that changes in | messages that contain ALARM_SPEC objects. Note that changes in | |||
ALARM_SPEC objects from one message to the next may include a | ALARM_SPEC objects from one message to the next may include a | |||
modification in the contents of a specific ALARM_SPEC object, or 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 | change in the number of ALARM_SPEC objects present. All changes in | |||
skipping to change at page 11, line 13 | skipping to change at page 10, line 44 | |||
information not being properly or fully communicated. | information not being properly or fully communicated. | |||
3.1.3. Error Codes and Values | 3.1.3. Error Codes and Values | |||
The Error Codes and Values used in ALARM_SPEC objects are the same as | The Error Codes and Values used in ALARM_SPEC objects are the same as | |||
those used in ERROR_SPEC objects. New Error Code values for use with | those used in ERROR_SPEC objects. New Error Code values for use with | |||
both ERROR_SPEC and ALARM_SPEC objects may be assigned to support | both ERROR_SPEC and ALARM_SPEC objects may be assigned to support | |||
alarm types defined by other standards. | alarm types defined by other standards. | |||
In this document we define one new Error Code. The Error Code uses | In this document we define one new Error Code. The Error Code uses | |||
the value TBA (by IANA) and is referred to as "Alarms". The values | the value 31 and is referred to as "Alarms". The values used in the | |||
used in the Error Values field when the Error Code is "Alarms" are | Error Values field when the Error Code is "Alarms" are the same as | |||
the same as the values defined in the IANAItuProbableCause Textual | the values defined in the IANAItuProbableCause Textual Convention of | |||
Convention of IANA-ITU-ALARM-TC-MIB in the Alarm MIB [RFC3877]. Note | IANA-ITU-ALARM-TC-MIB in the Alarm MIB [RFC3877]. Note that these | |||
these values are managed by IANA, see http://www.iana.org. | values are managed by IANA; see http://www.iana.org. | |||
3.1.4. Backwards Compatibility | 3.1.4. Backwards Compatibility | |||
The support of ALARM_SPEC objects is OPTIONAL. Non-supporting nodes | The support of ALARM_SPEC objects is OPTIONAL. Non-supporting nodes | |||
will (according to the rules defined in [RFC2205]) pass the objects | will (according to the rules defined in [RFC2205]) pass the objects | |||
through the node unmodified, because the ALARM_SPEC object has a C- | through the node unmodified, because the ALARM_SPEC object has a | |||
Num of the form 11bbbbbb. | C-Num of the form 11bbbbbb. | |||
This allows alarm information to be collected and examined in a | This allows alarm information to be collected and examined in a | |||
network built from a collection of nodes some of which support the | network built from a collection of nodes some of which support the | |||
communication of alarm information, and some of which do not. | communication of alarm information, and some of which do not. | |||
3.2. Controlling Alarm Communication | 3.2. Controlling Alarm Communication | |||
Alarm information communication is controlled via Administrative | Alarm information communication is controlled via Administrative | |||
Status Information as carried in the Admin_Status object. A new bit | Status Information as carried in the Admin_Status object. A new bit | |||
is defined, called the I bit, that indicates when alarm communication | is defined, called the I bit, that indicates when alarm communication | |||
is to be inhibited. The definition of this bit does not modify the | is to be inhibited. The definition of this bit does not modify the | |||
procedures defined in Section 7 of [RFC3473]. | procedures defined in Section 7 of [RFC3473]. | |||
3.2.1. Updated Admin Status Object | 3.2.1. Updated Admin_Status Object | |||
The format of the Admin_Status object is updated to include the I | The format of the Admin_Status object is updated to include the I | |||
bit: | bit: | |||
0 1 2 3 | 0 1 2 3 | |||
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | 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) | | | Length | Class-Num(196)| C-Type (1) | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
|R| Reserved |I| |T|A|D| | |R| Reserved |I| |T|A|D| | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
Inhibit Alarm Communication (I): 1 bit | Inhibit Alarm Communication (I): 1 bit | |||
When set, indicates that alarm communication is disabled for | When set, indicates that alarm communication is disabled for | |||
the LSP and that nodes SHOULD NOT add local alarm information. | the LSP and that nodes SHOULD NOT add local alarm information. | |||
See section 7.1 of [RFC3473] for the definition of the remaining | See Section 7.1 of [RFC3473] for the definition of the remaining | |||
bits. | bits. | |||
3.2.2. Procedures | 3.2.2. Procedures | |||
The I bit may be set and cleared using the procedures defined in | The I bit may be set and cleared using the procedures defined in | |||
Sections 7.2 and 7.3 of [RFC3473]. A node that receives (or | 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), | generates) an Admin_Status object with the A or I bits set (1), | |||
SHOULD remove all locally generated alarm information from the | SHOULD remove all locally generated alarm information from the | |||
matching LSP's outgoing Path and Resv messages. When a node receives | matching LSP's outgoing Path and Resv messages. When a node receives | |||
(or generates) an Admin_Status object with the A and I bits clear (0) | (or generates) an Admin_Status object with the A and I bits clear (0) | |||
and there is local alarm information present, it SHOULD add the local | and there is local alarm information present, it SHOULD add the local | |||
alarm information to the matching LSP's outgoing Path and Resv | alarm information to the matching LSP's outgoing Path and Resv | |||
messages. | messages. | |||
The processing of non-locally generated ALARM_SPEC objects MUST NOT | The processing of non-locally generated ALARM_SPEC objects MUST NOT | |||
be impacted by the contents of the Admin_Status object, that is, | be impacted by the contents of the Admin_Status object; that is, | |||
received ALARM_SPEC objects MUST be forwarded unchanged regardless of | received ALARM_SPEC objects MUST be forwarded unchanged regardless of | |||
the received or transmitted settings of the I and A-bits. Note, per | the received or transmitted settings of the I and A bits. Note that, | |||
[RFC3473], the absence of the Admin_Status object is equivalent to | per [RFC3473], the absence of the Admin_Status object is equivalent | |||
receiving an object containing values all set to zero (0). | to receiving an object containing values all set to zero (0). | |||
I bit related processing behavior MAY be overridden locally based on | I bit related processing behavior MAY be overridden locally based on | |||
configuration. | configuration. | |||
When generating Notify messages for LSPs with the I bit set, the TLVs | 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 | described in this document MAY be added to the ERROR_SPEC object sent | |||
in the the Notify message. | in the Notify message. | |||
3.3. Message Formats | 3.3. Message Formats | |||
This section presents the RSVP message related formats as modified by | This section presents the RSVP message-related formats as modified by | |||
this document. The formats specified in [RFC3473] served as the | this document. The formats specified in [RFC3473] served as the | |||
basis of these formats. The objects are listed in suggested | basis of these formats. The objects are listed in suggested | |||
ordering. | ordering. | |||
The format of a Path message is as follows: | The format of a Path message is as follows: | |||
<Path Message> ::= <Common Header> [ <INTEGRITY> ] | <Path Message> ::= <Common Header> [ <INTEGRITY> ] | |||
[ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ... ] | [ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ... ] | |||
[ <MESSAGE_ID> ] | [ <MESSAGE_ID> ] | |||
<SESSION> <RSVP_HOP> | <SESSION> <RSVP_HOP> | |||
skipping to change at page 14, line 8 | skipping to change at page 13, line 24 | |||
[ <ADMIN_STATUS> ] | [ <ADMIN_STATUS> ] | |||
[ <POLICY_DATA> ... ] | [ <POLICY_DATA> ... ] | |||
[ <ALARM_SPEC> ... ] | [ <ALARM_SPEC> ... ] | |||
<STYLE> <flow descriptor list> | <STYLE> <flow descriptor list> | |||
<flow descriptor list> is not modified by this document. | <flow descriptor list> is not modified by this document. | |||
3.4. Relationship to GMPLS UNI | 3.4. Relationship to GMPLS UNI | |||
[RFC4208] defines how GMPLS may be used in an overlay model to | [RFC4208] defines how GMPLS may be used in an overlay model to | |||
provide a user-to-network interface. In this model, restrictions may | provide a user-to-network interface (UNI). In this model, | |||
be applied to the information that is signaled between an edge-node | restrictions may be applied to the information that is signaled | |||
and a core-node. This restriction allows the core network to limit | between an edge-node and a core-node. This restriction allows the | |||
the information that is visible outside of the core. This restriction | core network to limit the information that is visible outside of the | |||
may be made for confidentiality, privacy or security reasons. It may | core. This restriction may be made for confidentiality, privacy, or | |||
also be made for operational reasons, for example if the information | security reasons. It may also be made for operational reasons, for | |||
is only applicable within the core network. | example, if the information is only applicable within the core | |||
network. | ||||
The extensions described in this document are candidates for | The extensions described in this document are candidates for | |||
filtering as described in [RFC4208]. In particular the following | filtering as described in [RFC4208]. In particular, the following | |||
observations apply. | observations apply. | |||
o An ingress or egress core-node MAY filter alarms from the GMPLS | o An ingress or egress core-node MAY filter alarms from the GMPLS | |||
core to a client-node UNI LSP. This may be to protect information | core to a client-node UNI LSP. This may be to protect information | |||
about the core network, or to indicate that the core network is | about the core network, or to indicate that the core network is | |||
performing or has completed recovery actions for the GMPLS LSP. | performing or has completed recovery actions for the GMPLS LSP. | |||
o An ingress or egress core-node MAY modify alarms from the GMPLS | o An ingress or egress core-node MAY modify alarms from the GMPLS | |||
core when sending to a client-node UNI LSP. This may facilitate | core when sending to a client-node UNI LSP. This may facilitate | |||
the UNI client's ability to understand the failure and its effect | the UNI client's ability to understand the failure and its effect | |||
on the data plane, and enable the UNI client to take corrective | on the data plane, and enable the UNI client to take corrective | |||
actions in a more-appropriate manner. | actions in a more appropriate manner. | |||
o Similarly, an egress core-node MAY choose to not request alarm | o Similarly, an egress core-node MAY choose not to request alarm | |||
reporting on Path messages that it sends downstream to the overlay | reporting on Path messages that it sends downstream to the overlay | |||
network. | network. | |||
3.5. Relationship to GMPLS E-NNI | 3.5. Relationship to GMPLS E-NNI | |||
GMPLS may be used at the external network-to-network (E-NNI) | GMPLS may be used at the external network-to-network interface | |||
interface, see [ASON-APPL]. At this interface, restrictions may be | (E-NNI); see [ASON-APPL]. At this interface, restrictions may be | |||
applied to the information that is signaled between an egress and an | applied to the information that is signaled between an egress and an | |||
ingress core-node. | ingress core-node. | |||
This restriction allows the ingress core network to limit the | This restriction allows the ingress core network to limit the | |||
information that is visible outside of its core network. This | information that is visible outside of its core network. This | |||
restriction may be made for confidentiality, privacy or security | restriction may be made for confidentiality, privacy, or security | |||
reasons. It may also be made for operational reasons, for example if | reasons. It may also be made for operational reasons, for example, | |||
the information is only applicable within the core network. | if the information is only applicable within the core network. | |||
The extensions described in this document are candidates for | The extensions described in this document are candidates for | |||
filtering as described in [ASON-APPL]. In particular the following | filtering as described in [ASON-APPL]. In particular, the following | |||
observations apply. | observations apply. | |||
o An ingress or egress core-node MAY filter internal core network | o An ingress or egress core-node MAY filter internal core network | |||
alarms. This may be to protect information about the internal | alarms. This may be to protect information about the internal | |||
network, or to indicate that the core network is performing or has | network or to indicate that the core network is performing or has | |||
completed recovery actions for this LSP. | completed recovery actions for this LSP. | |||
o An ingress or egress core-node MAY modify internal core network | o An ingress or egress core-node MAY modify internal core network | |||
alarms. This may facilitate the peering E-NNI (i.e. the egress | alarms. This may facilitate the peering E-NNI (i.e., the egress | |||
core-node) to understand the failure and its effect on the data | core-node) to understand the failure and its effect on the data | |||
plane, and take corrective actions in a more-appropriate manner or | plane, and take corrective actions in a more appropriate manner or | |||
prolong the generated alarms upstream/downstream as appropriated. | prolong the generated alarms upstream/downstream as appropriated. | |||
o Similarly, an egress/ingress core-node MAY choose to not request | o Similarly, an egress/ingress core-node MAY choose not to request | |||
alarm reporting on Path messages that it sends downstream. | alarm reporting on Path messages that it sends downstream. | |||
4. Acknowledgments | 4. Security Considerations | |||
Valuable comments and input were received from a number of people, | ||||
including Wes Doonan, Bert Wijnen for the DISMAN reference, Tom Petch | ||||
for getting the disman WG interactions started. We also thank David | ||||
Black, Lars Eggert, Russ Housley, Dan Romascanu, and Magnus | ||||
Westerlund, for their valuable comments. | ||||
5. Security Considerations | ||||
Some operators may consider alarm information as sensitive. To | Some operators may consider alarm information as sensitive. To | |||
support environments where this is the case, implementations SHOULD | support environments where this is the case, implementations SHOULD | |||
allow the user to disable the generation of ALARM_SPEC objects, or to | allow the user to disable the generation of ALARM_SPEC objects, or to | |||
filter or correlate them at domain boundaries. | filter or correlate them at domain boundaries. | |||
This document introduces no additional security considerations. See | This document introduces no additional security considerations. See | |||
[RFC3473] for relevant security considerations. | [RFC3473] for relevant security considerations. | |||
It may be noted that if the security considerations of [RFC3473] are | It may be noted that if the security considerations of [RFC3473] are | |||
breached, alarm information may be spoofed. Such spoofing would be at | breached, alarm information may be spoofed. Such spoofing would be | |||
most annoying and cause slight degradation of control plane | at most annoying and cause slight degradation of control plane | |||
performance since the details are provided for information only and | performance since the details are provided for information only and | |||
do not result in protocol actions beyond the exchange of messages to | do not result in protocol actions beyond the exchange of messages to | |||
convey the information. If the protocol security is able to be | convey the information. If the protocol security is able to be | |||
breached sufficiently to allow spoofing of alarm information then | breached sufficiently to allow spoofing of alarm information then | |||
considerably more interesting and exciting damage can be caused by | considerably more interesting and exciting damage can be caused by | |||
spoofing other elements of the protocol messages. | spoofing other elements of the protocol messages. | |||
6. IANA Considerations | 5. IANA Considerations | |||
IANA is requested to administer assignment of new values for | IANA administered assignment of new values for namespaces defined in | |||
namespaces defined in this document and reviewed in this section. | this document and reviewed in this section. | |||
6.1. New RSVP Object | 5.1. New RSVP Object | |||
Upon approval of this document, the IANA will make the following | IANA made the following assignments in the "Class Names, Class | |||
assignments in the "Class Names, Class Numbers, and Class Types" | Numbers, and Class Types" section of the "RSVP PARAMETERS" registry | |||
section of the "RSVP PARAMETERS" registry located at | located at http://www.iana.org/assignments/rsvp-parameters. | |||
http://www.iana.org/assignments/rsvp-parameters | ||||
A new class named ALARM_SPEC will be created in the 11bbbbbb range | A new class named ALARM_SPEC (198) was created in the 11bbbbbb range | |||
(197 suggested) with following values | with following values | |||
o Class = TBA, C-Type = 1 | o Class = 198, C-Type = 1 | |||
[RFC-ccamp-gmpls-alarm-spec] | RFC 4783 | |||
Reserved. (C-Type value defined for ERROR_SPEC, but is not | Reserved. (C-Type value defined for ERROR_SPEC, but is not | |||
defined for use with ALARM_SPEC.) | defined for use with ALARM_SPEC.) | |||
o Class = TBA, C-Type = 2 | o Class = 198, C-Type = 2 | |||
[RFC-ccamp-gmpls-alarm-spec] | RFC 4783 | |||
Reserved. (C-Type value defined for ERROR_SPEC, but is not | Reserved. (C-Type value defined for ERROR_SPEC, but is not | |||
defined for use with ALARM_SPEC.) | defined for use with ALARM_SPEC.) | |||
o IPv4 IF_ID ALARM_SPEC object: Class = TBA, C-Type = 3 | o IPv4 IF_ID ALARM_SPEC object: Class = 198, C-Type = 3 | |||
[RFC-ccamp-gmpls-alarm-spec] | RFC 4783 | |||
Definition same as IPv4 IF_ID ERROR_SPEC [RFC3473]. | Definition same as IPv4 IF_ID ERROR_SPEC [RFC3473]. | |||
o IPv6 IF_ID ALARM_SPEC object: Class = TBA, C-Type = 4 | o IPv6 IF_ID ALARM_SPEC object: Class = 198, C-Type = 4 | |||
[RFC-ccamp-gmpls-alarm-spec] | RFC 4783 | |||
Definition same as IPv6 IF_ID ERROR_SPEC [RFC3473]. | Definition same as IPv6 IF_ID ERROR_SPEC [RFC3473]. | |||
The ALARM_SPEC object uses the Error Code and Error Values from the | The ALARM_SPEC object uses the Error Code and Error Values from the | |||
ERROR_SPEC object. | ERROR_SPEC object. | |||
6.2. New Interface ID Types | 5.2. New Interface ID Types | |||
Upon approval of this document, the IANA will make the following | IANA made the following assignments in the "Interface_ID Types" | |||
assignments in the "Interface_ID Types" section of the "GMPLS | section of the "GMPLS Signaling Parameters" registry located at | |||
Signaling Parameters" registry located at | http://www.iana.org/assignments/gmpls-sig-parameters. | |||
http://www.iana.org/assignments/gmpls-sig-parameters | ||||
xx2 8 REFERENCE_COUNT [RFC-ccamp-gmpls-alarm-spec] | 512 8 REFERENCE_COUNT RFC 4783 | |||
xx3 8 SEVERITY [RFC-ccamp-gmpls-alarm-spec] | 513 8 SEVERITY RFC 4783 | |||
xx4 8 GLOBAL_TIMESTAMP [RFC-ccamp-gmpls-alarm-spec] | 514 8 GLOBAL_TIMESTAMP RFC 4783 | |||
xx5 8 LOCAL_TIMESTAMP [RFC-ccamp-gmpls-alarm-spec] | 515 8 LOCAL_TIMESTAMP RFC 4783 | |||
xx6 variable ERROR_STRING [RFC-ccamp-gmpls-alarm-spec] | 516 variable ERROR_STRING RFC 4783 | |||
(The value of 51 is suggested for xx.) | ||||
6.3. New Registry for Admin-Status Object Bit Fields | 5.3. New Registry for Admin-Status Object Bit Fields | |||
Upon approval of this document, the IANA will create a new section | IANA created a new section titled "Administrative Status Information | |||
titled "Administrative Status Information Flags" in the "GMPLS | Flags" in the "GMPLS Signaling Parameters" registry located at | |||
Signaling Parameters" registry located at | http://www.iana.org/assignments/gmpls-sig-parameters and made the | |||
http://www.iana.org/assignments/gmpls-sig-parameters and make the | ||||
following assignments: | following assignments: | |||
Value Name Reference | Value Name Reference | |||
----------- -------------------------------- ----------------- | ----------- -------------------------------- ----------------- | |||
0x80000000 Reflect (R) [RFC3473/RFC3471] | 0x80000000 Reflect (R) [RFC3473/RFC3471] | |||
0x00000010 Inhibit Alarm Communication (I) | 0x00000010 Inhibit Alarm Communication (I) RFC 4783 | |||
[RFC-ccamp-gmpls-alarm-spec] | ||||
0x00000004 Testing (T) [RFC3473/RFC3471] | 0x00000004 Testing (T) [RFC3473/RFC3471] | |||
0x00000002 Administratively down (A) [RFC3473/RFC3471] | 0x00000002 Administratively down (A) [RFC3473/RFC3471] | |||
0x00000001 Deletion in progress (D) [RFC3473/RFC3471] | 0x00000001 Deletion in progress (D) [RFC3473/RFC3471] | |||
6.4. New RSVP Error Code | 5.4. New RSVP Error Code | |||
Upon approval of this document, the IANA will make the following | IANA made the following assignments in the "Error Codes and Values" | |||
assignments in the "Error Codes and Values" section of the "RSVP | section of the "RSVP PARAMETERS" registry located at | |||
PARAMETERS" registry located at http://www.iana.org/assignments/rsvp- | http://www.iana.org/assignments/rsvp-parameters. | |||
parameters | ||||
xx Alarms [RFC-ccamp-gmpls-alarm-spec] | 31 Alarms RFC 4783 | |||
The Error Value sub-codes for this Error Code have values and | The Error Value sub-codes for this Error Code have values and | |||
meanings identical to the values and meanings defined in the | meanings identical to the values and meanings defined in the | |||
IANAItuProbableCause Textual Convention of IANA-ITU-ALARM-TC-MIB | IANAItuProbableCause Textual Convention of IANA-ITU-ALARM-TC-MIB | |||
in the Alarm MIB [RFC3877]. Note these values are already | in the Alarm MIB [RFC3877]. Note that these values are already | |||
managed the IANA. | managed the IANA. | |||
(The value of 31 is suggested for xx.) | 6. References | |||
7. References | 6.1. Normative References | |||
7.1. Normative References | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
Requirement Levels", BCP 14, RFC 2119, March 1997. | ||||
[RFC2205] Braden, R. Ed. et al, "Resource ReserVation Protocol | [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and | |||
-- Version 1 Functional Specification", RFC 2205, | S. Jamin, "Resource ReSerVation Protocol (RSVP) -- | |||
September 1997. | Version 1 Functional Specification", RFC 2205, September | |||
1997. | ||||
[RFC3471] Berger, L., Editor, "Generalized Multi-Protocol | [RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label | |||
Label Switching (GMPLS) Signaling Functional | Switching (GMPLS) Signaling Functional Description", RFC | |||
Description", RFC 3471, January 2003. | 3471, January 2003. | |||
[RFC3473] Berger, L., Editor, "Generalized Multi-Protocol Label | [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label | |||
Switching (GMPLS) Signaling - Resource ReserVation | Switching (GMPLS) Signaling Resource ReserVation | |||
Protocol-Traffic Engineering (RSVP-TE) Extensions", | Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC | |||
RFC 3473, January 2003. | 3473, January 2003. | |||
[RFC3877] Chisholm, S., Romascanu, D., "Alarm Management | [RFC3877] Chisholm, S. and D. Romascanu, "Alarm Management | |||
Information Base (MIB)", RFC 3877, September 2004. | Information Base (MIB)", RFC 3877, September 2004. | |||
[M.3100] ITU Recommendation M.3100, "Generic Network Information | [M.3100] ITU Recommendation M.3100, "Generic Network Information | |||
Model", 1995 | Model", 1995. | |||
7.2. Informative References | 6.2. Informative References | |||
[RFC4201] Kompella, K., Rekhter, Y., Berger, L., "Link Bundling | [RFC4201] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling | |||
in MPLS Traffic Engineering (TE)", RFC 4201, October 2005. | in MPLS Traffic Engineering (TE)", RFC 4201, October | |||
2005. | ||||
[M.20] ITU-T, "MAINTENANCE PHILOSOPHY FOR TELECOMMUNICATION | [M.20] ITU-T, "MAINTENANCE PHILOSOPHY FOR TELECOMMUNICATION | |||
NETWORKS", Recommendation M.20, October 1992. | NETWORKS", Recommendation M.20, October 1992. | |||
[GR833] Bellcore, "Network Maintenance: Network Element and | [GR833] Bellcore, "Network Maintenance: Network Element and | |||
Transport Surveillance Messages" (GR-833-CORE), Issue 3, | Transport Surveillance Messages" (GR-833-CORE), Issue 3, | |||
February 1999. | February 1999. | |||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter, | |||
Requirement Levels," RFC 2119. | "Generalized Multiprotocol Label Switching (GMPLS) User- | |||
Network Interface (UNI): Resource ReserVation Protocol- | ||||
[RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Rekhter, Y. | Traffic Engineering (RSVP-TE) Support for the Overlay | |||
"Generalized Multiprotocol Label Switching (GMPLS) | Model", RFC 4208, October 2005. | |||
User-Network Interface (UNI): Resource ReserVation | ||||
Protocol-Traffic Engineering (RSVP-TE) Support for the | ||||
Overlay Model", RFC 4208, October 2005. | ||||
[ASON-APPL] D. Papadimitriou et. al., "Generalized MPLS (GMPLS) | [ASON-APPL] Papadimitriou, D., et al., "Generalized MPLS (GMPLS) | |||
RSVP-TE signaling usage in support of Automatically | RSVP-TE signaling usage in support of Automatically | |||
Switched Optical Network (ASON)," | Switched Optical Network (ASON)", Work in Progress, July | |||
draft-ietf-ccamp-gmpls-rsvp-te-ason, work in progress. | 2005. | |||
7. Acknowledgments | ||||
Valuable comments and input were received from a number of people, | ||||
including Wes Doonan, Bert Wijnen for the DISMAN reference, and Tom | ||||
Petch for getting the DISMAN WG interactions started. We also thank | ||||
David Black, Lars Eggert, Russ Housley, Dan Romascanu, and Magnus | ||||
Westerlund for their valuable comments. | ||||
8. Contributors | 8. Contributors | |||
Contributors are listed in alphabetical order: | Contributors are listed in alphabetical order: | |||
Lou Berger Deborah Brungard | Deborah Brungard | |||
LabN Consulting, L.L.C. AT&T Labs, Room MT D1-3C22 | AT&T Labs, Room MT D1-3C22 | |||
200 Laurel Avenue | 200 Laurel Avenue | |||
Middletown, NJ 07748, USA | Middletown, NJ 07748, USA | |||
Phone: +1 301-468-9228 Phone: (732) 420-1573 | Phone: (732) 420-1573 | |||
Email: lberger@labn.net Email: dbrungard@att.com | EMail: dbrungard@att.com | |||
Igor Bryskin Adrian Farrel | Igor Bryskin Adrian Farrel | |||
Movaz Networks, Inc. Old Dog Consulting | Movaz Networks, Inc. Old Dog Consulting | |||
7926 Jones Branch Drive | 7926 Jones Branch Drive | |||
Suite 615 | Suite 615 | |||
McLean VA, 22102, USA Phone: +44 (0) 1978 860944 | McLean VA, 22102, USA Phone: +44 (0) 1978 860944 | |||
Email: ibryskin@movaz.com Email: adrian@olddog.co.uk | EMail: ibryskin@movaz.com EMail: adrian@olddog.co.uk | |||
Dimitri Papadimitriou (Alcatel) Arun Satyanarayana | Dimitri Papadimitriou (Alcatel) Arun Satyanarayana | |||
Francis Wellesplein 1 Cisco Systems, Inc | Francis Wellesplein 1 Cisco Systems, Inc | |||
B-2018 Antwerpen, Belgium 170 West Tasman Dr. | B-2018 Antwerpen, Belgium 170 West Tasman Dr. | |||
San Jose, CA 95134 USA | San Jose, CA 95134 USA | |||
Phone: +32 3 240-8491 Phone: +1 408 853-3206 | Phone: +32 3 240-8491 Phone: +1 408 853-3206 | |||
Email: dimitri.papadimitriou@alcatel.be Email: asatyana@cisco.com | EMail: dimitri.papadimitriou@alcatel.be EMail: asatyana@cisco.com | |||
9. Contact Address | Editor's Address | |||
Lou Berger | Lou Berger | |||
LabN Consulting, L.L.C. | LabN Consulting, L.L.C. | |||
Phone: +1 301-468-9228 | Phone: +1 301-468-9228 | |||
Email: lberger@labn.net | EMail: lberger@labn.net | |||
10. Full Copyright Statement | Full Copyright Statement | |||
Copyright (C) The Internet Society (2006). This document is subject | Copyright (C) The IETF Trust (2006). | |||
to the rights, licenses and restrictions contained in BCP 78, and | ||||
except as set forth therein, the authors retain all their rights. | 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 | This document and the information contained herein are provided on an | |||
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS | "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS | |||
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET | OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST, | |||
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, | AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, | |||
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE | EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT | |||
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED | THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY | |||
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. | IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR | |||
PURPOSE. | ||||
11. Intellectual Property | Intellectual Property | |||
The IETF takes no position regarding the validity or scope of any | The IETF takes no position regarding the validity or scope of any | |||
Intellectual Property Rights or other rights that might be claimed to | Intellectual Property Rights or other rights that might be claimed to | |||
pertain to the implementation or use of the technology described in | pertain to the implementation or use of the technology described in | |||
this document or the extent to which any license under such rights | this document or the extent to which any license under such rights | |||
might or might not be available; nor does it represent that it has | might or might not be available; nor does it represent that it has | |||
made any independent effort to identify any such rights. Information | made any independent effort to identify any such rights. Information | |||
on the procedures with respect to rights in RFC documents can be | on the procedures with respect to rights in RFC documents can be | |||
found in BCP 78 and BCP 79. | found in BCP 78 and BCP 79. | |||
Copies of IPR disclosures made to the IETF Secretariat and any | Copies of IPR disclosures made to the IETF Secretariat and any | |||
assurances of licenses to be made available, or the result of an | assurances of licenses to be made available, or the result of an | |||
attempt made to obtain a general license or permission for the use of | attempt made to obtain a general license or permission for the use of | |||
such proprietary rights by implementers or users of this | such proprietary rights by implementers or users of this | |||
specification can be obtained from the IETF on-line IPR repository at | specification can be obtained from the IETF on-line IPR repository at | |||
http://www.ietf.org/ipr. | http://www.ietf.org/ipr. | |||
The IETF invites any interested party to bring to its attention any | The IETF invites any interested party to bring to its attention any | |||
copyrights, patents or patent applications, or other proprietary | copyrights, patents or patent applications, or other proprietary | |||
rights that may cover technology that may be required to implement | rights that may cover technology that may be required to implement | |||
this standard. Please address the information to the IETF at ietf- | this standard. Please address the information to the IETF at | |||
ipr@ietf.org. | ietf-ipr@ietf.org. | |||
Generated on: Thu Sep 7 22:15:17 TST 2006 | Acknowledgement | |||
Funding for the RFC Editor function is currently provided by the | ||||
Internet Society. | ||||
End of changes. 99 change blocks. | ||||
253 lines changed or deleted | 237 lines changed or added | |||
This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |