wdiff draft-ietf-teas-rsvp-ingress-protection-04.txt draft-ietf-teas-rsvp-ingress-protection-05.txt

Internet Engineering Task Force H. Chen, Ed.
Internet-Draft Huawei Technologies
Intended status: Standards Track Experimental R. Torvi, Ed.
Expires: April 21, September 22, 2016 Juniper Networks
October 19, 2015
March 21, 2016

Extensions to RSVP-TE for LSP Ingress Local Protection
draft-ietf-teas-rsvp-ingress-protection-04.txt
draft-ietf-teas-rsvp-ingress-protection-05.txt

Abstract

This document describes extensions to Resource Reservation Protocol -
Traffic Engineering (RSVP-TE) for locally protecting the ingress node
of a Traffic Engineered (TE) Label Switched Path (LSP), which is a
Point-to-Point (P2P) LSP or a Point-to-Multipoint (P2MP) LSP.

Status of this Memo

This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

This Internet-Draft will expire on April 21, September 22, 2016.

This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.

Table of Contents

1. Co-authors . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. An Example of Ingress Local Protection . . . . . . . . . . 3
2.2. Ingress Local Protection with FRR . . . . . . . . . . . . 4
3. Ingress Failure Detection . . . . . . . . . . . . . . . . . . 4
3.1. Source Detects Failure . . . . . . . . . . . . . . . . . . 4
3.2. Backup and Source Detect Failure . . . . . . . . . . . . . 5
4. Backup Forwarding State . . . . . . . . . . . . . . . . . . . 5
4.1. Forwarding State for Backup LSP . . . . . . . . . . . . . 5
5. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 6
5.1. INGRESS_PROTECTION Object . . . . . . . . . . . . . . . . 6
5.1.1. Subobject: Backup Ingress IPv4 Address . . . . . . . . 7
5.1.2. Subobject: Backup Ingress IPv6 Address . . . . . . . . 8
5.1.3. Subobject: Ingress IPv4 Address . . . . . . . . . . . 8
5.1.4. Subobject: Ingress IPv6 Address . . . . . . . . . . . 8
5.1.5. Subobject: Traffic Descriptor . . . . . . . . . . . . 9
5.1.6. Subobject: Label-Routes . . . . . . . . . . . . . . . 9 10
6. Behavior of Ingress Protection . . . . . . . . . . . . . . . . 10
6.1. Ingress Behavior Overview . . . . . . . . . . . . . . . . . . . . . . . . . 10
6.1.1. Relay-Message Method . . . . . . . . . . . . . . . . . 10
6.1.2. Proxy-Ingress Method . . . . . . . . . . . . . . . . . 11
6.1.3. Comparing Two Methods . . . . . . . . . . . . . . . . 12
6.2. Backup Ingress Behavior . . . . . . . . . . . . . . . . . 11 . . . . 12
6.2.1. Relay-Message Method . . . . . . . . . . . . . . . . . 13
6.2.2. Proxy-Ingress Method . . . . . . . . . . . . . . . . . 13
6.3. Backup Ingress Behavior . . . . . . . . . . . . . . . . . 14
6.3.1. Backup Ingress Behavior in Off-path Case . . . . . . . 11
6.2.2. 15
6.3.2. Backup Ingress Behavior in On-path Case . . . . . . . 13
6.2.3. 17
6.3.3. Failure Detection and Refresh PATH Messages . . . . . 14
6.3. 18
6.4. Revertive Behavior . . . . . . . . . . . . . . . . . . . . 14
6.3.1. 18
6.4.1. Revert to Primary Ingress . . . . . . . . . . . . . . 15
6.3.2. 18
6.4.2. Global Repair by Backup Ingress . . . . . . . . . . . 15 19
7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 19
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 19
8.1. A New Class Number . . . . . . . . . . . . . . . . . . . . 16 20
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 16 20
10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 17 21
11. Normative References . . . . . . . . . . . . . . . . . . . . . 17 21
A. Problem Summary . . . . . . . . . . . . . . . . . . . . . . . 22
B. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 18 23

1. Co-authors

Ning So, Autumn Liu, Alia Atlas, Yimin Shen, Tarek Saad, Fengman Xu,
Mehmet Toy, Lei Liu

2. Introduction

For a MPLS LSP it is important to have a fast-reroute method for
protecting its ingress node and transit nodes. Protecting an ingress
is not covered either in the fast-reroute method defined in [RFC4090]
or in the P2MP fast-reroute extensions to fast-reroute in [RFC4875].

An alternate approach to local protection (fast-reroute) is to use
global protection and set up a secondary backup LSP (whether P2MP or
P2P) from a backup ingress to the egresses. The main disadvantage of
this is that the backup LSP may reserve additional network bandwidth.

This specification defines a simple extension to RSVP-TE for local
protection of the ingress node of a P2MP or P2P LSP.

2.1. An Example of Ingress Local Protection

Figure 1 shows an example of using a backup P2MP LSP to locally
protect the ingress of a primary P2MP LSP, which is from ingress R1
to three egresses: L1, L2 and L3. The backup LSP is from backup
ingress Ra to the next hops R2 and R4 of ingress R1.

[R2]******[R3]*****[L1]
* | **** Primary LSP
* | ---- Backup LSP
* / .... BFD Session
* / $ Link
....[R1]*******[R4]****[R5]*****[L2] $
: $ $ / / * $
: $ $ / / *
[S] $ / / *
$ $ / / *
$ $/ / *
[Ra]----[Rb] [L3]

Figure 1: Backup P2MP LSP for Locally Protecting Ingress

In normal operations, source S sends the traffic to primary ingress
R1. R1 imports the traffic into the primary LSP.

When source S detects the failure of R1, it switches the traffic to
backup ingress Ra, which imports the traffic from S into the backup
LSP to R1's next hops R2 and R4, where the traffic is merged into the
primary LSP, and then sent to egresses L1, L2 and L3. Source S
detects the failure of R1 and switches the traffic within 10s of ms.

Note that the backup ingress is one logical hop away from the
ingress. A logical hop is a direct link or a tunnel such as a GRE
tunnel, over which RSVP-TE messages may be exchanged.

2.2. Ingress Local Protection with FRR

Through using the ingress local protection and the FRR, we can
locally protect the ingress, all the links and the transit nodes of
an LSP. The traffic switchover time is within 10s of ms whenever the
ingress, any of the links and the transit nodes of the LSP fails.

The ingress node of the LSP can be locally protected through using
the ingress local protection. All the links and all the transit
nodes of the LSP can be locally protected through using the FRR.

3. Ingress Failure Detection

