分享
 
 
 

RFC4090 - Fast Reroute Extensions to RSVP-TE for LSP Tunnels

王朝other·作者佚名  2008-05-31
窄屏简体版  字體: |||超大  

Network Working Group P. Pan, Ed.

Request for Comments: 4090 Hammerhead Systems

Category: Standards Track G. Swallow, Ed.

Cisco Systems

A. Atlas, Ed.

Avici Systems

May 2005

Fast Reroute Extensions to RSVP-TE for LSP Tunnels

Status of This Memo

This document specifies an Internet standards track protocol for the

Internet community, and requests discussion and suggestions for

improvements. Please refer to the current edition of the "Internet

Official Protocol Standards" (STD 1) for the standardization state

and status of this protocol. Distribution of this memo is unlimited.

Copyright Notice

Copyright (C) The Internet Society (2005).

Abstract

This document defines RSVP-TE extensions to establish backup label-

switched path (LSP) tunnels for local repair of LSP tunnels. These

mechanisms enable the re-direction of traffic onto backup LSP tunnels

in 10s of milliseconds, in the event of a failure.

Two methods are defined here. The one-to-one backup method creates

detour LSPs for each protected LSP at each potential point of local

repair. The facility backup method creates a bypass tunnel to

protect a potential failure point; by taking advantage of MPLS label

stacking, this bypass tunnel can protect a set of LSPs that have

similar backup constraints. Both methods can be used to protect

links and nodes during network failure. The described behavior and

extensions to RSVP allow nodes to implement either method or both and

to interoperate in a mixed network.

Table of Contents

1. IntrodUCtion ...................................................3

1.1. Background ...............................................4

2. Terminology ....................................................4

3. Local Repair Techniques ........................................6

3.1. One-to-One Backup ........................................6

3.2. Facility Backup ..........................................7

4. RSVP Extensions ................................................8

4.1. FAST_REROUTE Object ......................................8

4.2. DETOUR Object ...........................................11

4.2.1. DETOUR Object for IPv4 Address ...................11

4.2.2. DETOUR Object for IPv6 Address ...................12

4.3. SESSION_ATTRIBUTE Flags .................................13

4.4. RRO IPv4/IPv6 Sub-object Flags ..........................14

5. Head-End Behavior .............................................15

6. Point of Local Repair (PLR) Behavior ..........................16

6.1. Signaling a Backup Path .................................17

6.1.1. Backup Path Identification: Sender

Template-Specific ................................19

6.1.2. Backup Path Identification: Path-Specific ........19

6.2. Procedures for Backup Path Computation ..................20

6.3. Signaling Backups for One-to-One Protection .............21

6.3.1. Make-before-Break with Detour LSPs ...............22

6.3.2. Message Handling .................................23

6.3.3. Local Reroute of Traffic onto Detour LSP .........23

6.4. Signaling for Facility Protection .......................24

6.4.1. Discovering Downstream Labels ....................24

6.4.2. Procedures for the PLR before Local Repair .......24

6.4.3. Procedures for the PLR during Local Repair .......25

6.4.4. Processing Backup Tunnel's ERO ...................26

6.5. PLR Procedures during Local Repair ......................26

6.5.1. Notification of Local Repair .....................26

6.5.2. Revertive Behavior ...............................27

7. Merge Node Behavior ...........................................28

7.1. Handling Backup Path Messages before Failure ............28

7.1.1. Merging Backup Paths using the Sender

Template-Specific Method .........................29

7.1.2. Merging Detours using the Path-Specific Method ...29

7.1.3. Message Handling for Merged Detours ..............31

7.2. Handling Failures .......................................31

8. Behavior of All LSRs ..........................................32

8.1. Merging Detours in the Path-Specific Method .............32

9. Security Considerations .......................................33

10. IANA Considerations ...........................................33

11. Contributors ..................................................35

12. Acknowledgments ...............................................36

13. Normative References ..........................................36

1. Introduction

This document extends RSVP [RSVP] to establish backup label-switched

path (LSP) tunnels for the local repair of LSP tunnels. This

extension will meet the needs of real-time applications such as voice

over IP, for which user traffic should be redirected onto backup LSP

tunnels in 10s of milliseconds. This timing requirement can be

satisfied by computing and signaling backup LSP tunnels in advance of

failure and by re-directing traffic as close to the failure point as

possible. In this way, the time for redirection includes no path

computation and no signaling delays, including delays to propagate

failure notification between label-switched routers (LSRs). Speed of

repair is the primary advantage of the methods and extensions

described here. The term local repair is used when referring to

techniques that re-direct traffic to a backup LSP tunnel in response

to a local failure.

A protected LSP is an eXPlicitly-routed LSP that is provided with

protection. The repair methods described here are applicable only to

explicitly-routed LSPs. Application of these methods to LSPs that

dynamically change their routes, such as LSPs used in unicast IGP

routing, is beyond the scope of this document.

Section 2 covers new terminology used in this document. Section 3

describes two basic methods for creating backup LSPs. Section 4

describes the RSVP protocol extensions to support local protection.

Section 5 presents the behavior of an LSR that seeks to request local

protection for an LSP. The behavior of a potential point of local

repair (PLR) is given in Section 6, which describes how to determine

the appropriate strategy for protecting an LSP and how to implement

each of the strategies. Section 7 describes the behavior of a merge

node, the LSR where a protected LSP and its backup LSP rejoin.

Finally, Section 8 discusses the required behavior of other nodes in

the network.

The methods discussed in this document depend upon three assumptions:

o An LSR that 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.

o 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.

o Understanding 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.

1.1. Background

Several years before work began on this document, operational

networks had deployed two independent methods of doing fast reroute;

