draft-ietf-ccamp-gmpls-alarm-spec-02.txt | draft-ietf-ccamp-gmpls-alarm-spec-03.txt | |||
---|---|---|---|---|
Internet Draft Lou Berger - Editor (Movaz Networks) | Internet Draft Lou Berger - Editor (Movaz Networks) | |||
Updates: 3473 | Updates: 3473 | |||
Category: Standards Track | Category: Standards Track | |||
Expiration Date: May 2005 | Expiration Date: March 2006 | |||
November 2004 | September 2005 | |||
GMPLS - Communication of Alarm Information | GMPLS - Communication of Alarm Information | |||
draft-ietf-ccamp-gmpls-alarm-spec-02.txt | draft-ietf-ccamp-gmpls-alarm-spec-03.txt | |||
Status of this Memo | Status of this Memo | |||
By submitting this Internet-Draft, I certify that any applicable | By submitting this Internet-Draft, each author represents that any | |||
patent or other IPR claims of which I am aware have been disclosed, | applicable patent or other IPR claims of which he or she is aware | |||
or will be disclosed, and any of which I become aware will be | have been or will be disclosed, and any of which he or she becomes | |||
disclosed, in accordance with RFC 3668. | aware will be disclosed, in accordance with Section 6 of BCP 79. | |||
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 | |||
other groups may also distribute working documents as Internet- | other groups may also distribute working documents as Internet- | |||
Drafts. | Drafts. | |||
Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
material or to cite them other than a "work in progress." | material or to cite them other than as "work in progress." | |||
The list of current Internet-Drafts can be accessed at | The list of current Internet-Drafts can be accessed at | |||
http://www.ietf.org/1id-abstracts.html | http://www.ietf.org/1id-abstracts.html | |||
The list of Internet-Draft Shadow Directories can be accessed at | The list of Internet-Draft Shadow Directories can be accessed at | |||
http://www.ietf.org/shadow.html | 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 | ||||
Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic | ||||
Engineering (RSVP-TE) Extensions" through the addition of new, | ||||
optional protocol elements. It does not change, and is fully backward | ||||
compatible with the procedures specified in RFC 3473. | ||||
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 .................... 6 | 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 ........................... 11 | 3.2 Controlling Alarm Communication ........................... 11 | |||
3.2.1 Updated Admin Status Object ............................... 11 | 3.2.1 Updated Admin Status Object ............................... 11 | |||
3.2.2 Procedures ................................................ 11 | 3.2.2 Procedures ................................................ 11 | |||
3.3 Message Formats ........................................... 12 | 3.3 Message Formats ........................................... 12 | |||
3.4 Relationship to GMPLS UNI ................................. 13 | 3.4 Relationship to GMPLS UNI ................................. 13 | |||
3.5 Relationship to GMPLS E-NNI .............................. 14 | 3.5 Relationship to GMPLS E-NNI .............................. 14 | |||
4 Security Considerations ................................... 14 | 4 Security Considerations ................................... 14 | |||
5 IANA Considerations ....................................... 15 | 5 IANA Considerations ....................................... 15 | |||
6 References ................................................ 15 | 6 References ................................................ 16 | |||
6.1 Normative References ...................................... 15 | 6.1 Normative References ...................................... 16 | |||
6.2 Informative References .................................... 16 | 6.2 Informative References .................................... 16 | |||
7 Contributors .............................................. 17 | 7 Contributors .............................................. 17 | |||
8 Contact Address ........................................... 17 | 8 Contact Address ........................................... 17 | |||
9 Full Copyright Statement .................................. 18 | 9 Full Copyright Statement .................................. 17 | |||
10 Intellectual Property ..................................... 18 | 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 4, line 16 | 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 | |||
exa | exacerbated by the absence of any way to communicate that a problem | |||
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 7, line 48 | skipping to change at page 8, line 4 | |||
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 26 | skipping to change at page 8, line 25 | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Type | Length | | | Type | Length | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Local Timestamp | | | Local Timestamp | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
Local Timestamp: 32 bits | Local Timestamp: 32 bits | |||
Number of seconds reported by the local system clock at the | Number of seconds reported by the local system clock at the | |||
time the associated alarm was detected on the node that | time the associated alarm was detected on the node that | |||
originates this TLV. | originates this TLV. This number is expected to be meaningful | |||
in the context of the originating node. For example, it may | ||||
indicate the number of seconds since the node rebooted or may | ||||
be a local representation of an unsynchronized real-time clock. | ||||
Only one Local Timestamp TLV may be included in an object. | Only one Local Timestamp TLV may be included in an object. | |||
The Error String TLV has the following format: | The Error String 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 | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | | | | | |||
// 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 in US-ASCII, representing the type of | |||
This string is padded to the next largest 4 byte boundary using | error/alarm. This string is padded to the next largest 4 byte | |||
null characters. Null padding is not required when the string | boundary using null characters. Null padding is not required | |||
is 32-bit aligned. The contents of error string are | when the string is 32-bit aligned. The contents of error | |||
implementation dependent. See the condition types listed in | string are implementation dependent. See the condition types | |||
Appendices of [GR833] for a list of example strings. Note | listed in Appendices of [GR833] for a list of example strings. | |||
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 | |||
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. | messages. Multiple ALARM_SPEC objects MAY be present. | |||
Nodes that support the communication of alarm information, SHOULD | Nodes that support the communication of alarm information, SHOULD | |||
skipping to change at page 9, line 36 | skipping to change at page 9, line 36 | |||
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 effected LSP. In all cases, appropriate Error Node Address, | for the effected LSP. 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. TLVs SHOULD be included to identify the | SHOULD NOT be set. TLVs SHOULD be included in the ALARM_SPEC object | |||
interface, if any, the severity, the time and a (brief) string | to identify the interface, if any, associated with the alarm - the | |||
TLVs defined in [RFC3471] for identifying interfaces in the IF_ID | ||||
ERROR_SPEC object [RCF3473] SHOULD be used for this purpose, but note | ||||
that TLVs type 4 and 5 (component interfaces) are deprecated by | ||||
[BUNDLE] and SHOULD NOT be used. TLVs SHOULD also be included to | ||||
indicate the severity (Severity TLV), the time (Global Timestamp | ||||
and/or Local Timestamp TLVs), and a (brief) string (Error String TLV) | ||||
associated with the alarm. The reference count TLV MAY also be | associated with the alarm. The reference count TLV MAY also be | |||
included. ALARM_SPEC objects received from other nodes are not | included. ALARM_SPEC objects received from other nodes are not | |||
effected by the addition of local ALARM_SPEC objects, i.e., they | effected by the addition of local ALARM_SPEC objects, i.e., they | |||
continue to be processed as described above. The choice of which | continue to be processed as described above. The choice of which | |||
alarm or alarms to advertise and which to omit is a local policy | alarm or alarms to advertise and which to omit is a local policy | |||
matter, and may configurable by the user. | matter, and may 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 | |||
skipping to change at page 11, line 30 | skipping to change at page 11, line 31 | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| 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 [RFC3471] for the definition of the remaining bits. | See section 7.1 of [RFC3473] 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 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 | (or generates) an Admin_Status object with the A and I bits clear (0) | |||
(0), it SHOULD add any local alarm information to the matching LSP's | and there is local alarm information present, it SHOULD add the local | |||
outgoing Path and Resv messages. | alarm information to the matching LSP's outgoing Path and Resv | |||
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, per | |||
[RFC3473], the absence of the Admin_Status object is equivalent to | [RFC3473], the absence of the Admin_Status object is equivalent to | |||
receiving an object containing values all set to zero (0). | 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. | |||
skipping to change at page 15, line 5 | skipping to change at page 14, line 46 | |||
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, 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 | ||||
breached, alarm information may be spoofed. Such spoofing would be at | ||||
most annoying and cause slight degradation of control plane | ||||
performance since the details are provided for information only and | ||||
do not result in protocol actions beyond the exchange of messages to | ||||
convey the information. If the protocol security is able to be | ||||
breached sufficiently to allow spoofing of alarm information then | ||||
considerably more interesting and exciting damage can be caused by | ||||
spoofing other elements of the protocol messages. | ||||
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 and reviewed in this section. | |||
terminology of BCP 26 "Guidelines for Writing an IANA Considerations | This section uses the terminology of BCP 26 "Guidelines for Writing | |||
Section in RFCs" [BCP26]. | an IANA Considerations 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, see section 3.1. The value 197 is suggested. | of the form 11bbbbbb, see section 3.1. The value 197 is suggested. | |||
The C-type values associated with this object should read "Same | The C-type values associated with this object should read "Same | |||
values as ERROR_SPEC (C-Num 6), with the exception of C-Types 1 and 2 | values as ERROR_SPEC (C-Num 6), with the exception of C-Types 1 and 2 | |||
which are reserved". The text associated with ALARM_SPEC object | which are reserved". The text associated with ALARM_SPEC object | |||
should also read "The ALARM_SPEC objec | should also read "The ALARM_SPEC object uses the Error Code and | |||
t uses the Error Code and | ||||
Values from the ERROR_SPEC object." | 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 RSVP Error Code. The Error | |||
is "Alarms" and uses Error Values defined in the Alarm MIB [RFC3877]. | Code is "Alarms" and uses Error Values defined in the Alarm MIB | |||
The suggested Error code value is 28. | [RFC3877]. 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 RSVP IF_ID | |||
objects defined in [RFC3473]. Please see Section 3.1.1 for a list of | ERROR_SPEC objects defined in [RFC3473]. Please see Section 3.1.1 | |||
TLV description and (suggested) type values. | for a list of TLV descriptions 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 RSVP IF_ID | |||
object TLV assignments. This is intentional and is intended to | ERROR_SPEC object TLV assignments. This is intentional and is | |||
provide space for future error TLVs. | intended to 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 begin managing assignment of | of [RFC3473]. We request IANA to begin managing assignment of bits | |||
bits in the Admin Status Object, and that the bits be allocated | in the Admin Status Object, and that the bits be allocated through | |||
through IETF Consensus actions. | IETF Consensus actions. Within the 32 bit field in the Admin Status | |||
Object, the defined bits are: | ||||
Value Name Reference | ||||
---------- --------------------------------- ----------------- | ||||
0x80000000 Reflect (R) [RFC3473/RFC3471] | ||||
0x00000010 Inhibit Alarm Communication (I) [This document] | ||||
0x00000004 Testing (T) [RFC3473/RFC3471] | ||||
0x00000002 Administratively down (A) [RFC3473/RFC3471] | ||||
0x00000001 Deletion in progress (D) [RFC3473/RFC3471] | ||||
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 | |||
skipping to change at page 17, line 13 | skipping to change at page 17, line 13 | |||
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 | |||
McLean VA, 22102 Middletown, NJ 07748, USA | McLean VA, 22102, USA Middletown, NJ 07748, USA | |||
Phone: +1 703 847-1801 Phone: (732) 420-1573 | Phone: +1 703 847-1801 Phone: (732) 420-1573 | |||
Email: lberger@movaz.com Email: dbrungard@att.com | Email: lberger@movaz.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 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 Movaz Networks, Inc. | Francis Wellesplein 1 Cisco Systems, Inc | |||
B-2018 Antwerpen, Belgium 7926 Jones Branch Drive | B-2018 Antwerpen, Belgium 170 West Tasman Dr. | |||
Suite 615 | San Jose, CA 95134 USA | |||
McLean VA, 22102 | Phone: +32 3 240-8491 Phone: +1 408 853-3206 | |||
Phone: +32 3 240-8491 Phone: +1 703 847-1785 | Email: dimitri.papadimitriou@alcatel.be Email: asatyana@cisco.com | |||
Email: dimitri.papadimitriou@alcatel.be Email: aruns@movaz.com | ||||
8. Contact Address | 8. Contact Address | |||
Lou Berger | Lou Berger | |||
Movaz Networks, Inc. | Movaz Networks, Inc. | |||
7926 Jones Branch Drive | 7926 Jones Branch Drive | |||
Suite 615 | Suite 615 | |||
McLean VA, 22102 | McLean VA, 22102 | |||
Phone: +1 703 847-1801 | Phone: +1 703 847-1801 | |||
Email: lberger@movaz.com | Email: lberger@movaz.com | |||
9. Full Copyright Statement | 9. Full Copyright Statement | |||
Copyright (C) The Internet Society (2004). This document is subject | Copyright (C) The Internet Society (2005). This document is subject | |||
to the rights, licenses and restrictions contained in BCP 78, and | to the rights, licenses and restrictions contained in BCP 78, and | |||
except as set forth therein, the authors retain all their rights. | 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 AND THE INTERNET | |||
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, | ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, | |||
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE | INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE | |||
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED | INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED | |||
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. | WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. | |||
skipping to change at line 738 | skipping to change at line 768 | |||
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: Fri Sep 9 11:00:37 EDT 2005 | ||||
End of changes. | ||||
This html diff was produced by rfcdiff 1.25, available from http://www.levkowetz.com/ietf/tools/rfcdiff/ |