draft-ietf-ccamp-gmpls-alarm-spec-03.txt | draft-ietf-ccamp-gmpls-alarm-spec-04.txt | |||
---|---|---|---|---|
Internet Draft Lou Berger - Editor (Movaz Networks) | Internet Draft Lou Berger - Editor (LabN) | |||
Updates: 3473 | Updates: 3473 | |||
Category: Standards Track | Category: Standards Track | |||
September 2005 | Expiration Date: February 2007 | |||
August 2006 | ||||
GMPLS - Communication of Alarm Information | GMPLS - Communication of Alarm Information | |||
draft-ietf-ccamp-gmpls-alarm-spec-03.txt | draft-ietf-ccamp-gmpls-alarm-spec-04.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 15 | skipping to change at page 2, line 15 | |||
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 ................................... 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 Security Considerations ................................... 14 | |||
5 IANA Considerations ....................................... 15 | 5 IANA Considerations ....................................... 15 | |||
6 References ................................................ 16 | 6 References ................................................ 16 | |||
6.1 Normative References ...................................... 16 | 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 .................................. 17 | 9 Full Copyright Statement .................................. 18 | |||
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 5, line 30 | skipping to change at page 5, line 30 | |||
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). | 11bbbbbb, per Section 3.1.4). | |||
o Class = TBA, C-Type = 1 | o Class = TBA, C-Type = 1 | |||
Reserved. | Reserved. (C-Type value defined for ERROR_SPEC, but is not defined | |||
for use with ALARM_SPEC.) | ||||
o Class = TBA, C-Type = 2 | o Class = TBA, C-Type = 2 | |||
Reserved. | Reserved. (C-Type value defined for ERROR_SPEC, but is not defined | |||
for use with ALARM_SPEC.) | ||||
o IPv4 IF_ID ALARM_SPEC object: Class = TBA, C-Type = 3 | o IPv4 IF_ID ALARM_SPEC object: Class = 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 | |||
skipping to change at page 7, line 25 | skipping to change at page 7, line 25 | |||
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] for more information on severity. The following | [RFC3877] and [M.3100] for more information on severity. The | |||
values are defined: | following values are defined: | |||
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 9, line 35 | skipping to change at page 9, line 35 | |||
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 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. As the InPlace and NotGuilty flags | |||
SHOULD NOT be set. TLVs SHOULD be included in the ALARM_SPEC object | only have meaning in ERROR_SPEC objects, they SHOULD NOT be set. | |||
to identify the interface, if any, associated with the alarm - the | TLVs SHOULD be included in the ALARM_SPEC object to identify the | |||
TLVs defined in [RFC3471] for identifying interfaces in the IF_ID | interface, if any, associated with the alarm - the TLVs defined in | |||
ERROR_SPEC object [RCF3473] SHOULD be used for this purpose, but note | [RFC3471] for identifying interfaces in the IF_ID ERROR_SPEC object | |||
that TLVs type 4 and 5 (component interfaces) are deprecated by | [RFC3473] SHOULD be used for this purpose, but note that TLVs type 4 | |||
[BUNDLE] and SHOULD NOT be used. TLVs SHOULD also be included to | and 5 (component interfaces) are deprecated by [RFC4201] and SHOULD | |||
indicate the severity (Severity TLV), the time (Global Timestamp | NOT be used. TLVs SHOULD also be included to indicate the severity | |||
and/or Local Timestamp TLVs), and a (brief) string (Error String TLV) | (Severity TLV), the time (Global Timestamp and/or Local Timestamp | |||
associated with the alarm. The reference count TLV MAY also be | TLVs), and a (brief) string (Error String TLV) associated with the | |||
included. ALARM_SPEC objects received from other nodes are not | alarm. The reference count TLV MAY also be included to indicate the | |||
effected by the addition of local ALARM_SPEC objects, i.e., they | number of times an alarm has been repeated at the reporting node. | |||
continue to be processed as described above. The choice of which | ALARM_SPEC objects received from other nodes are not effected by the | |||
alarm or alarms to advertise and which to omit is a local policy | addition of local ALARM_SPEC objects, i.e., they continue to be | |||
matter, and may configurable by the user. | processed as described above. The choice of which alarm or alarms to | |||
advertise and which to omit is a local policy 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 | |||
occurrence of an alarm that is relative to other information | occurrence of an alarm that is relative to other information | |||
advertised by the node. The global timestamp SHOULD be used on nodes | advertised by the node. The global timestamp SHOULD be used on nodes | |||
that maintain an absolute time reference. Both timestamp TLVs MAY be | that maintain an absolute time reference. Both timestamp TLVs MAY be | |||
used simultaneously. | used simultaneously. | |||
Note, ALARM_SPEC objects SHOULD NOT be added to the state of LSPs | Note, ALARM_SPEC objects SHOULD NOT be added to the Path and Resv | |||
that are in "alarm communication inhibited state." ALARM_SPEC | states of LSPs that are in "alarm communication inhibited state." | |||
objects MAY be added to the state of LSPs that are in an | ALARM_SPEC objects MAY be added to the state of LSPs that are in an | |||
"administratively down" state. These states are indicated by the I | "administratively down" state. These states are indicated by the I | |||
and A bits of the Admin_Status object, see Section 3.2. | and A bits of the Admin_Status object, see Section 3.2. | |||
To remove local alarm information, a node simply removes the matching | To remove local alarm information, a node simply removes the matching | |||
locally generated ALARM_SPEC objects from the outgoing Path and Resv | locally generated ALARM_SPEC objects from the outgoing Path and Resv | |||
messages. A node MAY modify a locally generated ALARM_SPEC object. | messages. A node MAY modify a locally generated ALARM_SPEC object. | |||
Normal refresh and trigger message processing applies to Path or Resv | Normal refresh and trigger message processing applies to Path or Resv | |||
messages that contain ALARM_SPEC objects. Note that changes in | messages that contain ALARM_SPEC objects. Note that changes in | |||
ALARM_SPEC objects from one message to the next may include a | ALARM_SPEC objects from one message to the next may include a | |||
modification in the contents of a specific ALARM_SPEC object, or a | modification in the contents of a specific ALARM_SPEC object, or a | |||
change in the number of ALARM_SPEC objects present. All changes in | change in the number of ALARM_SPEC objects present. All changes in | |||
ALARM_SPEC objects SHOULD be processed as trigger messages. | ALARM_SPEC objects SHOULD be processed as trigger messages. | |||
Failure to follow the above directives, in particular the ones | ||||
labeled "SHOULD" and "SHOULD NOT", may result in the alarm | ||||
information not being properly or fully communicated. | ||||
3.1.3. Error Codes and Values | 3.1.3. Error Codes and Values | |||
The Error Codes and Values used in ALARM_SPEC objects are the same as | The Error Codes and Values used in ALARM_SPEC objects are the same as | |||
those used in ERROR_SPEC objects. New Error Code values for use with | those used in ERROR_SPEC objects. New Error Code values for use with | |||
both ERROR_SPEC and ALARM_SPEC objects may be assigned to support | both ERROR_SPEC and ALARM_SPEC objects may be assigned to support | |||
alarm types defined by other standards. | alarm types defined by other standards. | |||
In this document we define one new Error Code. The Error Code uses | In this document we define one new Error Code. The Error Code uses | |||
the value TBA (by IANA) and is referred to as "Alarms". The values | the value 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 | |||
skipping to change at page 13, line 23 | skipping to change at page 13, line 23 | |||
[ <NOTIFY_REQUEST> ] | [ <NOTIFY_REQUEST> ] | |||
[ <ADMIN_STATUS> ] | [ <ADMIN_STATUS> ] | |||
[ <POLICY_DATA> ... ] | [ <POLICY_DATA> ... ] | |||
[ <ALARM_SPEC> ... ] | [ <ALARM_SPEC> ... ] | |||
<STYLE> <flow descriptor list> | <STYLE> <flow descriptor list> | |||
<flow descriptor list> is not modified by this document. | <flow descriptor list> is not modified by this document. | |||
3.4. Relationship to GMPLS UNI | 3.4. Relationship to GMPLS UNI | |||
[GMPLS-UNI] defines how GMPLS may be used in an overlay model to | [RFC4208] defines how GMPLS may be used in an overlay model to | |||
provide a user-to-network interface. In this model, restrictions may | provide a user-to-network interface. In this model, restrictions may | |||
be applied to the information that is signaled between an edge-node | be applied to the information that is signaled between an edge-node | |||
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 [RFC4208]. In particular the following | |||
observations apply. | observations apply. | |||
o An ingress or egress core-node MAY filter alarms from the GMPLS | o An ingress or egress core-node MAY filter alarms from the GMPLS | |||
core to a client-node UNI LSP. This may be to protect information | core to a client-node UNI LSP. This may be to protect information | |||
about the core network, or to indicate that the core network is | about the core network, or to indicate that the core network is | |||
performing or has completed recovery actions for the GMPLS LSP. | performing or has completed recovery actions for the GMPLS LSP. | |||
o An ingress or egress core-node MAY modify alarms from the GMPLS | o An ingress or egress core-node MAY modify alarms from the GMPLS | |||
core when sending to a client-node UNI LSP. This may facilitate | core when sending to a client-node UNI LSP. This may facilitate | |||
the UNI client's ability to understand the failure and its effect | the UNI client's ability to understand the failure and its effect | |||
on the data plane, and enable the UNI client to take corrective | on the data plane, and enable the UNI client to take corrective | |||
actions in a more-appropriate manner. | actions in a more-appropriate manner. | |||
o Similarly, an egress core-node MAY choose to not request alarm | o Similarly, an egress core-node MAY choose 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. | |||
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-ENNI]. At this interface, restrictions may be | interface, see [ASON-APPL]. At this interface, restrictions may be | |||
applied to the information that is signaled between an egress and an | applied to the information that is signaled between an egress and an | |||
ingress core-node. | ingress core-node. | |||
This restriction allows the ingress core network to limit the | This restriction allows the ingress core network to limit the | |||
information that is visible outside of its core network. This | information that is visible outside of its core network. This | |||
restriction may be made for confidentiality, privacy or security | restriction may be made for confidentiality, privacy or security | |||
reasons. It may also be made for operational reasons, for example if | reasons. It may also be made for operational reasons, for example 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-ENNI]. In particular the following | filtering as described in [ASON-APPL]. In particular the following | |||
observations apply. | observations apply. | |||
o An ingress or egress core-node MAY filter internal core network | o An ingress or egress core-node MAY filter internal core network | |||
alarms. This may be to protect information about the internal | alarms. This may be to protect information about the internal | |||
network, or to indicate that the core network is performing or has | network, or to indicate that the core network is performing or has | |||
completed recovery actions for this LSP. | completed recovery actions for this LSP. | |||
o An ingress or egress core-node MAY modify internal core network | o An ingress or egress core-node MAY modify internal core network | |||
alarms. This may facilitate the peering E-NNI (i.e. the egress | alarms. This may facilitate the peering E-NNI (i.e. the egress | |||
core-node) to understand the failure and its effect on the data | core-node) to understand the failure and its effect on the data | |||
plane, and take corrective actions in a more-appropriate manner or | plane, and take corrective actions in a more-appropriate manner or | |||
prolong the generated alarms upstream/downstream as appropriated. | prolong the generated alarms upstream/downstream as appropriated. | |||
o Similarly, an egress/ingress core-node MAY choose to not request | o Similarly, an egress/ingress core-node MAY choose to not request | |||
alarm reporting on Path messages that it sends downstream. | alarm reporting on Path messages that it sends downstream. | |||
.Pa "Acknowledgments" | ||||
Valuable comments and input were received from a number of people, | ||||
including Wes Doonan, Bert for the DISMAN reference, Tom Petch for | ||||
getting the disman WG interactions started. We also thank David | ||||
Black for his valuable comments. | ||||
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. | |||
skipping to change at page 15, line 29 | skipping to change at page 15, line 35 | |||
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 object uses the Error Code and | should also read "The ALARM_SPEC object 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 RSVP Error Code. The Error | Additionally, Section 3.1.3 defines a new RSVP Error Code. The Error | |||
Code is "Alarms" and uses Error Values defined in the Alarm MIB | Code is "Alarms" and uses Error Values defined in the Alarm MIB | |||
[RFC3877]. 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 RSVP IF_ID | This document also defines the TLVs for use with the RSVP IF_ID | |||
ERROR_SPEC objects defined in [RFC3473]. Please see Section 3.1.1 | ERROR_SPEC objects defined in [RFC3473]. The following are the TLV | |||
for a list of TLV descriptions and (suggested) type 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 | Note that the type values are not sequential with existing RSVP IF_ID | |||
ERROR_SPEC object TLV assignments. This is intentional and is | ERROR_SPEC object TLV assignments. This is intentional and is | |||
intended to 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 request IANA to begin managing assignment of bits | of [RFC3473]. We request IANA to begin managing assignment of bits | |||
in the Admin Status Object, and that the bits be allocated through | in the Admin Status Object, and that the bits be allocated through | |||
IETF Consensus actions. Within the 32 bit field in the Admin Status | IETF Consensus actions. Within the 32 bit field in the Admin Status | |||
skipping to change at page 16, line 18 | skipping to change at page 16, line 29 | |||
[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 MIB", | [RFC3877] Chisholm, S., Romascanu, D., "Alarm Management | |||
draft-ietf-disman-alarm-mib-18.txt, September 2004. | Information Base (MIB)", RFC 3877, September 2004. | |||
[M.3100] ITU Recommendation M.3100, "Generic Network Information | ||||
Model", 1995 | ||||
6.2. Informative References | 6.2. Informative References | |||
[RFC4201] Kompella, K., Rekhter, Y., Berger, L., "Link Bundling | ||||
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 | [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. | [RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Rekhter, Y. | |||
"GMPLS UNI: RSVP Support for the Overlay Model", | "Generalized Multiprotocol Label Switching (GMPLS) | |||
draft-ietf-ccamp-gmpls-overlay-05.txt, October 2004, | User-Network Interface (UNI): Resource ReserVation | |||
work in progress. | Protocol-Traffic Engineering (RSVP-TE) Support for the | |||
Overlay Model", RFC 4208, October 2005. | ||||
[GMPLS-ENNI] Papadimitriou, D., Editor, "Generalized MPLS (GMPLS) | [ASON-APPL] D. Papadimitriou et. al., "Generalized MPLS (GMPLS) | |||
RSVP-TE Signaling in support of Automatically Switched | RSVP-TE signaling usage in support of Automatically | |||
Optical Network (ASON)", | Switched Optical Network (ASON)," | |||
draft-ietf-ccamp-gmpls-rsvp-te-ason-02.txt, July 2004, | draft-ietf-ccamp-gmpls-rsvp-te-ason, 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 | LabN Consulting, L.L.C. AT&T Labs, Room MT D1-3C22 | |||
7926 Jones Branch Drive 200 Laurel Avenue | 200 Laurel Avenue | |||
Suite 615 | Middletown, NJ 07748, USA | |||
McLean VA, 22102, USA Middletown, NJ 07748, USA | Phone: +1 301-468-9228 Phone: (732) 420-1573 | |||
Phone: +1 703 847-1801 Phone: (732) 420-1573 | Email: lberger@labn.net 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, 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 | 8. Contact Address | |||
Lou Berger | Lou Berger | |||
Movaz Networks, Inc. | LabN Consulting, L.L.C. | |||
7926 Jones Branch Drive | Phone: +1 301-468-9228 | |||
Suite 615 | Email: lberger@labn.net | |||
McLean VA, 22102 | ||||
Phone: +1 703 847-1801 | ||||
Email: lberger@movaz.com | ||||
9. Full Copyright Statement | 9. Full Copyright Statement | |||
Copyright (C) The Internet Society (2005). 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. | |||
skipping to change at line 767 | skipping to change at line 794 | |||
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 | Generated on: Mon Aug 14 06:52:31 EDT 2006 | |||
End of changes. 27 change blocks. | ||||
58 lines changed or deleted | 85 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/ |