these methods are called here one-to-one backup and facility backup.

Vendors trying to support both methods experienced compatibility

problems in attempting to produce a single implementation capable of

interoperating with both methods. There are technical tradeoffs

between the methods. These tradeoffs are so topologically dependent

that the community has not converged on a single approach.

This document rationalizes the RSVP signaling for both methods so

that any implementation can recognize all fast reroute requests and

clearly respond. The response may be positive if the method can be

performed, or it may be a clear error to inform the requester to seek

alternate backup means. This document also allows a single

implementation to support both methods, thereby providing a range of

capabilities. The described behavior and extensions to RSVP allow

LERs and LSRs to implement either method or both.

While the two methods could in principle be used in a single network,

it is expected that operators will continue to deploy either one or

the other. The goal of this document is to standardize the RSVP

signaling so that a network composed of LSRs that implement both

methods or a network composed of some LSRs that support one method

and others that support both can properly signal among those LSRs to

achieve fast restoration.

2. Terminology

The key Words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",

"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this

document are to be interpreted as described in RFC2119 [RFC-WORDS].

The reader is assumed to be familiar with the terminology in [RSVP]

and [RSVP-TE].

LSR: Label-Switch Router.

LSP: An MPLS Label-Switched Path. In this document, an LSP will

always be explicitly routed.

Local Repair: Techniques used to repair LSP tunnels quickly when a

node or link along the LSP's path fails.

PLR: Point of Local Repair. The head-end LSR of a backup tunnel

or a detour LSP.

One-to-One Backup: A local repair method in which a backup LSP is

separately created for each protected LSP at a PLR.

Facility Backup: A local repair method in which a bypass tunnel is

used to protect one or more protected LSPs that traverse the

PLR, the resource being protected, and the Merge Point in

that order.

Protected LSP: An LSP is said to be protected at a given hop if it

has one or multiple associated backup tunnels originating at

that hop.

Detour LSP: The LSP that is used to re-route traffic around a

failure in one-to-one backup.

Bypass Tunnel: An LSP that is used to protect a set of LSPs

passing over a common facility.

Backup Tunnel: The LSP that is used to backup up one of the many

LSPs in many-to-one backup.

NHOP Bypass Tunnel: Next-Hop Bypass Tunnel. A backup tunnel that

bypasses a single link of the protected LSP.

NNHOP Bypass Tunnel: Next-Next-Hop Bypass Tunnel. A backup tunnel

that bypasses a single node of the protected LSP.

Backup Path: The LSP that is responsible for backing up one

protected LSP. A backup path refers to either a detour LSP

or a backup tunnel.

MP: Merge Point. The LSR where one or more backup tunnels rejoin

the path of the protected LSP downstream of the potential

failure. The same LSR may be both an MP and a PLR

simultaneously.

DMP: Detour Merge Point. In the case of one-to-one backup, this

is an LSR where multiple detours converge. Only one detour

is signaled beyond that LSR.

Reroutable LSP: Any LSP for which the head-end LSR requests local

protection. See Section 5 for more detail.

CSPF: Constraint-based Shortest Path First.

SRLG Disjoint: A path is considered to be SRLG disjoint from a

given link or node if the path does not use any links or

nodes which belong to the same SRLG as that given link or

node.

3. Local Repair Techniques

Two different methods for local protection are described. In the

one-to-one backup method, a PLR computes a separate backup LSP,

called a detour LSP, for each LSP that the PLR protects. In the

facility backup method, the PLR creates a single bypass tunnel that

can be used to protect multiple LSPs.

3.1. One-to-One Backup

In the one-to-one backup method, a label-switched path is established

that intersects the original LSP somewhere downstream of the point of

link or node failure. A separate backup LSP is established for each

LSP that is backed up.

[R1]----[R2]----[R3]------[R4]------[R5]

\ \ \ / \ /

[R6]----[R7]----[R8]------[R9]

Protected LSP: [R1->R2->R3->R4->R5]

R1's Backup: [R1->R6->R7->R8->R3]

R2's Backup: [R2->R7->R8->R4]

R3's Backup: [R3->R8->R9->R5]

R4's Backup: [R4->R9->R5]

Example 1. One-to-One Backup Technique

In the simple topology shown in Example 1, the protected LSP runs

from R1 to R5. R2 can provide user traffic protection by creating a

partial backup LSP that merges with the protected LSP at R4. We

refer to a partial one-to-one backup LSP [R2->R7->R8->R4] as a

detour.

To protect an LSP that traverses N nodes fully, there could be as

many as (N - 1) detours. Example 1 shows the paths for the detours

necessary to protect fully the LSP in the example. To minimize the

number of LSPs in the network, it is desirable to merge a detour back

to its protected LSP, when feasible. When a detour LSP intersects

its protected LSP at an LSR with the same outgoing interface, it will

be merged.

When a failure occurs along the protected LSP, the PLR redirects

traffic onto the local detour. For instance, if the link [R2->R3]

fails in Example 1, R2 will switch traffic received from R1 onto the

protected LSP along link [R2->R7], using the label received when R2

created the detour. When R4 receives traffic with the label provided

for R2's detour, R4 will switch that traffic onto link [R4-R5], using

the label received from R5 for the protected LSP. At no point does

the depth of the label stack increase as a result of the detour.

While R2 is using its detour, traffic will take the path

[R1->R2->R7->R8->R4->R5].

3.2. Facility Backup

The facility backup method takes advantage of the MPLS label stack.

Instead of creating a separate LSP for every backed-up LSP, a single

LSP is created that serves to back up a set of LSPs. We call such an

LSP tunnel a bypass tunnel.

The bypass tunnel must intersect the path of the original LSP(s)