Exactly how to detect the failure of the ingress is out of scope.
However, it is necessary to discuss different modes for detecting the
failure because they determine what is the required behavior for the
source and backup ingress.

3.1. Source Detects Failure

Source Detects Failure or Source-Detect for short means that the
source is responsible for fast detecting the failure of the primary
ingress of an LSP. The backup ingress is ready to import the traffic
from the source into the backup LSP after the backup LSP is up.

In normal operations, the source sends the traffic to the primary
ingress. When the source detects the failure of the primary ingress,
it switches the traffic to the backup ingress, which delivers the
traffic to the next hops of the primary ingress through the backup
LSP, where the traffic is merged into the primary LSP.

For a P2P LSP, after the primary ingress fails, the backup ingress
MUST use a method to reliably detect the failure of the primary
ingress before the PATH message for the LSP expires at the next hop
of the primary ingress. After reliably detecting the failure, the
backup ingress sends/refreshes the PATH message to the next hop
through the backup LSP as needed.

After the primary ingress fails, it will not be reachable after
routing convergence. Thus checking whether the primary ingress
(address) is reachable is a possible method.

3.2. Backup and Source Detect Failure

Backup and Source Detect Failure or Backup-Source-Detect for short
means that both the backup ingress and the source are concurrently
responsible for fast detecting the failure of the primary ingress.

In normal operations, the source sends the traffic to the primary
ingress. It switches the traffic to the backup ingress when it
detects the failure of the primary ingress.

The backup ingress does not import any traffic from the source into
the backup LSP in normal operations. When it detects the failure of
the primary ingress, it imports the traffic from the source into the
backup LSP to the next hops of the primary ingress, where the traffic
is merged into the primary LSP.

The source-detect is preferred. It is simpler than the backup-
source-detect, which needs both the source and the backup ingress
detect the ingress failure quickly.

4. Backup Forwarding State

Before the primary ingress fails, the backup ingress is responsible
for creating the necessary backup LSPs. These LSPs might be multiple
bypass P2P LSPs that avoid the ingress. Alternately, the backup
ingress could choose to use a single backup P2MP LSP as a bypass or
detour to protect the primary ingress of a primary P2MP LSP.

The backup ingress may be off-path or on-path of an LSP. If a backup
ingress is not any node of the LSP, we call it is off-path. If a
backup ingress is a next-hop of the primary ingress of the LSP, we
call it is on-path. If it is on-path, the primary forwarding state
associated with the primary LSP SHOULD be clearly separated from the
backup LSP(s) state.

4.1. Forwarding State for Backup LSP

A forwarding entry for a backup LSP is created on the backup ingress
after the LSP is set up. Depending on the failure-detection mode
(e.g., source-detect), it may be used to forward received traffic or
simply be inactive (e.g., backup-source-detect) until required. In
either case, when the primary ingress fails, this entry is used to
import the traffic into the backup LSP to the next hops of the
primary ingress, where the traffic is merged into the primary LSP.

The forwarding entry for a backup LSP is a local implementation
issue. In one device, it may have an inactive flag. This inactive
forwarding entry is not used to forward any traffic normally. When
the primary ingress fails, it is changed to active, and thus the
traffic from the source is imported into the backup LSP.

5. Protocol Extensions

A new object INGRESS_PROTECTION is defined for signaling ingress
local protection. It is backward compatible.

5.1. INGRESS_PROTECTION Object

The INGRESS_PROTECTION object with the FAST_REROUTE object in a PATH
message is used to control the backup for protecting the primary
ingress of a primary LSP. The primary ingress MUST insert this
object into the PATH message to be sent to the backup ingress for
protecting the primary ingress. It has the following format:

Class-Num = TBD C-Type = 1 for INGRESS_PROTECTION_IPv4
C-Type = 2 for INGRESS_PROTECTION_IPv6
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length (bytes) | Class-Num | C-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved (zero) Secondary LSP ID | Flags | Options |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ (Subobjects) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Flags
0x01 Ingress local protection available
0x02 Ingress local protection in use
0x04 Bandwidth protection

Options
0x01 Revert to Ingress
0x02 P2MP Backup

The Secondary LSP ID in the object is an LSP ID that the primary
ingress has allocated for a protected LSP tunnel. The backup ingress
may use this LSP ID to set up a new LSP from the backup ingress to
the destinations of the protected LSP tunnel. This allows the new
LSP to share resources with the old one.

The flags are used to communicate status information from the backup
ingress to the primary ingress.

o Ingress local protection available: The backup ingress sets this
flag after backup LSPs are up and ready for locally protecting the
primary ingress. The backup ingress sends this to the primary
ingress to indicate that the primary ingress is locally protected.

o Ingress local protection in use: The backup ingress sets this flag
when it detects a failure in the primary ingress. The backup
ingress keeps it and does not send it to the primary ingress since
the primary ingress is down.

o Bandwidth protection: The backup ingress sets this flag if the
backup LSPs guarantee to provide desired bandwidth for the
protected LSP against the primary ingress failure.

The options are used by the primary ingress to specify the desired
behavior to the backup ingress.

o Revert to Ingress: The primary ingress sets this option indicating
that the traffic for the primary LSP successfully re-signaled will
be switched back to the primary ingress from the backup ingress
when the primary ingress is restored.

o P2MP Backup: This option is set to ask for the backup ingress to
use P2MP backup LSP to protect the primary ingress. Note that one
spare bit of the flags in the FAST-REROUTE object can be used to
indicate whether P2MP or P2P backup LSP is desired for protecting
an ingress and transit node.

The INGRESS_PROTECTION object may contain some sub objects below.

5.1.1. Subobject: Backup Ingress IPv4 Address

