draft-ietf-ccamp-gmpls-alarm-spec-04.txt   draft-ietf-ccamp-gmpls-alarm-spec-05.txt 
Internet Draft Lou Berger - Editor (LabN) Internet Draft Lou Berger - Editor (LabN)
Updates: 3473 Updates: 3473
Category: Standards Track Category: Standards Track
Expiration Date: February 2007 September 2006
August 2006
GMPLS - Communication of Alarm Information GMPLS - Communication of Alarm Information
draft-ietf-ccamp-gmpls-alarm-spec-04.txt draft-ietf-ccamp-gmpls-alarm-spec-05.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. 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
skipping to change at page 2, line 7 skipping to change at page 2, line 7
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 backward
compatible with the procedures specified in RFC 3473. 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 ................................... 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 ............................... 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 Acknowledgements ........................................ 14
5 IANA Considerations ....................................... 15 5 Security Considerations ................................. 14
6 References ................................................ 16 6 IANA Considerations ..................................... 15
6.1 Normative References ...................................... 16 6.1 New RSVP Object ......................................... 15
6.2 Informative References .................................... 16 6.2 New Interface ID Types .................................. 16
7 Contributors .............................................. 17 6.3 New Registry for Admin-Status Object Bit Fields ......... 16
8 Contact Address ........................................... 17 6.4 New RSVP Error Code ..................................... 16
9 Full Copyright Statement .................................. 18 7 References .............................................. 17
10 Intellectual Property ..................................... 18 7.1 Normative References .................................... 17
7.2 Informative References .................................. 17
8 Contributors ............................................ 18
9 Contact Address ......................................... 18
10 Full Copyright Statement ................................ 18
11 Intellectual Property ................................... 19
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 5, line 23 skipping to change at page 5, line 24
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 TBA (to be assigned by IANA in the form
11bbbbbb, per Section 3.1.4). 11bbbbbb, per Section 3.1.4).
o Class = TBA, C-Type = 1 o Class = TBA, 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 defined
skipping to change at page 6, line 11 skipping to change at page 6, line 11
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 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] [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
skipping to change at page 6, line 39 skipping to change at page 6, line 39
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. a TLV is sent and a received TLV 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: 24 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: The following values are defined in this document. The details
of the semantics may be found in [M.20].
Value Definition Value Definition
----- --------------------- ----- ---------------------
0 Unspecified impact 0 Unspecified impact
1 Non-Service Affecting (Data traffic not interrupted) 1 Non-Service Affecting (Data traffic not interrupted)
2 Service Affecting (Data traffic is interrupted) 2 Service Affecting (Data traffic is interrupted)
Severity: 8 bits Severity: 8 bits
Indicates the impact of the alarm indicated in the TLV. See Indicates the impact of the alarm indicated in the TLV. See
[RFC3877] and [M.3100] for more information on severity. The [RFC3877] and [M.3100] for more information on severity. The
following values are defined: The following values are defined in this document. The details
of the semantics may be found in [RFC3877] and [M.3100].
Value Definition Value Definition
----- ---------- ----- ----------
0 Cleared 0 Cleared
1 Indeterminate 1 Indeterminate
2 Critical 2 Critical
3 Major 3 Major
4 Minor 4 Minor
5 Warning 5 Warning
skipping to change at page 8, line 6 skipping to change at page 8, line 6
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Global Timestamp: 32 bits Global Timestamp: 32 bits
The number of seconds since 0000 UT on 1 January 1970, A positive integer where all 32 bits are valid that indicates
according to the clock on the node that originates this TLV. the number of seconds since 0000 UT on 1 January 1970 according
to the clock on the node that originates this TLV. This time
MAY include leap seconds if they are used by the local clock.
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
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 9, line 22 skipping to change at page 9, line 22
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
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 extensions defined in this document SHOULD
record the information contained in a received ALARM_SPEC for later store any alarm information from received ALARM_SPEC objects for
use. All ALARM_SPEC objects received in Path messages SHOULD be future use. All ALARM_SPEC objects received in Path messages SHOULD
passed unmodified downstream in the corresponding Path messages. All be passed unmodified downstream in the corresponding Path messages.
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 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. As the InPlace and NotGuilty flags on Error Code and Error Values. As the InPlace and NotGuilty flags
only have meaning in ERROR_SPEC objects, they SHOULD NOT be set. only have meaning in ERROR_SPEC objects, they SHOULD NOT be set.
skipping to change at page 10, line 45 skipping to change at page 10, line 45
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 when the Error Code is "Alarms" are
IANAItuProbableCause in the Alarm MIB [RFC3877]. Note these values the same as the values defined in the IANAItuProbableCause Textual
are managed by IANA, see http://www.iana.org. Convention of IANA-ITU-ALARM-TC-MIB in the Alarm MIB [RFC3877]. Note
these 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 pass the objects through the node unmodified, because the will (according to the rules defined in [RFC2205]) pass the objects
ALARM_SPEC object has a C-Num of the form 11bbbbbb. through the node unmodified, because the 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
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
skipping to change at page 14, line 36 skipping to change at page 14, line 36
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 to not request
alarm reporting on Path messages that it sends downstream. alarm reporting on Path messages that it sends downstream.
.Pa "Acknowledgments" 4. Acknowledgments
Valuable comments and input were received from a number of people, Valuable comments and input were received from a number of people,
including Wes Doonan, Bert for the DISMAN reference, Tom Petch for including Wes Doonan, Bert Wijnen for the DISMAN reference, Tom Petch
getting the disman WG interactions started. We also thank David for getting the disman WG interactions started. We also thank David
Black for his valuable comments. Black, Lars Eggert, Russ Housley, Dan Romascanu, and Magnus
Westerlund, for their valuable comments.
4. Security Considerations 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 at
most annoying and cause slight degradation of control plane 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.
5. IANA Considerations 6. 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 and reviewed in this section. namespaces defined in this document and reviewed in this section.
This section uses the terminology of BCP 26 "Guidelines for Writing
an IANA Considerations Section in RFCs" [BCP26].
This document defines a new RSVP "ALARM_SPEC object" with a Class-Num 6.1. New RSVP Object
of the form 11bbbbbb, see section 3.1. The value 197 is suggested.
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
which are reserved". The text associated with ALARM_SPEC object
should also read "The ALARM_SPEC object uses the Error Code and
Values from the ERROR_SPEC object."
Additionally, Section 3.1.3 defines a new RSVP Error Code. The Error Upon approval of this document, the IANA will make the following
Code is "Alarms" and uses Error Values defined in the Alarm MIB assignments in the "Class Names, Class Numbers, and Class Types"
[RFC3877]. The suggested Error Code value is 28. section of the "RSVP PARAMETERS" registry located at
http://www.iana.org/assignments/rsvp-parameters
This document also defines the TLVs for use with the RSVP IF_ID A new class named ALARM_SPEC will be created in the 11bbbbbb range
ERROR_SPEC objects defined in [RFC3473]. The following are the TLV (197 suggested) with following values
descriptions and (suggested) type values listed in Section 3.1.1:
Type Length Description
----------------------------------
512 8 REFERENCE_COUNT
513 8 SEVERITY
514 8 GLOBAL_TIMESTAMP
515 8 LOCAL_TIMESTAMP
516 variable ERROR_STRING
Note that the type values are not sequential with existing RSVP IF_ID o Class = TBA, C-Type = 1
ERROR_SPEC object TLV assignments. This is intentional and is [RFC-ccamp-gmpls-alarm-spec]
intended to provide space for future error TLVs. Reserved. (C-Type value defined for ERROR_SPEC, but is not defined
for use with ALARM_SPEC.)
This document also defines the I bit in the Admin Status Object, see o Class = TBA, C-Type = 2
Section 3.2.1. This bit field was originally defined in Section 7.1 [RFC-ccamp-gmpls-alarm-spec]
of [RFC3473]. We request IANA to begin managing assignment of bits Reserved. (C-Type value defined for ERROR_SPEC, but is not defined
in the Admin Status Object, and that the bits be allocated through for use with ALARM_SPEC.)
IETF Consensus actions. Within the 32 bit field in the Admin Status
Object, the defined bits are: o IPv4 IF_ID ALARM_SPEC object: Class = TBA, C-Type = 3
[RFC-ccamp-gmpls-alarm-spec]
Definition same as IPv4 IF_ID ERROR_SPEC [RFC3473].
o IPv6 IF_ID ALARM_SPEC object: Class = TBA, C-Type = 4
[RFC-ccamp-gmpls-alarm-spec]
Definition same as IPv6 IF_ID ERROR_SPEC [RFC3473].
The ALARM_SPEC object uses the Error Code and Error Values from the
ERROR_SPEC object.
6.2. New Interface ID Types
Upon approval of this document, the IANA will make the following
assignments in the "Interface_ID Types" section of the "GMPLS
Signaling Parameters" registry located at
http://www.iana.org/assignments/gmpls-sig-parameters
xx2 8 REFERENCE_COUNT [RFC-ccamp-gmpls-alarm-spec]
xx3 8 SEVERITY [RFC-ccamp-gmpls-alarm-spec]
xx4 8 GLOBAL_TIMESTAMP [RFC-ccamp-gmpls-alarm-spec]
xx5 8 LOCAL_TIMESTAMP [RFC-ccamp-gmpls-alarm-spec]
xx6 variable ERROR_STRING [RFC-ccamp-gmpls-alarm-spec]
(The value of 51 is suggested for xx.)
6.3. New Registry for Admin-Status Object Bit Fields
Upon approval of this document, the IANA will create a new section
titled "Administrative Status Information Flags" in the "GMPLS
Signaling Parameters" registry located at
http://www.iana.org/assignments/gmpls-sig-parameters and make the
following assignments:
Value Name Reference Value Name Reference
---------- --------------------------------- ----------------- ---------- --------------------------------- -----------------
0x80000000 Reflect (R) [RFC3473/RFC3471] 0x80000000 Reflect (R) [RFC3473/RFC3471]
0x00000010 Inhibit Alarm Communication (I) [This document] 0x00000010 Inhibit Alarm Communication (I)
[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. References 6.4. New RSVP Error Code
6.1. Normative References Upon approval of this document, the IANA will make the following
assignments in the "Error Codes and Values" section of the "RSVP
PARAMETERS" registry located at
http://www.iana.org/assignments/rsvp-parameters
xx Alarms [RFC4124]
The Error Value sub-codes for this Error Code have values and
meanings identical to the values and meanings defined in the
IANAItuProbableCause Textual Convention of IANA-ITU-ALARM-TC-MIB
in the Alarm MIB [RFC3877]. Note these values are already
managed the IANA.
(The value of 31 is suggested for xx.)
7. References
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels," RFC 2119.
[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.
[RFC3877] Chisholm, S., Romascanu, D., "Alarm Management [RFC3877] Chisholm, S., Romascanu, D., "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
6.2. Informative References 7.2. Informative References
[RFC4201] Kompella, K., Rekhter, Y., Berger, L., "Link Bundling [RFC4201] Kompella, K., Rekhter, Y., Berger, L., "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
Requirement Levels," RFC 2119.
[RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Rekhter, Y. [RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Rekhter, Y.
"Generalized Multiprotocol Label Switching (GMPLS) "Generalized Multiprotocol Label Switching (GMPLS)
User-Network Interface (UNI): Resource ReserVation User-Network Interface (UNI): Resource ReserVation
Protocol-Traffic Engineering (RSVP-TE) Support for the Protocol-Traffic Engineering (RSVP-TE) Support for the
Overlay Model", RFC 4208, October 2005. Overlay Model", RFC 4208, October 2005.
[ASON-APPL] D. Papadimitriou et. al., "Generalized MPLS (GMPLS) [ASON-APPL] D. Papadimitriou 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),"
draft-ietf-ccamp-gmpls-rsvp-te-ason, work in progress. draft-ietf-ccamp-gmpls-rsvp-te-ason, work in progress.
7. Contributors 8. Authors' Addresses
Contributors are listed in alphabetical order: Contributors are listed in alphabetical order:
Lou Berger Deborah Brungard Lou Berger Deborah Brungard
LabN Consulting, L.L.C. AT&T Labs, Room MT D1-3C22 LabN Consulting, L.L.C. 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: +1 301-468-9228 Phone: (732) 420-1573
Email: lberger@labn.net Email: dbrungard@att.com Email: lberger@labn.net Email: dbrungard@att.com
skipping to change at page 17, line 41 skipping to change at page 18, line 30
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
8. Contact Address 9. Contact 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
9. Full Copyright Statement 10. Full Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject Copyright (C) The Internet Society (2006). 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.
10. Intellectual Property 11. 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.
skipping to change at line 793 skipping to change at line 841
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: Mon Aug 14 06:52:31 EDT 2006
 End of changes. 34 change blocks. 
96 lines changed or deleted 144 lines changed or added

This html diff was produced by rfcdiff 1.32. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/