somewhere downstream of the PLR. Naturally, this constrains the set

of LSPs being backed up via that bypass tunnel to those that pass

through some common downstream node. All LSPs that pass through the

point of local repair and through this common node that do not also

use the facilities involved in the bypass tunnel are candidates for

this set of LSPs.

[R8]

[R1]---[R2]----[R3]-----[R4]---[R5]

\ / [R6]===[R7] [R9]

Protected LSP 1: [R1->R2->R3->R4->R5]

Protected LSP 2: [R8->R2->R3->R4]

Protected LSP 3: [R2->R3->R4->R9]

Bypass LSP Tunnel: [R2->R6->R7->R4]

Example 2. Facility Backup Technique

In Example 2, R2 has built a bypass tunnel that protects against the

failure of link [R2->R3] and node [R3]. The doubled lines represent

this tunnel. This technique provides a scalability improvement, in

that the same bypass tunnel can also be used to protect LSPs from any

of R1, R2, or R8 to any of R4, R5, or R9. Example 2 describes three

different protected LSPs that are using the same bypass tunnel for

protection.

As with the one-to-one method, there could be as many as (N-1) bypass

tunnels to fully protect an LSP that traverses N nodes. However,

each of those bypass tunnels could protect a set of LSPs.

When a failure occurs along a protected LSP, the PLR redirects

traffic into the appropriate bypass tunnel. For instance, if link

[R2->R3] fails in Example 2, R2 will switch traffic received from R1

on the protected LSP onto link [R2->R6]. The label will be switched

for one which will be understood by R4 to indicate the protected LSP,

and the bypass tunnel's label will then be pushed onto the label-

stack of the redirected packets. If penultimate-hop-popping is used,

the merge point in Example 2, R4, will receive the redirected packet

with a label indicating the protected LSP that the packet is to

follow. If penultimate-hop-popping is not used, R4 will pop the

bypass tunnel's label and examine the label underneath to determine

the protected LSP that the packet is to follow. When R2 is using the

bypass tunnel for protected LSP 1, the traffic takes the path

[R1->R2->R6->R7->R4->R5]; the bypass tunnel is the connection between

R2 and R4.

4. RSVP Extensions

This specification defines two additional objects, FAST_REROUTE and

DETOUR, to extend RSVP-TE for fast-reroute signaling. These new

objects are backward compatible with LSRs that do not recognize them

(see section 3.10 in [RSVP]). Both objects can only be carried in

RSVP Path messages.

The SESSION_ATTRIBUTE and RECORD_ROUTE objects are also extended to

support bandwidth and node protection features.

4.1. FAST_REROUTE Object

The FAST_REROUTE object is used to control the backup used for the

protected LSP. This specifies the setup and hold priorities, session

attribute filters, and bandwidth to be used for protection. It also

allows a specific local protection method to be requested. This

object MUST only be inserted into the PATH message by the head-end

LER and MUST NOT be changed by downstream LSRs. The FAST_REROUTE

object has the following format:

Class-Num = 205

C-Type = 1

0 1 2 3

+-------------+-------------+-------------+-------------+

Length (bytes) Class-Num C-Type

+-------------+-------------+-------------+-------------+

Setup Prio Hold Prio Hop-limit Flags

+-------------+-------------+-------------+-------------+

Bandwidth

+-------------+-------------+-------------+-------------+

Include-any

+-------------+-------------+-------------+-------------+

Exclude-any

+-------------+-------------+-------------+-------------+

Include-all

+-------------+-------------+-------------+-------------+

Setup Priority

The priority of the backup path with respect to taking

resources, in the range 0 to 7. The value 0 is the highest

priority. Setup Priority is used in deciding whether this

session can preempt another session. See [RSVP-TE] for the

usage on priority.

Holding Priority

The priority of the backup path with respect to holding

resources, in the range 0 to 7. The value 0 is the highest

priority. Holding Priority is used in deciding whether this

session can be preempted by another session. See [RSVP-TE] for

the usage on priority.

Hop-limit

The maximum number of extra hops the backup path is allowed to

take, from current node (a PLR) to an MP, with PLR and MP

excluded from the count. For example, hop-limit of 0 means

that only direct links between PLR and MP can be considered.

Flags

0x01 One-to-One Backup Desired

Requests protection via the one-to-one backup method.

0x02 Facility Backup Desired

Requests protection via the facility backup method.

Bandwidth

Bandwidth estimate; 32-bit IEEE floating point integer, in

bytes per second.

Exclude-any

A 32-bit vector representing a set of attribute filters

associated with a backup path, any of which renders a link

unacceptable.

Include-any

A 32-bit vector representing a set of attribute filters

associated with a backup path, any of which renders a link

acceptable (with respect to this test). A null set (all bits

set to zero) automatically passes.

Include-all

A 32-bit vector representing a set of attribute filters

associated with a backup path, all of which must be present for

a link to be acceptable (with respect to this test). A null

set (all bits set to zero) automatically passes.

The two high-order bits of the Class-Num (11) cause nodes that do not

understand the object to ignore it and pass it forward unchanged.

For informational purposes, a different C-Type value and format for

the FAST_REROUTE object are specified below. This is used by legacy

implementations. The meaning of the fields is the same as that

described for C-Type 1.

Class-Num = 205

C-Type = 7

0 1 2 3

+-------------+-------------+-------------+-------------+

Length (bytes) Class-Num C-Type

+-------------+-------------+-------------+-------------+

Setup Prio Hold Prio Hop-limit Reserved

+-------------+-------------+-------------+-------------+

Bandwidth

+-------------+-------------+-------------+-------------+

Include-any

+-------------+-------------+-------------+-------------+

