MPLS Working Group S. Kini
Internet-Draft A. Liu
Intended Status: Standards Track Ericsson
Expires: July 2011 January 13, 2011
Efficient Fast Re-route (FRR) using Facility backup in ring topology
draft-kini-mpls-ring-frr-facility-backup-02.txt
Status of this Memo
Distribution of this memo is unlimited.
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), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on July 17, 2011.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
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.
Kini & Liu Expires July 2011 [Page 1]
Internet Draft Efficient Facility Backup FRR January 13, 2010
Abstract
Fast Re-route (FRR) using facility backup is a widely deployed MPLS
protection mechanism that can protect against link and node failure.
It provides a fast protection switch mechanism to minimize traffic
loss (typically sub 50msec) if the node that detects the failure
locally, does the repair by re-routing the protected traffic to go
over the backup tunnel. A direct application of this mechanism to a
ring topology results in an inefficient use of link bandwidth that
could also result in degraded service. This document describes a
mechanism to do it without such problems.
Kini & Liu Expires July 2011 [Page 2]
Internet Draft Efficient Facility Backup FRR January 13, 2010
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions used in this document . . . . . . . . . . . . . . . 4
2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . . 4
4. Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. RSVP-TE signaling extensions . . . . . . . . . . . . . . . 7
4.2. Triggering protection switch at PLR-u . . . . . . . . . 10
4.3. Procedures at PLR . . . . . . . . . . . . . . . . . . . 10
4.4. Procedures at PLR-u . . . . . . . . . . . . . . . . . . 11
5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
6. Applicability to generic topologies . . . . . . . . . . . . . 12
7. Future work . . . . . . . . . . . . . . . . . . . . . . . . . 13
8. Security Considerations . . . . . . . . . . . . . . . . . . . 13
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
10.1. Normative References . . . . . . . . . . . . . . . . . 14
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
Kini & Liu Expires July 2011 [Page 3]
Internet Draft Efficient Facility Backup FRR January 13, 2010
1. Introduction
Fast Re-route for TE tunnels [MPLS-FRR] is widely used to realize sub
50msec protection of traffic in case of link or node failure.
Specifically, the facility backup method described in [MPLS-FRR]
provides a scalable mechanism to protect a large number of LSPs in
sub 50msec. When applied to a ring topology this results in an in-
efficient use of bandwidth and also leads to degraded service. This
is described in detail with a sample topology/scenario in section 3.
A solution that extends the facility backup method of [MPLS-FRR] is
described in section 4. An explanation of the solution by applying it
to the topology/scenario in the problem statement is provided in
section 5.
2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALLNOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
2.1. Terminology
PLR-u - Point of Local Repair (PLR) Upstream. A PLR that is upstream
along the protected LSP from the point of failure. This must be used
in the context of a technique that conveys failure quickly from the
failure point to the PLR-u so that the overall traffic loss is
comparable to local repair adjacent to the failure.
Path Backup Tunnel - A backup tunnel that can be used to protect many
LSPs where each LSP traverses a path through the head-end and the
tail-end of the path backup tunnel going through one or more
intermediate facilities and LSRs. A path bypass tunnel is also a
backup tunnel that bypasses a subset of the path of the protected
LSP. It is also a backup path.
Efficient-path backup tunnel - A path backup tunnel that improves the
efficiency of backup tunnels that bypass a portion of the path that
it bypasses. This is also referred to as e-backup tunnel.
3. Problem Statement
Kini & Liu Expires July 2011 [Page 4]
Internet Draft Efficient Facility Backup FRR January 13, 2010
+-------L1--------L2---------L3--------L4-------+
| .........>.........B1.........>............ |
| . .......<.........B2.........<.......... . |
| . . . . |
| . . . . |
L10 ^ V ^ V L5
| . . . . |
| . . . . |
| . ............> >............... . |
| ..............< <................. |
+-------L9--------L8---------L7--------L6-------+
>**************P1**************>
<**************P2**************<
...... Bypass LSP
****** Protected LSP
Figure 1 Facility bypass in a Ring topology
The issue with backup tunnel in a ring topology is illustrated
through the example in Figure 1. L1-10 are LSRs in a ring topology
and say each link in the ring has 1G bandwidth. To protect the
facility L8-L7, a uni-directional backup tunnel B1 is routed along
L8-L9-L10-L1-L2-L3-L4-L5-L6-L7 with L8 as PLR and L7 as MP.
Similarly, a uni-directional backup tunnel B2 is routed along L7-L6-
L5-L4-L3-L2-L1-L10-L9-L8 with L7 as PLR and L8 as MP. A protected LSP
P1 is routed along L9-L8-L7-L6 and has a bandwidth constraint of
0.6G. Another uni-directional protected LSP P2 is routed along L6-L7-
L8-L9 and has bandwidth constraint of 0.6G.
When facility L8-L7 fails, P1 is protection switched over B1 at PLR
L8 and P2 over B2 at PLR L7, thereby bypassing the failed
resource/facility. Since the aggregate bandwidth requirement on L8-
>L9 becomes 1.2G (0.6G for P1 + 0.6G for B2), both P1 and P2 start
experiencing degraded service. If there are other uni-directional
protected LSPs e.g. P3 along the path L10-L9-L8-L7-L6, P4 along the
path L8-L9, etc, they would also start experiencing degraded service.
Even when P1 needs bandwidth less than 0.5G, the wraparound consumes
bandwidth that would be better used by other LSPs such as P4.
Note that similar issues would arise if (P1, P2) was a single bi-
directional protected LSP and/or (B1, B2) was a single bi-directional
bypass tunnel.
4. Solution
To solve the problem described above it is required to switch the
traffic from the protected LSP to a backup tunnel that does not U-
Kini & Liu Expires July 2011 [Page 5]
Internet Draft Efficient Facility Backup FRR January 13, 2010
turn overlap the protected LSP. This traffic switchover MUST be
realized with timing characteristics similar to methods that execute
local repair adjacent to the point of failure.
To achieve this, an additional e-backup tunnel is proposed to be
setup for any backup tunnel whose route is U-turn overlapping an LSP
that it is protecting. Note that the e-backup tunnel would have its
head-end and tail-end on the protected LSP. To switchover the traffic
from the protected LSP to the e-backup tunnel with timing
characteristics similar to a local repair method performed at a node
adjacent to the failure, the head-end of the e-backup tunnel MUST
receive the trigger within a very short duration after of failure. A
simple and fast method to propagate the failed condition via the
backup tunnel is proposed in section 4.2. It requires the head-end of
the e-backup tunnel to be on the backup tunnel. The following
criteria must be used to route the e-backup tunnel so that efficiency
is realized:
1. The head-end of the e-backup tunnel SHOULD be at an LSR that is
upstream (on the protected LSP) of the PLR where the protected
LSP and the backup tunnel stop U-turn overlapping. In some
scenarios it is possible that such an LSR may lack the
functionality described in this draft. In such a case an LSR
that has this functionality and is furthest upstream from the
PLR but not beyond the LSR where the protected and the backup
tunnel stop overlapping should be chosen to achieve the maximal
efficiency. Since the head-end of the e-backup tunnel performs
a repair by routing traffic from the protected LSP to the e-
backup tunnel it is referred to as Point of Local Repair
Upstream (PLR-u). The details of receiving a trigger and
performing the protection switch are described in section 4.4.
2. The e-backup tunnel should be routed along the backup tunnel so
that it can share reservation with the backup tunnel. It could
also be routed along another path as long as resources are
available and it satisfies the protection constraints of the
protected LSP.
3. The tail-end of the e-backup tunnel SHOULD be at an LSR that is
downstream (on the protected LSP) of the MP where the protected
LSP and the backup LSP stop overlapping. The merge action at
the tail-end is the same as described in [MPLS-FRR] for any
backup tunnel. This document does not describe any additional
procedures for the tail-end of the e-backup tunnel.
Similar to a backup tunnel, an e-backup tunnel may be setup in
advance or at the time a protected LSP is setup. An e-backup tunnel
can make efficient the FRR of more than one backup tunnel. In a
Kini & Liu Expires July 2011 [Page 6]
Internet Draft Efficient Facility Backup FRR January 13, 2010
typical case an e-backup tunnel will make efficient the FRR for many
NHOP Bypass Tunnels along the path that an e-backup tunnel would
bypass. The following associations MUST be known in advance to setup
the protection switch actions:
1. The e-backup tunnel and the protected LSP.
2. The e-backup tunnel and the backup tunnel whose FRR it is
making efficient.
If the protected LSP is setup via RSVP-TE then these associations can
be signaled by the extensions defined in section 4.1.
4.1. RSVP-TE signaling extensions
To enable e-backup path computation, the information about the backup
tunnel is needed at LSRs that are upstream of the PLR. The RRO is
used to record this information. This additional information is
requested using the "Session Attribute" object as described in
section 4.1.1. The information in the RRO is described in 4.1.2.
4.1.1. Session Attribute Object Flag: Local_protection_recording
A new flag "Local protection recording desired" is defined for the
"Flags" field in the Session Attribute object. This flag indicates
that information about the local protection used should be included
when doing a route record.
4.1.2. RRO subobjects
A new RRO subobject called "Backup Session" subobject is defined. It
follows an IPv4/IPv6 address sub-object (that would have "Local
Protection Available" set). This subobject describes the backup LSP
that protects against a failure detected at the interface
corresponding to the preceding IPv4/IPv6 address sub-object. This
subobject is carried in the RRO of a protected LSP. The encoding of
this subobject is described in section 4.1.2.1.
A new RRO subobject called "Backup Sender Template" subobject is
defined. It follows the "Backup Session" subobject and is included
only if the "Backup Session" subobject does not uniquely identify the
backup LSP. The encoding of this subobject is described in section
section 4.1.2.2.
4.1.2.1. Backup Session Subobject
Kini & Liu Expires July 2011 [Page 7]
Internet Draft Efficient Facility Backup FRR January 13, 2010
4.1.2.1.1. Backup_LSP_TUNNEL_IPv4 Session Suboobject
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Backup_LSP_TUNNEL_IPv4 Session Subobject (12 bytes) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved
This field is reserved. It MUST be set to zero on transmission
and MUST be ignored on receipt.
Backup_LSP_TUNNEL_IPv4 Session subobject
This must be the same as the object defined in section 4.6.1.1 of
[RSVP-TE].
4.1.2.1.2. Backup_LSP_TUNNEL_IPv6 Session Subobject
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Backup_LSP_TUNNEL_IPv6 Session Subobject (36 bytes) .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved
This field is reserved. It MUST be set to zero on transmission
and MUST be ignored on receipt.
Backup_LSP_TUNNEL_IPv6 Session subobject
This must be the same as the object defined in section 4.6.1.2 of
[RSVP-TE].
Kini & Liu Expires July 2011 [Page 8]
Internet Draft Efficient Facility Backup FRR January 13, 2010
4.1.2.2. Backup Sender Template Subobject
4.1.2.2.1. Backup_LSP_TUNNEL_IPv4 Sender Template Suboobject
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Backup_LSP_TUNNEL_IPv4 Sender Template Subobject (8 bytes) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved
This field is reserved. It MUST be set to zero on transmission
and MUST be ignored on receipt.
Backup_LSP_TUNNEL_IPv4 Sender Template subobject
This must be the same as the object defined in section 4.6.2.1 of
[RSVP-TE].
4.1.2.2.2. Backup_LSP_TUNNEL_IPv6 Sender Template Subobject
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Backup_LSP_TUNNEL_IPv6 Sender Template Subobject (20 bytes) .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved
This field is reserved. It MUST be set to zero on transmission
and MUST be ignored on receipt.
Backup_LSP_TUNNEL_IPv6 Sender Template subobject
This must be the same as the object defined in section 4.6.2.2 of
[RSVP-TE].
Kini & Liu Expires July 2011 [Page 9]
Internet Draft Efficient Facility Backup FRR January 13, 2010
4.2. Triggering protection switch at PLR-u
Any LSR along the backup tunnel may be the head-end of an associated
e-backup tunnel. Hence all the LSRs along a backup tunnel must be
alerted immediately when a failure is detected at PLR. It is required
to convey this failure information from the PLR instantaneously
(except being gated by propagation delays) for the timing
characteristics to be similar to methods that execute local repair
adjacent to the point of failure. This document proposes using the
alert mechanism in [ID.fast-lsp-alert] to convey the trigger message.
A message format that can be implemented in hardware/firmware is
required since the trigger should be generated and processed as
quickly as possible to reduce traffic loss. Typically,
implementations of [ID.BFD] fit these requirements. Hence the
mechanism in [ID.BFD-MPLS] operating in the G-ACh ([RFC5586]) of the
backup tunnel is proposed with an extension to signal that protection
switch has occurred at PLR.
A new BFD control packet diagnostic (Diag) code "Backup LSP not
carrying protected traffic" is defined. It is applicable even if the
"State" of the BFD session is "Up". A transit LSR along the backup
tunnel may choose to ignore validating the "Authentication" section
of the BFD control packet received via this alert mechanism for that
backup since the end point would do the authentication and that would
be sufficient to authenticate the BFD session. Similar reasoning
holds true for any validation of ACH TLVs (some of them are listed in
[ID.ACH-TLVs]). Also, a transit LSP along the backup tunnel that is
not an upstream LSR for any of the protected LSPs, simply ignores
this BFD message for local processing.
4.3. Procedures at PLR
A PLR runs a BFD session on the backup tunnel's G-ACh. When the BFD
session is Up, it signals the association of the protected LSPs with
that backup tunnel by updating the RRO of the protected LSP as
described in section 4.1.
While the protection switch has not occurred at PLR and the BFD
session in Up, the "Diagnostic" field in the BFD control packet is
set to "Backup LSP not carrying protected traffic". When the PLR
switches the protected LSP the backup tunnel, the value "Backup LSP
not carrying protected traffic" is not used anymore in the
"Diagnostic" field.
The PLR sends the BFD Control packets on the backup tunnel in a way
that all LSRs along the backup tunnel are alerted with the BFD
message. To do this it uses the mechanism described [ID.fast-lsp-
Kini & Liu Expires July 2011 [Page 10]
Internet Draft Efficient Facility Backup FRR January 13, 2010
alert] i.e., the BFD packet is sent with TTL=1 in the LSP label, GAL
TTL=255 and the FLA-bit set. The PLR may choose to not use this alert
mechanism for every BFD control packet. In that case, the alert
mechanism must be set for a period of at least the BFD "Detection
Time" when any of the following events occur:
1. The association of a protected LSP with this backup tunnel is
setup or deleted.
2. A protection switch or revert action occurs for a protected LSP
to the backup (at PLR).
3. The backup tunnel is re-routed (typically with Make-before
break or MBB).
The BFD transmit timer must be treated as if it expired as soon as
any of the above events occur. Additionally, to recover from packet
loss, the BFD control packet (with the LSP alert mechanism) should be
sent a couple more times within a very short duration (typically 10
milliseconds). Under stable conditions the PLR should send BFD packet
with the alert mechanism enabled at a much lower frequency. It is
recommended that this frequency be once every 100 * "Detection Time".
4.4. Procedures at PLR-u
An upstream LSR on the protected LSP that is a transit for the backup
tunnel routed in a direction opposite to the protected LSP, deduces
the association between the protected LSP and the backup tunnel when
processing the protected LSP's RRO. Such a LSR is a PLR-u and it
creates an e-backup LSP (if one does not already exist) to a
destination LSR as has been described earlier.
The PLR-u associates a protection switch action of re-routing the
protected LSP to the e-backup tunnel with a trigger. The trigger is
an alert message received on the backup tunnel indicating that the
PLR has done a protection switch action (as a result of locally
detecting a failure) and re-routed the protected LSP to the backup
tunnel.
The PLR-u's protection switch action depends on the current status of
the protection switch at PLR-u and the status of the protection
switch at the PLR (known through the alert message on the backup
tunnel). When the protection switch status at PLR-u is in-active
i.e., the protected LSP is not re-routed to the e-backup tunnel, and
the received alert message indicates that protection switch has
occurred at PLR i.e., the BFD packet received as an alert message on
the backup tunnel has Status as Up and the Diagnostic code is not
"Backup LSP not carrying protected traffic", then the PLR-u re-routes
Kini & Liu Expires July 2011 [Page 11]
Internet Draft Efficient Facility Backup FRR January 13, 2010
traffic on the protected LSP over the e-backup tunnel. In all other
conditions the protected LSP is not re-routed over the e-backup LSP.
5. Example
Consider the scenario described in section 3. PLR (L8) creates a BFD
session on B1. When the BFD session is Up, L8 appends to the RRO of
P1, P3, P4, P5 the backup LSP Tunnel Session (of B1) subobject
following the interface address of the link L8->L7. L9 on
interpreting this subobject for P1 and also that the corresponding
LSP (B1) is going in the opposite direction as P1, functions as PLR-u
for P1. Using the RROs of B1, P1 and the TED, it deduces that a
backup path L9-L10-L1-L2-L3-L4-L5-L6 can be used to protect P1. Say
this LSP is called B3. L9 initiates a setup of B3 if it does not
already exist and associates the trigger of an alert message on B1 to
perform the protection switch from P1 to B3. Normally PLR-u (L9)
receives a BFD control packet with FLA-bit set on the backup tunnel
with "State" as "Up" and the "Diagnostic" code as "Backup LSP not
carrying protected traffic".
Say L8 does not set FLA-bit on all BFD control packets on the bypass.
When L8 detects failure on link L8-L7 (due to loss of signal, BFD,
etc), it does a protection switch of P1 to the bypass B1. It also
modifies the BFD control packet for the session on B1, by clearing
the "Diagnostic" code. The FLA-bit for the session is set for a short
time. When PLR-u (L9) receives the G-Ach message due to FLA-bit being
set, it processes the embedded BFD control packet. Since "State" is
"Up" and the "Diagnostic" code is clear, L9 does a protection switch
of P1 to B3. Conversely when the fault on L8-L7 clears, L8 switches
traffic on P1 out of the bypass and sends it directly to L7. It also
modifies the BFD control packet for the session on B1, by setting the
"Diagnostic" code to "Backup LSP not carrying protected traffic". The
FLA-bit for the session is set for a short time. Again PLR-u (L9)
receives the G-Ach message and processes the embedded BFD control
packet. Since "State" is "Up" and the "Diagnostic" code is "Backup
LSP not carrying protected traffic", L9 reverts P1 by sending traffic
directly to L8 instead of the backup path.
6. Applicability to generic topologies
This document uses a ring topology in isolation, purely for
illustrative clarity purposes. Any backup tunnel along with the
segment that it is protecting, forms a logical ring. This sub-graph
can be placed in any generic topology. This problem and solution
would still be equally applicable.
Kini & Liu Expires July 2011 [Page 12]
Internet Draft Efficient Facility Backup FRR January 13, 2010
7. Future work
The solution in its current form is applicable to point-to-point
protected LSPs. However the problem applies to point-to-multipoint
LSPs as well and a solution could follow a similar approach.
Solutions to P2MP LSPs would be incorporated in future versions of
this draft.
Authentication parameters required by [ID.BFD] or the ACH TLVs, need
to be communicated to all LSRs along the backup if it required to do
authentication at each transit LSR. This can be simplified by
extensions to [RSVP-TE].
8. Security Considerations
This document does not introduce new security considerations other
than those already described in [MPLS-FRR], [ID.BFD] and [ID.fast-
lsp-alert]. The optimization (optional) of not validating the
authenticity of the BFD control packet (via authentication field or
ACH TLVs) in a transit LSR of the backup tunnel should not introduce
any new security threats. Note that this message is processed only
when the "State" in the BFD control packet indicates Up. Any non-
authentic packets would be detected by the LSRs at the LSP's end-
points. Alarms would be raised by the end point and should be
sufficient to diagnose potential problems.
9. IANA Considerations
Values need to be allocated for:
1. "Flags" field position in SESSION_ATTRIBUTE object for newly
defined flag "Local protection recording desired". Recommend
using next unused field position 0x20.
2. "Type" field in RECORD_ROUTE object with C-Type 1 for newly
defined subobjects Backup_LSP_TUNNEL_IPv4_Session,
Backup_LSP_TUNNEL_IPv6_Session,
Backup_LSP_Tunnel_IPv4_Sender_Template and
Backup_LSP_TUNNEL_IPv6_Sender_Template. Recommend using values
the next available values 4, 5, 6 and 7 respectively.
3. "Diagnostic" field in BFD control packet for newly defined code
"Backup LSP not carrying protected traffic". Recommend using
the first reserved value 9 for this purpose.
10. References
Kini & Liu Expires July 2011 [Page 13]
Internet Draft Efficient Facility Backup FRR January 13, 2010
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RSVP-TE] Awduche, D., et al, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC3209, December 2001.
[MPLS-FRR] Pan, P., et al, "Fast Reroute Extensions to RSVP-TE for
LSP Tunnels", RFC4090, May 2005.
[RFC4561] Vasseur, J. P., et al, "Definition of a Record Route
Object (RRO) Node-Id Sub-Object", RFC4561, June 2006.
[RFC5586] Bocci, M., et al, "MPLS Generic Associated Channel", RFC
5586, June 2009.
[ID.BFD] Katz, D., et al, "Bidirectional Forwarding Detection",
draft-ietf-bfd-base-11, (Work in progress), Jan 2010.
[ID.BFD-MPLS] Aggarwal, R., et al, "BFD For MPLS LSPs", draft-ietf-
bfd-mpls-07 (Work in progress), June 2008.
[ID.ACH-TLVs] Boutros, S., et al, "Definition of ACH TLV Structure",
draft-ietf-mpls-tp-ach-tlv-02 (Work in progress), March
2010.
[ID.fast-lsp-alert] Kini, S., Liu, A., "A fast LSP-alert mechanism",
draft-kini-mpls-tp-fast-lsp-alert-01 (Work in progress),
July 2010.
11. Acknowledgements
The authors would like to thank Marc Rapoport and Joel Halpern for
their comments.
Kini & Liu Expires July 2011 [Page 14]
Internet Draft Efficient Facility Backup FRR January 13, 2010
Authors' Addresses
Sriganesh Kini
Ericsson
300 Holger Way, San Jose, CA 95134
EMail: sriganesh.kini@ericsson.com
Autumn Liu
Ericsson
300 Holger Way, San Jose, CA 95134
EMail: autumn.liu@ericsson.com
Kini & Liu Expires July 2011 [Page 15]