When the primary ingress of a protected LSP sends a PATH message with
an INGRESS_PROTECTION object to the backup ingress, the object may
have a Backup Ingress IPv4 Address sub object containing an IPv4
address belonging to the backup ingress. The Type of the sub object
is TBD1 (the exact number to be assigned by IANA), and the body of
the sub object is given below:

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Backup ingress IPv4 address (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Backup ingress IPv4 address: An IPv4 host address of backup ingress

5.1.2. Subobject: Backup Ingress IPv6 Address

When the primary ingress of a protected LSP sends a PATH message with
an INGRESS_PROTECTION object to the backup ingress, the object may
have a Backup Ingress IPv6 Address sub object containing an IPv6
address belonging to the backup ingress. The Type of the sub object
is TBD2, the body of the sub object is given below:

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Backup ingress IPv6 address (16 bytes) |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Backup ingress IPv6 address: An IPv6 host address of backup ingress

5.1.3. Subobject: Ingress IPv4 Address

The INGRESS_PROTECTION object may have an Ingress IPv4 Address sub
object containing an IPv4 address belonging to the primary ingress.
The Type of the sub object is TBD3. The sub object has the following
body:

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ingress IPv4 address (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Ingress IPv4 address: An IPv4 host address of ingress

5.1.4. Subobject: Ingress IPv6 Address

The INGRESS_PROTECTION object may have an Ingress IPv6 Address sub
object containing an IPv6 address belonging to the primary ingress.
The Type of the sub object is TBD4. The sub object has the following
body:

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ingress IPv6 address (16 bytes) |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Ingress IPv6 address: An IPv6 host address of ingress

5.1.5. Subobject: Traffic Descriptor

The INGRESS_PROTECTION object may have a Traffic Descriptor sub
object describing the traffic to be mapped to the backup LSP on the
backup ingress for locally protecting the primary ingress. The Type
of the sub object is TBD5, TBD6, TBD7 or TBD8 for Interface, IPv4
Prefix, IPv6 Prefix or Application Identifier respectively. The sub
object has the following body:

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Traffic Element 1 |
~ ~
| Traffic Element n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The Traffic Descriptor sub object may contain multiple Traffic
Elements of same type as follows:

o Interface Traffic (Type TBD5): Each of the Traffic Elements is a
32 bit index of an interface, from which the traffic is imported
into the backup LSP.

o IPv4 Prefix Traffic (Type TBD6): Each of the Traffic Elements is
an IPv4 prefix, containing an 8-bit prefix length followed by an
IPv4 address prefix, whose length, in bits, is specified by the
prefix length, padded to a byte boundary.

o IPv6 Prefix Traffic (Type TBD7): Each of the Traffic Elements is
an IPv6 prefix, containing an 8-bit prefix length followed by an
IPv6 address prefix, whose length, in bits, is specified by the
prefix length, padded to a byte boundary.

o Application Traffic (Type TBD8): Each of the Traffic Elements is a
32 bit identifier of an application, from which the traffic is
imported into the backup LSP.

5.1.6. Subobject: Label-Routes

The INGRESS_PROTECTION object in a PATH message from the primary
ingress to the backup ingress will have a Label-Routes sub object
containing the labels and routes that the next hops of the ingress
use. The Type of the sub object is TBD9. The sub object has the
following body:

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Subobjects ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The Subobjects in the Label-Routes are copied from those in the
RECORD_ROUTE objects in the RESV messages that the primary ingress
receives from its next hops for the primary LSP. They MUST contain
the first hops of the LSP, each of which is paired with its label.

6. Behavior of Ingress Protection

6.1. Overview

There are four parts of ingress protection: 1) setting up the
necessary backup LSP forwarding state; 2) identifying the failure and
providing the fast repair (as discussed in Sections 3 and 4); 3)
maintaining the RSVP-TE control plane state until a global repair is
done; and 4) performing the global repair(see Section 6.3).

6.1. Ingress Behavior

The primary ingress MUST be configured with a couple of pieces of
information for 6.4).

There are two different proposed signaling approaches to obtain
ingress protection.

o Backup Ingress Address: The primary ingress MUST know an IP
address for it to be included in They both use the same new INGRESS_PROTECTION
object.

o Application Traffic Identifier: The primary ingress and backup
ingress MUST both know what application traffic should be directed
into the LSP. If a list of prefixes in the Traffic Descriptor
sub-object will not suffice, then a commonly understood
Application Traffic Identifier can be object is sent between the primary
ingress and backup ingress. The exact meaning of the identifier
should be configured similarly at in both the primary ingress and
backup ingress. The Application Traffic Identifier is understood
within the unique context of the primary ingress and backup
ingress.

With this additional information, the primary ingress can create PATH and
signal the necessary RSVP extensions to support ingress protection. RESV messages.

6.1.1. Relay-Message Method

The primary ingress relays the information for ingress protection of
an LSP to the backup ingress via PATH messages. Once the LSP is
created, the ingress of the LSP sends the backup ingress a PATH
message with an INGRESS_PROTECTION object with Label-Routes
subobject, which is populated with the next-hops and labels. This
provides sufficient information for the backup ingress to create the
appropriate forwarding state and backup LSP(s).

The ingress also sends the backup ingress all the other PATH messages
for the LSP with an empty INGRESS_PROTECTION object. Thus, the
backup ingress has access to all the PATH messages needed for
modification to refresh control-plane state after a failure.

To protect the ingress

The advantages of an LSP, the ingress MUST do the following
after this method include: 1) the primary LSP is up.

1. Select a PATH message.

2. If
independent of the backup ingress; 2) simple; 3) less configuration;
and 4) less control traffic.

6.1.2. Proxy-Ingress Method

Conceptually, a proxy ingress is off-path, then send it a PATH message
with created that starts the content RSVP
signaling. The explicit path of the LSP goes from the selected PATH message and an
INGRESS_PROTECTION object; else (the backup proxy ingress is a next
hop, i.e., on-path case) add an INGRESS_PROTECTION object into
the existing PATH message
to the backup ingress (i.e., and then to the next
hop). real ingress. The object contains the Traffic-Descriptor sub-object, the
Backup Ingress Address sub-object behavior and
signaling for the Label-Routes sub-
object. The options is set to indicate whether a Backup P2MP LSP proxy ingress is desired. The Label-Routes sub-object contains done by the next-hops
of real ingress; the use
of a proxy ingress and their labels.

3. For each of the other PATH messages, send the address avoids problems with loop detection.

[ traffic source ] *** Primary LSP
$ $ --- Backup LSP
$ $ $$ Link
$ $
[ proxy ingress ] [ backup ]
[ & ingress a
PATH message ] |
* |
*****[ MP ]----|

Figure 2: Example Protected LSP with Proxy Ingress Node

The backup ingress must know the content copied from the message merge points or next-hops and an
empty INGRESS_PROTECTION object, which their
associated labels. This is an object without any
Traffic-Descriptor sub-object.

6.2. Backup Ingress Behavior

An LER determines that accomplished by having the RSVP PATH and
RESV messages go through the backup ingress, although the forwarding
path need not go through the backup ingress. If the backup ingress local protection is requested for
an LSP if
fails, the ingress simply removes the INGRESS_PROTECTION object is included in and
forwards the PATH
message it receives messages to the LSP's next-hop(s). If the ingress
has its LSP configured for ingress protection, then the LSP. The LER ingress can further determine that
it is
add the backup ingress if one of its addresses is in and itself to the Backup
Ingress Address sub-object of ERO and start forwarding the INGRESS_PROTECTION object. The LER
as
PATH messages to the backup ingress will assume full responsibility of ingress.