Exclude-any

+-------------+-------------+-------------+-------------+

Unknown C-Types should be treated as specified in [RSVP] Section

3.10.

4.2. DETOUR Object

The DETOUR object is used in the one-to-one backup method to identify

detour LSPs.

4.2.1. DETOUR Object for IPv4 Address

Class-Num = 63

C-Type = 7

0 1 2 3

+-------------+-------------+-------------+-------------+

Length (bytes) Class-Num C-Type

+-------------+-------------+-------------+-------------+

PLR_ID 1

+-------------+-------------+-------------+-------------+

Avoid_Node_ID 1

+-------------+-------------+-------------+-------------+

// .... //

+-------------+-------------+-------------+-------------+

PLR_ID n

+-------------+-------------+-------------+-------------+

Avoid_Node_ID n

+-------------+-------------+-------------+-------------+

PLR_ID (1 - n)

IPv4 address identifying the PLR that is the beginning point of

the detour. Any local address on the PLR can be used.

Avoid_Node_ID (1 - n)

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 the merging rules discussed below.

4.2.2. DETOUR Object for IPv6 Address

Class-Num = 63

C-Type = 8

0 1 2 3

+-------------+-------------+-------------+-------------+

Length (bytes) Class-Num C-Type

+-------------+-------------+-------------+-------------+

PLR_ID 1

+-------------+-------------+-------------+-------------+

PLR_ID 1 (continued)

+-------------+-------------+-------------+-------------+

PLR_ID 1 (continued)

+-------------+-------------+-------------+-------------+

PLR_ID 1 (continued)

+-------------+-------------+-------------+-------------+

Avoid_Node_ID 1

+-------------+-------------+-------------+-------------+

Avoid_Node_ID 1 (continued)

+-------------+-------------+-------------+-------------+

Avoid_Node_ID 1 (continued)

+-------------+-------------+-------------+-------------+

Avoid_Node_ID 1 (continued)

+-------------+-------------+-------------+-------------+

// .... //

+-------------+-------------+-------------+-------------+

PLR_ID (1 - n)

An IPv6 128-bit unicast host address identifying the PLR that

is the beginning point of the detour. Any local address on the

PLR can be used.

Avoid_Node_ID (1 - n)

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 the 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 subsequent Path messages.

The high-order bit of the Class-Num 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 Class-Num

of the form "0bbbbbbb".

Unknown C-Types should be treated as specified in [RSVP] Section

3.10.

4.3. SESSION_ATTRIBUTE Flags

To request bandwidth and node protection explicitly, two new flags

are defined in the SESSION_ATTRIBUTE object.

For both C-Type 1 and 7, the SESSION_ATTRIBUTE object currently has

the following flags defined [RSVP-TE]:

Local protection desired: 0x01

This flag permits transit routers to use a local repair

mechanism that may result in violation of the explicit route

object. When a fault is detected on an adjacent downstream

link or node, a transit node may reroute traffic for fast

service restoration.

Label recording desired: 0x02

This flag indicates that label information should be included

when doing a route record.

SE Style desired: 0x04

This flag indicates that the tunnel ingress node may choose to

reroute this tunnel without tearing it down. A tunnel egress

node SHOULD use the SE Style when responding with a Resv

message. When requesting fast reroute, the head-end LSR SHOULD

set this flag; this is not necessary for the path-specific

method of the one-to-one backup method.

The following new flags are defined:

Bandwidth protection desired: 0x08

This flag indicates to the PLRs along the protected LSP path

that a backup path with a bandwidth guarantee is desired. The

bandwidth to be guaranteed is that of the protected LSP, if no

FAST_REROUTE object is included in the PATH message; if a

FAST_REROUTE object is in the PATH message, then the bandwidth

specified therein is to be guaranteed.

Node protection desired: 0x10

This flag indicates to the PLRs along a protected LSP path that

a backup path that bypasses at least the next node of the

protected LSP is desired.

4.4. RRO IPv4/IPv6 Sub-object Flags

To report whether bandwidth and/or node protection are provided as

requested, we define two new flags in the RRO IPv4 sub-object.

The RRO IPv4 and IPv6 address sub-objects currently have the

following flags defined [RSVP-TE]:

Local protection available: 0x01

Indicates that the link downstream of this node is protected

via a local repair mechanism, which can be either one-to-one or

facility backup.

Local protection in use: 0x02

Indicates that a local repair mechanism is in use to maintain

this tunnel (usually in the face of an outage of the link it

was previously routed over, or an outage of the neighboring

node).

Two new flags are defined:

Bandwidth protection: 0x04

The PLR will set this bit when the protected LSP has a backup

path that is guaranteed to provide the desired bandwidth that

is specified in the FAST_REROUTE object or the bandwidth of the

protected LSP, if no FAST_REROUTE object was included. The PLR

may set this whenever the desired bandwidth is guaranteed; the

PLR MUST set this flag when the desired bandwidth is guaranteed

and the "bandwidth protection desired" flag was set in the

SESSION_ATTRIBUTE object. If the requested bandwidth is not

guaranteed, the PLR MUST NOT set this flag.

Node protection: 0x08

The PLR will set this bit when the protected LSP has a backup

path that provides protection against a failure of the next LSR

along the protected LSP. The PLR may set this whenever node

protection is provided by the protected LSP's backup path; the

PLR MUST set this flag when the node protection is provided and

the "node protection desired" flag was set in the

SESSION_ATTRIBUTE object. If node protection is not provided,

the PLR MUST NOT set this flag. Thus, if a PLR could only set

up a link-protection backup path, the "Local protection

available" bit will be set, but the "Node protection" bit will

be cleared.

5. Head-End Behavior

