MPLS Working Group A. Atlas
Internet-Draft R. Torvi
Intended status: Standards Track M. Jork
Expires: January 10, 2013 Juniper Networks
July 9, 2012
Ingress Protection for RSVP-TE p2p and p2mp LSPs
draft-torvi-mpls-rsvp-ingress-protection-00
Abstract
Protection against node failure is important for RSVP-TE LSPs,
whether point-to-point or point-to-multipoint. While [RFC4090]
provides a mechanism for node protection, it does not specify how to
protect against failure of the ingress node. This document specifies
the RSVP extensions to support ingress node protection and describes
the necessary processing behavior.
Status of this Memo
This Internet-Draft is submitted 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 January 10, 2013.
Copyright Notice
Copyright (c) 2012 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. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
Atlas, et al. Expires January 10, 2013 [Page 1]
Internet-Draft RSVP-TE LSP Ingress Protection July 2012
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Failure Detection Issues and Solution . . . . . . . . . . . . 4
3. Description of Behavior . . . . . . . . . . . . . . . . . . . 5
3.1. Ingress Node . . . . . . . . . . . . . . . . . . . . . . . 5
3.1.1. Required Configuration Information . . . . . . . . . . 5
3.1.2. Signaling Behavior . . . . . . . . . . . . . . . . . . 6
3.2. Backup Node . . . . . . . . . . . . . . . . . . . . . . . 7
3.2.1. Behavior for On-Forwarding-Path Backup Node . . . . . 7
3.2.2. Behavior for Off-Forwarding-Path Backup Node . . . . . 7
3.3. Merge Node . . . . . . . . . . . . . . . . . . . . . . . . 8
3.4. Global Repair . . . . . . . . . . . . . . . . . . . . . . 8
3.5. Ingress Revival and Administrative Switching . . . . . . . 9
4. RSVP Extensions . . . . . . . . . . . . . . . . . . . . . . . 9
4.1. INGRESS-PROTECTION object . . . . . . . . . . . . . . . . 9
5. Normative References . . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
Atlas, et al. Expires January 10, 2013 [Page 2]
Internet-Draft RSVP-TE LSP Ingress Protection July 2012
1. Introduction
It is desirable to protect RSVP-TE LSPs, whether p2p or p2mp, against
ingress failure. To do this, a backup node must be pre-identified
and prepared with the necessary state so that it can forward traffic
when necessary.
Conceptually, a proxy ingress node is created that starts the RSVP
signaling. The explicit path of the LSP goes from the proxy ingress
node to the backup node and then to the real ingress node. The
behavior and signaling for the proxy ingress node is done by the real
ingress node.
The backup node must be only one logical hop away from the ingress,
whether that be via a direct link or a tunnel.
[ traffic source ]
| |
| |
| |
[ proxy ingress ] [ backup ]
[ & ingress ] |
| |
|----[ MP ]----|
Figure 1: Example Protected LSP with Proxy Ingress Node
There are three different scenarios that this document addresses for
ingress protection. All three can be handled using the same set of
signaling defined in this document.
A. Traffic Source detects failure The traffic source(s) can rapidly
determine that the ingress has failed and switch over to sending
traffic to the backup node. When this mode is specified, the
backup node will forward any appropriately received traffic along
its bypass tunnel to the merge point(s).
B. MP detects failure The traffic source(s) always send traffic to
both the ingress and backup nodes. The backup node always
forwards traffic along its bypass tunnel to the merge point(s).
Each MP determines whether the ingress node has failed and, if so,
switches over to accepting the traffic from the backup node.
Atlas, et al. Expires January 10, 2013 [Page 3]
Internet-Draft RSVP-TE LSP Ingress Protection July 2012
C. Backup detects failure The traffic source(s) always send traffic
to both the ingress and backup nodes. The backup node does not
forward the received traffic from the traffic source under normal
conditions. When the backup node determines that the ingress node
has failed, the backup node starts forwarding the traffic alongs
its bypass tunnel(s) to the merge point(s).
For all three scenarios, it is necessary for the backup node to know
the merge point(s) and associated MPLS labels. This is accomplished
by having the RSVP Path and RESV messages go through the backup node,
although the forwarding path need not go through the backup node.
There are two cases of interest - on-forwarding-path and off-
forwarding-path. In the on-forwarding-path case, the backup node is
already the immediate node after the ingress node for the LSP. In
the off-forwarding-path, the backup node is not the immediate node
after the ingress node for all asociated sub-LSPs.
For ingress protection to be functional, the backup node must have
access and knowledge of the appropriate traffic to send into the
protected LSP. The ingress node must be capable of describing the
traffic to the backup node.
Once the backup node has the necessary state for the LSP, including
the set of merge points, the backup node can use bypass tunnels as
described in [RFC4090]. If the LSP is a point-to-multipoint, then
the backup node has the option of choosing to use a bypass p2mp
tunnel for protection.
Finally, an assumption of local protection is that a global repair
mechanism will occur to replace the patched LSP with a new fully
functional one. To do this, it is necessary that the backup node be
able to enact a global repair that still allows sharing of bandwidth
resources between the old and new LSPs.
2. Failure Detection Issues and Solution
For each of the different scenarios, the details of detecting an
ingress node failure can vary. This document does not specify the
details of how to do so, but it is possible using either approriately
routed BFD sessions or direct link information.
For traffic-source detection and fail-over, the traffic source can
merely monitor the state of the direct links over which traffic is
sent to the ingress.
For MP detection, the MP can be configured with the appropriate BFD
discriminators used on the BFD sessions. It is desirable for the MP
Atlas, et al. Expires January 10, 2013 [Page 4]
Internet-Draft RSVP-TE LSP Ingress Protection July 2012
to know that the ingress can't send traffic to the MP or downstream
(for when the ingress is protecting against the MP failure). The
appropriate BFD discriminators will vary by MP; they are not signaled
in the RSVP extensions described in this draft.
For backup node detection, the backup node can be configured with the
appropriate BFD discriminators used on the BFD sessions. Again, they
are not signaled in the RSVP extensions described in this draft.
3. Description of Behavior
3.1. Ingress Node
3.1.1. Required Configuration Information
The ingress node must be configured with four pieces of information
for these extensions to work.
Backup Node Address The ingress node must know an IP address for the
backup node that can be included in the ERO.
Protection Scenario The ingress node must know whether the traffic
source, backup node, or merge point(s) will be responsible for
handling fail-over.
Ingress-Protector-Context-Id The Ingress-Protector-Context-Id is
used for the Extended Session ID in ingress-protected LSPs instead
of using the ingress node's loopback address. The Ingress-
Protector-Context-Id should not be the same as another address
associated with a router that may signal TE LSPs. By having an
Ingress-Protector-Context-Id, the backup node can perform global
repair.
Application Traffic Identifier The ingress and backup node must both
know what application traffic should be directed into the LSP. A
commonly understood Application Traffic Identifier is sent between
the ingress and backup nodes in RSVP signaling. The exact meaning
of the identifier should be configured similarly at both the
ingress and backup nodes. The Application Traffic Identifier is
understood within the unique context of the Ingress-Protector-
Context-Id.
With this additional information, the ingress node can create and
signal the necessary RSVP extensions to support ingress protection.
Atlas, et al. Expires January 10, 2013 [Page 5]
Internet-Draft RSVP-TE LSP Ingress Protection July 2012
3.1.2. Signaling Behavior
The ingress node is responsible for starting the RSVP signaling for
the proxy-ingress node. To do this, the following is done for the
RSVP Path message.
1. Compute the EROs for the LSP as normal for the ingress.
2. If the selected backup node is not the first node on the path
(for all sub-LSPs), then insert at the beginning of the ERO first
the backup node and then the ingress node.
3. Change the IPv4 tunnel sender address in the Sender Template
Object to be that of the Ingress-Protector-Context-Id.
4. In the Path RRO, instead of recording the ingress node's address,
replace it with the Ingress-Protector-Context-Id.
5. Leave the HOP object populated as usual with information for the
ingress-node.
6. Add the INGRESS-PROTECTION object to the Path message. Allocate
a second LSP-ID to be used in the INGRESS-PROTECTION object.
7. The RSVP Path message is sent to the backup node as normal.
Since the backup node must be only one logical hop away from the
ingress, normal RSVP signaling can be used.
When the backup node is off the forwarding path, there are additional
behaviors for the ingress node to do when it is handling the
associated PATH and RESV messages.
When the ingress node receives an RSVP Path message with an INGRESS-
PROTECTION object and the object specifies that node as the ingress
node and the PHOP as the backup node, the ingress node SHOULD check
the Failure Scenario specified in the INGRESS-PROTECTION object and,
if it is not the "MP detects failure" scenario, then the ingress node
SHOULD remove the INGRESS-PROTECTION object from the PATH message
before sending it out. Additionally, the ingress node must store
that it will install ingress forwarding state for the LSP rather than
midpoint forwarding.
When an RSVP RESV message is received by the ingress, it uses the
NHOP to determine whether the message is received from the backup
node or from a different node. The stored associated PATH message
contains an INGRESS-PROTECTION object that identifies the backup
node. If the RESV message is not from the backup node, then ingress
forwarding state should be set up, and the INGRESS-PROTECTION object
Atlas, et al. Expires January 10, 2013 [Page 6]
Internet-Draft RSVP-TE LSP Ingress Protection July 2012
MUST be added to the RESV before it is sent to the NHOP, which should
be the backup node. If the RESV message is from the backup node,
then the LSP should be considered available for use.
If the backup node is on the forwarding path, then a RESV is received
with an INGRESS-PROTECTION object and an NHOP that matches the backup
node. In this case, the ingress node's address will not appear after
the backup node in the RRO. The ingress node should set up ingress
forwarding state, just as is done if the LSP weren't ingress-node
protected.
3.2. Backup Node
An LER determines that the LSP is ingress-protected based upon the
presence of the INGRESS-PROTECTION object in the PATH message. An
LER can further determine that it is the backup node if one of its
addresses is listed as the backup node in the INGRESS-PROTECTION
object.
3.2.1. Behavior for On-Forwarding-Path Backup Node
If the backup node is on the forwarding path, then the backup node
MUST remove the INGRESS-PROTECTION object from the PATH message
before forwarding it.
If the failure scenario is either "MP-detected" or "Backup-detected",
then the backup node is responsible for determining if the ingress
node has failed and forwarding the identified traffic from the
traffic source(s) to the next-hop(s) on the LSP instead of forwarding
the traffic from the ingress node.
When the backup node receives a RESV message, it should add back in
the INGRESS-PROTECTION object before forwarding it.
3.2.2. Behavior for Off-Forwarding-Path Backup Node
When the backup node receives a PATH message with the INGRESS-
PROTECTION object, the backup node examines the INGRESS-PROTECTION
object to learn what traffic associated with the LSP and what failure
scenario is being used. The backup node forwards the PATH message to
the ingress node with the normal RSVP changes.
When the backup node receives a RESV message with the INGRESS-
PROTECTION object, the backup node records an IMPLICIT-NULL label in
the RRO. The backup node creates the appropriate forwarding state
for the failure scenario specified. For the "MP-detected" and
"traffic-source-detected", this means that backup node forwards any
received identified traffic into the bypass tunnel(s) to the merge
Atlas, et al. Expires January 10, 2013 [Page 7]
Internet-Draft RSVP-TE LSP Ingress Protection July 2012
point(s). For the "backup-detected", this means that the backup node
creates state to quickly determine the ingress has failed and switch
to sending any received identified traffic into the bypass tunnel(s)
to the merge point(s). Then the backup node forwards the RESV
message to the ingress node, which is acting for the proxy ingress.
If the backup node doesn't have a bypass tunnel to a merge point,
then the backup node can wait to send the RESV until such has been
created or it can send a Path Err with an Error Code of "Routing
Problem (24)" and a new Error Value sub-code of "No Bypass Tunnel to
Merge Point (TBD)".
3.3. Merge Node
An LSR that is serving as a Merge Node may need to support the
INGRESS-PROTECTION object and functionality defined in this
specification if the LSP is ingress-protected where the failure
scenario is "MP-detected". An LSR can determine that it must be a
merge point by examining the INGRESS-PROTECTION object and
determining that it is neither the ingress node nor the backup node
and the PHOP is the ingress node.
In that case, when the LSR receives a PATH message with an INGRESS-
PROTECTION object, the LSR MUST remove the INGRESS-PROTECTION object
before forwarding on the PATH message.
If the failure scenario specified is "MP-detected", the MP must
connect up the fast-failure detection (as configured) to accepting
backup traffic received from the backup node. There are a number of
different ways that the MP can enforce not forwarding traffic
normally received from the backup node. For instance, first, any
LSPs set up from the backup node should not be signaled with an
IMPLICIT NULL label and second, the associated label for the ingress-
protected LSP could be set to normally discard inside that context.
When the MP receives a RESV message whose matching PATH state had an
INGRESS-PROTECTION object, the MP SHOULD add the INGRESS-PROTECTION
object to the RESV message before forwarding it.
3.4. Global Repair
When the backup node learns the ingress node has failed (e.g. via the
IGP), then the backup node can compute new ERO(s) and signal the new
LSP so that it no longer relies upon local repair. To do this, the
backup node uses the same Ingress-Protector-Context-Id as the Ipv4
tunnel sender address in the Sender Template Object and uses the
previously allocated second LSP-ID signaled in the INGRESS-PROTECTION
object. This allows the new LSP to share resources with the old LSP.
Atlas, et al. Expires January 10, 2013 [Page 8]
Internet-Draft RSVP-TE LSP Ingress Protection July 2012
3.5. Ingress Revival and Administrative Switching
In a future version, it is intended to describe the behavior when the
ingress node comes back and how to handle management-triggered
switches from ingress to backup node and vice versa.
4. RSVP Extensions
4.1. INGRESS-PROTECTION object
Class-Num = TBD
C-Type = TBD
0 1 2 3
+-------------+-------------+-------------+-------------+
| Length (bytes) | Class-Num | C-Type |
+-------------+-------------+-------------+-------------+
| Backup Node Address |
+-------------+-------------+-------------+-------------+
| Ingress Node Address |
+-------------+-------------+-------------+-------------+
| Application Traffic Identifier |
+-------------+-------------+-------------+-------------+
| Secondary LSP ID | Protection | Flags |
| | Scenario | |
+-------------+-------------+-------------+-------------+
Figure 2: INGRESS-PROTECTION object
Backup Node Address
Ingress Node Address
Application Traffic Identifier
Ingress-Protector-Context-Id
Secondary LSP ID
Protection Scenario Indicates if (1) traffic source(s), (2) backup
node, (3) or merge point(s) will handle the fail-over.
Atlas, et al. Expires January 10, 2013 [Page 9]
Internet-Draft RSVP-TE LSP Ingress Protection July 2012
Control Flags Backup sent flags: (0x01)Ingress-Protection in-use,
(0x02)Ingress Detected Down, (0x04)Admin Override caused Ingress-
Protection-in-use. Ingress sent flags: (0x08)Revert Control to
Ingress, (0x10)Force control to Backup
5. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, September 1997.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001.
[RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute
Extensions to RSVP-TE for LSP Tunnels", RFC 4090,
May 2005.
[RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa,
"Extensions to Resource Reservation Protocol - Traffic
Engineering (RSVP-TE) for Point-to-Multipoint TE Label
Switched Paths (LSPs)", RFC 4875, May 2007.
Authors' Addresses
Alia Atlas
Juniper Networks
10 Technology Park Drive
Westford, MA 01886
USA
Email: akatlas@juniper.net
Raveendra Torvi
Juniper Networks
10 Technology Park Drive
Westford, MA 01886
USA
Email: rtorvi@juniper.net
Atlas, et al. Expires January 10, 2013 [Page 10]
Internet-Draft RSVP-TE LSP Ingress Protection July 2012
Markus Jork
Juniper Networks
10 Technology Park Drive
Westford, MA 01886
USA
Email: mjork@juniper.net
Atlas, et al. Expires January 10, 2013 [Page 11]