Slightly different behavior can apply for the on-path and off-path
cases. In the on-path case, the backup ingress is a next hop node
after the primary ingress fails. for the LSP. In addition, the LER determines
that it is off-path if it off-path, the backup ingress
is not any next-hop node of after the LSP.

6.2.1. Backup Ingress Behavior in Off-path Case

The backup ingress considers itself as a PLR and for all associated sub-
LSPs.

The key advantage of this approach is that it minimizes the primary special
handling code requires. Because the backup ingress
as its next hop and provides a local protection for is on the primary
ingress.
signaling path, it can receive various notifications. It behaves very similarly easily has
access to a PLR providing fast-reroute
where all the PATH messages needed for modification to be sent to
refresh control-plane state after a failure.

6.1.3. Comparing Two Methods

+-------+-----------+-------+--------------+---------------+---------+
|\_ Item|Primary LSP|Config |PATH Msg from |RESV Msg from |Reuse |
| \_ |Depends on |Proxy- |Backup Ingress|Primary Ingress|Some |
| \|Backup |Ingress|to Primary |to Backup |Existing |
|Method |Ingress |ID |Ingress |Ingress |Functions|
+-------+-----------+-------+--------------+---------------+---------+
|Relay- | No | No | No | No | Yes- |
|Message| | | | | |
+-------+-----------+-------+--------------+---------------+---------+
|Proxy- | Yes | Yes- | Yes | Yes | Yes |
|Ingress| | | | | |
+-------+-----------+-------+--------------+---------------+---------+

6.2. Ingress Behavior

The primary ingress is considered as the failure-point to
protect. Where not otherwise specified, the behavior given in
[RFC4090] for MUST be configured with a PLR applies. couple of pieces of
information for ingress protection.

o Backup Ingress Address: The backup primary ingress MUST follow the control-options specified know an IP
address for it to be included in the INGRESS_PROTECTION object and the flags and specifications in the
FAST-REROUTE object. This applies to providing a P2MP backup if the
"P2MP backup" is set, a one-to-one backup if "one-to-one desired" is
set, facility backup if the "facility backup desired"

o Proxy-Ingress-Id (only needed for Proxy-Ingress Method): The
Proxy-Ingress-Id is set, and
backup paths that support only used in the desired bandwidth, and administrative-
colors that are requested.

If multiple non empty INGRESS_PROTECTION objects have been received
via multiple PATH messages Record Route Object for
recording the same LSP, proxy-ingress. If no proxy-ingress-id is specified,
then the most recent one
MUST a local interface address that will not otherwise be included
in the one Record Route Object can be used. A similar technique is
used in [RFC4090 Sec 6.1.1].

o Application Traffic Identifier: The backup primary ingress creates the appropriate forwarding state for the
backup LSP tunnel(s) to the merge point(s).

When the and backup
ingress sends a RESV message to the primary ingress,
it MUST add an INGRESS_PROTECTION object both know what application traffic should be directed
into the message. It MUST
set or clear the flags LSP. If a list of prefixes in the object to report "Ingress local
protection available", "Ingress local protection in use", and
"bandwidth protection".

If Traffic Descriptor
sub-object will not suffice, then a commonly understood
Application Traffic Identifier can be sent between the backup primary
ingress doesn't have a and backup LSP tunnel to each ingress. The exact meaning of the
merge points, it SHOULD clear "Ingress local protection available".
[Editor Note: It identifier
should be configured similarly at both the primary ingress and
backup ingress. The Application Traffic Identifier is possible to indicate understood
within the number or which are
unprotected via a sub-object if desired.]

When unique context of the primary ingress fails, the and backup
ingress.

o A connection between backup ingress redirects and primary ingress: If there
is not any direct link between the
traffic from a source into primary ingress and the backup P2P LSPs or
ingress, a tunnel MUST be configured between them.

With this additional information, the backup P2MP LSP
transmitting primary ingress can create and
signal the traffic necessary RSVP extensions to support ingress protection.

6.2.1. Relay-Message Method

To protect the next hops ingress of an LSP, the primary ingress,
where ingress MUST do the traffic is merged into following
after the protected LSP.

In this case, LSP is up.

1. Select a PATH message.

2. If the backup ingress MUST keep the is off-path, then send it a PATH message
with the
INGRESS_PROTECTION object received content from the primary ingress and the
RESV selected PATH message with the and an
INGRESS_PROTECTION object; else (the backup ingress is a next
hop, i.e., on-path case) add an INGRESS_PROTECTION object to be sent into
the existing PATH message to the
primary ingress. The backup ingress MUST set (i.e., the "local protection
in use" flag in the RESV message, indicating that the backup ingress
is actively redirecting next
hop). The object contains the traffic into Traffic-Descriptor sub-object, the backup P2P LSPs or
Backup Ingress Address sub-object and the
backup Label-Routes sub-
object. The options is set to indicate whether a Backup P2MP LSP for locally protecting
is desired. A secondary LSP-ID is allocated (if it is not
allocated yet) and used in the primary ingress failure.

Note that object. The Label-Routes sub-
object contains the RESV message with this piece next-hops of information will not be
sent to the primary ingress because and their labels.

3. For each of the primary ingress has failed.

If other PATH messages, send the backup ingress has not received any a
PATH message with the content copied from the
primary ingress for an extended period of time (e.g., a cleanup
timeout interval) message and a confirmed an
empty INGRESS_PROTECTION object, which is an object without any
Traffic-Descriptor sub-object.

6.2.2. Proxy-Ingress Method

The primary ingress failure did not
occur, then is responsible for starting the standard RSVP soft-state removal SHOULD occur. The
backup ingress SHALL remove signaling
for the state proxy-ingress node. To do this, the following MUST be done
for the RSVP PATH message from message.

1. Compute the
primary ingress, and tear down EROs for the one-to-one backup LSPs LSP as normal for
protecting the primary ingress if one-to-one backup is used or unbind ingress.

2. If the facility backup LSPs if facility selected backup ingress node is used.

When not the first node on the
path (for all sub-LSPs), then insert at the beginning of the ERO
first the backup ingress receives a PATH message from node and then the primary ingress for locally protecting node.

3. In the primary ingress PATH RRO, instead of a protected
LSP, recording the ingress node's address,
replace it MUST check to see if any critical information has been
changed. If with the next hops of Proxy-Ingress-Id.

4. Leave the primary ingress are changed, HOP object populated as usual with information for the
backup ingress SHALL update its backup LSP(s) accordingly.

When
ingress-node.