The head-end of an LSP determines whether local protection should be

requested for that LSP and which local protection method is desired

for the protected LSP. The head-end also determines what constraints

should be requested for the backup paths of a protected LSP.

To indicate that an LSP should be locally protected, the head-end LSR

MUST either set the "local protection desired" flag in the

SESSION_ATTRIBUTE object or include a FAST_REROUTE object in the PATH

message, or both. The "local protection desired" flag in the

SESSION_ATTRIBUTE object SHOULD always be set. If a head-end LSR

signals a FAST_REROUTE object, it MUST be stored for Path refreshes.

The head-end LSR of a protected LSP MUST set the "label recording

desired" flag in the SESSION_ATTRIBUTE object. This facilitates the

use of the facility backup method. If node protection is desired,

the head-end LSR should set the "node protection desired" flag in the

SESSION_ATTRIBUTE object; otherwise, this flag should be cleared.

Similarly, if a guarantee of bandwidth protection is desired, then

the "bandwidth protection desired" flag in the SESSION_ATTRIBUTE

object should be set; otherwise, this flag should be cleared. If the

head-end LSR determines that control of the backup paths for the

protected LSP is desired, then the LSR should include the

FAST_REROUTE object. The PLRs will use the attribute filters,

bandwidth, hop-limit, and priorities to determine the backup paths.

If the head-end LSR desires that the one-to-one backup method be used

for the protected LSP, then the head-end LSR should include a

FAST_REROUTE object and set the "one-to-one backup desired" flag. If

the head-end LSR desires that the protected LSP be protected via the

facility backup method, then the head-end LSR should include a

FAST_REROUTE object and set the "facility backup desired" flag. The

lack of a FAST_REROUTE object, or having both these flags clear,

should be treated by PLRs as a lack of preference. If both flags are

set, a PLR may use either method or both.

The head-end LSR of a protected LSP MUST support the additional flags

defined in Section 4.4 being set or clear in the RRO IPv4 and IPv6

sub-objects. The head-end LSR of a protected LSP MUST support the

RRO Label sub-object.

If the head-end LSR of an LSP determines that local protection is

newly desired, this SHOULD be signaled via make-before-break.

6. Point of Local Repair (PLR) Behavior

Every LSR along a protected LSP (except the egress) MUST follow the

PLR behavior described in this document.

A PLR SHOULD support the FAST_REROUTE object, the "local protection

desired", "label recording desired", "node protection desired", and

"bandwidth protection desired" flags in the SESSION_ATTRIBUTE object,

and the "local protection available", "local protection in use",

"bandwidth protection", and "node protection" flags in the RRO IPv4

and IPv6 sub-objects. A PLR MAY support the DETOUR object.

A PLR MUST consider an LSP to have asked for local protection if the

"local protection desired" flag is set in the SESSION_ATTRIBUTE

object and/or the FAST_REROUTE object is included. If the

FAST_REROUTE object is included, a PLR SHOULD consider providing

one-to-one protection if the "one-to-one desired" is set, and it

SHOULD consider providing facility backup if the "facility backup

desired" flag is set. If the "node protection desired" flag is set,

the PLR SHOULD try to provide node protection; if this is not

feasible, the PLR SHOULD 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

must be followed if an RRO is included in the protected LSP's RESV

message. Based on this additional information, the head-end may take

appropriate actions.

- Until a PLR has a backup path available, the PLR MUST clear the

relevant four flags in the corresponding RRO IPv4 or IPv6 sub-

object.

- Whenever the PLR has a backup path available, the PLR MUST set the

"local protection available" flag. If no established one-to-one

backup LSP or bypass tunnel exists, or if the one-to-one LSP and

the bypass tunnel is in "DOWN" state, the PLR MUST clear the

"local protection available" flag in its IPv4 (or IPv6) address

sub-object of the RRO and SHOULD send the updated RESV.

- The PLR MUST clear the "local protection in use" flag unless it is

actively redirecting traffic into the backup path instead of along

the protected LSP.

- The PLR SHOULD also set the "node protection" flag if the backup

path protects against the failure of the immediate downstream

node, and, if the path does not, the PLR SHOULD clear the "node

protection" flag. This MUST be done if the "node protection

desired" flag was set in the SESSION_ATTRIBUTE object.

- The PLR SHOULD set the "bandwidth protection" flag if the backup

path offers a bandwidth guarantee, and, if the path does not, the

PLR SHOULD clear the "bandwidth protection" flag. This MUST be

done if the "bandwidth protection desired" flag was set in the

SESSION_ATTRIBUTE object.

6.1. Signaling a Backup Path

A number of objectives must be met to oBTain a satisfactory signaling

solution. These are summarized as follows:

1. Unambiguously and uniquely identifying backup paths.

2. Unambiguously associating protected LSPs with their backup

paths.

3. Working with both global and non-global label spaces.

4. Allowing merging of backup paths.

5. Maintaining RSVP state during and after fail-over.

LSP tunnels are identified by a combination of the SESSION and

SENDER_TEMPLATE objects [RSVP-TE]. The relevant fields are as

follows.

IPv4 (or IPv6) tunnel end point address

IPv4 (or IPv6) address of the egress node for the tunnel.

Tunnel ID

A 16-bit identifier used in the SESSION that remains constant

over the life of the tunnel.

Extended Tunnel ID

A 32-bit (IPv4) or 128-bit (IPv6) identifier used in the

SESSION that remains constant over the life of the tunnel.

Normally it is set to all zero. Ingress nodes that wish to

narrow the scope of a SESSION to the ingress-egress pair may

place their IP address here as a globally unique identifier.

IPv4 (or IPv6) tunnel sender address

IPv4 (or IPv6) address for a sender node.

