draft-ietf-mpls-rsvp-lsp-fastreroute-01.txt   draft-ietf-mpls-rsvp-lsp-fastreroute-02.txt 
Internet Draft Ping Pan, Ed (Ciena Corp) Internet Draft Ping Pan, Ed (Ciena Corp)
Expires: May 2003 Der-Hwa Gan (Juniper Networks) Expires: Aug 2003 Der-Hwa Gan (Juniper Networks)
George Swallow (Cisco Systems) George Swallow (Cisco Systems)
Jean Philippe Vasseur (Cisco Systems) Jean Philippe Vasseur (Cisco Systems)
Dave Cooper (Global Crossing) Dave Cooper (Global Crossing)
Alia Atlas, Ed (Avici Systems) Alia Atlas, Ed (Avici Systems)
Markus Jork (Avici Systems) Markus Jork (Avici Systems)
Fast Reroute Extensions to RSVP-TE for LSP Tunnels Fast Reroute Extensions to RSVP-TE for LSP Tunnels
draft-ietf-mpls-rsvp-lsp-fastreroute-01.txt draft-ietf-mpls-rsvp-lsp-fastreroute-02.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 38 skipping to change at page 1, line 38
material or to cite them other than as ``work in progress.'' material or to cite them other than as ``work in progress.''
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Abstract Abstract
This document defines extensions to and describes the use of RSVP This document defines extensions to and describes the use of RSVP to
[RSVP, RSVP-TE] to establish backup LSP tunnels for local repair of establish backup label-switched path (LSP) tunnels for local repair
LSP tunnels. These mechanisms enable the re-direction of traffic of LSP tunnels. These mechanisms enable the re-direction of traffic
onto backup LSP tunnels in 10s of milliseconds in the event of a onto backup LSP tunnels in 10s of milliseconds in the event of a
failure. failure.
Two methods are defined here. The one-to-one backup method creates Two methods are defined here. The one-to-one backup method creates
detour LSPs for each protected LSP at each potential point of local detour LSPs for each protected LSP at each potential point of local
repair. The facility backup method creates a bypass tunnel to repair. The facility backup method creates a bypass tunnel to
protect a potential failure point; by taking advantage of MPLS label protect a potential failure point; by taking advantage of MPLS label
stacking, this bypass tunnel can protect a set of protected LSPs that stacking, this bypass tunnel can protect a set of protected LSPs that
have similar backup constraints. Both methods can be used to protect have similar backup constraints. Both methods can be used to protect
links and nodes during network failure. The described behavior and links and nodes during network failure. The described behavior and
extensions to RSVP allow LERs and LSRs to implement either or both extensions to RSVP allow nodes to implement either or both methods
methods and to interoperate in a mixed network. and to interoperate in a mixed network.
Contents Contents
1 Introduction ............................................. 4 1 Introduction ............................................. 4
2 Terminology ............................................... 4 2 Terminology ............................................... 4
3 Local Repair Techniques ................................... 6 3 Local Repair Techniques ................................... 6
3.1 One-to-one Backup ....................................... 6 3.1 One-to-one Backup .................................... 6
3.2 Facility Backup ......................................... 7 3.2 Facility Backup ...................................... 7
4 RSVP Extensions ........................................... 8 4 RSVP Extensions ........................................... 8
4.1 FAST_REROUTE Object ..................................... 8 4.1 FAST_REROUTE Object .................................... 8
4.2 DETOUR Object ........................................... 11 4.2 DETOUR Object .......................................... 11
4.3 SESSION_ATTRIBUTE Flags ................................. 12 4.3 SESSION_ATTRIBUTE Flags ................................ 12
4.4 RRO IPv4/IPv6 Sub-Object Flags .......................... 13 4.4 RRO IPv4/IPv6 Sub-Object Flags ......................... 13
5 Head-End Behavior ......................................... 14 5 Head-End Behavior ......................................... 14
6 Point of Local Repair Behavior ............................ 15 6 Point of Local Repair Behavior ............................ 15
6.1 Signaling a Backup Path ................................. 16 6.1 Signaling a Backup Path ................................ 16
6.1.1 Backup Path Identification: Sender-Template Specific ... 17 6.1.1 Backup Path Identification: Sender-Template Specific . 17
6.1.2 Backup Path Identification: Path-Specific ............. 18 6.1.2 Backup Path Identification: Path-Specific ........... 18
6.2 Procedures for Backup Path Computation .................. 18 6.2 Procedures for Backup Path Computation ................. 18
6.3 Signaling Backups for One-To-One Protection ............. 20 6.3 Signaling Backups for One-To-One Protection ............ 20
6.3.1 Make-Before-Break with Detour LSPs .................... 21 6.3.1 Make-Before-Break with Detour LSPs .................. 21
6.3.2 Message Handling ...................................... 21 6.3.2 Message Handling .................................... 21
6.3.3 Local Reroute of Traffic Onto Detour LSP .............. 22 6.3.3 Local Reroute of Traffic Onto Detour LSP ............ 22
6.4 Signaling for Facility Protection ....................... 23 6.4 Signaling for Facility Protection ...................... 23
6.4.1 Discovering Downstream Labels ......................... 23 6.4.1 Discovering Downstream Labels ....................... 23
6.4.2 Procedures for the PLR before Local Repair ............ 23 6.4.2 Procedures for the PLR before Local Repair .......... 23
6.4.3 Procedures for the PLR during Local Repair ............ 23 6.4.3 Procedures for the PLR during Local Repair .......... 23
6.4.4 Processing backup tunnel's ERO ........................ 24 6.4.4 Processing backup tunnel's ERO ...................... 24
6.5 PLR Procedures During Local Repair ...................... 25 6.5 PLR Procedures During Local Repair ..................... 25
6.5.1 Notification of local repair .......................... 25 6.5.1 Notification of local repair ........................ 25
6.5.2 Revertive Behavior .................................... 26 6.5.2 Revertive Behavior .................................. 26
7 Merge Node Behavior ....................................... 27 7 Merge Node Behavior ....................................... 27
7.1 Handling Backup Path Messages Before Failure ............ 27 7.1 Handling Backup Path Messages Before Failure ........... 27
7.1.1 Merging Backup Paths using the Sender-Template 7.1.1 Merging Backup Paths using the Sender-Template
Specific Method ....................................... 28 Specific Method ..................................... 28
7.1.2 Merging Detours using Path-Specific Method ............ 28 7.1.2 Merging Detours using Path-Specific Method .......... 28
7.1.2.1 An Example on Path Message Merging .................. 29 7.1.2.1 An Example on Path Message Merging ............... 29
7.1.3 Message Handling for Merged Detours ................... 30 7.1.3 Message Handling for Merged Detours ................. 30
7.2 Handling Failures ....................................... 30 7.2 Handling Failures ...................................... 30
8 Behavior of all LSRs ...................................... 31 8 Behavior of all LSRs ...................................... 31
8.1 Merging Detours in Path-Specific Method ................. 31 8.1 Merging Detours in Path-Specific Method ................ 31
9 Security Considerations ................................... 32 9 Security Considerations ................................... 32
10 IANA Guidelines ........................................... 32 10 IANA Guidelines ........................................... 32
11 Intellectual Property Considerations ...................... 32 11 Intellectual Property Considerations ...................... 32
12 Full Copyright Statement .................................. 32 12 Full Copyright Statement .................................. 32
13 Acknowledgments ........................................... 33 13 Acknowledgments ........................................... 33
14 References ................................................ 33 14 Normative References ...................................... 33
15 Author Information ........................................ 33 15 Author Information ........................................ 33
1. Introduction 1. Introduction
This document extends RSVP [RSVP] to establish backup LSP tunnels This document extends RSVP [RSVP] to establish backup LSP tunnels
for the local repair of LSP tunnels. This technique is presented for the local repair of LSP tunnels. This technique is presented
to meet the needs of real-time applications, such as voice over IP, to meet the needs of real-time applications, such as voice over IP,
for which it is highly desirable to be able to re-direct user for which it is highly desirable to be able to re-direct user
traffic onto backup LSP tunnels in 10s of milliseconds. This traffic onto backup LSP tunnels in 10s of milliseconds. This
timing requirement can be satisfied by computing and signaling timing requirement can be satisfied by computing and signaling
skipping to change at page 4, line 40 skipping to change at page 4, line 40
protection are described. In Section 5, the behavior of an LER protection are described. In Section 5, the behavior of an LER
which wishes to request local protection for an LSP is presented. which wishes to request local protection for an LSP is presented.
The behavior of a potential point of local repair (PLR) is given in The behavior of a potential point of local repair (PLR) is given in
Section 6; this describes how to determine the appropriate strategy Section 6; this describes how to determine the appropriate strategy
to use for protecting an LSP and how to implement each of the to use for protecting an LSP and how to implement each of the
strategies. The behavior of a merge node, the LSR where a strategies. The behavior of a merge node, the LSR where a
protected LSP and its backup LSP rejoin, is described in Section 7. protected LSP and its backup LSP rejoin, is described in Section 7.
Finally, the required behavior of other nodes in the network is Finally, the required behavior of other nodes in the network is
discussed in Section 8. discussed in Section 8.
For the techniques discussed in this document to function properly,
there are three assumptions which must be made. First, an LSR
which is on the path of a protected LSP SHOULD always assume that
it is a merge point; this is necessary because the facility backup
method does not signal backups through a bypass tunnel before
failure. Second, if the one-to-one backup method is used and a
DETOUR object is included, the LSRs in the traffic-engineered
network should support the DETOUR object; this is necessary so that
the Path message containing the DETOUR object is not rejected.
Third, understanding of the DETOUR object is required to support
the path-specific method which requires that LSRs in the
traffic-engineered network be capable of merging detours.
2. Terminology 2. Terminology
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 RFC2119 [RFC-WORDS]. document are to be interpreted as described in RFC2119 [RFC-WORDS].
The reader is assumed to be familiar with the terminology in [RSVP] The reader is assumed to be familiar with the terminology in [RSVP]
and [RSVP-TE]. and [RSVP-TE].
LSR - Label Switch Router LSR - Label Switch Router
skipping to change at page 12, line 15 skipping to change at page 12, line 19
is preferred. This field is mandatory, and is used by is preferred. This field is mandatory, and is used by
the MP for merging rules discussed below. the MP for merging rules discussed below.
There can be more than one pair of (PLR_ID, Avoid_Node_ID) entries in There can be more than one pair of (PLR_ID, Avoid_Node_ID) entries in
a DETOUR object. If detour merging is desired, after each merging a DETOUR object. If detour merging is desired, after each merging
operation, the Detour Merge Point should combine all the merged operation, the Detour Merge Point should combine all the merged
detours in the subsequent Path messages. detours in the subsequent Path messages.
The high-order bit of the C-Class is zero; LSRs that do not support The high-order bit of the C-Class is zero; LSRs that do not support
the DETOUR objects MUST reject any Path message containing a DETOUR the DETOUR objects MUST reject any Path message containing a DETOUR
object and send a PathErr to notify the PLR. object and send a PathErr to notify the PLR. This PathErr SHOULD
be generated as specified in [RSVP] for unknown objects with a
class-num of the form "0bbbbbbb".
4.3. SESSION_ATTRIBUTE Flags 4.3. SESSION_ATTRIBUTE Flags
To explicitly request bandwidth and node protection, two new flags To explicitly request bandwidth and node protection, two new flags
are defined in the SESSION_ATTRIBUTE object. are defined in the SESSION_ATTRIBUTE object.
For both C-Type 1 and 7, the SESSION_ATTRIBUTE object currently has For both C-Type 1 and 7, the SESSION_ATTRIBUTE object currently has
the following flags defined: the following flags defined:
Local protection desired: 0x01 Local protection desired: 0x01
skipping to change at page 14, line 41 skipping to change at page 14, line 45
SESSION_ATTRIBUTE object or include a FAST_REROUTE object in the SESSION_ATTRIBUTE object or include a FAST_REROUTE object in the
PATH message or both. It is recommended that the "local protection PATH message or both. It is recommended that the "local protection
desired" flag in the SESSION_ATTRIBUTE object always be set. If a desired" flag in the SESSION_ATTRIBUTE object always be set. If a
head-end LSR signals a FAST_REROUTE object, it MUST be stored for head-end LSR signals a FAST_REROUTE object, it MUST be stored for
Path refreshes. Path refreshes.
The head-end LSR of a protected LSP MUST set the "label recording The head-end LSR of a protected LSP MUST set the "label recording
desired" flag in the SESSION_ATTRIBUTE object. This facilitates desired" flag in the SESSION_ATTRIBUTE object. This facilitates
the use of the facility backup technique. If node protection is the use of the facility backup technique. If node protection is
desired, the head-end LSR should set the "node protection desired" desired, the head-end LSR should set the "node protection desired"
flag in the SESSION_ATTRIBUTE object; if only link protection is flag in the SESSION_ATTRIBUTE object; otherwise this flag should be
desired, this flag should be cleared. Similarly, if a guarantee of cleared. Similarly, if a guarantee of bandwidth protection is
bandwidth protection is desired, then the "bandwidth protection desired, then the "bandwidth protection desired" flag in the
desired" flag in the SESSION_ATTRIBUTE object should be set; SESSION_ATTRIBUTE object should be set; otherwise, this flag should
otherwise, this flag should be cleared. be cleared.
If the head-end LSR determines that control of the backup paths for If the head-end LSR determines that control of the backup paths for
the protected LSP is desired, then the LSR should include the the protected LSP is desired, then the LSR should include the
FAST_REROUTE object. The attribute filters, bandwidth, hop-limit FAST_REROUTE object. The attribute filters, bandwidth, hop-limit
and priorities will be used by the PLRs when determining the backup and priorities will be used by the PLRs when determining the backup
paths. paths.
If the head-end LSR desires that the protected LSP be protected via If the head-end LSR desires that the protected LSP be protected via
the one-to-one backup technique, then head-end LSR should include a the one-to-one backup technique, then head-end LSR should include a
FAST_REROUTE object and set the "one-to-one backup desired" flag. FAST_REROUTE object and set the "one-to-one backup desired" flag.
skipping to change at page 15, line 48 skipping to change at page 16, line 4
A PLR MUST consider an LSP as having asked for local protection if A PLR MUST consider an LSP as having asked for local protection if
the "local protection desired" flag is set in the SESSION_ATTRIBUTE the "local protection desired" flag is set in the SESSION_ATTRIBUTE
object and/or the FAST_REROUTE object is included. If the object and/or the FAST_REROUTE object is included. If the
FAST_REROUTE object is included, a PLR SHOULD consider providing FAST_REROUTE object is included, a PLR SHOULD consider providing
one-to-one protection if the "one-to-one desired" is set and SHOULD one-to-one protection if the "one-to-one desired" is set and SHOULD
consider providing facility backup if the "facility backup desired" consider providing facility backup if the "facility backup desired"
flag is set when determining whether to provide local protection flag is set when determining whether to provide local protection
and which technique to use to provide that local protection. If and which technique to use to provide that local protection. If
the "node protection desired" flag is set, the PLR SHOULD try to the "node protection desired" flag is set, the PLR SHOULD try to
provide node protection; if this is not feasible, the PLR SHOULD provide node protection; if this is not feasible, the PLR SHOULD
then try to provide link protection. then try to provide link protection. If the "bandwidth protection
guaranteed" flag is set, the PLR SHOULD try to provide a bandwidth
guarantee; if this is not feasible, the PLR SHOULD then try to
provide a backup without a guarantee of the full bandwidth.
The following treatment for the RRO IPv4 or IPv6 sub-object's flags The following treatment for the RRO IPv4 or IPv6 sub-object's flags
must be followed if an RRO is included in the protected LSP's RESV must be followed if an RRO is included in the protected LSP's RESV
message. Based on this additional information the head-end may message. Based on this additional information the head-end may
take appropriate actions. take appropriate actions.
- Until a PLR has a backup path available, the PLR MUST clear the - Until a PLR has a backup path available, the PLR MUST clear the
relevant four flags in the corresponding RRO IPv4 or IPv6 relevant four flags in the corresponding RRO IPv4 or IPv6
sub-object. sub-object.
skipping to change at page 18, line 4 skipping to change at page 18, line 9
backup path must inherit its LSP ID from the associated protected backup path must inherit its LSP ID from the associated protected
LSP. Thus, the only field in the SESSION and SENDER_TEMPLATE LSP. Thus, the only field in the SESSION and SENDER_TEMPLATE
objects which could be varied between a backup path and a protected objects which could be varied between a backup path and a protected
LSP is the "IPv4 (or IPv6) tunnel sender address" in the LSP is the "IPv4 (or IPv6) tunnel sender address" in the
SENDER_TEMPLATE. SENDER_TEMPLATE.
There are two different methods to uniquely identify a backup There are two different methods to uniquely identify a backup
path. These are described below. path. These are described below.
6.1.1. Backup Path Identification: Sender-Template-Specific 6.1.1. Backup Path Identification: Sender-Template-Specific
In this approach, the SESSION object and the LSP_ID are copied from In this approach, the SESSION object and the LSP_ID are copied from
the protected LSP. The "IPv4 tunnel sender address" is set to an the protected LSP. The "IPv4 tunnel sender address" is set to an
address of the PLR. If the head-end of a tunnel is also acting as address of the PLR. If the head-end of a tunnel is also acting as
the PLR, it must choose an IP address different from the one used the PLR, it MUST choose an IP address different from the one used
in the SENDER_TEMPLATE of the original LSP tunnel. in the SENDER_TEMPLATE of the original LSP tunnel.
When using the sender-template-specific approach, the protected When using the sender-template-specific approach, the protected
LSPs and the backup paths SHOULD use the Shared Explicit (SE) LSPs and the backup paths SHOULD use the Shared Explicit (SE)
style. This allows bandwidth sharing between multiple backup style. This allows bandwidth sharing between multiple backup
paths. The backup paths and the protected LSP MAY be merged by the paths. The backup paths and the protected LSP MAY be merged by the
Detour Merge Points, when the ERO from the MP to the egress is the Detour Merge Points, when the ERO from the MP to the egress is the
same on each LSP to be merged, as specified in [RSVP-TE]. same on each LSP to be merged, as specified in [RSVP-TE].
6.1.2. Backup Path Identification: Path-Specific 6.1.2. Backup Path Identification: Path-Specific
skipping to change at page 18, line 34 skipping to change at page 18, line 40
Thus, the backup paths use the same SESSION and SENDER_TEMPLATE Thus, the backup paths use the same SESSION and SENDER_TEMPLATE
objects as the ones used in the protected LSP. The presence of objects as the ones used in the protected LSP. The presence of
DETOUR object in Path messages signifies a backup path; the DETOUR object in Path messages signifies a backup path; the
presence of FAST_REROUTE object and/or the "local protection presence of FAST_REROUTE object and/or the "local protection
requested" flag in the SESSION_ATTRIBUTE object indicates a requested" flag in the SESSION_ATTRIBUTE object indicates a
protected LSP. protected LSP.
In the path-message-specific approach, when an LSR receives In the path-message-specific approach, when an LSR receives
multiple Path messages which have the same SESSION and multiple Path messages which have the same SESSION and
SENDER_TEMPLATE objects and also have the same next-hop, that LSR SENDER_TEMPLATE objects and also have the same next-hop, that LSR
must merge the Path messages. Without this behavior, the multiple MUST merge the Path messages. Without this behavior, the multiple
RESV messages received back would not be distinguishable as to RESV messages received back would not be distinguishable as to
which backup path each belongs to. This merging behavior does which backup path each belongs to. This merging behavior does
reduce the total number of RSVP states inside the network at the reduce the total number of RSVP states inside the network at the
expense of merging LSPs with different EROs. expense of merging LSPs with different EROs.
6.2 Procedures for Backup Path Computation 6.2 Procedures for Backup Path Computation
Before a PLR can create a detour or a bypass tunnel, the desired Before a PLR can create a detour or a bypass tunnel, the desired
explicit route must be determined. This can be done using a CSPF. explicit route must be determined. This can be done using a CSPF.
skipping to change at page 20, line 15 skipping to change at page 20, line 20
would be used twice in the event of a failure. would be used twice in the event of a failure.
- The backup LSP cannot traverse the downstream node and/or link - The backup LSP cannot traverse the downstream node and/or link
whose failure is being protected against. Note that if the whose failure is being protected against. Note that if the
PLR is the penultimate hop, node protection is not possible PLR is the penultimate hop, node protection is not possible
and only the downstream link can be avoided. The backup path and only the downstream link can be avoided. The backup path
may be computed to be SRLG disjoint from the downstream node may be computed to be SRLG disjoint from the downstream node
and/or link being avoided. and/or link being avoided.
- The backup path must satisfy the resource requirements of the - The backup path must satisfy the resource requirements of the
protected LSP. This SHOULD consider the link attribute protected LSP. This includes the link attribute filters,
filters, bandwidth, and hop limits determined from the bandwidth, and hop limits determined from the FAST_REROUTE
FAST_REROUTE object and SESSION_ATTRIBUTE object. object and SESSION_ATTRIBUTE object.
If such computation succeeds, the PLR should attempt to establish a If such computation succeeds, the PLR should attempt to establish a
backup path. The PLR may schedule a re-computation at a later time backup path. The PLR may schedule a re-computation at a later time
to discover better paths that may have emerged. If for any reason, to discover better paths that may have emerged. If for any reason,
the PLR is unable to bring up a backup path, it must schedule a the PLR is unable to bring up a backup path, it must schedule a
retry at a later time. retry at a later time.
6.3 Signaling Backups for One-To-One Protection 6.3 Signaling Backups for One-To-One Protection
Once a PLR has decided to locally protect an LSP with one-to-one Once a PLR has decided to locally protect an LSP with one-to-one
skipping to change at page 20, line 49 skipping to change at page 21, line 7
DETOUR object MAY be added to the PATH message. DETOUR object MAY be added to the PATH message.
- If the path-specific method is to be used, then the PLR MUST add - If the path-specific method is to be used, then the PLR MUST add
a DETOUR object to the PATH message. a DETOUR object to the PATH message.
- The SESSION_ATTRIBUTE flags "Local protection desired", - The SESSION_ATTRIBUTE flags "Local protection desired",
"Bandwidth protection desired" and "Node protection desired" MUST "Bandwidth protection desired" and "Node protection desired" MUST
be cleared. The "Label recording desired" flag MAY be modified. be cleared. The "Label recording desired" flag MAY be modified.
If the Path Message contained a FAST_REROUTE object, and the ERO If the Path Message contained a FAST_REROUTE object, and the ERO
is not completely strict, the Include-any, Exclude-any, and is not completely strict, the Include-any, Exclude-any, and
Include-all fields of the FAST_REROUTE object should be copied to Include-all fields of the FAST_REROUTE object SHOULD be copied to
the corresponding fields of the SESSION_ATTRIBUTE object. the corresponding fields of the SESSION_ATTRIBUTE object.
- If the protected LSP's Path message contained a FAST_REROUTE - If the protected LSP's Path message contained a FAST_REROUTE
object, this MUST be removed from the detour LSP's PATH message. object, this MUST be removed from the detour LSP's PATH message.
- The PLR must generate an EXPLICIT_ROUTE object toward the egress. - The PLR MUST generate an EXPLICIT_ROUTE object toward the egress.
First, the PLR must remove all sub-objects preceding the first First, the PLR must remove all sub-objects preceding the first
address belonging to the Merge Point. Then the PLR should add address belonging to the Merge Point. Then the PLR SHOULD add
sub-objects corresponding to the desired backup path between the sub-objects corresponding to the desired backup path between the
PLR and the MP. PLR and the MP.
- The SENDER_TSPEC object should contain the bandwidth information - The SENDER_TSPEC object SHOULD contain the bandwidth information
from the received FAST_REROUTE object, if included in the from the received FAST_REROUTE object, if included in the
protected LSP's PATH message. protected LSP's PATH message.
- The RSVP_HOP object containing one of the PLR's IP address. - The RSVP_HOP object containing one of the PLR's IP address.
- The detour LSPs MUST use the same reservation style as the - The detour LSPs MUST use the same reservation style as the
protected LSP. This must be correctly reflected in the protected LSP. This must be correctly reflected in the
SESSION_ATTRIBUTE object. SESSION_ATTRIBUTE object.
Detour LSPs are regular LSPs in operation. Once a detour path is Detour LSPs are regular LSPs in operation. Once a detour path is
skipping to change at page 23, line 38 skipping to change at page 23, line 45
When MPs use per-interface-label spaces, the PLR must send Path When MPs use per-interface-label spaces, the PLR must send Path
messages (for each protected LSP using a bypass tunnel) via that messages (for each protected LSP using a bypass tunnel) via that
bypass tunnel prior to the failure in order to discover the bypass tunnel prior to the failure in order to discover the
appropriate MP label. The signaling procedures for this are in appropriate MP label. The signaling procedures for this are in
Section 6.4.3 below. Section 6.4.3 below.
6.4.2. Procedures for the PLR before Local Repair 6.4.2. Procedures for the PLR before Local Repair
A PLR which determines to use facility-backup to protect a given A PLR which determines to use facility-backup to protect a given
LSP SHOULD select a bypass tunnel to use taking into account LSP should select a bypass tunnel to use taking into account
whether node protection is to be provided, what bandwidth was whether node protection is to be provided, what bandwidth was
requested and whether a bandwidth guarantee is desired, and what requested and whether a bandwidth guarantee is desired, and what
link attribute filters were specified in the FAST_REROUTE object. link attribute filters were specified in the FAST_REROUTE object.
The selection of a bypass tunnel for a protected LSP is performed The selection of a bypass tunnel for a protected LSP is performed
by the PLR when the LSP is first setup. by the PLR when the LSP is first setup.
6.4.3. Procedures for the PLR during Local Repair 6.4.3. Procedures for the PLR during Local Repair
When the PLR detects a link or/and node failure condition, it needs When the PLR detects a link or/and node failure condition, it needs
to reroute the data traffic onto the bypass tunnel and to start to reroute the data traffic onto the bypass tunnel and to start
sending the control traffic for the protected LSP onto the bypass sending the control traffic for the protected LSP onto the bypass
tunnel. tunnel.
skipping to change at page 24, line 20 skipping to change at page 24, line 29
- The SESSION is unchanged. - The SESSION is unchanged.
- The SESSION_ATTRIBUTE is unchanged except as follows: - The SESSION_ATTRIBUTE is unchanged except as follows:
The "Local protection desired", "Bandwidth protection desired", The "Local protection desired", "Bandwidth protection desired",
and "Node protection desired" flags SHOULD be cleared. and "Node protection desired" flags SHOULD be cleared.
The "Label recording desired" MAY be modified. The "Label recording desired" MAY be modified.
- The IPv4 (or IPv6) tunnel sender address of the SENDER_TEMPLATE - The IPv4 (or IPv6) tunnel sender address of the SENDER_TEMPLATE
is set to an address belonging to the PLR. is set to an address belonging to the PLR.
- The RSVP_HOP object must contain an IP source address - The RSVP_HOP object MUST contain an IP source address
belonging to the PLR. Consequently, the MP will send messages belonging to the PLR. Consequently, the MP will send messages
back to the PLR using as a destination that IP address. back to the PLR using as a destination that IP address.
- The PLR must generate an EXPLICIT_ROUTE object toward the - The PLR MUST generate an EXPLICIT_ROUTE object toward the
egress. Detailed ERO processing is described below. egress. Detailed ERO processing is described below.
- The RRO object may need to be updated, as described in Section - The RRO object may need to be updated, as described in Section
6.5. 6.5.
The PLR sends Path, PathTear, and ResvConf messages via the backup The PLR sends Path, PathTear, and ResvConf messages via the backup
tunnel. The MP sends Resv, ResvTear, and PathErr messages by tunnel. The MP sends Resv, ResvTear, and PathErr messages by
directly addressing them to the address in the RSVP_HOP object directly addressing them to the address in the RSVP_HOP object
contents as specified in [RSVP]. contents as specified in [RSVP].
If it is necessary to signal the backup prior to failure to If it is necessary to signal the backup prior to failure to
determine the MP label to use, then the same Path message is sent. determine the MP label to use, then the same Path message is sent.
In this case, the PLR should continue to send Path messages for the In this case, the PLR SHOULD continue to send Path messages for the
protected LSP along the normal route. PathTear messages should be protected LSP along the normal route. PathTear messages should be
duplicated, with one sent along the normal route and one sent thru duplicated, with one sent along the normal route and one sent thru
the bypass tunnel. The MP should duplicate the Resv and ResvTear the bypass tunnel. The MP should duplicate the Resv and ResvTear
messages and sent them to both the PLR and the LSR indicated by the messages and sent them to both the PLR and the LSR indicated by the
protected LSP's RSVP_HOP object. protected LSP's RSVP_HOP object.
6.4.4. Processing backup tunnel's ERO 6.4.4. Processing backup tunnel's ERO
Procedures for ERO processing are described in [RSVP-TE]. This Procedures for ERO processing are described in [RSVP-TE]. This
section describes additional ERO update procedures for Path messages section describes additional ERO update procedures for Path messages
skipping to change at page 25, line 14 skipping to change at page 25, line 22
unmodified ERO might contain the IP address of a bypassed node (in unmodified ERO might contain the IP address of a bypassed node (in
the case of a NNHOP Backup Tunnel), or of an interface which is the case of a NNHOP Backup Tunnel), or of an interface which is
currently down (in the case of a NHOP Backup Tunnel). For this currently down (in the case of a NHOP Backup Tunnel). For this
reason, the PLR invoke the following ERO procedures before sending a reason, the PLR invoke the following ERO procedures before sending a
Path message via a bypass tunnel. Path message via a bypass tunnel.
Sub-objects belonging to abstract nodes which precede the Merge Point Sub-objects belonging to abstract nodes which precede the Merge Point
are removed, along with the first sub-object belonging to the MP. A are removed, along with the first sub-object belonging to the MP. A
sub-object identifying the Backup Tunnel destination is then added. sub-object identifying the Backup Tunnel destination is then added.
More specifically, the PLR must: More specifically, the PLR MUST:
- remove all the sub-objects proceeding the first address belonging - remove all the sub-objects proceeding the first address belonging
to the MP. to the MP.
- replace this first MP address with an IP address of the MP. - replace this first MP address with an IP address of the MP.
(Note that this could be same address that was just removed.) (Note that this could be same address that was just removed.)
6.5. PLR Procedures During Local Repair 6.5. PLR Procedures During Local Repair
In addition to the technique specific signaling and packet In addition to the technique specific signaling and packet
treatment, there is common signaling which should be followed. treatment, there is common signaling which should be followed.
During fast reroute, for each protected LSP containing an RRO During fast reroute, for each protected LSP containing an RRO
object, the PLR obtains the RRO from the protected LSP's stored object, the PLR obtains the RRO from the protected LSP's stored
RESV and updates it by inserting an IPv4 sub-object with the IPv4 RESV. The PLR MUST update the IPv4 or IPv6 sub-object it inserted
address of the outbound interface address the traffic is forwarded into the RRO by setting the "Local protection in use" and "Local
onto. Protection Available" flags.
The PLR MUST update the IPv4 or IPv6 sub-object it
inserted into the RRO by setting the "Local protection in use" and
"Local Protection Available" flags.
6.5.1. Notification of local repair 6.5.1. Notification of local repair
In many situations, the route used during a Local Repair will be less In many situations, the route used during a Local Repair will be less
than optimal. The purpose of Local Repair is to keep high priority than optimal. The purpose of Local Repair is to keep high priority
and loss sensitive traffic flowing while a more optimal re-routing of and loss sensitive traffic flowing while a more optimal re-routing of
the tunnel can be effected by the head-end of the tunnel. Thus the the tunnel can be effected by the head-end of the tunnel. Thus the
head-end needs to know of the failure so it may re-signal an LSP head-end needs to know of the failure so it may re-signal an LSP
which is optimal. which is optimal.
skipping to change at page 28, line 27 skipping to change at page 28, line 30
7.1.1. Merginging Backup Paths using the Sender-Template Specific Method 7.1.1. Merginging Backup Paths using the Sender-Template Specific Method
An LSR may receive multiple Path messages for one or more backup An LSR may receive multiple Path messages for one or more backup
LSPs and, possibly, the protected LSP. Each of these Path messages LSPs and, possibly, the protected LSP. Each of these Path messages
will have a different SENDER_TEMPLATE. The protected LSP can be will have a different SENDER_TEMPLATE. The protected LSP can be
recognized because it will either include the FAST_REROUTE object, recognized because it will either include the FAST_REROUTE object,
have the "local protection desired" flag set in the have the "local protection desired" flag set in the
SESSION_ATTRIBUTE object or both. SESSION_ATTRIBUTE object or both.
If the outgoing interface and next-hop LSR are the same, then the If the outgoing interface and next-hop LSR are the same, then the
Path messages are eligible for merging. As specified in [RSVP], Path messages are eligible for merging. Similar to that specified
only those Path messages whose ERO from that LSR to the egress is in [RSVP-TE] for merging of RESV messages, only those Path messages
the same can be merged. If merging occurs and one of the Path whose ERO from that LSR to the egress is the same can be merged.
messages merged was for the protected LSP, then the final Path If merging occurs and one of the Path messages merged was for the
message to be sent MUST be that of the protected LSP. This merges protected LSP, then the final Path message to be sent MUST be that
the backup LSPs into the protected LSP at that LSR. Once the final of the protected LSP. This merges the backup LSPs into the
Path message has been identified, the MP MUST start to refresh it protected LSP at that LSR. Once the final Path message has been
downstream periodically. identified, the MP MUST start to refresh it downstream
periodically.
If merging occurs and all the Path messages were for backup LSPs, If merging occurs and all the Path messages were for backup LSPs,
then the DETOUR object, if any, should be altered as specified in then the DETOUR object, if any, should be altered as specified in
Section 8.1 Section 8.1
7.1.2. Merging Detours using the Path-Specific Method 7.1.2. Merging Detours using the Path-Specific Method
An LSR (that is, an MP) may receive multiple Path messages from An LSR (that is, an MP) may receive multiple Path messages from
different interfaces with identical SESSION and SENDER_TEMPLATE different interfaces with identical SESSION and SENDER_TEMPLATE
objects. In this case, Path state merging is REQUIRED. objects. In this case, Path state merging is REQUIRED.
The merging rule is the following: The merging rule is the following:
For all Path messages that do not have either a FAST_REROUTE or a For all Path messages that do not have either a FAST_REROUTE or a
DETOUR object, or the MP is the egress of the LSP, no merging is DETOUR object, or the MP is the egress of the LSP, no merging is
required. The messages are processed according to [RSVP-TE]. required. The messages are processed according to [RSVP-TE].
Otherwise, the MP MUST record the Path state as well as their Otherwise, the MP MUST record the Path state as well as their
incoming interface. If the Path messages do not share outgoing incoming interface. If the Path messages do not share outgoing
interface and next-hop LSR, the MP must consider them as independent interface and next-hop LSR, the MP MUST consider them as independent
LSPs, and must not merge them. LSPs, and MUST NOT merge them.
For all the Path messages that share the same outgoing interface and For all the Path messages that share the same outgoing interface and
next-hop LSR, the MP runs the following procedure to select one of next-hop LSR, the MP runs the following procedure to select one of
them as the Path message to forward downstream. them as the Path message to forward downstream.
1. Eliminate from consideration those that traverse nodes that 1. Eliminate from consideration those that traverse nodes that
other Path messages want to avoid. other Path messages want to avoid.
2. If one LSP is originated from this node, this must be 2. If one LSP is originated from this node, this must be
the final LSP. Quit. the final LSP. Quit.
skipping to change at page 30, line 31 skipping to change at page 30, line 38
7.1.3. Message Handling for Merged Detours 7.1.3. Message Handling for Merged Detours
When an LSR receives a ResvTear for an LSP, the LSR must determine When an LSR receives a ResvTear for an LSP, the LSR must determine
whether it has an alternate associated LSP. For instance, if the whether it has an alternate associated LSP. For instance, if the
ResvTear was received for a protected LSP, but an associated backup ResvTear was received for a protected LSP, but an associated backup
LSP has not received a ResvTear, then the LSR has an alternate LSP has not received a ResvTear, then the LSR has an alternate
associated LSP. If the LSR does not have an alternate associated associated LSP. If the LSR does not have an alternate associated
LSP, then the MP MUST propogate the ResvTear toward the LSP's LSP, then the MP MUST propogate the ResvTear toward the LSP's
ingress and, for each backup LSP merged into that LSP at this LSR, ingress and, for each backup LSP merged into that LSP at this LSR,
the ResvTear should also be propogated along the backup LSP. the ResvTear SHOULD also be propogated along the backup LSP.
The MP may receive PathTear messages for some of the merging LSPs. The MP may receive PathTear messages for some of the merging LSPs.
No PathTear message should be propagated downstream until the MP PathTear messages SHOULD NOT be propagated downstream until the MP
has received PathTear messages for each of the merged LSPs. has received PathTear messages for each of the merged LSPs.
However, the fact that one or more of the merged LSPs has been torn However, the fact that one or more of the merged LSPs has been torn
down should be reflected in the downstream message, such as by down should be reflected in the downstream message, such as by
changing the DETOUR object, if any. changing the DETOUR object, if any.
7.2. Handling Failures 7.2. Handling Failures
When a downstream LSR detects a local link failure, for any When a downstream LSR detects a local link failure, for any
protected LSPs routed over the failed link, Path and Resv state protected LSPs routed over the failed link, Path and Resv state
MUST NOT be cleared and PathTear and ResvErr messages MUST NOT be MUST NOT be cleared and PathTear and ResvErr messages MUST NOT be
skipping to change at page 33, line 22 skipping to change at page 33, line 28
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
13. Acknowledgments 13. Acknowledgments
We would like to acknowledge input and helpful comments from Rob We would like to acknowledge input and helpful comments from Rob
Goguen, Tony Li, Yakov Rekhter and Curtis Villamizar. Especially, Goguen, Tony Li, Yakov Rekhter and Curtis Villamizar. Especially,
we thank those, who have been involved in interoperability testing we thank those, who have been involved in interoperability testing
and field trails, and provided invaluable ideas and suggestions. and field trails, and provided invaluable ideas and suggestions.
They are Rob Goguen, Carol Iturralde, Brook Bailey, Safaa Hasan, They are Rob Goguen, Carol Iturralde, Brook Bailey, Safaa Hasan,
and Richard Southern. Richard Southern, and Bijan Jabbari.
14. References 14. Normative References
[RSVP] R. Braden, Ed., et al, "Resource ReSerVation protocol (RSVP) [RSVP] R. Braden, Ed., et al, "Resource ReSerVation protocol (RSVP)
-- version 1 functional specification," RFC2205, September 1997. -- version 1 functional specification," RFC2205, September 1997.
[RSVP-TE] D. Awduche, et al, "RSVP-TE: Extensions to RSVP for LSP [RSVP-TE] D. Awduche, et al, "RSVP-TE: Extensions to RSVP for LSP
tunnels", RFC3029, December 2001. tunnels", RFC3029, December 2001.
[RFC-WORDS] Bradner, S., "Key words for use in RFCs to Indicate [RFC-WORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997. Requirement Levels", RFC 2119, March 1997.
[OSPF-TE] Katz, Yeung, Traffic Engineering Extensions to OSPF,
draft-katz-yeung-ospf-traffic-05.txt, June 2001.
[ISIS-TE] Smit, Li, IS-IS extensions for Traffic Engineering, draft-
ietf-isis-tr affic-03.txt, June 2001.
[RSVP-REFRESH] L. Berger, et al, "RSVP Refresh Overhead Reduction
Extensions", RFC2961.
[RFC-IANA] T. Narten and H. Alvestrand, "Guidelines for Writing an [RFC-IANA] T. Narten and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", RFC 2434. IANA Considerations Section in RFCs", RFC 2434.
15. Author Information 15. Author Information
Ping Pan Ping Pan
CIENA Corp. CIENA Corp.
10480 Ridgeview Court 10480 Ridgeview Court
Cupertino, CA 95014 Cupertino, CA 95014
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/