5. Add the backup ingress receives a PATH message with an non empty INGRESS_PROTECTION object, it examines the object to learn what
traffic associated with the LSP. It determines the next-hops PATH message. Allocate
a secondary LSP-ID to be
merged to by examining the Label-Routes sub-object used in the INGRESS-PROTECTION object.

The backup ingress MUST store
Include the PATH message received from Backup Ingress Address (IPv4 or IPv6) sub-object and
the
primary ingress, but NOT forward it.

The backup ingress responds with Traffic-Descriptor sub-object. Set or clear the options
indicating that a RESV Backup P2MP LSP is desired.

6. Optionally, add the FAST-REROUTE object [RFC4090] to the Path
message. Indicate whether one-to-one backup is desired.
Indicate whether facility backup is desired.

7. The RSVP PATH message received
from is sent to the primary ingress. backup node as normal.

If the INGRESS_PROTECTION object is not
"empty", ingress detects that it can't communicate with the backup
ingress, then the ingress SHALL SHOULD instead send the RESV PATH message with to the
state indicating protection is available after
next-hop indicated in the backup LSP(s) are
successfully established.

6.2.2. Backup Ingress Behavior ERO computed in On-path Case

An LER as step 1. Once the backup ingress determines
detects that it is on-path if one of
its addresses is a next hop of the primary ingress. The LER on-path
MUST send can communicate with the corresponding PATH messages without any
INGRESS_PROTECTION object to its next hops. It creates a number of
backup P2P LSPs or a backup P2MP LSP from itself to the other next
hops (i.e., ingress, the next hops other than ingress
SHOULD follow the backup ingress) of steps 1-7 to obtain ingress failure protection.

When the
primary ingress. The other next hops are from the Label-Routes sub
object.

It also creates a forwarding entry, which sends/multicasts the
traffic from the source to the next hops of the backup ingress along node receives an RSVP PATH message with an INGRESS-
PROTECTION object and the protected LSP when object specifies that node as the primary ingress fails. The traffic is
described by the Traffic-Descriptor.

After the forwarding entry is created, all the backup P2P LSPs or the
backup P2MP LSP is up
node and associated with the protected LSP, PHOP as the backup ingress MUST send node, the primary ingress the RESV message with node SHOULD
remove the INGRESS_PROTECTION object containing the state of the local
protection such as "local protection available" flag set to one,
which indicates that from the primary ingress is locally protected.

When PATH message before
sending it out. Additionally, the primary ingress fails, the backup node MUST store that it
will install ingress sends/multicasts
the traffic from the source to its next hops along forwarding state for the protected LSP
and imports the traffic into each of the backup P2P LSPs or rather than
midpoint forwarding.

When an RSVP RESV message is received by the
backup P2MP LSP transmitting ingress, it uses the traffic
NHOP to determine whether the other next hops of
the primary ingress, where the traffic message is merged into protected LSP.

During the local repair, received from the backup
ingress MUST continue to send the
PATH messages to its next hops as before, keep the or from a different node. The stored associated PATH message with
the
contains an INGRESS_PROTECTION object received from that identifies the primary backup
ingress and node. If the RESV message with is not from the backup node, then
ingress forwarding state SHOULD be set up, and the INGRESS_PROTECTION
object to MUST be added to the RESV before it is sent to the
primary ingress. It MUST set NHOP, which
SHOULD be the "local protection in use" flag in backup node. If the RESV message.

6.2.3. Failure Detection and Refresh PATH Messages

As described in [RFC4090], it message is necessary to refresh the PATH
messages via from the backup LSP(s). The Backup Ingress MUST wait to
refresh the PATH messages until it can accurately detect that
node, then the
ingress node has failed. An example of such an accurate detection
would LSP SHOULD be that the IGP has no bi-directional links to considered available for use.

If the backup ingress node
and the last change was long enough in is on the past that changes should
have been forwarding path, then a RESV is
received (i.e., with an IGP network convergence time or
approximately 2-3 seconds) or a BFD session to INGRESS_PROTECTION object and an NHOP that matches
the primary ingress'
loopback backup ingress. In this case, the ingress node's address has failed and stayed failed will
not appear after the network has
reconverged.

As described backup ingress in [RFC4090 Section 6.4.3], the backup ingress, acting RRO. The ingress node
SHOULD set up ingress forwarding state, just as PLR, MUST modify and send any saved PATH messages associated with is done if the primary LSP to
weren't ingress-node protected.

6.3. Backup Ingress Behavior

An LER determines that the ingress local protection is requested for
an LSP if the corresponding next hops through backup LSP(s).
Any PATH message sent will not contain any INGRESS_PROTECTION object.
The RSVP_HOP object is included in the PATH
message contains an IP source address
belonging to it receives for the backup ingress. LSP. The sender template object has LER can further determine that
it is the backup ingress address as if one of its tunnel sender address.

6.3. Revertive Behavior

Upon a failure event addresses is in the (primary) ingress Backup
Ingress Address sub-object of a protected LSP, the
protected LSP is locally repaired by INGRESS_PROTECTION object. The LER
as the backup ingress. There are a
couple of basic strategies for restoring the LSP to a full working
path.

- Revert to Primary Ingress: When the primary ingress is restored,
it re-signals each will assume full responsibility of the LSPs that start from the primary
ingress. The traffic for every LSP successfully re-signaled is
switched back to ingress
after the primary ingress from fails. In addition, the backup ingress.

- Global Repair by Backup Ingress: After determining LER determines
that the
primary ingress it is off-path if it is not any node of an LSP has failed, the backup ingress computes
a new optimal path, signals a new LSP along the new path, and
switches the traffic to the new LSP.

6.3.1. Revert to Primary Backup Ingress

If "Revert to Primary Ingress" is desired for a protected LSP, the
(primary) Behavior in Off-path Case

The backup ingress of the LSP SHOULD re-signal the LSP that starts
from considers itself as a PLR and the primary ingress after
as its next hop and provides a local protection for the primary ingress restores. After
the LSP is re-signaled successfully, the traffic SHOULD be switched
back
ingress. It behaves very similarly to a PLR providing fast-reroute
where the primary ingress from the backup ingress on the source
node and redirected into is considered as the LSP starting from failure-point to
protect. Where not otherwise specified, the primary ingress. behavior given in
[RFC4090] for a PLR applies.

The primary backup ingress can specify MUST follow the "Revert to Ingress" control-
option control-options specified in the
INGRESS_PROTECTION object and the flags and specifications in the PATH messages
FAST-REROUTE object. This applies to the providing a P2MP backup ingress. After receiving if the "Revert to Ingress" control-
option,
"P2MP backup" is set, a one-to-one backup if "one-to-one desired" is
set, facility backup if the "facility backup ingress MUST stop sending/refreshing desired" is set, and
backup paths that support the desired bandwidth, and administrative-
colors that are requested.