LSP ID

A 16-bit identifier used in the SENDER_TEMPLATE and the

FILTER_SPEC, which can be changed to allow a sender to share

resources with itself.

The first three of these are in the SESSION object and are the basic

identification for the tunnel. Setting the "Extended Tunnel ID" to

an IP address of the head-end LSR allows the scope of the SESSION to

be narrowed to only LSPs sent by that LSR. A backup LSP is

considered part of the same session as its protected LSP; therefore

these three cannot be varied.

The last two are in the SENDER_TEMPLATE. Multiple LSPs in the same

SESSION may be protected and may take different routes; this is

common when a tunnel is rerouted using make-before-break. A backup

path must be clearly identified with its protected LSP to allow

correct merging and state treatment. Therefore, a backup path must

inherit its LSP ID from the associated protected LSP. Thus, the only

field in the SESSION and SENDER_TEMPLATE objects that could be varied

between a backup path and a protected LSP is the "IPv4 (or IPv6)

tunnel sender address" in the SENDER_TEMPLATE.

There are two different methods to uniquely identify a backup path,

described below.

6.1.1. Backup Path Identification: Sender Template-Specific

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

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 in

the SENDER_TEMPLATE of the original LSP tunnel.

When the sender template-specific approach is used, the protected

LSPs and the backup paths SHOULD use the Shared Explicit (SE) style.

This allows bandwidth sharing between multiple backup 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 same on each

LSP to be merged, as specified in [RSVP-TE].

6.1.2. Backup Path Identification: Path-Specific

In this approach, rather than vary the SESSION or SENDER_TEMPLATE

objects, an implementation uses a new object, the DETOUR object, to

distinguish between PATH messages for a backup path and the protected

LSP.

Thus, the backup paths use the same SESSION and SENDER_TEMPLATE

objects as the ones used in the protected LSP. The presence of a

DETOUR object in Path messages signifies a backup path; the presence

of a FAST_REROUTE object and/or the "local protection requested" flag

in the SESSION_ATTRIBUTE object indicates a protected LSP.

In the path message-specific approach, an LSR merges Path messages

that are received with the same SESSION and SENDER_TEMPLATE objects

and that also have the same next-hop object. Without this behavior,

it would be impossible to associate the multiple RESV messages with

the backup paths. However, this merging behavior reduces the total

number of RSVP states inside the network at the expense of merging

LSPs with different EROs.

6.2. Procedures for Backup Path Computation

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

(Constraint-based Shortest Path First) computation. Before this CSPF

computation, the following information must be collected at a PLR:

- The list of downstream nodes that the protected LSP passes

through. This information is readily available from the

RECORD_ROUTE objects during LSP setup. This information is also

available from the ERO. However, if the ERO contains loose

sub-objects, the ERO may not provide adequate information.

- The downstream links/nodes that we want to protect against.

Once again, this information is learned from the RECORD_ROUTE

objects. Whether node protection is desired is determined by

the "node protection" flag in the SESSION_ATTRIBUTE object and

local policy.

- The upstream uni-directional links that the protected LSP passes

through. This information is learned from the RECORD_ROUTE

objects; it is only needed for setting up one-to-one protection.

In the path-specific method, it is necessary to avoid the detour

and the protected LSP sharing a common next-hop upstream of the

failure. In the sender template-specific mode, this same

restriction is necessary to avoid sharing bandwidth between the

detour and its protected LSP, where that bandwidth has been

reserved only once.

- The link attribute filters to be applied. These are derived

from the FAST_REROUTE object, if it is included in the PATH

message, or from the SESSION_ATTRIBUTE object otherwise.

- The bandwidth to be used is found in the FAST_REROUTE object, if

it is included in the PATH message, or in the SESSION_ATTRIBUTE

object otherwise. Local policy may modify the bandwidth to be

reserved.

- The hop-limit, if a FAST_REROUTE object was included in the PATH

message.

When a CSPF algorithm is used to compute the backup route, the

following constraints must be satisfied:

- For detour LSPs, the destination MUST be the tail-end of the

protected LSP. For bypass tunnels (Section 7), the destination

MUST be the address of the MP.

- When one-to-one protection is set up by using the path-specific

method, a detour MUST not traverse the upstream links of the

protected LSP in the same direction. This prevents the

possibility of early merging of the detour into the protected

LSP. When one-to-one protection is set up using the sender-

template-specific method, a detour should not traverse the

upstream links of the protected LSP in the same direction. This

prevents sharing the bandwidth between a protected LSP and its

backup upstream of the failure where the bandwidth would be used

twice in the event of a failure.

- The backup LSP cannot traverse the downstream node and/or link

whose failure is being protected against. Note that if the PLR

is the penultimate hop, node protection is not possible, and

only the downstream link can be avoided. The backup path may be

computed to be SRLG disjoint from the downstream node and/or

link being avoided.

- The backup path must satisfy the resource requirements of the

protected LSP. This includes the link attribute filters,

bandwidth, and hop limits determined from the FAST_REROUTE

object and the SESSION_ATTRIBUTE object.

If such computation succeeds, the PLR should attempt to establish a

backup path. The PLR may schedule a re-computation at a later time

to discover better paths that might have emerged. If for any reason,

the PLR is unable to bring up a backup path, it must schedule a retry

at a later time.

6.3. Signaling Backups for One-to-One Protection

Once a PLR has decided to protect an LSP locally with one-to-one

backup and has identified the desired path, it signals for the

detour.

The following describes the transformation to be performed upon the

protected LSP's PATH message to create the detour LSP's PATH message.

- If the sender template-specific method is to be used, then the

PLR MUST change the "IPv4 (or IPv6) tunnel sender address" of

