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/