If multiple non empty INGRESS_PROTECTION objects have been received
via multiple PATH messages for the protected LSP.

6.3.2. Global Repair by Backup Ingress

When same LSP, then the most recent one
MUST be the one used.

The backup ingress has determined that creates the primary ingress of appropriate forwarding state for the protected
backup LSP has failed (e.g., via tunnel(s) to the IGP), it can compute a
new path and signal merge point(s).

When the backup ingress sends a new LSP along RESV message to the new path so that primary ingress,
it no longer
relies upon local repair. To do this, MUST add an INGRESS_PROTECTION object into the backup ingress message. It MUST use
set or clear the same tunnel sender address flags in the Sender Template Object object to report "Ingress local
protection available", "Ingress local protection in use", and
allocate a LSP ID different from the one of
"bandwidth protection".

If the old backup ingress doesn't have a backup LSP as the LSP-ID tunnel to each of the new LSP. This allows the new LSP
merge points, it SHOULD clear "Ingress local protection available".
[Editor Note: It is possible to share resources with indicate the
old LSP. In addition, number or which are
unprotected via a sub-object if desired.]

When the Ingress recovers, primary ingress fails, the Backup Ingress
SHOULD send it RESVs with backup ingress redirects the INGRESS_PROTECTION object where
traffic from a source into the
"Revert backup P2P LSPs or the backup P2MP LSP
transmitting the traffic to Ingress" the next hops of the primary ingress,
where the traffic is specified. The Ingress can learn merged into the protected LSP.

In this case, the backup ingress MUST keep the PATH message with the
INGRESS_PROTECTION object received from the
RESVs what primary ingress and the
RESV message with the INGRESS_PROTECTION object to be sent to signal. The Backup Ingress can reoptimize the new LSP
as necessary until
primary ingress. The backup ingress MUST set the Ingress recovers. Alternately, "local protection
in use" flag in the Backup
Ingress can create a new LSP with no bandwidth reservation RESV message, indicating that
duplicates the path(s) of backup ingress
is actively redirecting the protected LSP, move traffic to the new
LSP, delete into the protected LSP, and then resignal backup P2P LSPs or the new
backup P2MP LSP for locally protecting the primary ingress failure.

Note that the RESV message with
bandwidth.

7. Security Considerations

In principle this document does piece of information will not introduce new security issues.
The security considerations pertaining to RFC 4090, RFC 4875 and
other RSVP protocols remain relevant.

8. IANA Considerations

IANA is requested be
sent to administer the assignment primary ingress because the primary ingress has failed.

If the backup ingress has not received any PATH message from the
primary ingress for an extended period of new values defined
in this document and summarized in this section.

8.1. A New Class Number

IANA maintains time (e.g., a registry called "Class Names, Class Numbers, cleanup
timeout interval) and
Class Types" under "Resource Reservation Protocol-Traffic a confirmed primary ingress failure did not
occur, then the standard RSVP soft-state removal SHOULD occur. The
backup ingress SHALL remove the state for the PATH message from the
primary ingress, and tear down the one-to-one backup LSPs for
protecting the primary ingress if one-to-one backup is used or unbind
the facility backup LSPs if facility backup is used.

When the backup ingress receives a PATH message from the primary
ingress for locally protecting the primary ingress of a protected
LSP, it MUST check to see if any critical information has been
changed. If the next hops of the primary ingress are changed, the
backup ingress SHALL update its backup LSP(s) accordingly.

6.3.1.1. Relay-Message Method

When the backup ingress receives a PATH message with an non empty
INGRESS_PROTECTION object, it examines the object to learn what
traffic associated with the LSP. It determines the next-hops to be
merged to by examining the Label-Routes sub-object in the object.

The backup ingress MUST store the PATH message received from the
primary ingress, but NOT forward it.

The backup ingress responds with a RESV to the PATH message received
from the primary ingress. If the INGRESS_PROTECTION object is not
"empty", the backup ingress SHALL send the RESV message with the
state indicating protection is available after the backup LSP(s) are
successfully established.

6.3.1.2. Proxy-Ingress Method

The backup ingress determines the next-hops to be merged to by
collecting the set of the pair of (IPv4/IPv6 sub-object, Label sub-
object) from the Record Route Object of each RESV that are closest to
the top and not the Ingress router; this should be the second to the
top pair. If a Label-Routes sub-object is included in the
INGRESS_PROTECTION object, the included IPv4/IPv6 sub-objects are
used to filter the set down to the specific next-hops where
protection is desired. A RESV message MUST have been received before
the Backup Ingress can create or select the appropriate backup LSP.

When the backup ingress receives a PATH message with the
INGRESS_PROTECTION object, the backup ingress examines the object to
learn what traffic associated with the LSP. The backup ingress
forwards the PATH message to the ingress node with the normal RSVP
changes.

When the backup ingress receives a RESV message with the
INGRESS_PROTECTION object, the backup ingress records an IMPLICIT-
NULL label in the RRO. Then the backup ingress forwards the RESV
message to the ingress node, which is acting for the proxy ingress.

6.3.2. Backup Ingress Behavior in On-path Case

An LER as the backup ingress determines that it is on-path if one of
its addresses is a next hop of the primary ingress (and for Proxy-
Ingress Method the primary ingress is not its next hop via checking
the PATH message with the INGRESS_PROTECTION object received from the
primary ingress). The LER on-path MUST send the corresponding PATH
messages without any INGRESS_PROTECTION object to its next hops. It
creates a number of backup P2P LSPs or a backup P2MP LSP from itself
to the other next hops (i.e., the next hops other than the backup
ingress) of the primary ingress. The other next hops are from the
Label-Routes sub object.

It also creates a forwarding entry, which sends/multicasts the
traffic from the source to the next hops of the backup ingress along
the protected LSP when the primary ingress fails. The traffic is
described by the Traffic-Descriptor.

After the forwarding entry is created, all the backup P2P LSPs or the
backup P2MP LSP is up and associated with the protected LSP, the
backup ingress MUST send the primary ingress the RESV message with
the INGRESS_PROTECTION object containing the state of the local
protection such as "local protection available" flag set to one,
which indicates that the primary ingress is locally protected.

When the primary ingress fails, the backup ingress sends/multicasts
the traffic from the source to its next hops along the protected LSP
and imports the traffic into each of the backup P2P LSPs or the
backup P2MP LSP transmitting the traffic to the other next hops of
the primary ingress, where the traffic is merged into protected LSP.