the SENDER_TEMPLATE to an address belonging to the PLR that is

not the same as that used for the protected LSP. Additionally,

the DETOUR object MAY be added to the PATH message.

- If the path-specific method is to be used, then the PLR MUST add

a DETOUR object to the PATH message.

- The SESSION_ATTRIBUTE flags "Local protection desired",

"Bandwidth protection desired", and "Node protection desired"

MUST be cleared. The "Label recording desired" flag MAY be

modified. If the Path Message contained a FAST_REROUTE object

and the ERO is not completely strict, the Include-any, Exclude-

any, and Include-all fields of the FAST_REROUTE object SHOULD be

copied to the corresponding fields of the SESSION_ATTRIBUTE

object.

- If the protected LSP's Path message contained a FAST_REROUTE

object, this object MUST be removed from the detour LSP's PATH

message.

- The PLR MUST generate an EXPLICIT_ROUTE object toward the

egress. First, the PLR must remove all sub-objects preceding

the first address belonging to the Merge Point. Then the PLR

SHOULD add sub-objects corresponding to the desired backup path

between the PLR and the MP.

- The SENDER_TSPEC object SHOULD contain the bandwidth information

from the received FAST_REROUTE object, if included in the

protected LSP's PATH message.

- The RSVP_HOP object containing one of the PLR's IP address.

- The detour LSPs MUST use the same reservation style as the

protected LSP. This must be correctly reflected in the

SESSION_ATTRIBUTE object.

Detour LSPs operate like regular LSPs. Once a detour path is

successfully computed and the detour LSP is established, the PLR

need not compute detour routes again, unless (1) the contents of

FAST_REROUTE have changed or (2) the downstream interface and/or

the nexthop router for a protected LSP has changed. The PLR may

recompute detour routes at any time.

6.3.1. Make-before-Break with Detour LSPs

If the sender template-specific method is used, it is possible to do

make-before-break with detour LSPs. This is done using two different

IP addresses belonging to the PLR (which were not used in the

SENDER_TEMPLATE of the protected LSP). If the current detour LSP

uses the first IP address in its SENDER_TEMPLATE, then the new detour

LSP should be signaled by using the second IP address in its

SENDER_TEMPLATE. Once the new detour LSP has been created, the

current detour LSP can be torn down. By alternating the use of these

IP addresses, the current and new detour LSPs will have different

SENDER_TEMPLATES and, thus, different state in the downstream LSRs.

This make-before-break mechanism, which changes the PLR IP address in

the DETOUR object instead, is not feasible with the path-specific

method, as the PATH messages for new and current detour LSPs may be

merged if they share a common next-hop.

6.3.2. Message Handling

LSRs must process the detour LSPs independently of the protected LSPs

to avoid triggering the LSP loop detection procedure described in

[RSVP-TE].

The PLR MUST not mix the messages for the protected and the detour

LSPs. When a PLR receives Resv, ResvTear, and PathErr messages from

the downstream detour destination, the messages MUST not be forwarded

upstream. Similarly, when a PLR receives ResvErr and ResvConf

messages from a protected LSP, it MUST not propagate them onto the

associated detour LSP.

A session tear-down request is normally originated by the sender via

PathTear messages. When a PLR node receives a PathTear message from

upstream, it MUST delete both the protected and the detour LSPs. The

PathTear messages MUST propagate to both protected and detour LSPs.

During error conditions, the LSRs may send ResvTear messages to fix

problems on the failing path. When a PLR node receives the ResvTear

messages from downstream for a protected LSP, as long as a detour is

up, the ResvTear messages MUST not be sent further upstream.

PathErrs should be treated similarly.

6.3.3. Local Reroute of Traffic onto Detour LSP

When the PLR detects a failure on the protected LSP, the PLR MUST

rapidly switch packets to the protected LSP's backup LSP instead of

to the protected LSP's normal out-segment. The goal of this method

is to effect the redirection within 10s of milliseconds.

L32 L33 L34 L35

R1-------R2-------R3-------R4-------R5

L46 L44

L47

R6----------------R7

Protected LSP: [R1->R2->R3->R4->R5]

Detour LSP: [R2->R6->R7->R4]

Example 3. Redirect to Detour

In Example 3, if the link [R2->R3] fails, R2 would do the following.

Any traffic received on link [R1->R2] with label L32 would be sent on

link [R2->R6] with label L46 (along the detour LSP) instead of on

link [R3->R4] with label L34 (along the protected LSP). The merge

point R4 would recognize that packets received on link [R7->R4] with

label L44 should be sent on link [R4->R5] with label L35 and that

they should be merged with the protected LSP.

6.4. Signaling for Facility Protection

A PLR may use one or more bypass tunnels to protect against the

failure of a link and/or a node. These bypass tunnels may be set up

in advance or may be dynamically created as new protected LSPs are

signaled.

6.4.1. Discovering Downstream Labels

To support facility backup, the PLR must determine a label that will

indicate to the MP that packets received with that label should be

switched along the protected LSP. This can be done without

explicitly signaling the backup path if the MP uses a label space

global to that LSR.

As described in Section 6, the head-end LSR MUST set the "label

recording requested" flag in the SESSION_ATTRIBUTE object for LSPs

requesting local protection. This will cause (as specified in

[RSVP-TE]) all LSRs to record their INBOUND labels and to note via a

flag whether the label is global to the LSR. Thus, when a protected

LSP is first signaled through a PLR, the PLR can examine the RRO in

the Resv message and learn about the incoming labels that are used by

all downstream nodes for this LSP

When MPs use per-interface label spaces, the PLR must send Path

messages (for each protected LSP using a bypass tunnel) via that

