draft-ietf-mpls-rsvp-lsp-fastreroute-04.txt   draft-ietf-mpls-rsvp-lsp-fastreroute-05.txt 
Internet Draft Ping Pan, Ed (Ciena Corp) Internet Draft Ping Pan, Ed (Ciena Corp)
Expires: August 2004 George Swallow, Ed (Cisco Systems) Expires: November 2004 George Swallow, Ed (Cisco Systems)
Alia Atlas, Ed (Avici Systems) Alia Atlas, Ed (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-04.txt draft-ietf-mpls-rsvp-lsp-fastreroute-05.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 13, line 7 skipping to change at page 13, line 7
| Avoid Node ID n | | Avoid Node ID n |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
PLR ID (1 - n) PLR ID (1 - n)
IPv4 address identifying the beginning point of detour which is IPv4 address identifying the beginning point of detour which is
a PLR. Any local address on the PLR can be used. a PLR. Any local address on the PLR can be used.
Avoid Node ID (1 - n) Avoid Node ID (1 - n)
IP address identifying the immediate downstream node that IPv4 address identifying the immediate downstream node that
the PLR is trying to avoid. Router ID of downstream node the PLR is trying to avoid. Any local address of the downstream
is preferred. This field is mandatory, and is used by node can be used. This field is mandatory, and is used by
the MP for merging rules discussed below. the MP for merging rules discussed below.
5.2.2 DETOUR object for IPv6 address 5.2.2 DETOUR object for IPv6 address
C-Type = 8 C-Type = 8
0 1 2 3 0 1 2 3
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| Length (bytes) | Class-Num | C-Type | | Length (bytes) | Class-Num | C-Type |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
skipping to change at page 13, line 41 skipping to change at page 13, line 41
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| Avoid Node ID 1 (continued) | | Avoid Node ID 1 (continued) |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| Avoid Node ID 1 (continued) | | Avoid Node ID 1 (continued) |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
// .... // // .... //
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
PLR ID (1 - n) PLR ID (1 - n)
A 128-bit unicast host address identifying the beginning point An IPv6 128-bit unicast host address identifying the beginning
of detour which is a PLR. Any local address on the PLR can be point of detour which is a PLR. Any local address on the PLR
used. can be used.
Avoid Node ID (1 - n) Avoid Node ID (1 - n)
A 128-bit unicast host address identifying the immediate An IPv6 128-bit unicast host address identifying the immediate
downstream node that the PLR is trying to avoid. Router ID of downstream node that the PLR is trying to avoid. Any local
downstream node is preferred. This field is mandatory, and is address on the downstream node can be used. This field is
used by the MP for merging rules discussed below. mandatory, and is used by 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. This PathErr SHOULD object and send a PathErr to notify the PLR. This PathErr SHOULD
be generated as specified in [RSVP] for unknown objects with a be generated as specified in [RSVP] for unknown objects with a
skipping to change at page 31, line 9 skipping to change at page 31, line 12
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 a Path message
them as the Path message to forward downstream. to forward downstream.
1. Eliminate from consideration those that traverse nodes that
other Path messages want to avoid.
2. If one LSP is originated from this node, this must be
the final LSP. Quit.
3. If only one Path message contains FAST_REROUTE object, this
becomes the chosen Path message. Quit.
4. If there are several LSPs, and not all of them have a DETOUR
object, then eliminate those with DETOUR from consideration.
5. If several candidates remain (that is, there are both detour 1. If one or more of the Path messages is for the protected LSP
and protected LSPs), prefer the ones with FAST_REROUTE object. (a protected LSP is one originated from this node, or with
the FAST_REROUTE object, or without the DETOUR object),
one of these must become the chosen Path message. There could
be more than one; in that case, it is a local decision to choose
which one to forward. Quit.
6. If none found, prefer the ones without DETOUR object. If none 2. From the remaining set of Detour Path messages, eliminate from
found, prefer the ones with DETOUR object. consideration, those that traverse nodes which others want to
avoid.
7. If several candidate Path message still remain, it is a local 3. If several still remain, it is a local decision to choose which
decision to choose which one will be the final LSP. The decision one to forward. If none remain, then the MP may try and find a
can be based on the number of IP hops in ERO, bandwidth new route that does avoid all nodes that all merging Detour
requirements, or others. Paths want to avoid and forward a Path message with that ERO.
Once the final Path message has been identified, the MP MUST start to Once the final Path message has been identified, the MP MUST start to
refresh it downstream periodically. Other LSPs are considered merged refresh it downstream periodically. Other LSPs are considered merged
at this node. For bandwidth reservation on the outgoing link, any at this node. For bandwidth reservation on the outgoing link, any
merging should be considered to have occured before bandwidth is merging should be considered to have occured before bandwidth is
reserved. Thus, even though Fixed Filter is specified, multiple reserved. Thus, even though Fixed Filter is specified, multiple
detours and/or their protected LSP which are to be merged due to detours and/or their protected LSP which are to be merged due to
sharing an outgoing interface and next-hop LSR will reserve only sharing an outgoing interface and next-hop LSR will reserve only
the bandwidth of the final Path message on that outgoing the bandwidth of the final Path message on that outgoing
interface. interface.
If no merged Path message can be constructed then the MP SHOULD send
a PathErr in response to the most recently received detour Path
message. If a protected Path is chosen to be forwarded, but it
traverses nodes that some detours want to avoid, PathErrs should be
sent in response to those detour Paths which cannot merge.
8.1.2.1. An Example on Path Message Merging 8.1.2.1. An Example on Path Message Merging
R7---R8---R9-\ R7---R8---R9-\
| | | \ | | | \
R1---R2---R3---R4---R5---R6 R1---R2---R3---R4---R5---R6
Protected LSP: [R1->R2->R3->R4->R5->R6] Protected LSP: [R1->R2->R3->R4->R5->R6]
R2's Detour: [R2->R7->R8->R9->R4->R5->R6] R2's Detour: [R2->R7->R8->R9->R4->R5->R6]
R3's Detour: [R3->R8->R9->R5->R6] R3's Detour: [R3->R8->R9->R5->R6]
Example 4: Path Message Merging Example 4: Path Message Merging
In Example 4 above, R8 will receive Path messages that have the In Example 4 above, R8 will receive Path messages that have the
same SESSION and SENDER_TEMPLATE from detours for R2 and R3. same SESSION and SENDER_TEMPLATE from detours for R2 and R3.
During merging at R8 since detour R3 has a shorter ERO path length During merging at R8 since detour R3 has a shorter ERO path length
(that is, ERO is [R9->R5->R6], and path length is 3), R8 will (that is, ERO is [R9->R5->R6], and path length is 3), R8 will
 End of changes. 

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