During the local repair, the backup ingress MUST continue to send the
PATH messages to its next hops as before, keep the PATH message with
the INGRESS_PROTECTION object received from the primary ingress and
the RESV message with the INGRESS_PROTECTION object to be sent to the
primary ingress. It MUST set the "local protection in use" flag in
the RESV message.

6.3.3. Failure Detection and Refresh PATH Messages

As described in [RFC4090], it is necessary to refresh the PATH
messages via the backup LSP(s). The Backup Ingress MUST wait to
refresh the PATH messages until it can accurately detect that the
ingress node has failed. An example of such an accurate detection
would be that the IGP has no bi-directional links to the ingress node
and the last change was long enough in the past that changes should
have been received (i.e., an IGP network convergence time or
approximately 2-3 seconds) or a BFD session to the primary ingress'
loopback address has failed and stayed failed after the network has
reconverged.

As described in [RFC4090 Section 6.4.3], the backup ingress, acting
as PLR, MUST modify and send any saved PATH messages associated with
the primary LSP to the corresponding next hops through backup LSP(s).
Any PATH message sent will not contain any INGRESS_PROTECTION object.
The RSVP_HOP object in the message contains an IP source address
belonging to the backup ingress. The sender template object has the
backup ingress address as its tunnel sender address.

6.4. Revertive Behavior

Upon a failure event in the (primary) ingress of a protected LSP, the
protected LSP is locally repaired by the backup ingress. There are a
couple of basic strategies for restoring the LSP to a full working
path.

- Revert to Primary Ingress: When the primary ingress is restored,
it re-signals each of the LSPs that start from the primary
ingress. The traffic for every LSP successfully re-signaled is
switched back to the primary ingress from the backup ingress.

- Global Repair by Backup Ingress: After determining that the
primary ingress of an LSP has failed, the backup ingress computes
a new optimal path, signals a new LSP along the new path, and
switches the traffic to the new LSP.

6.4.1. Revert to Primary Ingress

If "Revert to Primary Ingress" is desired for a protected LSP, the
(primary) ingress of the LSP SHOULD re-signal the LSP that starts
from the primary ingress after the primary ingress restores. After
the LSP is re-signaled successfully, the traffic SHOULD be switched
back to the primary ingress from the backup ingress on the source
node and redirected into the LSP starting from the primary ingress.

The primary ingress can specify the "Revert to Ingress" control-
option in the INGRESS_PROTECTION object in the PATH messages to the
backup ingress. After receiving the "Revert to Ingress" control-
option, the backup ingress MUST stop sending/refreshing PATH messages
for the protected LSP.

6.4.2. Global Repair by Backup Ingress

When the backup ingress has determined that the primary ingress of
the protected LSP has failed (e.g., via the IGP), it can compute a
new path and signal a new LSP along the new path so that it no longer
relies upon local repair. To do this, the backup ingress MUST use
the same tunnel sender address in the Sender Template Object and the
previously allocated secondary LSP-ID in the INGRESS_PROTECTION
object of the PATH message as the LSP-ID of the new LSP. This allows
the new LSP to share resources with the old LSP. In addition, if the
Ingress recovers, the Backup Ingress SHOULD send it RESVs with the
INGRESS_PROTECTION object where the "Revert to Ingress" is specified.
The Secondary LSP ID MUST be the unused LSP ID - while the LSP ID
signaled in the RESV will be that currently active. The Ingress can
learn from the RESVs what to signal. Even if the Ingress does not
take over, the RESVs notify it that the particular LSP IDs are in
use. The Backup Ingress can reoptimize the new LSP as necessary
until the Ingress recovers. Alternately, the Backup Ingress can
create a new LSP with no bandwidth reservation that duplicates the
path(s) of the protected LSP, move traffic to the new LSP, delete the
protected LSP, and then resignal the new LSP with bandwidth.

7. Security Considerations

In principle this document does not introduce new security issues.
The security considerations pertaining to RFC 4090, RFC 4875 and
other RSVP protocols remain relevant.

8. IANA Considerations

IANA is requested to administer the assignment of new values defined
in this document and summarized in this section.

8.1. A New Class Number

IANA maintains a registry called "Class Names, Class Numbers, and
Class Types" under "Resource Reservation Protocol-Traffic Engineering
(RSVP-TE) Parameters". IANA is requested to assign a new Class
Number for new object INGRESS_PROTECTION as follows:

+====================+===============+============================+
| Class Names | Class Numbers | Class Types |
+====================+===============+============================+
| INGRESS_PROTECTION | TBD (>192) | 1: INGRESS_PROTECTION_IPv4 |
| | +----------------------------+
| | | 2: INGRESS_PROTECTION_IPv6 |
+--------------------+---------------+----------------------------+

IANA is requested to assign Types for new TLVs in the new objects as
follows:

Type Name Allowed in
1 BACKUP_INGRESS_IPv4_ADDRESS INGRESS_PROTECTION_IPv4
2 BACKUP_INGRESS_IPv6_ADDRESS INGRESS_PROTECTION_IPv6
3 INGRESS_IPv4_ADDRESS INGRESS_PROTECTION_IPv4
4 INGRESS_IPv6_ADDRESS INGRESS_PROTECTION_IPv6
5 TRAFFIC_DESCRIPTOR_INTERFACE INGRESS_PROTECTION
6 TRAFFIC_DESCRIPTOR_IPv4_PREFIX INGRESS_PROTECTION_IPv4
7 TRAFFIC_DESCRIPTOR_IPv6_PREFIX INGRESS_PROTECTION_IPv6
8 TRAFFIC_DESCRIPTOR_APPLICATION INGRESS_PROTECTION
9 LabeL_Routes INGRESS_PROTECTION

9. Contributors

Renwei Li
Huawei Technologies
2330 Central Expressway
Santa Clara, CA 95050
USA
Email: renwei.li@huawei.com

Quintin Zhao
Huawei Technologies
Boston, MA
USA
Email: quintin.zhao@huawei.com
Zhenbin Li
Huawei Technologies
2330 Central Expressway
Santa Clara, CA 95050
USA
Email: zhenbin.li@huawei.com

Boris Zhang
Telus Communications
200 Consilium Pl Floor 15
Toronto, ON M1H 3J3
Canada
Email: Boris.Zhang@telus.com

Markus Jork
Juniper Networks
10 Technology Park Drive
Westford, MA 01886
USA
Email: mjork@juniper.net

10. Acknowledgement

The authors would like to thank Nobo Akiya, Rahul Aggarwal, Eric
Osborne, Ross Callon, Loa Andersson, Daniel King, Michael Yue,
Olufemi Komolafe, Rob Rennison, Neil Harrison, Kannan Sampath,
Gregory Mirsky, and Ronhazli Adam for their valuable comments and
suggestions on this draft.

