draft-ietf-ccamp-gmpls-alarm-spec-01.txt | draft-ietf-ccamp-gmpls-alarm-spec-02.txt | |||
---|---|---|---|---|
Internet Draft Lou Berger - Editor (Movaz Networks) | Internet Draft Lou Berger - Editor (Movaz Networks) | |||
Updates: 3473 | ||||
Category: Standards Track | Category: Standards Track | |||
Expiration Date: March 2005 | Expiration Date: May 2005 | |||
September 2004 | ||||
November 2004 | ||||
GMPLS - Communication of Alarm Information | GMPLS - Communication of Alarm Information | |||
draft-ietf-ccamp-gmpls-alarm-spec-01.txt | draft-ietf-ccamp-gmpls-alarm-spec-02.txt | |||
Status of this Memo | Status of this Memo | |||
By submitting this Internet-Draft, I certify that any applicable | By submitting this Internet-Draft, I certify that any applicable | |||
patent or other IPR claims of which I am aware have been disclosed, | patent or other IPR claims of which I am aware have been disclosed, | |||
or will be disclosed, and any of which I become aware will be | or will be disclosed, and any of which I become aware will be | |||
disclosed, in accordance with RFC 3668. | disclosed, in accordance with RFC 3668. | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF), its areas, and its working groups. Note that | Task Force (IETF), its areas, and its working groups. Note that | |||
skipping to change at page 2, line 12 | skipping to change at page 2, line 12 | |||
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. | |||
Contents | 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 .................... 5 | 3.1.1 IF_ID ALARM_SPEC (and ERROR_SPEC) TLVs .................... 6 | |||
3.1.2 Procedures ................................................ 9 | 3.1.2 Procedures ................................................ 9 | |||
3.1.3 Error Codes and Values .................................... 10 | 3.1.3 Error Codes and Values .................................... 10 | |||
3.1.4 Backwards Compatibility ................................... 10 | 3.1.4 Backwards Compatibility ................................... 10 | |||
3.2 Controlling Alarm Communication ........................... 10 | 3.2 Controlling Alarm Communication ........................... 11 | |||
3.2.1 Updated Admin Status Object ............................... 10 | 3.2.1 Updated Admin Status Object ............................... 11 | |||
3.2.2 Procedures ................................................ 11 | 3.2.2 Procedures ................................................ 11 | |||
3.3 Message Formats ........................................... 11 | 3.3 Message Formats ........................................... 12 | |||
3.4 Relationship to GMPLS UNI ................................. 12 | 3.4 Relationship to GMPLS UNI ................................. 13 | |||
3.5 Relationship to GMPLS E-NNI .............................. 13 | 3.5 Relationship to GMPLS E-NNI .............................. 14 | |||
4 Security Considerations ................................... 14 | 4 Security Considerations ................................... 14 | |||
5 IANA Considerations ....................................... 14 | 5 IANA Considerations ....................................... 15 | |||
6 References ................................................ 15 | 6 References ................................................ 15 | |||
6.1 Normative References ...................................... 15 | 6.1 Normative References ...................................... 15 | |||
6.2 Informative References .................................... 15 | 6.2 Informative References .................................... 16 | |||
7 Contributors .............................................. 16 | 7 Contributors .............................................. 17 | |||
8 Contact Address ........................................... 16 | 8 Contact Address ........................................... 17 | |||
9 Full Copyright Statement .................................. 17 | 9 Full Copyright Statement .................................. 18 | |||
10 Intellectual Property ..................................... 17 | 10 Intellectual Property ..................................... 18 | |||
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 an LSP. This support is provided | |||
via Administrative Status Information [RFC3471] and the Admin_Status | via Administrative Status Information [RFC3471] and the Admin_Status | |||
object [RFC3473]. These mechanisms only control if alarm reporting | object [RFC3473]. These mechanisms only control if alarm reporting | |||
is inhibited. No provision is made for communication of alarm | is inhibited. No provision is made for communication of alarm | |||
information within GMPLS. | information within GMPLS. | |||
skipping to change at page 3, line 34 | skipping to change at page 3, line 34 | |||
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. | communication of alarms outside of GMPLS. Additionally, the | |||
extension described in this document is not intended to replace any | ||||
(existing) data plane fault propagation techniques. | ||||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | |||
document are to be interpreted as described in [RFC2119]. | document are to be interpreted as described in [RFC2119]. | |||
1.1. Background | 1.1. Background | |||
Problems with data plane state can often be detected by associated | Problems with data plane state can often be detected by associated | |||
data plane hardware components. Such data plane problems are | data plane hardware components. Such data plane problems are | |||
typically filtered based on elapsed time and local policy. Problems | typically filtered based on elapsed time and local policy. Problems | |||
skipping to change at page 4, line 13 | skipping to change at page 4, line 16 | |||
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 and | |||
Notify messages, these messages typically indicate a problem in | 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 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 | exa | |||
cerbated 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 | |||
the real alarm status in the network. Finally, the extensions make | the real alarm status in the network. Finally, the extensions make | |||
the list available at every node traversed by an LSP. | the list available at every node traversed by an LSP. | |||
2. Alarm Information Communication | 2. Alarm Information Communication | |||
skipping to change at page 5, line 31 | skipping to change at page 5, line 32 | |||
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 TBA (to be assigned by IANA in the form | |||
11bbbbbb). | 11bbbbbb). | |||
o IPv4 ALARM_SPEC object: Class = TBA, C-Type = 1 | o Class = TBA, C-Type = 1 | |||
Definition same as IPv4 ERROR_SPEC [RFC2205]. | Reserved. | |||
o IPv6 ALARM_SPEC object: Class = TBA, C-Type = 2 | o Class = TBA, C-Type = 2 | |||
Definition same as IPv6 ERROR_SPEC [RFC2205]. | Reserved. | |||
o IPv4 IF_ID ALARM_SPEC object: Class = TBA, C-Type = 3 | o IPv4 IF_ID ALARM_SPEC object: Class = TBA, 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 = TBA, 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 | ||||
No rules apply to the relative ordering of these TLVs. These TLVs | rules apply to the relative ordering of the TLVs defined in this | |||
MUST be listed after any interface identifying TLVs. | section. | |||
[Note: Type values are TBA (to be assigned) by IANA] | [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 | |||
skipping to change at page 6, line 30 | skipping to change at page 6, line 38 | |||
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 | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Reference Count | | | Reference Count | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
Reference Count: 32 bits | Reference Count: 32 bits | |||
The number of times this alarm has been repeated. This field | The number of times this alarm has been repeated as determined | |||
MUST NOT be set to zero. | by the reporting node. This field MUST NOT be set to zero. | |||
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 | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
skipping to change at page 6, line 44 | skipping to change at page 7, line 4 | |||
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: 24 bits | Reserved: 24 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, | |||
and MUST be ignored on receipt. | MUST be ignored on receipt and MUST be forwarded unchanged and | |||
unexamined by transit nodes. | ||||
Impact: 4 bits | Impact: 4 bits | |||
Indicates the impact of the alarm indicated in the TLV. The | Indicates the impact of the alarm indicated in the TLV. See | |||
following values are defined: | [M.20] for a general discussion on classification of failures. | |||
The following values are defined: | ||||
Value Definition | Value Definition | |||
----- --------------------- | ----- --------------------- | |||
0 Unspecified impact | 0 Unspecified impact | |||
1 Non-Service Affecting | 1 Non-Service Affecting (Data traffic not interrupted) | |||
2 Service Affecting | 2 Service Affecting (Data traffic is interrupted) | |||
Severity: 8 bits | Severity: 8 bits | |||
Indicates the impact of the alarm indicated in the TLV. The | Indicates the impact of the alarm indicated in the TLV. See | |||
following values are defined: | [RFC3877] for more information on severity. The following | |||
values are defined: | ||||
Value Definition | Value Definition | |||
----- ---------- | ----- ---------- | |||
0 Reserved | 0 Cleared | |||
1 Critical | 1 Indeterminate | |||
2 Major | 2 Critical | |||
3 Minor | 3 Major | |||
4 Warning | 4 Minor | |||
5 Warning | ||||
Only one Severity TLV may be included in an object. | Only one Severity TLV may be included in an object. | |||
The Global Timestamp TLV has the following format: | The Global Timestamp 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 | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Global Timestamp | | | Global Timestamp | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
Berger, et. al. | ||||
Global Timestamp: 32 bits | Global Timestamp: 32 bits | |||
The number of seconds since 0000 UT on 1 January 1970, | The number of seconds since 0000 UT on 1 January 1970, | |||
according to the clock on the node that originates this TLV. | according to the clock on the node that originates this TLV. | |||
Only one Global Timestamp TLV may be included in an object. | Only one Global Timestamp TLV may be included in an object. | |||
The Local Timestamp TLV has the following format: | The Local Timestamp TLV has the following format: | |||
0 1 2 3 | 0 1 2 3 | |||
skipping to change at page 8, line 34 | 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, representing the type of error/alarm. | A string of characters, representing the type of error/alarm. | |||
This string is padded to the next largest 4 byte boundary using | This string is padded to the next largest 4 byte boundary using | |||
null characters. Null padding is not required when the string | null characters. Null padding is not required when the string | |||
is 32-bit aligned. The contents of error string are | is 32-bit aligned. The contents of error string are | |||
implementation dependent. See the condition types listed in | implementation dependent. See the condition types listed in | |||
Appendices of [GR833] for a list of example strings. | Appendices of [GR833] for a list of example strings. 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 | |||
This section applies to nodes that support the communication of alarm | This section applies to nodes that support the communication of alarm | |||
information. ALARM_SPEC objects are carried in Path and Resv | information. ALARM_SPEC objects are carried in Path and Resv | |||
messages. Multiple ALARM_SPEC objects MAY be present. The IPv4 and | messages. Multiple ALARM_SPEC objects MAY be present. | |||
IPv6 formats of the ALARM_SPEC object, C-Type 1 and 2, SHOULD NOT be | ||||
used as they do not support the inclusion of the TLVs defined above. | ||||
Nodes that support the communication of alarm information, SHOULD | Nodes that support the communication of alarm information, SHOULD | |||
record the information contained in a received ALARM_SPECs for later | record the information contained in a received ALARM_SPEC for later | |||
use. All ALARM_SPEC objects received in Path messages SHOULD be | use. All ALARM_SPEC objects received in Path messages SHOULD be | |||
passed unmodified downstream in the corresponding Path messages. All | passed unmodified downstream in the corresponding Path messages. All | |||
ALARM_SPEC objects received in Resv messages SHOULD be passed | 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 affected LSP. The IPv4 or IPv6 IF_ID ALARM_SPEC object | for the effected LSP. In all cases, appropriate Error Node Address, | |||
format SHOULD be used. In all cases, appropriate Error Node Address, | ||||
Error Code and Error Values MUST be set, see below for a discussion | Error Code and Error Values MUST be set, see below for a discussion | |||
on Error Code and Error Values. The InPlace and NotGuilty flags | on Error Code and Error Values. The InPlace and NotGuilty flags | |||
SHOULD NOT be set. When the IPv4 or IPv6 IF_ID ALARM_SPEC object | SHOULD NOT be set. TLVs SHOULD be included to identify the | |||
format is used, TLVs SHOULD be included to identify the interface, if | interface, if any, the severity, the time and a (brief) string | |||
any, the severity, the time and a brief string associated with the | associated with the alarm. The reference count TLV MAY also be | |||
alarm. The reference count TLV MAY also be included. ALARM_SPEC | included. ALARM_SPEC objects received from other nodes are not | |||
objects received from other nodes are not effected by the addition of | effected by the addition of local ALARM_SPEC objects, i.e., they | |||
local ALARM_SPEC objects, i.e., they continue to be processed as | continue to be processed as described above. The choice of which | |||
described above. The choice of which alarm or alarms to advertise | alarm or alarms to advertise and which to omit is a local policy | |||
and which to omit is a local policy matter, and may configurable by | matter, and may configurable by the user. | |||
the user. | ||||
Note, ALARM_SPEC objects SHOULD NOT be added to LSPs that are in | There are two ways to indicate time. A global timestamp TLV is used | |||
"alarm communication inhibited." ALARM_SPEC objects MAY be added to | to provide an absolute time reference for the occurrence of an alarm. | |||
LSPs that are "administratively down". These states are indicated by | The local timestamp TLV is used to provide time reference for the | |||
the I and A bits of the Admin_Status object, see Section 3.2. | occurrence of an alarm that is relative to other information | |||
advertised by the node. 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 state of LSPs | ||||
that are in "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 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 | |||
message 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 | |||
ALARM_SPEC objects SHOULD be processed as trigger messages. | ALARM_SPEC objects SHOULD be processed as trigger messages. | |||
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 TBA (by IANA) and is referred to as "Alarms". The values | |||
used in the Error Values field are the same as the values used for | used in the Error Values field are the same as the values used for | |||
IANAItuProbableCause in the Alarm MIB [ALARM-MIB]. Note these values | IANAItuProbableCause in the Alarm MIB [RFC3877]. Note these values | |||
are managed by IANA, see http://www.iana.org. | 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 pass the objects through the node unmodified, because the | will pass the objects through the node unmodified, because the | |||
ALARM_SPEC object has a C-Num of the form 11bbbbbb. | ALARM_SPEC object has a 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 | |||
skipping to change at page 11, line 14 | skipping to change at page 11, line 36 | |||
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 [RFC3471] for the definition of the remaining bits. | See [RFC3471] for the definition of the remaining 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 and 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 | (or generates) an Admin_Status object with the A and I bits clear | |||
(0), it should add any local alarm information to the matching LSP's | (0), it SHOULD add any local alarm information to the matching LSP's | |||
outgoing Path and Resv messages. The processing of non-locally | outgoing Path and Resv messages. | |||
generated ALARM_SPEC objects MUST NOT be impacted by the contents of | ||||
the Admin_Status object. Note, per [RFC3473], the absence of the | The processing of non-locally generated ALARM_SPEC objects MUST NOT | |||
Admin_Status object is equivalent to receiving an object containing | be impacted by the contents of the Admin_Status object, that is, | |||
values all set to zero (0). | received ALARM_SPEC objects MUST be forwarded unchanged regardless of | |||
the received or transmitted settings of the I and A-bits. Note, per | ||||
[RFC3473], the absence of the Admin_Status object is equivalent to | ||||
receiving an object containing values all 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 | 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 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. | basis of these formats. The objects are listed in suggested | |||
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> | |||
<TIME_VALUES> | <TIME_VALUES> | |||
[ <EXPLICIT_ROUTE> ] | [ <EXPLICIT_ROUTE> ] | |||
<LABEL_REQUEST> | <LABEL_REQUEST> | |||
skipping to change at page 13, line 9 | skipping to change at page 13, line 36 | |||
and a core-node. This restriction allows the core network to limit | and a core-node. This restriction allows the core network to limit | |||
the information that is visible outside of the core. This restriction | the information that is visible outside of the core. This restriction | |||
may be made for confidentiality, privacy or security reasons. It may | may be made for confidentiality, privacy or security reasons. It may | |||
also be made for operational reasons, for example if the information | also be made for operational reasons, for example if the information | |||
is only applicable within the core network. | 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 [GMPLS-UNI]. In particular the following | filtering as described in [GMPLS-UNI]. In particular the following | |||
observations apply. | observations apply. | |||
o An ingress or egress core-node MAY filter alarms from the GMPLS core | o An ingress or egress core-node MAY filter alarms from the GMPLS | |||
to the overlay UNI LSP. This may be to protect information about the | core to a client-node UNI LSP. This may be to protect information | |||
core network, or to indicate that the core network is performing or | about the core network, or to indicate that the core network is | |||
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 the overlay UNI LSP. This may facilitate the | core when sending to a client-node UNI LSP. This may facilitate | |||
UNI client's ability to understand the failure and its effect on the | the UNI client's ability to understand the failure and its effect | |||
data plane, and enable the UNI client to take corrective actions in a | on the data plane, and enable the UNI client to take corrective | |||
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 to not 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. | |||
o Further, even when alarm reporting is requested along the whole | ||||
length of an overlay LSP, an ingress or egress core-node MAY choose | ||||
to selectively filter alarms that are reported to the overlay | ||||
network. This may be to protect information about the core network, | ||||
or may reflect the fact that the core network intends to take | ||||
remedial action and does not want the overlay network to operate on | ||||
the alarm information. | ||||
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 (E-NNI) | |||
interface, see [GMPLS-ASON]. At this interface, restrictions may be | interface, see [GMPLS-ENNI]. 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 if | |||
the information is only applicable within the core network. | 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 [GMPLS-ASON]. In particular the following | filtering as described in [GMPLS-ENNI]. In particular the following | |||
observations apply. | observations apply. | |||
o An ingress or egress core-node MAY filter internal core network alarms. | o An ingress or egress core-node MAY filter internal core network | |||
This may be to protect information about the internal network, or to | alarms. This may be to protect information about the internal | |||
indicate that the core network is performing or has completed recovery | network, or to indicate that the core network is performing or has | |||
actions for this LSP. | completed recovery actions for this LSP. | |||
o An ingress or egress core-node MAY modify internal core network alarms. | o An ingress or egress core-node MAY modify internal core network | |||
This may facilitate the peering E-NNI (i.e. the egress core-node) to | alarms. This may facilitate the peering E-NNI (i.e. the egress | |||
understand the failure and its effect on the data plane, and take | core-node) to understand the failure and its effect on the data | |||
corrective actions in a more-appropriate manner or prolong the | plane, and take corrective actions in a more-appropriate manner or | |||
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 to not request | |||
alarm reporting on Path messages that it sends downstream. | alarm reporting on Path messages that it sends downstream. | |||
o Further, even when alarm reporting is requested along the whole | ||||
length of an end-to-end LSP, an egress or an ingress core-node MAY | ||||
choose to selectively filter alarms that are reported through the | ||||
UNI. This may be to protect information about the whole core network, | ||||
or may reflect the fact that the core network intends to take | ||||
remedial action and does not want the overlay network to operate | ||||
on the alarm information. | ||||
4. Security Considerations | 4. 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. | 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 | This document introduces no additional security considerations. See | |||
[RFC3473] for relevant security considerations. | [RFC3473] for relevant security considerations. | |||
5. IANA Considerations | 5. IANA Considerations | |||
IANA is requested to administer assignment of new values for | IANA is requested to administer assignment of new values for | |||
namespaces defined in this document. This section uses the | namespaces defined in this document. This section uses the | |||
terminology of BCP 26 "Guidelines for Writing an IANA Considerations | terminology of BCP 26 "Guidelines for Writing an IANA Considerations | |||
Section in RFCs" [BCP26]. | Section in RFCs" [BCP26]. | |||
This document defines a new RSVP "ALARM_SPEC object" with a Class-Num | This document defines a new RSVP "ALARM_SPEC object" with a Class-Num | |||
of the form 11bbbbbb. The value 197 is suggested. The C-type values | of the form 11bbbbbb, see section 3.1. The value 197 is suggested. | |||
associated with this object should read "Same values as ERROR_SPEC | The C-type values associated with this object should read "Same | |||
(C-Num 6)". The text associated with ALARM_SPEC object should also | values as ERROR_SPEC (C-Num 6), with the exception of C-Types 1 and 2 | |||
read "The ALARM_SPEC object uses the Error Code and Values from the | which are reserved". The text associated with ALARM_SPEC object | |||
ERROR_SPEC object." | should also read "The ALARM_SPEC objec | |||
t uses the Error Code and | ||||
Values from the ERROR_SPEC object." | ||||
Additionally, Section 3.1.3 defines a new Error Code. The Error Code | Additionally, Section 3.1.3 defines a new Error Code. The Error Code | |||
is "Alarms" and uses Error Values defined in the Alarm MIB [ALARM- | is "Alarms" and uses Error Values defined in the Alarm MIB [RFC3877]. | |||
MIB]. The suggested Error code value is 28. | The suggested Error code value is 28. | |||
This document also defines the TLVs for use with the IF_ID ERROR_SPEC | This document also defines the TLVs for use with the IF_ID ERROR_SPEC | |||
objects defined in [RFC3473]. Please see Section 3.1.1 for a list of | objects defined in [RFC3473]. Please see Section 3.1.1 for a list of | |||
TLV description and (suggested) type values. | TLV description and (suggested) type values. | |||
Note that the type values are not sequential with existing ERROR_SPEC | Note that the type values are not sequential with existing ERROR_SPEC | |||
object TLV assignments. This is intentional and is intended to | object TLV assignments. This is intentional and is intended to | |||
provide space for future error TLVs. | provide space for future error TLVs. | |||
This document also defines the I bit in the Admin Status Object, see | This document also defines the I bit in the Admin Status Object, see | |||
Section 3.2.1. This bit field was originally defined in Section 7.1 | Section 3.2.1. This bit field was originally defined in Section 7.1 | |||
of [RFC3473]. We recommend that IANA being managing assignment of | of [RFC3473]. We recommend that IANA begin managing assignment of | |||
bits in the Admin Status Object, and that the bits be allocated | bits in the Admin Status Object, and that the bits be allocated | |||
through IETF Consensus actions. | through IETF Consensus actions. | |||
6. References | 6. References | |||
6.1. Normative References | 6.1. Normative References | |||
[RFC3471] Berger, L., Editor, "Generalized Multi-Protocol | [RFC3471] Berger, L., Editor, "Generalized Multi-Protocol | |||
Label Switching (GMPLS) Signaling Functional | Label Switching (GMPLS) Signaling Functional | |||
Description", RFC 3471, January 2003. | Description", RFC 3471, January 2003. | |||
[RFC3473] Berger, L., Editor, "Generalized Multi-Protocol Label | [RFC3473] Berger, L., Editor, "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 3473, January 2003. | RFC 3473, January 2003. | |||
[ALARM-MIB] Chisholm, S., Romascanu, D., "Alarm MIB", | [RFC3877] Chisholm, S., Romascanu, D., "Alarm MIB", | |||
draft-ietf-disman-alarm-mib-18.txt, February 2004 | draft-ietf-disman-alarm-mib-18.txt, September 2004. | |||
6.2. Informative References | 6.2. Informative References | |||
[M.20] ITU-T, "MAINTENANCE PHILOSOPHY FOR TELECOMMUNICATION | ||||
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 | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
Requirement Levels," RFC 2119. | Requirement Levels," RFC 2119. | |||
[GMPLS-UNI] Swallow, G., Drake, J., Ishimatsu, H., and Rekhter, Y. | [GMPLS-UNI] Swallow, G., Drake, J., Ishimatsu, H., and Rekhter, Y. | |||
"GMPLS UNI: RSVP Support for the Overlay Model", | "GMPLS UNI: RSVP Support for the Overlay Model", | |||
draft-ietf-ccamp-gmpls-overlay-02.txt, October 2003, | draft-ietf-ccamp-gmpls-overlay-05.txt, October 2004, | |||
work in progress. | work in progress. | |||
[GMPLS-ENNI] Papadimitriou, D., Editor, "Generalized MPLS (GMPLS) | [GMPLS-ENNI] Papadimitriou, D., Editor, "Generalized MPLS (GMPLS) | |||
RSVP-TE Signaling in support of Automatically Switched | RSVP-TE Signaling in support of Automatically Switched | |||
Optical Network (ASON)", | Optical Network (ASON)", | |||
draft-ietf-ccamp-gmpls-rsvp-te-ason-01.txt, January 2004, | draft-ietf-ccamp-gmpls-rsvp-te-ason-02.txt, July 2004, | |||
work in progress. | work in progress. | |||
7. Contributors | 7. Contributors | |||
Contributors are listed in alphabetical order: | Contributors are listed in alphabetical order: | |||
Lou Berger Deborah Brungard | Lou Berger Deborah Brungard | |||
Movaz Networks, Inc. AT&T Labs, Room MT D1-3C22 | Movaz Networks, Inc. AT&T Labs, Room MT D1-3C22 | |||
7926 Jones Branch Drive 200 Laurel Avenue | 7926 Jones Branch Drive 200 Laurel Avenue | |||
Suite 615 | Suite 615 | |||
skipping to change at line 726 | skipping to change at line 738 | |||
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 ietf- | |||
ipr@ietf.org. | ipr@ietf.org. | |||
Generated on: Tue Sep 21 09:52:18 2004 | ||||
End of changes. | ||||
This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/ |