--- 1/draft-ietf-mpls-rsvp-lsp-fastreroute-04.txt 2006-02-05 00:42:34.000000000 +0100 +++ 2/draft-ietf-mpls-rsvp-lsp-fastreroute-05.txt 2006-02-05 00:42:34.000000000 +0100 @@ -1,18 +1,17 @@ - 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) 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 This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. @@ -542,23 +541,23 @@ | Avoid Node ID n | +-------------+-------------+-------------+-------------+ PLR ID (1 - n) IPv4 address identifying the beginning point of detour which is a PLR. Any local address on the PLR can be used. Avoid Node ID (1 - n) - IP address identifying the immediate downstream node that - the PLR is trying to avoid. Router ID of downstream node - is preferred. This field is mandatory, and is used by + IPv4 address identifying the immediate downstream node that + the PLR is trying to avoid. Any local address of the downstream + node can be used. This field is mandatory, and is used by the MP for merging rules discussed below. 5.2.2 DETOUR object for IPv6 address C-Type = 8 0 1 2 3 +-------------+-------------+-------------+-------------+ | Length (bytes) | Class-Num | C-Type | +-------------+-------------+-------------+-------------+ @@ -576,30 +575,32 @@ +-------------+-------------+-------------+-------------+ | Avoid Node ID 1 (continued) | +-------------+-------------+-------------+-------------+ | Avoid Node ID 1 (continued) | +-------------+-------------+-------------+-------------+ // .... // +-------------+-------------+-------------+-------------+ PLR ID (1 - n) - A 128-bit unicast host address identifying the beginning point - of detour which is a PLR. Any local address on the PLR can be - used. + An IPv6 128-bit unicast host address identifying the beginning + point of detour which is a PLR. Any local address on the PLR + can be used. Avoid Node ID (1 - n) - A 128-bit unicast host address identifying the immediate - downstream node that the PLR is trying to avoid. Router ID of - downstream node is preferred. This field is mandatory, and is - used by the MP for merging rules discussed below. + An IPv6 128-bit unicast host address identifying the immediate + downstream node that the PLR is trying to avoid. Any local + address on the downstream node can be used. This field is + 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 a DETOUR object. If detour merging is desired, after each merging operation, the Detour Merge Point should combine all the merged detours in the subsequent Path messages. 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 object and send a PathErr to notify the PLR. This PathErr SHOULD be generated as specified in [RSVP] for unknown objects with a @@ -1389,61 +1387,61 @@ 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 required. The messages are processed according to [RSVP-TE]. Otherwise, the MP MUST record the Path state as well as their incoming interface. If the Path messages do not share outgoing interface and next-hop LSR, the MP MUST consider them as independent LSPs, and MUST NOT merge them. 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 - them as the Path message 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. + next-hop LSR, the MP runs the following procedure to a Path message + to forward downstream. - 5. If several candidates remain (that is, there are both detour - and protected LSPs), prefer the ones with FAST_REROUTE object. + 1. If one or more of the Path messages is for the protected LSP + (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 - found, prefer the ones with DETOUR object. + 2. From the remaining set of Detour Path messages, eliminate from + consideration, those that traverse nodes which others want to + avoid. - 7. If several candidate Path message still remain, it is a local - decision to choose which one will be the final LSP. The decision - can be based on the number of IP hops in ERO, bandwidth - requirements, or others. + 3. If several still remain, it is a local decision to choose which + one to forward. If none remain, then the MP may try and find a + new route that does avoid all nodes that all merging Detour + 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 refresh it downstream periodically. Other LSPs are considered merged at this node. For bandwidth reservation on the outgoing link, any merging should be considered to have occured before bandwidth is reserved. Thus, even though Fixed Filter is specified, multiple detours and/or their protected LSP which are to be merged due to sharing an outgoing interface and next-hop LSR will reserve only the bandwidth of the final Path message on that outgoing 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 R7---R8---R9-\ | | | \ R1---R2---R3---R4---R5---R6 + Protected LSP: [R1->R2->R3->R4->R5->R6] R2's Detour: [R2->R7->R8->R9->R4->R5->R6] R3's Detour: [R3->R8->R9->R5->R6] Example 4: Path Message Merging In Example 4 above, R8 will receive Path messages that have the same SESSION and SENDER_TEMPLATE from detours for R2 and R3. 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