Internet Engineering Task Force Yimin Shen
Internet-Draft Minto Jeyananth
Intended status: Informational Juniper Networks
Expires: August 20, 2016 February 17, 2016
MPLS Egress Protection Framework
draft-shen-mpls-egress-protection-framework-00
Abstract
This document specifies a fast reroute framework for protecting MPLS
tunnels and the IP/MPLS services carried by them against egress
router failures. The framework relies on local detection and local
repair to be performed by the router upstream adjacent to a failure.
The router can restore traffic in the order of tens of milliseconds,
by rerouting it to a protector through a pre-established bypass
tunnel. Therefore, the mechanism can be used to reduce traffic loss
before global repair reacts to the failure and control plane
protocols converge on the topology changes due to the failure.
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 August 20, 2016.
Copyright Notice
Copyright (c) 2016 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
Yimin Shen & Minto JeyanaExpires August 20, 2016 [Page 1]
Internet-Draft MPLS Egress Protection Framework February 2016
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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Specification of Requirements . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 4
5. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 5
5.1. Egress failure . . . . . . . . . . . . . . . . . . . . . 5
5.2. Protector and PLR . . . . . . . . . . . . . . . . . . . . 6
5.3. Protected egress . . . . . . . . . . . . . . . . . . . . 6
5.4. Egress-protected tunnel . . . . . . . . . . . . . . . . . 7
5.5. Egress-protected service . . . . . . . . . . . . . . . . 7
5.6. Egress-protected service to egress-protected tunnel
mapping . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.7. Egress-protection bypass tunnel . . . . . . . . . . . . . 7
5.8. Context ID, context label, and context based forwarding . 8
5.9. IGP advertisement and path computation for context ID . . 9
5.10. Egress-protection bypass tunnel establishment . . . . . . 10
5.11. Local Repair on PLR . . . . . . . . . . . . . . . . . . . 11
5.12. Label distribution from egress router to protector . . . 11
6. Global repair . . . . . . . . . . . . . . . . . . . . . . . . 12
7. Example: Layer-3 VPN egress protection . . . . . . . . . . . 12
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
9. Security Considerations . . . . . . . . . . . . . . . . . . . 14
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
11.1. Normative References . . . . . . . . . . . . . . . . . . 14
11.2. Informative References . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction
In MPLS networks, LSPs (label switched paths) are widely use as
transport tunnels to carry IP and MPLS services across MPLS domains.
Examples of MPLS services are layer-2 VPNs, layer-3 VPNs, etc.
Particularly, at the egress router of a tunnel, packets of an IP
service are forwarded to service destination based on IP header, and
packets of an MPLS service are forwarded to service destination based
on a service label.
Today, local repair based fast reroute mechanisms have been widely
deployed to protect MPLS tunnels against transit link and node
failures. They can achieve fast restoration in the order of tens of
Yimin Shen & Minto JeyanaExpires August 20, 2016 [Page 2]
Internet-Draft MPLS Egress Protection Framework February 2016
milliseconds. Local repair refers to the scenario where the router
(aka. PLR, i.e. point of local repair) upstream adjacent to an
anticipated failure pre-establishes a bypass tunnel around the
failure to another router (aka. MP, i.e. merge point) on the tunnel
and downstream of the failure, and pre-installs the forwarding state
of the bypass tunnel in the data plane. The PLR also has a rapid
mechanism to locally detect the failure in the data plane. When the
failure occurs, the PLR reroutes traffic through the bypass tunnel to
the MP. Thus, the traffic will continue to flow via the MP to the
tunnel's egress router.
This document describes a fast reroute framework for egress router
protection. Similar to the transit link/node protection, this
framework relies on local failure detection and local repair to be
performed by a PLR, which is the penultimate hop router of a tunnel.
However, there is no MP in this case, because the tunnel does not
have other router downstream of the egress router. Instead, this
framework relies on a so-called "protector" to serve as the tailend
of a bypass tunnel. The protector is simply a backup router that has
its own connectivity to service destinations. It performs context
label switching for rerouted MPLS service packets based on service
labels assigned by the protected egress router, and performs context
IP forwarding for rerouted IP service packets.
This framework considers an egress router failure as a failure of a
tunnel and a failure of the service(s) carried by the tunnel. Hence,
it addresses protection at both tunnel level and service level.
This framework requires that the destination (a CE or site) of a
protected service must be dual-homed or have dual paths to the MPLS
network, normally via two PEs.
The framework is described by mainly referring to P2P (point-to-
point) tunnels. However, it is equally applicable to P2MP (point-to-
multipoint), MP2P (multipoint-to-point) and MP2MP (multipoint-to-
multipoint) tunnels, where each sub-LSP can be viewed as a P2P tunnel
from traffic flow's perspective.
The framework does not require extensions for signaling or label
distribution protocols of MPLS tunnels. It may require extensions
for IGPs and service label distribution protocols, to facilitate
protection establishment and context label switching. This document
provides guidelines for these extensions, but the details should be
addressed in separate documents.
Yimin Shen & Minto JeyanaExpires August 20, 2016 [Page 3]
Internet-Draft MPLS Egress Protection Framework February 2016
2. Specification of Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC2119.
3. Terminology
EP - Egress protection.
Egress-protected tunnel - A tunnel that desires egress protection.
Protector - A router that acts as a backup for the egress router of
an egress-protected tunnel.
PLR - A router at point of local repair, which is the penultimate hop
router on an egress-protected tunnel.
Protected egress - A virtual node consisting of an ordered pair of
{egress router, protector}. It serves as the virtual destination of
an egress-protected tunnel.
Context identifier (ID) - A globally unique IP address assigned to a
protected egress {egress router, protector}, and owned by both
routers.
Context label - A non-reserved label assigned to a context ID by a
protector.
Egress-protection bypass tunnel - An tunnel established from a PLR to
a protector, bypassing the egress router of an egress-protected
tunnel.
Context label switching - Label switching performed by a protector,
in the label space (or label table) indicated by a context, i.e. a
context label in this document.
Context IP forwarding - IP forwarding performed by a protector, in
the IP forwarding table indicated by a context, i.e. a context label
in this document.
4. Requirements
This document considers the followings as requirements of the egress
protection framework.
o The framework must be based on local failure detection and local
repair, in a similar fashion to transit link and node protection.
Yimin Shen & Minto JeyanaExpires August 20, 2016 [Page 4]
Internet-Draft MPLS Egress Protection Framework February 2016
It must be able to achieve fast restoration in the order of tens
of milliseconds.
o The framework must support P2P tunnels. It should equally apply
to P2MP, MP2P and MP2MP tunnels, by treating each sub-LSP as a P2P
tunnel.
o The framework must be independent of signaling and label-
distribution protocols of tunnels and bypass tunnels, including
RSPV, LDP, BGP, IGP, segment routing, etc.
o The framework must be generic to support existing and future MPLS
services, including layer-2 VPNs, layer-3 VPNs, etc.
o A PLR must be agnostic on services and service labels. It must
maintain bypass tunnels and bypass forwarding state on a per-
transport-tunnel basis, rather than per-service or per-service-
label basis. It must support bypass tunnel sharing between
transport tunnels.
o A PLR must be able to use its local routing and TE information
database to compute or resolve path for a bypass tunnel.
o A protector must be able to perform context label switching for
rerouted MPLS service packets, based on a service label assigned
by a protected egress router.
o A protector must be able to perform context IP forwarding for
rerouted IP service packets.
o The framework must be able to work seamlessly with transit node
protection mechanisms to achieve end-to-end node protection for
MPLS tunnels.
o The framework must be able to work in conjunction with global
repair (aka. end-to-end repair) and control plane convergence.
5. Theory of Operation
5.1. Egress failure
An egress failure refers to the node failure of a tunnel's egress
router. As each MPLS service carried by the tunnel can be viewed as
a one-hop LSP from the ingress router to the egress router, the
failure is considered as an egress node failure of the service as
well.
Yimin Shen & Minto JeyanaExpires August 20, 2016 [Page 5]
Internet-Draft MPLS Egress Protection Framework February 2016
Failure detection mechanisms that are used by PLRs in transit link
and node protection are applicable to egress failure detection. In
the case where a PLR does not have a fast and reliable mechanism to
detect a node failure, it may treat a link failure as a node failure
and trigger node protection.
5.2. Protector and PLR
A router is assigned to protect a tunnel against egress failure. The
router is called a protector. It protects the tunnel, as well as the
services carried by the tunnel. A tunnel can be protected by only
one protector, while a protector may protect multiple tunnels to one
or multiple egress routers. Tunnels to a given egress router may be
protected by different protectors. Hence, egress routers and
protectors have a many-to-many relationship.
The penultimate hop router of a tunnel acts as a PLR. It pre-
establishes a bypass tunnel to the protector, and pre-installs bypass
forwarding state in the data plane. Upon detection of an egress
failure, the PLR reroutes all the packets received on the tunnel
though the bypass tunnel to the protector, with service label intact
for MPLS service packets. The protector in turn forwards the service
packets towards the ultimate service destination(s). Specifically,
for MPLS service packets, the protector performs context label
switching based on service labels assigned by the egress router of
the protected tunnel. For IP service packets, the protector performs
context IP forwarding based on destination addresses. The protector
has its own connectivity with the service destinations, which means
that the destinations must be dual-homed or have dual paths to the
egress router and the protector.
5.3. Protected egress
This document introduces the notion of "protected egress" as a
virtual node consisting of the egress router of a tunnel and a
protector. It is denoted by an ordered pair of {egress router,
protector}. It represents the relationship between the two routers in
the egress protection schema.
A given egress router E may be the tailend of multiple tunnels. At
the same time, it may be protected by multiple protectors, i.e. P1,
P2, etc, with each Pi protecting a subset of the tunnels. Hence,
these routers will form multiple protected egress', i.e. {E, P1} ,
{E, P2}, etc. Each tunnel is associated with one and only one
protected egress {E, Pi}. Every service carried by the tunnel is also
automatically associated with the protected egress {E, Pi}.
Yimin Shen & Minto JeyanaExpires August 20, 2016 [Page 6]
Internet-Draft MPLS Egress Protection Framework February 2016
Two node X and Y may be protectors for each other's tunnels. In this
case, they form two distinct protected egress', i.e. {X, Y} and {Y,
X}.
From another perspective, a service associated with a protected
egress {E, Pi} must be carried by a tunnel associated with the same
protected egress {E, Pi}. This is ensured by the ingress router
(Section 5.6).
5.4. Egress-protected tunnel
A tunnel, which is associated with a protected egress {E, P}, is
called an egress-protected tunnel. The tunnel is viewed as logically
"destined" for the protected egress, although it is physically
destined for E.
Each egress-protected tunnel is associated with one and only one
protected egress {E, P}.
Multiple of egress-protected tunnels may be associated with a given
protected egress {E, P}. These tunnels share the common egress router
and protector, but may not share a common ingress router.
5.5. Egress-protected service
A service, which is associated with a protected egress {E, P}, is
called an egress-protected service.
Each egress-protected service is associated with one and only one
protected egress {E, P}.
Multiple egress-protected services may be associated with a given
protected egress {E, P}. These services share the common egress
router and protector, but may not necessarily be transported by the
same tunnel or share a common ingress router.
5.6. Egress-protected service to egress-protected tunnel mapping
An ingress router must map an egress-protected service to an egress-
protected tunnel based on common protected egress {E, P}. This is
achieved by introducing the notion of "context ID" for protected
egress, as described in (Section 5.8).
5.7. Egress-protection bypass tunnel
An egress-protected tunnel destined for a protected egress {E, P}
should have a bypass tunnel from its PLR to the protector P. This
bypass tunnel is called an egress-protection bypass tunnel. An
Yimin Shen & Minto JeyanaExpires August 20, 2016 [Page 7]
Internet-Draft MPLS Egress Protection Framework February 2016
egress-protection bypass tunnel is associated with one and only one
protected egress {E, P}. The bypass tunnel is viewed as logically
"destined" for the protected egress {E, P}, although it is physically
destined for P and bypassing E.
A PLR may share an egress-protection bypass tunnel between multiple
egress-protected tunnels, if they are destined for a common protected
egress {E, P}.
For a given protected egress {E, P}, there may exist one or multiple
egress-protection bypass tunnel from multiple PLRs to the protector
P. The PLRs belong to different egress-protected tunnels destined
for the protected egress {E, P}.
Establishments of egress-protected tunnel and egress-protection
bypass tunnel are generally independent. In some cases, the former
may trigger the latter, if a PLR cannot find an existing egress-
protection bypass tunnel to use.
An egress-protection bypass tunnel has the property that it is not
affected by any topology change caused by an egress failure.
5.8. Context ID, context label, and context based forwarding
A context ID is a globally unique IPv4/v6 address assigned to a
protected egress {egress router, protector}. It is called context ID
due to its usage in context label switching and context IP forwarding
on the protector. It is an IP address owned by both the egress
router and the protector. For the egress node, it indicates the
protector. For the protector, it indicates the egress router. For
other routers in the network, it is an address reachable via both the
egress router and the protector in routing domain and TE domain
(Section 5.9).
Given an egress-protected service associated with a protected egress
{E, P} which is assigned a context ID, the context ID is used as
below:
o If the service is an MPLS service, when the egress router
distributes the label binding message of the service to the
ingress router, the egress router attaches the context ID to the
message. If the service is an IP service, when the egress router
advertises the service destination address to the ingress router,
the egress router attaches the context ID as a virtual next-hop to
the advertisement. How the context ID is encoded in the messages
is a choice of the related protocols, and may need protocol
extensions.
Yimin Shen & Minto JeyanaExpires August 20, 2016 [Page 8]
Internet-Draft MPLS Egress Protection Framework February 2016
o The ingress router then uses the context ID as destination to
establish or resolve an egress-protected tunnel. The ingress
router maps the service to the tunnel for transportation.
o The context ID is conveyed to the PLR by the signaling protocol of
the egress-protected tunnel or by the IGP or topology-driven label
distribution protocol of the network. The PLR uses the context ID
as destination to establish or resolve an egress-protection bypass
tunnel to the protector. Due to the context ID's reachability via
the protector, the PLR can achieve this without the knowledge of
egress protection schema.
o On the protector, the context ID is used to indicate the egress
router's label space and IP address space. The latter is the IP
address space of the destinations of egress-protected IP services.
o If the service is an MPLS service, the egress router uses a label
distribution protocol to advertise the label binding of the
service to the protector. The protector installs the label in a
dedicated label space, identified by the context ID.
o The protector assigns a non-reserved label to the context ID. In
the data plane, this label serves as a context to indicate the
egress router's label space and IP address space. Therefore, it
is called a "context label".
o The protector binds the context label to the egress-protection
bypass tunnel, based on the destination. During local repair, all
the service packets received on the bypass tunnel will have the
context label as top label. The protector will first pop the
context label. For MPLS service packets, the protector will
further look up the service label in the label space indicated by
the context label. This is called context label switching. For
IP service packets, the protector will look up the IP destination
address in the IP forwarding table indicated by the context label.
This is called context IP forwarding.
5.9. IGP advertisement and path computation for context ID
Given a protected egress {egress router, protector} and its context
ID, coordination must be done between the two routers for IGP
advertisement of the context ID in routing domain and TE domain. The
context ID must be advertised in such a way that all the egress-
protected tunnels destined for the context ID MUST be established
with the egress router as tailend, and all the egress-protection
bypass tunnels destined for the context ID MUST be established with
the protector as tailend, while avoiding the egress router.
Yimin Shen & Minto JeyanaExpires August 20, 2016 [Page 9]
Internet-Draft MPLS Egress Protection Framework February 2016
This document suggests two approaches:
1. The first approach is called "proxy mode". It does not require
an ingress router or a PLR to have knowledge of the egress
protection schema. The egress router and the protector advertise
the context ID as a virtual proxy node connected to the two
routers, with the link between the proxy node and the egress
router having more preferable IGP and TE metrics than the link
between the proxy node and the protector. Therefore, all egress-
protected tunnels destined for the context ID should
automatically follow shortest IGP paths or TE paths to the egress
router. Each PLR will no longer view itself as a penultimate
hop, but rather two hops away from the proxy node, via the egress
router. The PLR will be able to find a bypass path via the
protector to the proxy node, while the bypass tunnel should
actually be terminated by the protector.
2. The second approach is called "alias mode". It requires a PLR to
have knowledge of the egress protection schema. The egress
router advertises the context ID as a regular IP address. The
protector advertises the context ID and the context label by
using a special "context ID label binding" object. The object
must be understood by the PLR. In both routing domain and TE
domain, the context ID is only reachable via the egress router.
This ensures that all egress-protected tunnel destined for the
context ID are terminated by the egress router. Based on the
"context ID label binding" advertisement, the PLR can establish
an egress-protection bypass tunnel in a hierarchical fashion,
i.e. with a the context label as a one-hop LSP over a regular
bypass tunnel to the protector. The "context ID label binding"
object may require IGP extensions, or in a network with segment
routing, it may be an SID/Label Binding sub-TLV, treating a
context ID as a type of segment.
5.10. Egress-protection bypass tunnel establishment
In the control plane, an egress-protection bypass tunnel from a PLR
to a protector and destined for a context ID may be established via
several methods:
[1] It may be established by a signaling protocol (e.g. RSVP), with
the context ID as destination. The protector binds the context label
to the tunnel.
[2] It may be formed by a topology driven protocol (e.g. LDP). The
protector binds the context label to the context ID as an IP prefix
FEC.
Yimin Shen & Minto JeyanaExpires August 20, 2016 [Page 10]
Internet-Draft MPLS Egress Protection Framework February 2016
[3] It may be constructed by segment routing. In this case, the
protector must use the alias mode (Section 5.9) to advertise the
context ID and context label binding via IGP. The PLR can then
construct the bypass tunnel as a label stack to the protector, with
the context label as the inner-most label.
[4] It may be constructed as a hierarchical tunnel. When the
protector uses the alias mode (Section 5.9), the PLR will have the
knowledge of the context ID, context label, and protector (i.e. the
advertiser). The PLR can then establish the bypass tunnel in a
hierarchical fashion, with the context label as a one-hop LSP over a
regular bypass tunnel (signaled or topology-driven) to the protector.
5.11. Local Repair on PLR
A PLR is agnostic on services and services labels carried by its
egress-protected tunnel. During local repair, it simply reroutes all
service packets received on the tunnel to an egress-protection bypass
tunnel, and keeps service labels intact in the packets.
In the simplest case, the rerouting involves swapping the in-label of
the egress-protected tunnel to the out-label of the egress-protection
bypass tunnel. In the case where the bypass tunnel is a hierarchical
tunnel, the rerouting involves swapping the in-label of the egress-
protected tunnel to a context label, and pushing the out-label of a
regular bypass tunnel. In the case where the bypass tunnel is
constructed by segment routing, the rerouting involves swapping the
in-label of the egress-protected tunnel to a context label, and
pushing the label stack of a regular bypass tunnel.
Keeping service labels intact in the packets obviates the need for
the PLR to maintain bypass tunnels and bypass forwarding state on
per-service basis, and allows bypass sharing between egress-protected
tunnels.
5.12. Label distribution from egress router to protector
For rerouted MPLS service packets, a protector performs context label
switching for service labels assigned by egress routers. From the
protector's perspective, these service labels are "upstream assigned"
labels. The protector maintains the labels in dedicated label spaces
on a per protected egress basis, i.e. one label space for each egress
router that it protects.
There must be a label distribution protocol running between each
egress router and the protector. Through this protocol, the
protector learns the label bindings of egress-protected MPLS
services. It recognizes each service FEC, and resolves forwarding
Yimin Shen & Minto JeyanaExpires August 20, 2016 [Page 11]
Internet-Draft MPLS Egress Protection Framework February 2016
state based on its own connectivity to the service destination. It
installs the service label with the forwarding state in the label
space of the egress router.
Protocol extensions may be needed for the upstream label distribution
between egress router and protector.
6. Global repair
The framework in this document provides a fast but temporary reroute
for traffic upon an egress failure. As a permanent solution, it is
RECOMMENDED that the ingress router SHOULD move the traffic to
another fully functional tunnel or other fully functional services.
This is referred to as global repair. Possible triggers of global
repair include service and tunnel status notifications, end-to-end
OAM at service and tunnel levels, traffic marking in the reverse
direction, etc. These replacement tunnel and services may be pre-
established backups, or newly established as a result of the ingress
router's retry mechanism or network protocol convergence.
7. Example: Layer-3 VPN egress protection
This section shows an example of egress protection for a layer-3 VPN.
---------- R1 -------------- PE2 -
/ (PLR) \
( site 1 ) / | ( site 2 )
( ) / | ( )
( subnet )-- PE1 < | ( subnet )
( 8.0.0.0/8 ) \ | ( 9.0.0.0/8 )
( ) \ | ( )
\ | /
---------- R2 -------------- PE3 -
(protector)
Figure 1
In this example, the site 1 of a given VPN is attached to PE1, and
site 2 is dual-homed to PE2 and PE3. PE2 is the primary PE for site
2, and PE3 is the backup PE. R1 and R2 are core routers of the MPLS
network. The network uses OSPF as routing protocol, and RSVP-TE as
tunnel signaling protocol. The PEs use BGP to exchange VPN prefixes
and VPN labels between each other.
Yimin Shen & Minto JeyanaExpires August 20, 2016 [Page 12]
Internet-Draft MPLS Egress Protection Framework February 2016
Using the framework in this document, the network assigns PE3 to be a
protector for PE2 to protect the VPN traffic in the direction from
site 1 to site 2. Hence, PE2 and PE3 form a protected egress {PE2,
PE3}. A context ID 1.1.1.1 is assigned to the protected egress. On
PE3, a context label 100 is assigned to the context ID, and a label
table pe2.mpls is created to represent PE2's label space. PE3
installs the label 100 in its default MPLS forwarding table, with
nexthop pointing to the label table pe2.mpls. PE2 and PE3 are
coordinated to use the proxy mode to advertise the context ID in
routing domain and TE domain.
PE2 uses per-VRF VPN label allocation mode. In particular, it
assigns a single label 9000 for the VRF of the VPN. For a given VPN
prefix 9.0.0.0/8 in site 2, PE2 advertises it along with the label
9000 and other attributes (including route targets and route
distinguisher) to PE1 and PE3 via BGP. In particular, PE2 sets the
NEXT_HOP attribute to the context ID 1.1.1.1.
Upon receipt of the BGP advertisement, PE1 uses the context ID
1.1.1.1 as destination to compute a TE path for an egress-protected
tunnel. The resulted path is PE1->R1->PE2. PE1 then uses RSVP to
signal the tunnel, with the context ID 1.1.1.1 as destination, and
with the "node protection desired" flag set in the SESSION_ATTRIBUTE
of RSVP Path message. Once the tunnel comes up, PE1 maps the VPN
prefix 9.0.0.0/8 to the tunnel and installs a route for the prefix in
the corresponding VRF. The route's nexthop is a push of the VPN
label 9000, followed by a push of the out-label of the egress-
protected tunnel.
Upon receipt of the above BGP advertisement from PE2, PE3 (i.e. the
protector) installs a route for label 9000 in the label table
pe2.mpls, based on the context ID 1.1.1.1 in the NEXT_HOP attribute.
The route's nexthop points to PE3's VRF of the VPN.
R1, i.e. the penultimate hop router of the egress-protected tunnel,
acts as PLR. Based on the "node protection desired" flag and the
destination address (i.e. context ID 1.1.1.1) of the tunnel, R1
computes a bypass path to 1.1.1.1 while avoiding PE2. The resulted
bypass path is R1->R2->PE3. R1 then signals the path as an egress-
protection bypass tunnel, with 1.1.1.1 as destination.
Upon receipt of RSVP Path message of the egress-protection bypass
tunnel, PE3 recognizes the context ID 1.1.1.1 as the destination, and
hence responds with the context label 100 in RSVP Resv message.
Once the egress-protection bypass tunnel comes up, R1 installs a
bypass nexthop for the egress-protected tunnel. The bypass nexthop
Yimin Shen & Minto JeyanaExpires August 20, 2016 [Page 13]
Internet-Draft MPLS Egress Protection Framework February 2016
is a swap from the in-label of the egress-protected tunnel to the
out-label of the egress-protection bypass tunnel.
When R1 detects a failure of PE2, it will invoke the above bypass
nexthop to reroute VPN service packets. The packets will have the
label of the bypass tunnel as outer label, and the VPN label 9000 as
inner label. When the packets arrive at PE3, they will have the
context label 100 as outer label, and the VPN label 9000 as inner
label. The context label will first be popped, and then the VPN
label will be looked up in the label table pe2.mpls. The lookup will
cause the VPN label to be popped, and the IP packets will finally be
forwarded to site 2 based on PE3's VRF of the VPN.
Eventually, global repair will kick in, as control plane protocols
converge on the new topology. PE1 will choose PE3 as new entrance to
site 2. Before that happens, the VPN traffic has been protected by
the above local repair.
8. IANA Considerations
This document does not require any new IANA allocation.
9. Security Considerations
This document does not introduce any security issues.
Note that the framework requires a label distribution protocol to run
between an egress router and a protector, which is achievable in a
secured fashion.
10. Acknowledgements
This document leverages work done by Hannes Gredler, Yakov Rekhter,
Kevin Wang and several on MPLS egress protection.
11. References
11.1. Normative References
[RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed.,
"LDP Specification", RFC 5036, DOI 10.17487/RFC5036,
October 2007, <http://www.rfc-editor.org/info/rfc5036>.
[RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, DOI 10.17487/RFC2205,
September 1997, <http://www.rfc-editor.org/info/rfc2205>.
Yimin Shen & Minto JeyanaExpires August 20, 2016 [Page 14]
Internet-Draft MPLS Egress Protection Framework February 2016
[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>.
[RFC5286] Atlas, A., Ed. and A. Zinin, Ed., "Basic Specification for
IP Fast Reroute: Loop-Free Alternates", RFC 5286,
DOI 10.17487/RFC5286, September 2008,
<http://www.rfc-editor.org/info/rfc5286>.
[RFC5714] Shand, M. and S. Bryant, "IP Fast Reroute Framework",
RFC 5714, DOI 10.17487/RFC5714, January 2010,
<http://www.rfc-editor.org/info/rfc5714>.
[RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream
Label Assignment and Context-Specific Label Space",
RFC 5331, DOI 10.17487/RFC5331, August 2008,
<http://www.rfc-editor.org/info/rfc5331>.
[RFC6389] Aggarwal, R. and JL. Le Roux, "MPLS Upstream Label
Assignment for LDP", RFC 6389, DOI 10.17487/RFC6389,
November 2011, <http://www.rfc-editor.org/info/rfc6389>.
[SEGMENT-ROUTING-MPLS]
Filsfils, C., Previdi, S., and S. Previdi, "Segment
routing with MPLS data plane", draft-ietf-spring-segment-
routing-mpls (work in progress), 2016.
[IP-LDP-FRR-MRT]
Atlas, A., Bowers, C., and G. Enyedi, "An Architecture for
IP/LDP Fast-Reroute Using Maximally Redundant Trees",
draft-ietf-rtgwg-mrt-frr-architecture (work in progress),
2016.
11.2. Informative References
[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>.
Yimin Shen & Minto JeyanaExpires August 20, 2016 [Page 15]
Internet-Draft MPLS Egress Protection Framework February 2016
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS
Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010,
<http://www.rfc-editor.org/info/rfc5920>.
Authors' Addresses
Yimin Shen
Juniper Networks
10 Technology Park Drive
Westford, MA 01886
USA
Phone: +1 9785890722
Email: yshen@juniper.net
Minto Jeyananth
Juniper Networks
1133 Innovation Way
Sunnyvale, CA 94089
USA
Phone: +1 4089367563
Email: minto@juniper.net
Yimin Shen & Minto JeyanaExpires August 20, 2016 [Page 16]