draft-ietf-ccamp-gmpls-segment-recovery-02.txt   draft-ietf-ccamp-gmpls-segment-recovery-03.txt 
Internet Draft Louis Berger (Movaz Networks) Internet Draft Lou Berger (LabN)
Updates: 3473 Igor Bryskin (Movaz Networks) Updates: 3473, [E2E-RECOVERY] Igor Bryskin (Movaz Networks)
Category: Standards Track Dimitri Papadimitriou (Alcatel) Category: Standards Track Dimitri Papadimitriou (Alcatel)
Expiration Date: November 2005 Adrian Farrel (Old Dog Consulting) Expiration Date: April 2007 Adrian Farrel (Old Dog Consulting)
October 2006
GMPLS Based Segment Recovery GMPLS Based Segment Recovery
draft-ietf-ccamp-gmpls-segment-recovery-02.txt draft-ietf-ccamp-gmpls-segment-recovery-03.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 27 skipping to change at page 2, line 27
4.1 Secondary Explicit Route Object Format .................... 8 4.1 Secondary Explicit Route Object Format .................... 8
4.1.1 Protection Subobject ...................................... 8 4.1.1 Protection Subobject ...................................... 8
4.2 Explicit Control Procedures ............................... 9 4.2 Explicit Control Procedures ............................... 9
4.2.1 Branch Failure Handling ................................... 11 4.2.1 Branch Failure Handling ................................... 11
4.2.2 Resv Message Processing ................................... 12 4.2.2 Resv Message Processing ................................... 12
4.2.3 Admin Status Change ....................................... 12 4.2.3 Admin Status Change ....................................... 12
4.2.4 Recovery LSP Tear Down .................................... 12 4.2.4 Recovery LSP Tear Down .................................... 12
4.3 Tear Down From Non-Ingress Nodes .......................... 13 4.3 Tear Down From Non-Ingress Nodes .......................... 13
4.3.1 Modified Notify Request Object Processing ................. 13 4.3.1 Modified Notify Request Object Processing ................. 13
4.3.2 Modified Notify and Error Message Processing .............. 14 4.3.2 Modified Notify and Error Message Processing .............. 14
5 Secondary Record Route Objects ............................ 14 5 Secondary Record Route Objects ............................ 15
5.1 Format .................................................... 15 5.1 Format .................................................... 15
5.2 Path Processing ........................................... 15 5.2 Path Processing ........................................... 15
5.3 Resv Processing ........................................... 15 5.3 Resv Processing ........................................... 15
6 Dynamic Control of LSP Segment Recovery ................... 16 6 Dynamic Control of LSP Segment Recovery ................... 16
6.1 Modified Protection Object Format ......................... 16 6.1 Modified Protection Object Format ......................... 16
6.2 Dynamic Control Procedures ................................ 17 6.2 Dynamic Control Procedures ................................ 17
7 Updated RSVP Message Formats .............................. 18 7 Updated RSVP Message Formats .............................. 18
8 Security Considerations ................................... 20 8 Security Considerations ................................... 20
9 IANA Considerations ....................................... 21 9 IANA Considerations ....................................... 21
10 References ................................................ 21 9.1 New Association Type Assignment ........................... 21
10.1 Normative References ...................................... 21 9.2 Definition of Protection Object Reserved Bits ............. 21
10.2 Informative References .................................... 22 9.3 Secondary Explicit Route Object ........................... 21
11 Authors' Addresses ........................................ 22 9.4 Secondary Record Route Object ............................. 22
12 Full Copyright Statement .................................. 23 9.5 New Error Code ............................................ 22
13 Intellectual Property ..................................... 23 9.6 Use of Not Yet Assigned Protection Object C-type .......... 22
10 References ................................................ 23
10.1 Normative References ...................................... 23
10.2 Informative References .................................... 23
11 Authors' Addresses ........................................ 24
12 Full Copyright Statement .................................. 24
13 Intellectual Property ..................................... 25
Conventions used in this document Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
In addition, the reader is assumed to be familiar with the In addition, the reader is assumed to be familiar with the
terminology used in [RFC3209], [RFC3471], [RFC3473] as well as terminology used in [RFC3209], [RFC3471], [RFC3473] as well as
[TERM], [FUNCT], [E2E-RECOVERY] and [FRR]. [RFC4427], [RFC4426], [E2E-RECOVERY] and [RFC4090].
1. Introduction 1. Introduction
[TERM] covers multiple types of protection, including end-to-end and [RFC4427] covers multiple types of protection, including end-to-end
segment based approaches. [E2E-RECOVERY], RSVP-TE Extensions in and segment based approaches. [E2E-RECOVERY], RSVP-TE Extensions in
support of End-to-End GMPLS-based Recovery, defines a set of support of End-to-End GMPLS-based Recovery, defines a set of
extensions to support multiple types of recovery. The supported extensions to support multiple types of recovery. The supported
types include 1+1 unidirectional/ 1+1 bi-directional protection, LSP types include 1+1 unidirectional/ 1+1 bi-directional protection, LSP
protection with extra-traffic (including 1:N protection with extra- protection with extra-traffic (including 1:N protection with extra-
traffic), pre-planned LSP re-routing without extra-traffic (including traffic), pre-planned LSP re-routing without extra-traffic (including
shared mesh), and full LSP re-routing. In all cases, the recovery is shared mesh), and full LSP re-routing. In all cases, the recovery is
provided on an end-to-end basis, i.e., the ingress and egress nodes provided on an end-to-end basis, i.e., the ingress and egress nodes
of both the protected and the protecting LSP are the same. of both the protected and the protecting LSP are the same.
[FRR] provides a form of segment recovery for packet MPLS-TE [RFC4090] provides a form of segment recovery for packet MPLS-TE
networks. Two methods of Fast Reroute are defined in [FRR]. The networks. Two methods of Fast Reroute are defined in [RFC4090]. The
one-to-one backup method creates detour LSPs for each protected LSP one-to-one backup method creates detour LSPs for each protected LSP
at each potential point of local repair. The facility backup method at each potential point of local repair. The facility backup method
creates a bypass tunnel to protect a potential failure point which is creates a bypass tunnel to protect a potential failure point which is
shared by multiple LSPs and uses label stacking. Neither approach shared by multiple LSPs and uses label stacking. Neither approach
supports the full set of recovery types supported by [E2E-RECOVERY]. supports the full set of recovery types supported by [E2E-RECOVERY].
Additionally, the facility backup method is not applicable to most Additionally, the facility backup method is not applicable to most
non-PSC (packet) switching technologies. non-PSC (packet) switching technologies.
The extensions defined in this document allow for support of the full The extensions defined in this document allow for support of the full
set of recovery types supported by [E2E-RECOVERY], but on a segment, set of recovery types supported by [E2E-RECOVERY], but on a segment,
skipping to change at page 4, line 32 skipping to change at page 4, line 32
can be established along the path [C,G,I,E]. This LSP protects can be established along the path [C,G,I,E]. This LSP protects
against failures on spans {C,D} and {D,E} as well as a failure of against failures on spans {C,D} and {D,E} as well as a failure of
node D. This form of protection/restoration is referred to as node D. This form of protection/restoration is referred to as
Segment Protection and Segment Restoration, or Segment Recovery Segment Protection and Segment Restoration, or Segment Recovery
collectively. The LSP providing the protection or restoration is collectively. The LSP providing the protection or restoration is
referred to as a segment protection LSP or a segment restoration LSP. referred to as a segment protection LSP or a segment restoration LSP.
The term segment recovery LSP is used to cover either a segment The term segment recovery LSP is used to cover either a segment
protection LSP or a segment restoration LSP. The term branch node is protection LSP or a segment restoration LSP. The term branch node is
used to refer to a node that initiates a recovery LSP, e.g., node C used to refer to a node that initiates a recovery LSP, e.g., node C
in the figure shown above. This is equivalent to the point of local in the figure shown above. This is equivalent to the point of local
repair (PLR) used in [FRR]. As with [FRR], the term merge node is repair (PLR) used in [RFC4090]. As with [RFC4090], the term merge
used to refer to a node that terminates a recovery LSP, e.g., node E node is used to refer to a node that terminates a recovery LSP, e.g.,
in the figure shown above. node E in the figure shown above.
Segment protection or restoration is signaled using a working LSP and Segment protection or restoration is signaled using a working LSP and
one or more segment recovery LSPs. Each segment recovery LSP is one or more segment recovery LSPs. Each segment recovery LSP is
signaled as an independent LSP. Specifically, the Sender_Template signaled as an independent LSP. Specifically, the Sender_Template
object uses the IP address of the node originating the recovery path, object uses the IP address of the node originating the recovery path,
e.g., node C in the topology shown above, and the Session object e.g., node C in the topology shown above, and the Session object
contains the IP address of the node terminating the recovery path, contains the IP address of the node terminating the recovery path,
e.g., node E shown above. There is no specific requirement on LSP ID e.g., node E shown above. There is no specific requirement on LSP ID
value, Tunnel ID and Extended Tunnel ID. Values for these fields are value, Tunnel ID and Extended Tunnel ID. Values for these fields are
selected normally, including consideration for make-before-break. selected normally, including consideration for make-before-break.
Intermediate nodes follow standard signaling procedures when Intermediate nodes follow standard signaling procedures when
processing segment recovery LSPs. A segment recovery LSP may be processing segment recovery LSPs. A segment recovery LSP may be
protected itself using segment or end-to-end protection/restoration. protected itself using segment or end-to-end protection/restoration.
Note, in PSC environments it may be desirable to construct the Note, in PSC environments it may be desirable to construct the
Sender_Template and Session objects per [FRR]. Sender_Template and Session objects per [RFC4090].
When [FRR] isn't being used, the association between segment recovery When [RFC4090] isn't being used, the association between segment
LSPs with other LSPs is indicated using the Association object recovery LSPs with other LSPs is indicated using the Association
defined in [E2E-RECOVERY]. The Association object is used to object defined in [E2E-RECOVERY]. The Association object is used to
associate recovery LSPs with the LSP they are protecting. Working associate recovery LSPs with the LSP they are protecting. Working
and protecting LSPs, as well as primary and secondary LSPs, are and protecting LSPs, as well as primary and secondary LSPs, are
identified using LSP Status as described in [E2E-RECOVERY]. The identified using LSP Status as described in [E2E-RECOVERY]. The O-
0-bit in the segment flags portion of the Protection object is used bit in the segment flags portion of the Protection object is used to
to identify when a recovery LSP is carrying the normal (active) identify when a recovery LSP is carrying the normal (active) traffic.
traffic.
An upstream node can permit downstream nodes to dynamically identify An upstream node can permit downstream nodes to dynamically identify
branch and merge points by setting the desired LSP segment protection branch and merge points by setting the desired LSP segment protection
bits in the Protection object. These bits are defined below. bits in the Protection object. These bits are defined below.
Optionally, an upstream node, usually the ingress node, can identify Optionally, an upstream node, usually the ingress node, can identify
the endpoints of a segment recovery LSP. This is accomplished using the endpoints of a segment recovery LSP. This is accomplished using
a new object. This object uses the same format as an ERO and is a new object. This object uses the same format as an ERO and is
referred to as a Secondary Explicit Route object or SERO, see section referred to as a Secondary Explicit Route object or SERO, see section
4.1. SEROs also support a new subobject to indicate the type of 4.1. SEROs also support a new subobject to indicate the type of
skipping to change at page 6, line 39 skipping to change at page 6, line 39
basis. The segment forms of re-routing and restoration operate basis. The segment forms of re-routing and restoration operate
exactly like their end-to-end counterparts, with the exception that exactly like their end-to-end counterparts, with the exception that
the restoration LSP recovers only a portion of the working LSP. The the restoration LSP recovers only a portion of the working LSP. The
type of re-routing or restoration to be used on a segment restoration type of re-routing or restoration to be used on a segment restoration
LSP is indicated, to the restoration LSP's ingress, using the new LSP is indicated, to the restoration LSP's ingress, using the new
protection SERO subobject. protection SERO subobject.
3. Association Object 3. Association Object
The Association object is used association of segment protection LSPs The Association object is used association of segment protection LSPs
when [FRR] isn't being used. The Association object is defined in when [RFC4090] isn't being used. The Association object is defined
[E2E-RECOVERY]. In this document we define a new Association Type in [E2E-RECOVERY]. In this document we define a new Association Type
field value to support make before break, formats and procedures field value to support make before break, formats and procedures
defined in [E2E-RECOVERY] are not otherwise modified. defined in [E2E-RECOVERY] are not otherwise modified.
3.1. Format 3.1. Format
Association Type: 16 bits Association Type: 16 bits
Value Type Value Type
----- ---- ----- ----
2 Resource Sharing (R) 2 Resource Sharing (R)
skipping to change at page 7, line 23 skipping to change at page 7, line 23
See [E2E-RECOVERY] for the definition of other fields and other See [E2E-RECOVERY] for the definition of other fields and other
values. values.
3.2. Procedures 3.2. Procedures
The Association object is used to associate different LSPs with each The Association object is used to associate different LSPs with each
other. In the protection and restoration context, the object is used other. In the protection and restoration context, the object is used
to associate a recovery LSP with the LSP it is protecting. The to associate a recovery LSP with the LSP it is protecting. The
Association object is also used to support resource sharing during Association object is also used to support resource sharing during
make-before-break. This object MUST NOT be used when association is make-before-break. This object MUST NOT be used when association is
made according to the methods defined in [FRR]. made according to the methods defined in [RFC4090].
3.2.1. Recovery Type Processing 3.2.1. Recovery Type Processing
Recovery type processing procedures are the same as those defined in Recovery type processing procedures are the same as those defined in
[E2E-RECOVERY], but processing and identification occurs with respect [E2E-RECOVERY], but processing and identification occurs with respect
to segment recovery LSPs. Note that this means that multiple to segment recovery LSPs. Note that this means that multiple
Association objects of type recovery may be present on an LSP. Association objects of type recovery may be present on an LSP.
3.2.2. Resource Sharing Association Type Processing 3.2.2. Resource Sharing Association Type Processing
skipping to change at page 8, line 16 skipping to change at page 8, line 16
Any node processing a Path message for which it does not have Any node processing a Path message for which it does not have
matching state, and which contains a Association object with a matching state, and which contains a Association object with a
Resource Sharing type, examines existing LSPs for matching Resource Sharing type, examines existing LSPs for matching
Association Type, Association Source and Association ID values. If Association Type, Association Source and Association ID values. If
any match is found, then [RFC3209] style resource sharing SHOULD be any match is found, then [RFC3209] style resource sharing SHOULD be
provided between the new and old LSPs. See [RFC3209] for additional provided between the new and old LSPs. See [RFC3209] for additional
details. details.
4. Explicit Control of LSP Segment Recovery 4. Explicit Control of LSP Segment Recovery
Secondary Explicit Route objects, or SEROs, may be used to indicate Secondary Explicit Route objects, or SEROs, are defined in this
the branch and merge nodes of recovery LSPs. They may also provide document. They may be used to indicate the branch and merge nodes of
additional information that is to be carried in a recovery LSP's ERO. recovery LSPs. They may also provide additional information that is
When upstream control of branch and merge nodes is not desired, SEROs to be carried in a recovery LSP's ERO. When upstream control of
are not used. branch and merge nodes is not desired, SEROs are not used.
4.1. Secondary Explicit Route Object Format 4.1. Secondary Explicit Route Object Format
The format of a SECONDARY_EXPLICIT_ROUTE object is the same as an The format of a SECONDARY_EXPLICIT_ROUTE object is the same as an
EXPLICIT_ROUTE object. This includes the definition of subobjects EXPLICIT_ROUTE object. This includes the definition of subobjects
defined for EXPLICIT_ROUTE object. The class of the defined for EXPLICIT_ROUTE object. The class of the
SECONDARY_EXPLICIT_ROUTE object is TBA by IANA (of form 11bbbbbb). SECONDARY_EXPLICIT_ROUTE object is TBA by IANA (of form 11bbbbbb).
4.1.1. Protection Subobject 4.1.1. Protection Subobject
The protection subobject is not valid for use with the Explicit and A new subobject, called the protection subobject, is defined for use
Record Route objects and MUST NOT be included in those objects. in the SECONDARY_EXPLICIT_ROUTE object. As mentioned above, the new
protection subobject is used to create the Protection object for the
recovery LSP. Specific procedures related to the protection
subobject are provided in Section 4.2. The protection subobject is
not valid for use with the Explicit and Record Route objects and MUST
NOT be included in those objects.
The format of the Protection Subobject is defined as follows: The format of the Protection Subobject is defined as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| Type | Length | Reserved | C-Type | |L| Type | Length | Reserved | C-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PROTECTION Object Contents | | PROTECTION Object Contents |
| ... | | ... |
skipping to change at page 21, line 13 skipping to change at page 21, line 13
Thus, in the event of the interception of a signaling message, Thus, in the event of the interception of a signaling message,
slightly more could be deduced about the state of the network than slightly more could be deduced about the state of the network than
was previously the case, but this is judged to be a very minor was previously the case, but this is judged to be a very minor
security risk as this information is already available via routing. security risk as this information is already available via routing.
Otherwise, this document introduces no additional security Otherwise, this document introduces no additional security
considerations. See [RFC3473] for relevant security considerations. considerations. See [RFC3473] for relevant security considerations.
9. IANA Considerations 9. IANA Considerations
This document requests assignment of a new Association Type within IANA is requested to administer assignment of new values for
the Association object. It also defines bits previously reserved in namespaces defined in this document and reviewed in this section.
the Protection object. Both of these objects were defined in [E2E-
RECOVERY].
This document also defines the Secondary Explicit Route Objects and 9.1. New Association Type Assignment
Secondary Record Route Objects. Both of these objects of the form
11bbbbbb. The values 198 and 199 respectively are suggested. A new
subobject is also defined for the use with the Secondary Explicit
Route Objects and Secondary Record Route Objects. The c-type values
and subobjects associated with the Secondary Explicit Route Object
should read "Same values and subobjects as EXPLICIT_ROUTE (C-Num 20)
object. With the additonal subobject type: 37 Protection." The c-
type values and subobjects associated with the Secondary Record Route
Object should read "Same values as and subobjects as RECORD_ROUTE (C-
Num 21) object. With the additonal subobject type: 37 Protection."
This document defines the following new error codes: Upon approval of this document, the IANA will make the following
assignment to the "Association Types" Registry, see [E2E-RECOVERY],
in the "ASSOCIATION (object)" section of the "RSVP PARAMETERS"
registry located at http://www.iana.org/assignments/rsvp-parameters
o "Routing Problem/LSP Segment Protection Failed" (Suggested value =TBD) Value Type
----- ----
2 Resource Sharing (R) [RFC-ccamp-gmpls-segment-recovery]
9.2. Definition of Protection Object Reserved Bits
This document defines bits carried in the Reserved field of the
Protection Object defined in [E2E-RECOVERY]. As no IANA registry for
these bits is requested in [E2E-RECOVERY], no IANA action is required
related to this definition.
9.3. Secondary Explicit Route Object
Upon approval of this document, the IANA will make the following
assignments in the "Class Names, Class Numbers, and Class Types"
section of the "RSVP PARAMETERS" registry located at
http://www.iana.org/assignments/rsvp-parameters
A new class named SECONDARY_EXPLICIT_ROUTE will be created in the
11bbbbbb range (198 suggested) with the following definition:
Class Types or C-types:
Same values as EXPLICIT_ROUTE object (C-Num 20)
For Class 1, C-Type 1, the following additional Sub-object type is
defined:
37 Protection [RFC-ccamp-gmpls-segment-recovery]
9.4. Secondary Record Route Object
Upon approval of this document, the IANA will make the following
assignments in the "Class Names, Class Numbers, and Class Types"
section of the "RSVP PARAMETERS" registry located at
http://www.iana.org/assignments/rsvp-parameters
A new class named SECONDARY_RECORD_ROUTE will be created in the
11bbbbbb range (198 suggested) with the following definition:
Class Types or C-types:
Same values as RECORD_ROUTE object (C-Num 21)
For Class 1, C-Type 1, the following additional Sub-object type is
defined:
37 Protection [RFC-ccamp-gmpls-segment-recovery]
9.5. New Error Code
Upon approval of this document, the IANA will make the following
assignments in the "Routing Problem" subsection of "Error Codes and
Values" section of the "RSVP PARAMETERS" registry located at
http://www.iana.org/assignments/rsvp-parameters
xx = LSP Segment Protection Failed [RFC-ccamp-gmpls-segment-recovery]
9.6. Use of Not Yet Assigned Protection Object C-type
This document modifies the Protection Object, class number 37, C-Type
defined in [E2E-RECOVERY]. Per Section 14.1 of [E2E-RECOVERY], this
C-Type is still "TBA", but has a suggested value of 2. Section 6.1
of this document, should be updated to match the assignment made by
IANA for Section 14.1 of [E2E-RECOVERY].
10. References 10. References
10.1. Normative References 10.1. Normative References
[RFC2205] Braden, R. Ed. et al, "Resource ReserVation Protocol
-- Version 1 Functional Specification", RFC 2205,
September 1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels," RFC 2119.
[RFC3209] Awduche, et al, "RSVP-TE: Extensions to RSVP for [RFC3209] Awduche, et al, "RSVP-TE: Extensions to RSVP for
LSP Tunnels", RFC 3209, December 2001. LSP Tunnels", RFC 3209, December 2001.
[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.
[E2E-RECOVERY] Lang, J.P., Rekhter, Y., Papadimitriou, D., Editors, [E2E-RECOVERY] Lang, J.P., Rekhter, Y., Papadimitriou, D., Editors,
"RSVP-TE Extensions in support of End-to-End "RSVP-TE Extensions in support of End-to-End
GMPLS-based Recovery", Work in Progress, GMPLS-based Recovery", Work in Progress,
draft-lang-ccamp-gmpls-recovery-e2e-signaling-03.txt, draft-lang-ccamp-gmpls-recovery-e2e-signaling-03.txt,
April 2005. April 2005.
10.2. Informative References 10.2. Informative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC4090] Pan, et al, "Fast Reroute Extensions to RSVP-TE for LSP
Requirement Levels," RFC 2119. Tunnels", RFC 4090, May 2005.
[FUNCT] J.P.Lang and B.Rajagopalan (Editors), "Generalized MPLS [RFC4426] J.P.Lang and B.Rajagopalan (Editors), "Generalized MPLS
Recovery Functional Specification," Internet Draft, Recovery Functional Specification," RFC 4426, March 2006.
Work in Progress, draft-ietf-ccamp-gmpls-recovery-
functional-04.txt, April 2005.
[TERM] E.Mannie and D.Papadimitriou (Editors), "Recovery [RFC4427] E.Mannie and D.Papadimitriou (Editors), "Recovery
(Protection and Restoration) Terminology for GMPLS," (Protection and Restoration) Terminology for GMPLS,"
Internet Draft, Work in progress, draft-ietf-ccamp- Internet Draft, RFC 4427, March 2006.
gmpls-recovery-terminology-06.txt, March 2005.
[FRR] Pan, et al, "Fast Reroute Extensions to RSVP-TE for LSP
Tunnels", draft-ietf-mpls-rsvp-lsp-fastreroute-07.txt,
August 2004.
11. Authors' Addresses 11. Authors' Addresses
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
Igor Bryskin Igor Bryskin
Movaz Networks, Inc. Movaz Networks, Inc.
7926 Jones Branch Drive 7926 Jones Branch Drive
Suite 615 Suite 615
McLean VA, 22102 McLean VA, 22102
Email: ibryskin@movaz.com Email: ibryskin@movaz.com
Adrian Farrel Adrian Farrel
Old Dog Consulting Old Dog Consulting
Phone: +44 (0) 1978 860944 Phone: +44 (0) 1978 860944
Email: adrian@olddog.co.uk Email: adrian@olddog.co.uk
Dimitri Papadimitriou (Alcatel) Dimitri Papadimitriou (Alcatel)
Francis Wellesplein 1 Francis Wellesplein 1
B-2018 Antwerpen, Belgium B-2018 Antwerpen, Belgium
Phone: +32 3 240-8491 Phone: +32 3 240-8491
Email: dimitri.papadimitriou@alcatel.be Email: dimitri.papadimitriou@alcatel.be
skipping to change at page 23, line 17 skipping to change at page 24, line 32
Email: adrian@olddog.co.uk Email: adrian@olddog.co.uk
Dimitri Papadimitriou (Alcatel) Dimitri Papadimitriou (Alcatel)
Francis Wellesplein 1 Francis Wellesplein 1
B-2018 Antwerpen, Belgium B-2018 Antwerpen, Belgium
Phone: +32 3 240-8491 Phone: +32 3 240-8491
Email: dimitri.papadimitriou@alcatel.be Email: dimitri.papadimitriou@alcatel.be
12. Full Copyright Statement 12. 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 1015 skipping to change at line 1080
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: Thu May 26 11:03:09 EDT 2005 Generated on: Fri Oct 6 11:36:26 EDT 2006
 End of changes. 29 change blocks. 
74 lines changed or deleted 138 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/