11. Normative References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.

[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031, DOI 10.17487/
RFC3031, January 2001,
<http://www.rfc-editor.org/info/rfc3031>.

[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
<http://www.rfc-editor.org/info/rfc3209>.

[RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast
Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090,
DOI 10.17487/RFC4090, May 2005,
<http://www.rfc-editor.org/info/rfc4090>.

[RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S.
Yasukawa, Ed., "Extensions to Resource Reservation
Protocol - Traffic Engineering (RSVP-TE) Parameters". IANA for Point-to-
Multipoint TE Label Switched Paths (LSPs)", RFC 4875,
DOI 10.17487/RFC4875, May 2007,
<http://www.rfc-editor.org/info/rfc4875>.

Appendix A. Problem Summary

There is a need for a fast and efficient protection against the
failure of the ingress node of a MPLS TE LSP (either P2MP LSP or P2P
LSP).

For a MPLS TE LSP, protecting the failures of its transit nodes using
fast-reroute (FRR) is covered in RFC 4090 for P2P LSP and RFC 4875
for P2MP LSP. However, protecting the failure of its ingress node
using FRR is not covered in either RFC 4090 or RFC 4875. The MPLS
Transport Profile (MPLS-TP) Linear Protection described in RFC 6378
can provide a protection against the failure of any transit node of a
LSP between the ingress node and the egress node of the LSP, but
cannot protect against the failure of the ingress node.

To protect against the failure of the (primary) ingress node of a
primary end to end P2MP (or P2P) TE LSP, a typical existing solution
is to set up a secondary backup end to end P2MP (or P2P) TE LSP from
a backup ingress node, which is different from the primary ingress
node, to the backup egress nodes (or node), which are (or is)
different from the primary egress nodes (or node) of the primary LSP.
For a P2MP TE LSP, on each of the primary (and backup) egress nodes,
a P2P LSP is requested created from the egress node to assign a new Class
Number for new object INGRESS_PROTECTION as follows:

IANA its primary (backup)
ingress node and configured with BFD. This is requested used to assign Types detect the
failure of the primary (backup) ingress node for new TLVs in the new objects as
follows:

9. Contributors

Renwei Li
Huawei Technologies
2330 Central Expressway
Santa Clara, CA 95050
USA
Email: renwei.li@huawei.com
Quintin Zhao
Huawei Technologies
Boston, MA
USA
Email: quintin.zhao@huawei.com

Zhenbin Li
Huawei Technologies
2330 Central Expressway
Santa Clara, CA 95050
USA
Email: zhenbin.li@huawei.com

Boris Zhang
Telus Communications
200 Consilium Pl Floor 15
Toronto, ON M1H 3J3
Canada
Email: Boris.Zhang@telus.com

Markus Jork
Juniper Networks
10 Technology Park Drive
Westford, MA 01886
USA
Email: mjork@juniper.net

10. Acknowledgement

The authors would like receiver to thank Nobo Akiya, Rahul Aggarwal, Eric
Osborne, Ross Callon, Loa Andersson, Daniel King, Michael Yue,
Olufemi Komolafe, Rob Rennison, Neil Harrison, Kannan Sampath,
Gregory Mirsky,
switch to the backup (or primary) egress node to receive the traffic
after the primary (or backup) ingress node fails when both the
primary LSP and Ronhazli Adam for their valuable comments the secondary LSP carry the traffic. In addition,
FRR may be used to provide protections against the failures of the
transit nodes and the links of the primary and
suggestions on secondary end to end
TE LSPs.

There are a number of issues in this draft.

11. Normative References

[RFC2119] Bradner, S., "Key words for use solution, which are briefed as
follows:

o It consumes lots of network resources. Double states need to be
maintained in RFCs the network since two end to Indicate
Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.

[RFC3031] Rosen, E., Viswanathan, A., end TE LSPs are
created. Double link bandwidth is reserved and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031, DOI 10.17487/
RFC3031, January 2001,
<http://www.rfc-editor.org/info/rfc3031>.

[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., used when both the
primary and G. Swallow, "RSVP-TE: Extensions the secondary end to RSVP for LSP
Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
<http://www.rfc-editor.org/info/rfc3209>.

[RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast
Reroute Extensions end TE LSPs carry the traffic at
the same time.

o More operations are needed, which include the configurations of
two end to RSVP-TE for LSP Tunnels", RFC 4090,
DOI 10.17487/RFC4090, May 2005,
<http://www.rfc-editor.org/info/rfc4090>.

[RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., end TE LSPs and S.
Yasukawa, Ed., "Extensions BFDs from each of the egress nodes to Resource Reservation
Protocol - Traffic Engineering (RSVP-TE) for Point-to-
Multipoint TE Label Switched Paths (LSPs)", RFC 4875,
DOI 10.17487/RFC4875, May 2007,
<http://www.rfc-editor.org/info/rfc4875>.
its corresponding ingress node.

o The detection of the failure of the ingress node may not be
reliable. Any failure on the path of the BFD from an egress node
to an ingress node may cause the BFD down to indicate the failure
of the ingress node.

o The speed of protection against the failure of the ingress node
may be slow.

The ingress local protection proposed in this draft will resolve the
above issues.

Appendix A. B. Authors' Addresses

Huaimo Chen
Huawei Technologies
Boston, MA
USA
Email: huaimo.chen@huawei.com

Raveendra Torvi
Juniper Networks
10 Technology Park Drive
Westford, MA 01886
USA
Email: rtorvi@juniper.net
Ning So
Tata Communications
2613 Fairbourne Cir.
Plano, TX 75082
USA
Email: ningso01@gmail.com

Autumn Liu
Ericsson
300 Holger Way
San Jose, CA 95134
USA
Email: autumn.liu@ericsson.com

Alia Atlas
Juniper Networks
10 Technology Park Drive
Westford, MA 01886
USA
Email: akatlas@juniper.net

Yimin Shen
Juniper Networks
10 Technology Park Drive
Westford, MA 01886
USA
Email: yshen@juniper.net

Tarek Saad
Cisco Systems
Email: tsaad@cisco.com

Fengman Xu
Verizon
2400 N. Glenville Dr
Richardson, TX 75082
USA
Email: fengman.xu@verizon.com
Mehmet Toy
Comcast
1800 Bishops Gate Blvd.
Mount Laurel, NJ 08054
USA
Email: mehmet_toy@cable.comcast.com

Lei Liu
UC Davis
USA
Email: liulei.kddi@gmail.com