Internet Engineering Task Force Yimin Shen
Internet-Draft Minto Jeyananth
Intended status: Informational Juniper Networks
Expires: August 28, 2016 February 25, 2016
MPLS Egress Protection Framework
draft-shen-mpls-egress-protection-framework-01
Abstract
This document specifies a fast reroute framework for protecting MPLS
tunnels and IP/MPLS services 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 28, 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 28, 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 . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 6
5.1. Egress failure . . . . . . . . . . . . . . . . . . . . . 6
5.2. Protector and PLR . . . . . . . . . . . . . . . . . . . . 6
5.3. Protected egress . . . . . . . . . . . . . . . . . . . . 7
5.4. Egress-protected tunnel . . . . . . . . . . . . . . . . . 7
5.5. Egress-protected service . . . . . . . . . . . . . . . . 7
5.6. Egress-protected service to egress-protected tunnel
mapping . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.7. Egress-protection bypass tunnel . . . . . . . . . . . . . 8
5.8. Context ID, context label, and context based forwarding . 8
5.9. IGP advertisement and path computation for context ID . . 10
5.10. Egress-protection bypass tunnel establishment . . . . . . 11
5.11. Local Repair on PLR . . . . . . . . . . . . . . . . . . . 11
5.12. Label distribution from egress router to protector . . . 12
6. Global repair . . . . . . . . . . . . . . . . . . . . . . . . 12
7. Example: Layer-3 VPN egress protection . . . . . . . . . . . 12
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
9. Security Considerations . . . . . . . . . . . . . . . . . . . 15
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
11.1. Normative References . . . . . . . . . . . . . . . . . . 15
11.2. Informative References . . . . . . . . . . . . . . . . . 16
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. In
general, a single tunnel may carry multiple services of one or
multiple types, given that these services have corresponding service
instances on the tunnel's egress router. An MPLS service instance
forwards service packets to service destination based on service
label. An IP service instance forwards service packets to service
destination based on IP header.
Yimin Shen & Minto JeyanaExpires August 28, 2016 [Page 2]
Internet-Draft MPLS Egress Protection Framework February 2016
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
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
hosts some backup service instances and has its own connectivity to
service destinations. It performs context label switching for
rerouted MPLS service packets based on service labels assigned by the
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 for not being able to reach the egress router, and a failure
of the services carried by the tunnel for not being able to reach the
service instances on the egress router. Hence, it addresses
protection at both tunnel level and service level.
This framework requires that the destination (a CE or site) of a
service must be dual-homed or have dual paths to the MPLS network,
normally via two LERs (label edge routers), one of which is the
egress router of the service's transport tunnel.
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
Yimin Shen & Minto JeyanaExpires August 28, 2016 [Page 3]
Internet-Draft MPLS Egress Protection Framework February 2016
protection establishment and context label switching. This document
provides guidelines for these extensions, but the details should be
addressed in separate documents.
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 is protected by using this
egress protection framework.
Egress-protected service - An IP or MPLS service that is protected by
using this egress protection framework.
Protector - A router that acts as a backup router for the egress
router of an egress-protected tunnel, and hosts backup service
instances for the egress-protected services carried by the tunnel.
PLR - A router at point of local repair, which is the penultimate hop
router on an egress-protected tunnel.
Protected egress {E, P} - A virtual node consisting of an ordered
pair of egress router E and protector P. It serves as the virtual
destination for an egress-protected tunnel. It also serves as the
virtual location of service instances for the services carried by the
tunnel.
Context identifier (ID) - A globally unique IP address assigned to a
protected egress {E, P}.
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.
Backup service instance - A service instance hosted by the protector
of an egress-protected service, as a backup for the corresponding
service instance on the egress router.
Yimin Shen & Minto JeyanaExpires August 28, 2016 [Page 4]
Internet-Draft MPLS Egress Protection Framework February 2016
Context label switching - Label switching performed by a protector,
in the label space indicated by a context label.
Context IP forwarding - IP forwarding performed by a protector, in
the IP forwarding table indicated by a context label.
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.
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 existing and future 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 an 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.
o The framework must be able to work in conjunction with global
repair (aka. end-to-end repair) and control plane convergence.
Yimin Shen & Minto JeyanaExpires August 28, 2016 [Page 5]
Internet-Draft MPLS Egress Protection Framework February 2016
5. Theory of Operation
5.1. Egress failure
An egress failure refers to the node failure of a tunnel's egress
router. It also means a service instance failure for each service
carried by the tunnel.
Failure detection mechanisms that are used by PLRs in transit link
and node protection are applicable to egress failure detection. In a
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 and the services carried by
the tunnel against egress failure. This router is called a
protector. It hosts a backup service instance for each of the
services.
A tunnel can be protected by only one protector, while a protector
may protect multiple tunnels to one or different 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 (particularly the backup
service instances) in turn forwards the service packets towards the
ultimate service destinations. 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 must have its own
connectivity with the service destinations, which is not affected by
the egress failure. This requires that the service destinations must
be dual-homed or have dual paths to the egress router and the
protector.
Yimin Shen & Minto JeyanaExpires August 28, 2016 [Page 6]
Internet-Draft MPLS Egress Protection Framework February 2016
5.3. Protected egress
This document introduces the notion of "protected egress" as a
virtual node consisting of the egress router E of a tunnel and a
protector P. It is denoted by an ordered pair of {E, P}. It
represents the relationship between the two routers in the egress
protection schema. It serves as the virtual destination for a
tunnel, and the virtual location of service instances for the
services carried by the tunnel. The tunnel and services are
considered as being "associated" with the protected egress {E, P}.
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 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}.
Two node X and Y may be protectors for each other's tunnels. In this
case, they form two distinct protected egress {X, Y} and {Y, X}.
For egress protection, 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.
An 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.
An 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
Yimin Shen & Minto JeyanaExpires August 28, 2016 [Page 7]
Internet-Draft MPLS Egress Protection Framework February 2016
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 {E, P}, as described in (Section 5.8).
5.7. Egress-protection bypass tunnel
An egress-protected tunnel destined for a protected egress {E, P}
must have a bypass tunnel from its PLR to the protector P. This
bypass tunnel is called an egress-protection bypass tunnel. An
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.
An egress-protection bypass tunnel MUST have 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 {E, P}. 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 logically 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, particularly the egress
router's forwarding context. 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).
Yimin Shen & Minto JeyanaExpires August 28, 2016 [Page 8]
Internet-Draft MPLS Egress Protection Framework February 2016
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 E distributes the label
binding message of the service to the ingress router, E attaches
the context ID to the message. If the service is an IP service,
when E advertises the service destination address to the ingress
router, E 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 involved protocols, and may need protocol
extensions.
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 an IGP or topology-driven label
distribution protocol. The PLR uses the context ID as destination
to establish or resolve an egress-protection bypass tunnel to P.
Due to the context ID's reachability via P, the PLR can achieve
this without the knowledge of egress protection schema.
o P maintains a dedicated label space or a dedicated IP address
space for E, depending on whether the service is MPLS or IP. It
is referred to as E's label space or E's IP address space,
respectively. P uses the context ID to identify the space.
o If the service is an MPLS service, E uses a label distribution
protocol to advertise the label binding of the service to P. This
is the same label binding that E advertises to the ingress router,
attached with the context ID. Based on the context ID, P installs
a label route in E's label space. If the service is an IP
service, P installs an IP route in E's IP address space. In
either case, the corresponding backup service instance on P
constructs a nexthop for the route based on P's connectivity to
the service's destination.
o P assigns a non-reserved label to the context ID. In the data
plane, this label serves in the context ID's stead to indicate E's
label space and IP address space. Therefore, it is called a
"context label".
o P binds the context label to the egress-protection bypass tunnel,
based on the bypass tunnel's destination. During local repair,
all the service packets received on the bypass tunnel will have
the context label as top label. P will first pop the context
Yimin Shen & Minto JeyanaExpires August 28, 2016 [Page 9]
Internet-Draft MPLS Egress Protection Framework February 2016
label. For MPLS service packets, P will further look up the
service label in E's label space indicated by the context label.
This is called context label switching. For IP service packets, P
will look up the IP destination address in E's IP address space
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 {E, P} and its context ID, coordination must
be done between E and P 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 E as tailend, and all the egress-
protection bypass tunnels destined for the context ID MUST be
established with P as tailend, while avoiding E.
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. E and P advertise the context ID as a virtual
proxy node connected to the two routers, with the link between
the proxy node and E having more preferable IGP and TE metrics
than the link between the proxy node and P. Therefore, all
egress-protected tunnels destined for the context ID should
automatically follow shortest IGP paths or TE paths to E. Each
PLR will no longer view itself as a penultimate hop, but rather
two hops away from the proxy node, via E. The PLR will be able
to find a bypass path via P to the proxy node, while the bypass
tunnel should actually be terminated by P.
2. The second approach is called "alias mode". It requires a PLR to
have knowledge of the egress protection schema. E advertises the
context ID as a regular IP address. P 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 E. This ensures that all egress-protected tunnel
destined for the context ID are terminated by E. Based on the
"context ID label binding" advertisement, the PLR may 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 P. The PLR may also establish the egress-
protection bypass tunnel by using segment routing, with the
context label as the inner-most label in label stack. The
"context ID label binding" object may require IGP extensions, or
Yimin Shen & Minto JeyanaExpires August 28, 2016 [Page 10]
Internet-Draft MPLS Egress Protection Framework February 2016
in a network with segment routing, use the mechanism described in
[SPRING-ADV-LSP].
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.
[3] It may be constructed by segment routing. In this case, the
protector uses the alias mode (Section 5.9) to advertise the context
ID and context label binding via an IGP. The PLR can then construct
the bypass tunnel as a stack of labels, 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. For MPLS service packets, it 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 stack of labels of a regular bypass tunnel.
Yimin Shen & Minto JeyanaExpires August 28, 2016 [Page 11]
Internet-Draft MPLS Egress Protection Framework February 2016
Keeping service labels intact in MPSL service 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
When receiving a rerouted MPLS service packet, a protector performs
context label switching for a service label assigned by an egress
router. From the protector's perspective, this service label is an
"upstream assigned" service label. The protector maintains such kind
of service labels in dedicated label spaces on a per protected egress
{E, P} 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 binding of each egress-protected MPLS
service. This is the same label binding that the egress router
advertises to ingress router, attached with a context ID. A backup
service instance on the protector recognizes the service FEC, and
resolves forwarding state based on its own connectivity to the
service's destination. It installs the service label with the
forwarding state in the label space of the egress router, as
indicated by the context ID.
Protocol extensions may be needed for the upstream label distribution
between egress router and protector.
6. Global repair
The framework in this document provides fast but temporary repair for
traffic upon an egress failure. For permanent repair, it is
RECOMMENDED that the traffic SHOULD be moved to an alternative tunnel
or alternative services that are fully functional. This is referred
to as global repair. Possible triggers of global repair include
control plane notifications for tunnel and service status, OAM at
tunnel and service levels, traffic marking in the reverse direction,
etc. These alternative tunnel and services may be pre-established
backups, or newly established as a result of the triggers or network
protocol convergence.
7. Example: Layer-3 VPN egress protection
This section shows an example of egress protection for a layer-3 VPN.
Yimin Shen & Minto JeyanaExpires August 28, 2016 [Page 12]
Internet-Draft MPLS Egress Protection Framework February 2016
---------- 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. Every PE hosts a VPN instance. R1 and
R2 are transit routers in 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.
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 {PE2,
PE3}. The VPN instance on PE3 serves as a backup for the VPN instance
on PE2. 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
Yimin Shen & Minto JeyanaExpires August 28, 2016 [Page 13]
Internet-Draft MPLS Egress Protection Framework February 2016
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 VPN instance points the route's nexthop to the local 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
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 the local 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 has no request for new IANA allocation.
Yimin Shen & Minto JeyanaExpires August 28, 2016 [Page 14]
Internet-Draft MPLS Egress Protection Framework February 2016
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>.
[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>.
Yimin Shen & Minto JeyanaExpires August 28, 2016 [Page 15]
Internet-Draft MPLS Egress Protection Framework February 2016
[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.
[SPRING-ADV-LSP]
Bowers, C., Gredler, H., and U. Chunduri, "Advertising
LSPs with Segment Routing", draft-bowers-spring-adv-lsps-
with-sr (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>.
[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
Yimin Shen & Minto JeyanaExpires August 28, 2016 [Page 16]
Internet-Draft MPLS Egress Protection Framework February 2016
Minto Jeyananth
Juniper Networks
1133 Innovation Way
Sunnyvale, CA 94089
USA
Phone: +1 4089367563
Email: minto@juniper.net
Yimin Shen & Minto JeyanaExpires August 28, 2016 [Page 17]