bypass tunnel prior to the failure in order to discover the

appropriate MP label. The signaling procedures for this are in

Section 6.4.3 below.

6.4.2. Procedures for the PLR before Local Repair

A PLR that determines to use facility-backup to protect a given LSP

should select a bypass tunnel to use, taking into account whether

node protection is to be provided, what bandwidth was requested,

whether a bandwidth guarantee is desired, and what link attribute

filters were specified in the FAST_REROUTE object. The selection of

a bypass tunnel for a protected LSP is performed by the PLR when the

LSP is first set up.

6.4.3. Procedures for the PLR during Local Repair

When the PLR detects a link or/and node failure condition, it has to

reroute the data traffic onto the bypass tunnel and to start sending

the control traffic for the protected LSP onto the bypass tunnel.

The backup tunnel is identified by using the sender template-specific

method. The procedures to follow are similar to those described in

Section 6.3.

- The SESSION is unchanged.

- The SESSION_ATTRIBUTE is unchanged except as follows: The

"Local protection desired", "Bandwidth protection desired", and

"Node protection desired" flags SHOULD be cleared. The "Label

recording desired" MAY be modified.

- The IPv4 (or IPv6) tunnel sender address of the SENDER_TEMPLATE

is set to an address belonging to the PLR.

- The RSVP_HOP object MUST contain an IP source address belonging

to the PLR. Consequently, the MP will send messages back to the

PLR with that IP address as the destination.

- The PLR MUST generate an EXPLICIT_ROUTE object toward the

egress. Detailed ERO processing is described below.

- The RRO object may have to be updated as described in Section

6.5.

The PLR sends Path, PathTear, and ResvConf messages via the backup

tunnel. The MP sends Resv, ResvTear, and PathErr messages by sending

them directly to the address in the RSVP_HOP object, as specified in

[RSVP].

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. In this

case, the PLR SHOULD continue to send Path messages for the protected

LSP along the normal route. PathTear messages should be duplicated,

with one sent along the normal route and one sent through the bypass

tunnel. The MP should duplicate the Resv and ResvTear messages and

send them to both the PLR and the LSR indicated by the protected

LSP's RSVP_HOP object.

6.4.4. Processing Backup Tunnel's ERO

Procedures for ERO processing are described in [RSVP-TE]. This

section describes additional ERO update procedures for Path messages

that are sent over bypass tunnels. If normal ERO processing rules

were followed, the Merge Point would examine the first sub-object and

likely reject it (Bad initial sub-object). This is because the

unmodified ERO might contain the IP address of a bypassed node (in

the case of a NNHOP Bypass Tunnel) or of an interface that is

currently down (in the case of a NHOP Backup Tunnel). For this

reason, the PLR invokes the following ERO procedures before sending a

Path message via a bypass tunnel.

Sub-objects belonging to abstract nodes that precede the Merge

Point are removed, along with the first sub-object belonging to

the MP. A sub-object identifying the Backup Tunnel destination is

then added.

More specifically, the PLR MUST:

- remove all the sub-objects proceeding the first address

belonging to the MP, and

- replace this first MP address with an IP address of the MP.

(Note that this could be same address that was just removed.)

6.5. PLR Procedures during Local Repair

In addition to the method-specific signaling and packet treatment,

there is common signaling that should be followed.

During fast reroute, for each protected LSP containing an RRO object,

the PLR obtains the RRO from the protected LSP's stored RESV. 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

In many situations, the route used during local repair will be less

than optimal. The purpose of local repair is to keep high priority

and loss-sensitive traffic flowing while a more optimal re-routing of

 
 
 
免责声明:本文为网络用户发布,其观点仅代表作者个人观点,与本站无关,本站仅提供信息存储服务。文中陈述内容未经本站证实,其真实性、完整性、及时性本站不作任何保证或承诺,请读者仅作参考,并请自行核实相关内容。
2023年上半年GDP全球前十五强
 百态   2023-10-24
美众议院议长启动对拜登的弹劾调查
 百态   2023-09-13
上海、济南、武汉等多地出现不明坠落物
 探索   2023-09-06
印度或要将国名改为“巴拉特”
 百态   2023-09-06
男子为女友送行,买票不登机被捕
 百态   2023-08-20
手机地震预警功能怎么开?
 干货   2023-08-06
女子4年卖2套房花700多万做美容:不但没变美脸,面部还出现变形
 百态   2023-08-04
住户一楼被水淹 还冲来8头猪
 百态   2023-07-31
女子体内爬出大量瓜子状活虫
 百态   2023-07-25
地球连续35年收到神秘规律性信号,网友:不要回答!
 探索   2023-07-21
全球镓价格本周大涨27%
 探索   2023-07-09
钱都流向了那些不缺钱的人,苦都留给了能吃苦的人
 探索   2023-07-02
倩女手游刀客魅者强控制(强混乱强眩晕强睡眠)和对应控制抗性的关系
 百态   2020-08-20
美国5月9日最新疫情:美国确诊人数突破131万
 百态   2020-05-09
荷兰政府宣布将集体辞职
 干货   2020-04-30
倩女幽魂手游师徒任务情义春秋猜成语答案逍遥观:鹏程万里
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案神机营:射石饮羽
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案昆仑山:拔刀相助
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案天工阁:鬼斧神工
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案丝路古道:单枪匹马
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:与虎谋皮
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:李代桃僵
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:指鹿为马
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案金陵:小鸟依人
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案金陵:千金买邻
 干货   2019-11-12
 
推荐阅读
 
 
 
>>返回首頁<<
 
靜靜地坐在廢墟上,四周的荒凉一望無際,忽然覺得,淒涼也很美
© 2005- 王朝網路 版權所有