draft-ietf-mpls-egress-protection-framework-04.txt   draft-ietf-mpls-egress-protection-framework-05.txt 
Internet Engineering Task Force Yimin Shen Internet Engineering Task Force Yimin Shen
Internet-Draft Minto Jeyananth Internet-Draft Minto Jeyananth
Intended status: Standards Track Juniper Networks Intended status: Standards Track Juniper Networks
Expires: July 6, 2019 Bruno Decraene Expires: November 29, 2019 Bruno Decraene
Orange Orange
Hannes Gredler Hannes Gredler
RtBrick Inc RtBrick Inc
Carsten Michel Carsten Michel
Deutsche Telekom Deutsche Telekom
Huaimo Chen Huaimo Chen
Yuanlong Jiang
Huawei Technologies Co., Ltd. Huawei Technologies Co., Ltd.
January 2, 2019 May 28, 2019
MPLS Egress Protection Framework MPLS Egress Protection Framework
draft-ietf-mpls-egress-protection-framework-04 draft-ietf-mpls-egress-protection-framework-05
Abstract Abstract
This document specifies a fast reroute framework for protecting IP/ This document specifies a fast reroute framework for protecting IP/
MPLS services and MPLS transport tunnels against egress node and MPLS services and MPLS transport tunnels against egress node and
egress link failures. In this framework, the penultimate-hop router egress link failures. For each type of egress failure, it defines
of an MPLS tunnel acts as the point of local repair (PLR) for an the roles of point of local repair (PLR), protector, and backup
egress node failure, and the egress router of the MPLS tunnel acts as egress router, and the procedures of establishing a bypass tunnel
the PLR for an egress link failure. Each of them pre-establishes a from a PLR to a protector. It describes the behaviors of these
bypass tunnel to a protector. Upon an egress node or link failure, routers in handling an egress failure, including local repair on the
the corresponding PLR performs local failure detection and local PLR, and context based forwarding on the protector. The framework
repair, by rerouting packets over the corresponding bypass tunnel. can be used to develop egress protection mechanisms to reduce traffic
The protector in turn performs context label switching or context IP loss before global repair reacts to an egress failure and control
forwarding to send the packets to the ultimate service plane protocols converge on the topology changes due to the egress
destination(s). This mechanism can be used to reduce traffic loss failure.
before global repair reacts to the failure and control plane
protocols converge on the topology changes due to the failure. The
framework is applicable to all types of IP/MPLS services and MPLS
tunnels. Under the framework, service protocol extensions may be
further specified to support service label distribution from an
egress router to a protector.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 6, 2019. This Internet-Draft will expire on November 29, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 35 skipping to change at page 2, line 28
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Specification of Requirements . . . . . . . . . . . . . . . . 5 2. Specification of Requirements . . . . . . . . . . . . . . . . 5
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 7
5. Egress node protection . . . . . . . . . . . . . . . . . . . 8 5. Egress node protection . . . . . . . . . . . . . . . . . . . 8
5.1. Reference topology . . . . . . . . . . . . . . . . . . . 8 5.1. Reference topology . . . . . . . . . . . . . . . . . . . 8
5.2. Egress node failure and detection . . . . . . . . . . . . 9 5.2. Egress node failure and detection . . . . . . . . . . . . 8
5.3. Protector and PLR . . . . . . . . . . . . . . . . . . . . 9 5.3. Protector and PLR . . . . . . . . . . . . . . . . . . . . 9
5.4. Protected egress . . . . . . . . . . . . . . . . . . . . 10 5.4. Protected egress . . . . . . . . . . . . . . . . . . . . 10
5.5. Egress-protected tunnel and service . . . . . . . . . . . 11 5.5. Egress-protected tunnel and service . . . . . . . . . . . 10
5.6. Egress-protection bypass tunnel . . . . . . . . . . . . . 11 5.6. Egress-protection bypass tunnel . . . . . . . . . . . . . 11
5.7. Context ID, context label, and context based forwarding . 12 5.7. Context ID, context label, and context based forwarding . 11
5.8. Advertisement and path resolution for context ID . . . . 14 5.8. Advertisement and path resolution for context ID . . . . 13
5.9. Egress-protection bypass tunnel establishment . . . . . . 15 5.9. Egress-protection bypass tunnel establishment . . . . . . 15
5.10. Local repair on PLR . . . . . . . . . . . . . . . . . . . 16 5.10. Local repair on PLR . . . . . . . . . . . . . . . . . . . 15
5.11. Service label distribution from egress router to 5.11. Service label distribution from egress router to
protector . . . . . . . . . . . . . . . . . . . . . . . . 16 protector . . . . . . . . . . . . . . . . . . . . . . . . 16
5.12. Centralized protector mode . . . . . . . . . . . . . . . 17 5.12. Centralized protector mode . . . . . . . . . . . . . . . 17
6. Egress link protection . . . . . . . . . . . . . . . . . . . 19 6. Egress link protection . . . . . . . . . . . . . . . . . . . 18
7. Global repair . . . . . . . . . . . . . . . . . . . . . . . . 22 7. Global repair . . . . . . . . . . . . . . . . . . . . . . . . 21
8. General context-based forwarding . . . . . . . . . . . . . . 22 8. General context-based forwarding . . . . . . . . . . . . . . 21
9. Example: Layer-3 VPN egress protection . . . . . . . . . . . 23 9. Example: Layer-3 VPN egress protection . . . . . . . . . . . 22
9.1. Egress node protection . . . . . . . . . . . . . . . . . 24 9.1. Egress node protection . . . . . . . . . . . . . . . . . 23
9.2. Egress link protection . . . . . . . . . . . . . . . . . 25 9.2. Egress link protection . . . . . . . . . . . . . . . . . 24
9.3. Global repair . . . . . . . . . . . . . . . . . . . . . . 25 9.3. Global repair . . . . . . . . . . . . . . . . . . . . . . 24
9.4. Other modes of VPN label allocation . . . . . . . . . . . 25 9.4. Other modes of VPN label allocation . . . . . . . . . . . 24
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
11. Security Considerations . . . . . . . . . . . . . . . . . . . 26 11. Security Considerations . . . . . . . . . . . . . . . . . . . 25
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 26
13.1. Normative References . . . . . . . . . . . . . . . . . . 26 13.1. Normative References . . . . . . . . . . . . . . . . . . 26
13.2. Informative References . . . . . . . . . . . . . . . . . 27 13.2. Informative References . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27
1. Introduction 1. Introduction
In MPLS networks, label switched paths (LSPs) are widely used as In MPLS networks, label switched paths (LSPs) are widely used as
transport tunnels to carry IP and MPLS services across MPLS domains. transport tunnels to carry IP and MPLS services across MPLS domains.
Examples of MPLS services are layer-2 VPNs, layer-3 VPNs, Examples of MPLS services are layer-2 VPNs, layer-3 VPNs,
hierarchical LSPs, and others. In general, a tunnel may carry hierarchical LSPs, and others. In general, a tunnel may carry
multiple services of one or multiple types, if the tunnel can satisfy multiple services of one or multiple types, if the tunnel satisfies
both individual and aggregate requirements (e.g. CoS, QoS) of these both individual and aggregate requirements (e.g. CoS, QoS) of these
services. The egress router of the tunnel hosts the service services. The egress router of the tunnel hosts the service
instances of the services. Each MPLS service instance is responsible instances of the services. An MPLS service instance forwards service
for forwarding service packets via an egress link to the service packets via an egress link to the service destination, based on a
destination, based on a service label. Each IP service instance is service label. An IP service instance does the same based on a
responsible for doing the same based on a service IP address. The service IP address. The egress link is often called a PE-CE
egress link is often called a PE-CE (provider edge - customer edge) (provider edge - customer edge) link or attachment circuit (AC).
link or attachment circuit (AC).
Today, local repair based fast reroute mechanisms [RFC4090], Today, local repair based fast reroute mechanisms [RFC4090],
[RFC5286], [RFC7490], [RFC7812] have been widely deployed to protect [RFC5286], [RFC7490], [RFC7812] have been widely deployed to protect
MPLS tunnels against transit link/node failures, with traffic MPLS tunnels against transit link/node failures, with traffic
restoration time in the order of tens of milliseconds. Local repair restoration time in the order of tens of milliseconds. Local repair
refers to the scenario where the router upstream to an anticipated refers to the scenario where the router upstream to an anticipated
failure (aka. PLR, i.e. point of local repair) pre-establishes a failure (aka. PLR, i.e. point of local repair) pre-establishes a
bypass tunnel to the router downstream of the failure (aka. MP, i.e. bypass tunnel to the router downstream of the failure (aka. MP, i.e.
merge point), pre-installs the forwarding state of the bypass tunnel merge point), pre-installs the forwarding state of the bypass tunnel
in the data plane, and uses a rapid mechanism (e.g. link layer OAM, in the data plane, and uses a rapid mechanism (e.g. link layer OAM,
BFD, and others) to locally detect the failure in the data plane. BFD, and others) to locally detect the failure in the data plane.
When the failure occurs, the PLR reroutes traffic through the bypass When the failure occurs, the PLR reroutes traffic through the bypass
tunnel to the MP, allowing the traffic to continue to flow to the tunnel to the MP, allowing the traffic to continue to flow to the
tunnel's egress router. tunnel's egress router.
This document describes a fast reroute framework for egress node and This document specifies a fast reroute framework for egress node and
egress link protection. Similar to transit link/node protection, egress link protection. Similar to transit link/node protection,
this framework also relies on a PLR to perform local failure this framework also relies on a PLR to perform local failure
detection and local repair. In egress node protection, the PLR is detection and local repair. In egress node protection, the PLR is
the penultimate-hop router of a tunnel. In egress link protection, the penultimate-hop router of a tunnel. In egress link protection,
the PLR is the egress router of the tunnel. The framework further the PLR is the egress router of the tunnel. The framework further
relies on a so-called "protector" to serve as the tailend of a bypass uses a so-called "protector" to serve as the tailend of a bypass
tunnel. The protector is a router that hosts "protection service tunnel. The protector is a router that hosts "protection service
instances" and has its own connectivity or paths to service instances" and has its own connectivity or paths to service
destinations. When a PLR does local repair, the protector is destinations. When a PLR does local repair, the protector performs
responsible for performing "context label switching" for rerouted "context label switching" for rerouted MPLS service packets and
MPLS service packets and "context IP forwarding" for rerouted IP "context IP forwarding" for rerouted IP service packets, to allow the
service packets, to allow the service packets to continue to reach service packets to continue to reach the service destinations.
the service destinations.
This framework considers an egress node failure as a failure of a This framework considers an egress node failure as a failure of a
tunnel, as well as a failure of all the services carried by the tunnel, and a failure of all the services carried by the tunnel, as
tunnel, because service packets can no longer reach the service service packets can no longer reach the service instances on the
instances on the egress router. Therefore, the framework addresses egress router. Therefore, the framework addresses egress node
egress node protection at both tunnel level and service level protection at both tunnel level and service level simultaneously.
simultaneously. Likewise, the framework considers an egress link Likewise, the framework considers an egress link failure as a failure
failure as a failure of all the services traversing the link, and of all the services traversing the link, and addresses egress link
addresses egress link protection at the service level. protection at the service level.
This framework requires that the destination (a CE or site) of a This framework requires that the destination (a CE or site) of a
service MUST be dual-homed or have dual paths to an MPLS network, via service MUST be dual-homed or have dual paths to an MPLS network, via
two MPLS edge routers. One of the routers is the egress router of two MPLS edge routers. One of the routers is the egress router of
the service's transport tunnel, and the other is a backup egress the service's transport tunnel, and the other is a backup egress
router which hosts a "backup service instance". In the "co-located" router which hosts a "backup service instance". In the "co-located"
protector mode in this document, the backup egress router serves as protector mode in this document, the backup egress router serves as
the protector, and hence the backup service instance acts as the the protector, and hence the backup service instance acts as the
protection service instance. In the "centralized" protector mode protection service instance. In the "centralized" protector mode
(Section 5.12), the protector and the backup egress router are (Section 5.12), the protector and the backup egress router are
decoupled, and the protection service instance and the backup service decoupled, and the protection service instance and the backup service
instance are hosted separately by the two routers. instance are hosted separately by the two routers.
The framework is described by mainly referring to P2P (point-to- The framework is described by mainly referring to P2P (point-to-
point) tunnels. However, it is equally applicable to P2MP (point-to- point) tunnels. However, it is equally applicable to P2MP (point-to-
multipoint), MP2P (multipoint-to-point) and MP2MP (multipoint-to- multipoint), MP2P (multipoint-to-point) and MP2MP (multipoint-to-
multipoint) tunnels, if a sub-LSP can be viewed as a P2P tunnel. multipoint) tunnels, if the sub-LSPs of these tunnels can be viewed
as P2P tunnels.
The framework is a multi-service and multi-transport framework. It The framework is a multi-service and multi-transport framework. It
assumes a generic model where each service is comprised of a common assumes a generic model where each service is comprised of a common
set of components, including a service instance, a service label, and set of components, including a service instance, a service label, a
a service label distribution protocol, and the service is transported service label distribution protocol, and an MPLS transport tunnel.
over an MPLS tunnel of any type. The framework also assumes service The framework also assumes the service label to be downstream
labels to be downstream assigned, i.e. assigned by egress routers. assigned, i.e. assigned by an egress router. Therefore, the
Therefore, the framework is generally applicable to most existing and framework is generally applicable to most existing and future
future services. However, there are services with certain modes, services. However, there are services with certain modes, where a
where a protector is unable to pre-establish forwarding state for protector is unable to pre-establish forwarding state for egress
egress protection, or a PLR is prohibited from rerouting traffic to protection, or a PLR is not allowed to reroute traffic to other
any other router to avoid traffic duplication, e.g. the broadcast, routers in order to avoid traffic duplication, e.g. the broadcast,
multicast, and unknown unicast traffic in VPLS and EVPN. These cases multicast, and unknown unicast traffic in VPLS and EVPN. These cases
are left for future study. Services which use upstream-assigned are left for future study. Services which use upstream-assigned
service labels are also out of scope of this document and left for service labels are also out of scope of this document and left for
future study. future study.
The framework does not require extensions for the existing signaling The framework does not require extensions for the existing signaling
and label distribution protocols (e.g. RSVP, LDP, BGP, etc.) of MPLS and label distribution protocols (e.g. RSVP, LDP, BGP, etc.) of MPLS
tunnels. It expects transport tunnels and bypass tunnels to be tunnels. It assumes transport tunnels and bypass tunnels to be
established by using the generic mechanisms provided by the established by using the generic procedures provided by the
protocols. On the other hand, it does not preclude extensions to the protocols. On the other hand, it does not preclude extensions to the
protocols which may facilitate the procedures. One example of such protocols which may facilitate the procedures. One example of such
extension is [RFC8400]. The framework may need extensions for IGPs extension is [RFC8400]. The framework does see the need for
and service label distribution protocols, to support protection extensions of IGPs and service label distribution protocols in some
establishment and context label switching. This document provides procedures, particularly for supporting protection establishment and
guidelines for these extensions, but the specific details SHOULD be context label switching. This document provides guidelines for these
addressed in separate documents. extensions, but leaves the specific details to separate documents.
The framework is intended to complement control-plane convergence and The framework is intended to complement control-plane convergence and
global repair, which are traditionally used to recover networks from global repair. Control-plane convergence relies on control protocols
egress node and egress link failures. Control-plane convergence to react on the topology changes due to a failure. Global repair
relies on control protocols to react on the topology changes due to a relies an ingress router to remotely detect a failure and switch
failure. Global repair relies an ingress router to remotely detect a traffic to an alternative path. An example of global repair is the
failure and switch traffic to an alternative path. An example of BGP Prefix Independent Convergence mechanism [BGP-PIC] for BGP
global repair is the BGP Prefix Independent Convergence mechanism established services. Compared with these mechanisms, this framework
[BGP-PIC] for BGP established services. Compared with these is considered as faster in traffic restoration, due to the nature of
mechanisms, this framework is considered as faster in traffic local failure detection and local repair. It is RECOMMENDED that the
restoration, due to the nature of local failure detection and local framework SHOULD be used in conjunction with control-plane
repair. However, it is RECOMMENDED that the framework SHOULD be used convergence or global repair, in order to take the advantages of both
in conjunction with control-plane convergence or global repair, in approaches. That is, the framework provides fast and temporary
order to take the advantages of both approaches. That is, the repair, while control-plane convergence or global repair provides
framework provides fast and temporary repair, and control-plane ultimate and permanent repair.
convergence or global repair provides ultimate and permanent repair.
2. Specification of Requirements 2. Specification of Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119] and document are to be interpreted as described in [RFC2119] and
[RFC8174]. [RFC8174].
3. Terminology 3. Terminology
skipping to change at page 6, line 24 skipping to change at page 6, line 16
egress router, this is another router which has connectivity with all egress router, this is another router which has connectivity with all
or a subset of the destinations of the egress-protected services or a subset of the destinations of the egress-protected services
carried by the egress-protected tunnel. carried by the egress-protected tunnel.
Backup service instance - A service instance which is hosted by a Backup service instance - A service instance which is hosted by a
backup egress router, and corresponding to an egress-protected backup egress router, and corresponding to an egress-protected
service on a protected egress router. service on a protected egress router.
Protector - A role acted by a router as an alternate of a protected Protector - A role acted by a router as an alternate of a protected
egress router, to handle service packets in the event of an egress egress router, to handle service packets in the event of an egress
failure. A protector may be physically co-located with or decoupled failure. A protector MAY be physically co-located with or decoupled
from a backup egress router, depending on the co-located or from a backup egress router, depending on the co-located or
centralized protector mode. centralized protector mode.
Protection service instance - A service instance hosted by a Protection service instance - A service instance hosted by a
protector, corresponding to the service instance of an egress- protector, corresponding to the service instance of an egress-
protected service on a protected egress router. A protection service protected service on a protected egress router. A protection service
instance is a backup service instance, if the protector is co-located instance is a backup service instance, if the protector is co-located
with a backup egress router. with a backup egress router.
PLR - A router at the point of local repair. In egress node PLR - A router at the point of local repair. In egress node
skipping to change at page 7, line 24 skipping to change at page 7, line 17
Context IP forwarding - IP forwarding performed by a protector, in Context IP forwarding - IP forwarding performed by a protector, in
the IP address space of an egress router indicated by a context the IP address space of an egress router indicated by a context
label. label.
4. Requirements 4. Requirements
This document considers the followings as the design requirements of This document considers the followings as the design requirements of
this egress protection framework. this egress protection framework.
o The framework must support P2P tunnels. It should equally support o The framework MUST support P2P tunnels. It SHOULD equally support
P2MP, MP2P and MP2MP tunnels, by treating each sub-LSP as a P2P P2MP, MP2P and MP2MP tunnels, by treating each sub-LSP as a P2P
tunnel. tunnel.
o The framework must support multi-service and multi-transport o The framework MUST support multi-service and multi-transport
networks. It must accommodate existing and future signaling and networks. It MUST accommodate existing and future signaling and
label-distribution protocols of tunnels and bypass tunnels, label-distribution protocols of tunnels and bypass tunnels,
including RSVP, LDP, BGP, IGP, segment routing, and others. It including RSVP, LDP, BGP, IGP, segment routing, and others. It
must also accommodate existing and future IP/MPLS services, MUST also accommodate existing and future IP/MPLS services,
including layer-2 VPNs, layer-3 VPNs, hierarchical LSP, and including layer-2 VPNs, layer-3 VPNs, hierarchical LSP, and
others. It must provide a general solution for environments where others. It MUST provide a general solution for networks where
different types of services and tunnels may co-exist. different types of services and tunnels co-exist.
o The framework must consider minimizing disruption during o The framework MUST consider minimizing disruption during
deployment. It should only involve routers close to egress, and deployment. It SHOULD only involve routers close to egress, and
be transparent to ingress routers and other transit routers. be transparent to ingress routers and other transit routers.
o In egress node protection, for scalability and performance o In egress node protection, for scalability and performance
reasons, a PLR must be agnostic to services and service labels, reasons, a PLR MUST be agnostic to services and service labels.
like PLRs in transit link/node protection. It must maintain It MUST maintain bypass tunnels and bypass forwarding state on a
bypass tunnels and bypass forwarding state on a per-transport- per-transport-tunnel basis, rather than per-service-destination or
tunnel basis, rather than per-service-destination or per-service- per-service-label basis. It SHOULD also support bypass tunnel
label basis. It should also support bypass tunnel sharing between sharing between transport tunnels.
transport tunnels.
o A PLR must be able to use its local visibility or information of o A PLR MUST be able to use its local visibility or information of
routing and/or TE topology to compute or resolve a path for a routing or TE topology to compute or resolve a path for a bypass
bypass tunnel. tunnel.
o A protector must be able to perform context label switching for o A protector MUST be able to perform context label switching for
rerouted MPLS service packets, based on service label(s) assigned rerouted MPLS service packets, based on service label(s) assigned
by an egress router. It must be able to perform context IP by an egress router. It MUST be able to perform context IP
forwarding for rerouted IP service packets, in the public or forwarding for rerouted IP service packets, in the public or
private IP address space used by an egress router. private IP address space used by an egress router.
o The framework must be able to work seamlessly with transit link/ o The framework MUST be able to work seamlessly with transit link/
node protection mechanisms to achieve end-to-end coverage. node protection mechanisms to achieve end-to-end coverage.
o The framework must be able to work in conjunction with global o The framework MUST be able to work in conjunction with global
repair and control plane convergence. repair and control plane convergence.
5. Egress node protection 5. Egress node protection
5.1. Reference topology 5.1. Reference topology
This document refers to the following topology when describing the This document refers to the following topology when describing the
procedures of egress node protection. procedures of egress node protection.
services 1, ..., N services 1, ..., N
skipping to change at page 9, line 8 skipping to change at page 8, line 43
protector protector
(protection (protection
service service
instances) instances)
Figure 1 Figure 1
5.2. Egress node failure and detection 5.2. Egress node failure and detection
An egress node failure refers to the failure of an MPLS tunnel's An egress node failure refers to the failure of an MPLS tunnel's
egress router. At the service level, it also means a service egress router. At the service level, it is also a service instance
instance failure for each IP/MPLS service carried by the tunnel. failure for each IP/MPLS service carried by the tunnel.
Ideally, an egress node failure can be detected by an adjacent router An egress node failure can be detected by an adjacent router (i.e.
(i.e. PLR in this framework) using a node liveness detection PLR in this framework) through a node liveness detection mechanism,
mechanism, or based on a collective failure of all the links to that or a mechanism based on a collective failure of all the links to that
node. However, the assumption is that the mechanisms SHOULD be node. The mechanisms SHOULD be reasonably fast, i.e. faster than
reasonably fast, i.e. faster than control plane failure detection and control plane failure detection and remote failure detection.
remote failure detection. Otherwise, local repair will not be able
to provide much benefit compared to control plane convergence or Otherwise, local repair will not be able to provide much benefit
global repair. In general, the speed, accuracy, and reliability of a compared to control plane convergence or global repair. In general,
mechanism are the key factors to decide its applicability in egress the speed, accuracy, and reliability of a failure detection mechanism
node protection. This document provides the following guidelines in are the key factors to decide its applicability in egress node
this regard. protection. This document provides the following guidelines in this
regard.
o If the PLR has a reasonably fast mechanism to detect and o If the PLR has a reasonably fast mechanism to detect and
differentiate a link failure (of the link between the PLR and the differentiate a link failure (of the link between the PLR and the
egress node) and an egress node failure, it SHOULD set up both egress node) and an egress node failure, it SHOULD set up both
link protection and egress node protection, and trigger one and link protection and egress node protection, and trigger one and
only one protection upon a corresponding failure. only one protection upon a corresponding failure.
o If the PLR has a fast mechanism to detect a link failure and an o If the PLR has a fast mechanism to detect a link failure and an
egress node failure, but cannot distinguish them; Or, if the PLR egress node failure, but cannot distinguish them; Or, if the PLR
has a fast mechanism to detect a link failure only, but not an has a fast mechanism to detect a link failure only, but not an
egress node failure, the PLR has two options: egress node failure, the PLR has two options:
1. It MAY set up link protection only, and leave the egress node 1. It MAY set up link protection only, and leave the egress node
failure to global repair and control plane convergence to failure to be handled by global repair and control plane
handle. convergence.
2. It MAY set up egress node protection only, and treat a link 2. It MAY set up egress node protection only, and treat a link
failure as a trigger for the egress node protection. However, failure as a trigger for the egress node protection. The
the assumption is that treating a link failure as an egress assumption is that treating a link failure as an egress node
node failure MUST NOT have a negative impact on services. failure MUST NOT have a negative impact on services.
Otherwise, it SHOULD adopt the previous option. Otherwise, it SHOULD adopt the previous option.
5.3. Protector and PLR 5.3. Protector and PLR
A router is assigned to the "protector" role to protect a tunnel and A router is assigned to the "protector" role to protect a tunnel and
the services carried by the tunnel against an egress node failure. the services carried by the tunnel against an egress node failure.
The protector is responsible for hosting a protection service The protector is responsible for hosting a protection service
instance for each protected service, serving as the tailend of a instance for each protected service, serving as the tailend of a
bypass tunnel, and performing context label switching and/or context bypass tunnel, and performing context label switching and/or context
IP forwarding for rerouted service packets. IP forwarding for rerouted service packets.
A tunnel can be protected by only one protector at a given time. A tunnel is protected by only one protector. Multiple tunnels to a
Multiple tunnels to a given egress router may be protected by a given egress router MAY be protected by a common protector or
common protector or different protectors. A protector may protect different protectors. A protector MAY protect multiple tunnels with
multiple tunnels with a common egress router or different egress a common egress router or different egress routers.
routers.
For each tunnel, its penultimate-hop router acts as a PLR. The PLR For each tunnel, its penultimate-hop router acts as a PLR. The PLR
pre-establishes a bypass tunnel to the protector, and pre-installs pre-establishes a bypass tunnel to the protector, and pre-installs
bypass forwarding state in the data plane. Upon detection of an bypass forwarding state in the data plane. Upon detection of an
egress node failure, the PLR reroutes all the service packets egress node failure, the PLR reroutes all the service packets
received on the tunnel though the bypass tunnel to the protector. received on the tunnel though the bypass tunnel to the protector.
For MPLS service packets, the PLR keeps service labels intact in the For MPLS service packets, the PLR keeps service labels intact in the
packets. The protector in turn forwards the rerouted service packets packets. The protector in turn forwards the service packets towards
towards the ultimate service destinations. Specifically, it performs the ultimate service destinations. Specifically, it performs context
context label switching for MPLS service packets, based on the label switching for MPLS service packets, based on the service labels
service labels which are assigned by the protected egress router; It assigned by the protected egress router; It performs context IP
performs context IP forwarding for IP service packets, based on their forwarding for IP service packets, based on their destination
destination addresses. addresses.
The protector MUST have its own connectivity with each service The protector MUST have its own connectivity with each service
destination, via a direct link or a multi-hop path, which MUST NOT destination, via a direct link or a multi-hop path, which MUST NOT
traverse the protected egress router or be affected by the egress traverse the protected egress router or be affected by the egress
node failure. This also requires that each service destination MUST node failure. This also means that each service destination MUST be
be dual-homed or have dual paths to the egress router and a backup dual-homed or have dual paths to the egress router and a backup
egress router which serves as the protector. Each protection service egress router which serves as the protector. Each protection service
instance on the protector relies on such connectivity to set up instance on the protector relies on such connectivity to set up
forwarding state for context label switching and context IP forwarding state for context label switching and context IP
forwarding. forwarding.
5.4. Protected egress 5.4. Protected egress
This document introduces the notion of "protected egress" as a This document introduces the notion of "protected egress" as a
virtual node consisting of the egress router E of a tunnel and 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}, indicating protector P. It is denoted by an ordered pair of {E, P}, indicating
the primary-and-protector relationship between the two routers. It the primary-and-protector relationship between the two routers. It
serves as the virtual destination of the tunnel, and the virtual serves as the virtual destination of the tunnel, and the virtual
location of service instances for the services carried by the tunnel. location of service instances for the services carried by the tunnel.
Hence, the tunnel and services are considered as being "associated" The tunnel and services are considered as being "associated" with the
with the protected egress {E, P}. protected egress {E, P}.
A given egress router E may be the tailend of multiple tunnels. In A given egress router E MAY be the tailend of multiple tunnels. In
general, the tunnels may be protected by multiple protectors, e.g. general, the tunnels MAY be protected by multiple protectors, e.g.
P1, P2, and so on, with each Pi protecting a subset of the tunnels. P1, P2, and so on, with each Pi protecting a subset of the tunnels.
Thus, these routers form multiple protected egresses, i.e. {E, P1} , Thus, these routers form multiple protected egresses, i.e. {E, P1} ,
{E, P2}, and so on. Each tunnel is associated with one and only one {E, P2}, and so on. Each tunnel is associated with one and only one
protected egress {E, Pi}. All the services carried by the tunnel are protected egress {E, Pi}. All the services carried by the tunnel are
then automatically associated with the protected egress {E, Pi}. then automatically associated with the protected egress {E, Pi}.
Conversely, a service associated with a protected egress {E, Pi} MUST Conversely, a service associated with a protected egress {E, Pi} MUST
be carried by a tunnel associated with the protected egress {E, Pi}. be carried by a tunnel associated with the protected egress {E, Pi}.
This mapping MUST be ensured by the ingress router of the tunnel and This mapping MUST be ensured by the ingress router of the tunnel and
the service (Section 5.5). the service (Section 5.5).
Two routers X and Y may be protectors for each other. In this case, Two routers X and Y MAY be protectors for each other. In this case,
they form two distinct protected egresses {X, Y} and {Y, X}. they form two distinct protected egresses {X, Y} and {Y, X}.
5.5. Egress-protected tunnel and service 5.5. Egress-protected tunnel and service
A tunnel, which is associated with a protected egress {E, P}, is A tunnel, which is associated with a protected egress {E, P}, is
called an egress-protected tunnel. It is associated with one and called an egress-protected tunnel. It is associated with one and
only one protected egress {E, P}. Multiple egress-protected tunnels only one protected egress {E, P}. Multiple egress-protected tunnels
may be associated with a given protected egress {E, P}. In this case, MAY be associated with a given protected egress {E, P}. In this case,
they share the common egress router and protector, but may or may not they share the common egress router and protector, but MAY or MAY NOT
share a common ingress router, or a common PLR (i.e. penultimate-hop share a common ingress router, or a common PLR (i.e. penultimate-hop
router). router).
An egress-protected tunnel is considered as logically "destined" for An egress-protected tunnel is considered as logically "destined" for
its protected egress {E, P}. However, its path MUST be resolved and its protected egress {E, P}. Its path MUST be resolved and
established with E as the physical tailend. established with E as the physical tailend.
A service, which is associated with a protected egress {E, P}, is A service, which is associated with a protected egress {E, P}, is
called an egress-protected service. The egress router E hosts the called an egress-protected service. The egress router E hosts the
primary instance of the service, and the protector P hosts the primary instance of the service, and the protector P hosts the
protection instance of the service. protection instance of the service.
An egress-protected service is associated with one and only one An egress-protected service is associated with one and only one
protected egress {E, P}. Multiple egress-protected services may be protected egress {E, P}. Multiple egress-protected services MAY be
associated with a given protected egress {E, P}. In this case, these associated with a given protected egress {E, P}. In this case, these
services share the common egress router and protector, but may or may services share the common egress router and protector, but MAY or MAY
not share a common egress-protected tunnel or a common ingress NOT be carried by a common egress-protected tunnel or a common
router. ingress router.
An egress-protected service MUST be mapped to an egress-protected An egress-protected service MUST be mapped to an egress-protected
tunnel by its ingress router, based on the common protected egress tunnel by its ingress router, based on the common protected egress
{E, P} of the service and the tunnel. This is achieved by {E, P} of the service and the tunnel. This is achieved by
introducing the notion of "context ID" for protected egress {E, P}, introducing the notion of "context ID" for protected egress {E, P},
as described in (Section 5.7). as described in (Section 5.7).
5.6. Egress-protection bypass tunnel 5.6. Egress-protection bypass tunnel
An egress-protected tunnel destined for a protected egress {E, P} An egress-protected tunnel destined for a protected egress {E, P}
MUST have a bypass tunnel from its PLR to the protector P. This MUST have a bypass tunnel from its PLR to the protector P. This
bypass tunnel is called an egress-protection bypass tunnel. The bypass tunnel is called an egress-protection bypass tunnel. The
bypass tunnel is considered as logically "destined" for the protected bypass tunnel is considered as logically "destined" for the protected
egress {E, P}. However, due to its bypass nature, it MUST be resolved egress {E, P}. Due to its bypass nature, it MUST be established with
and established with P as the physical tailend and E as the node to P as the physical tailend and E as the node to avoid. The bypass
avoid. The bypass tunnel MUST have the property that it MUST NOT be tunnel MUST have the property that it MUST NOT be affected by the
affected by the topology change caused by an egress node failure. topology change caused by an egress node failure.
An egress-protection bypass tunnel is associated with one and only An egress-protection bypass tunnel is associated with one and only
one protected egress {E, P}. A PLR may share an egress-protection one protected egress {E, P}. A PLR MAY share an egress-protection
bypass tunnel for multiple egress-protected tunnels associated with a bypass tunnel for multiple egress-protected tunnels associated with a
common protected egress {E, P}. For multiple egress-protected tunnels common protected egress {E, P}.
associated with a common protected egress {E, P}, there may be one or
multiple egress-protection bypass tunnels from one or multiple PLRs
to the protector P, depending on the paths of the egress-protected
tunnels.
5.7. Context ID, context label, and context based forwarding 5.7. Context ID, context label, and context based forwarding
In this framework, a globally unique IPv4/v6 address is assigned to a In this framework, a globally unique IPv4/v6 address is assigned to a
protected egress {E, P} to serve as the identifier of the protected protected egress {E, P} as the identifier of the protected egress {E,
egress {E, P}. It is called a "context ID" due to its specific usage P}. It is called a "context ID" due to its specific usage in context
in context label switching and context IP forwarding on the label switching and context IP forwarding on the protector. It is an
protector. It is an IP address that is logically owned by both the IP address that is logically owned by both the egress router and the
egress router and the protector. For the egress node, it indicates protector. For the egress router, it indicates the protector. For
the protector. For the protector, it indicates the egress router, the protector, it indicates the egress router, particularly the
particularly the egress router's forwarding context. For other egress router's forwarding context. For other routers in the
routers in the network, it is an address reachable via both the network, it is an address reachable via both the egress router and
egress router and the protector in the routing domain and the TE the protector (Section 5.8), similar to an anycast address.
domain (Section 5.8), similar to an anycast address.
The main purpose of a context ID is to coordinate ingress router, The main purpose of a context ID is to coordinate ingress router,
egress router, PLR and protector to set up egress protection. Given egress router, PLR and protector to establish egress protection. The
an egress-protected service associated with a protected egress {E, procedures are described below, given an egress-protected service
P}, its context ID is used as below: associated with a protected egress {E, P} with context ID.
o If the service is an MPLS service, when E distributes a service o If the service is an MPLS service, when E distributes a service
label binding message to the ingress router, E attaches the label binding message to the ingress router, E attaches the
context ID to the message. If the service is an IP service, when context ID to the message. If the service is an IP service, when
E advertises the service destination address to the ingress E advertises the service destination address to the ingress
router, E also attaches the context ID to the advertisement router, E attaches the context ID to the advertisement message.
message. How the context ID is encoded in the messages is a How the context ID is encoded in the messages is a choice of the
choice of the service protocol. It may need protocol extensions service protocol. A protocol extension of a "context ID" object
to define a "context ID" object, if there is no existing object may be needed, if there is no existing mechanism for this purpose.
that can be used for this purpose.
o The ingress router uses the context ID as a destination to o The ingress router uses the service's context ID as the
establish or resolve an egress-protected tunnel. The ingress destination to establish or resolve an egress-protected tunnel.
router then maps the service to the tunnel for transportation. In The ingress router then maps the service to the tunnel for
this process, the semantics of the context ID is transparent to transportation. The semantics of the context ID is transparent to
the ingress router. The ingress router only treats the context ID the ingress router. The ingress router only treats the context ID
as an IP address of E, and behaves in the same manner as as an IP address of E, in the same manner as establishing or
establishing or resolving a regular transport tunnel, although the resolving a regular transport tunnel.
result should be an egress-protected tunnel.
o The context ID is conveyed to the PLR by the signaling protocol of o The context ID is conveyed to the PLR by the signaling protocol of
the egress-protected tunnel, or learned by the PLR via an IGP the egress-protected tunnel, or learned by the PLR via an IGP
(i.e. OSPF or ISIS) or a topology-driven label distribution (i.e. OSPF or ISIS) or a topology-driven label distribution
protocol (e.g. LDP). The PLR uses the context ID as destination protocol (e.g. LDP). The PLR uses the context ID as destination
to establish or resolve an egress-protection bypass tunnel to P to establish or resolve an egress-protection bypass tunnel to P
while avoiding E. while avoiding E.
o P maintains a dedicated label space or a dedicated IP address o P maintains a dedicated label space and a dedicated IP address
space for E, depending on whether the service is MPLS or IP. This space for E. They are referred to as "E's label space" and "E's
is referred to as "E's label space" or "E's IP address space", IP address space", respectively. P uses the context ID to
respectively. P uses the context ID to identify the space. identify the label space and IP address space.
o If the service is an MPLS service, E also distributes the service o If the service is an MPLS service, E also distributes the service
label binding message to P. This is the same label binding label binding message to P. This is the same label binding
message that E advertises to the ingress router, which is attached message that E advertises to the ingress router, which includes
with the context ID. Based on the context ID, P installs the the context ID. Based on the context ID, P installs the service
service label in an MPLS forwarding table corresponding to E's label in an MPLS forwarding table corresponding to E's label
label space. If the service is an IP service, P installs an IP space. If the service is an IP service, P installs an IP route in
route in an IP forwarding table corresponding to E's IP address an IP forwarding table corresponding to E's IP address space. In
space. In either case, the protection service instance on P either case, the protection service instance on P constructs
interprets the service and constructs forwarding state for the forwarding state for the label route or IP route based on P's own
route based on P's own connectivity with the service's connectivity with the service's destination.
destination.
o P assigns a non-reserved label to the context ID. In the data o P assigns a non-reserved label to the context ID. In the data
plane, this label represents the context ID and indicates E's plane, this label represents the context ID and indicates E's
label space and IP address space. Therefore, it is called a label space and IP address space. Therefore, it is called a
"context label". "context label".
o The PLR may establish the egress-protection bypass tunnel to P in o The PLR MAY establish the egress-protection bypass tunnel to P in
several manners. If the bypass tunnel is established by RSVP, the several manners. If the bypass tunnel is established by RSVP, the
PLR signals the bypass tunnel with the context ID as destination, PLR signals the bypass tunnel with the context ID as destination,
and P binds the context label to the bypass tunnel. If the bypass and P binds the context label to the bypass tunnel. If the bypass
tunnel is established by LDP, P advertises the context label for tunnel is established by LDP, P advertises the context label for
the context ID as an IP prefix FEC. If the bypass tunnel is the context ID as an IP prefix FEC. If the bypass tunnel is
established by the PLR in a hierarchical manner, the PLR treats established by the PLR in a hierarchical manner, the PLR treats
the context label as a one-hop LSP over a regular bypass tunnel to the context label as a one-hop LSP over a regular bypass tunnel to
P (e.g. a bypass tunnel to P's loopback IP address). If the P (e.g. a bypass tunnel to P's loopback IP address). If the
bypass tunnel is constructed by using segment routing, the bypass bypass tunnel is constructed by using segment routing, the bypass
tunnel is represented by a stack of SID labels with the context tunnel is represented by a stack of SID labels with the context
label as the inner-most SID label (Section 5.9). In any case, the label as the inner-most SID label (Section 5.9). In any case, the
bypass tunnel is a UHP tunnel whose incoming label on P is the bypass tunnel is a UHP tunnel whose incoming label on P is the
context label. context label.
o During local repair, all the service packets received by P on the o During local repair, all the service packets received by P on the
bypass tunnel have the context label as the top label. P first bypass tunnel have the context label as the top label. P first
pops the context label. For an MPLS service packet, P further pops the context label. For an MPLS service packet, P further
looks up the service label in E's label space indicated by the looks up the service label in E's label space indicated by the
context label, which is called context label switching. For an IP context label. Such kind of forwarding is called context label
service packet, P looks up the IP destination address in E's IP switching. For an IP service packet, P looks up the IP
address space indicated by the context label, which is called destination address in E's IP address space indicated by the
context IP forwarding. context label. Such kind of forwarding is called context IP
forwarding.
5.8. Advertisement and path resolution for context ID 5.8. Advertisement and path resolution for context ID
Path resolution and computation for a context ID are done on ingress Path resolution and computation for a context ID are done on ingress
routers for egress-protected tunnels, and on PLRs for egress- routers for egress-protected tunnels, and on PLRs for egress-
protection bypass tunnels. Given a protected egress {E, P} and its protection bypass tunnels. Given a protected egress {E, P} and its
context ID, E and P MUST coordinate the context ID in the routing context ID, E and P MUST coordinate on the reachability of the
domain and the TE domain via IGP advertisement. The context ID MUST context ID in the routing domain and the TE domain. The context ID
be advertised in such a manner that all egress-protected tunnels MUST MUST be advertised in such a manner that all egress-protected tunnels
have E as tailend, and all egress-protection bypass tunnels MUST have MUST have E as tailend, and all egress-protection bypass tunnels MUST
P as tailend while avoiding E. have P as tailend while avoiding E.
This document suggests three approaches: This document suggests three approaches:
1. The first approach is called "proxy mode". It requires E and P, 1. The first approach is called "proxy mode". It requires E and P,
but not the PLR, to have the knowledge of the egress protection but not the PLR, to have the knowledge of the egress protection
schema. E and P advertise the context ID as a virtual proxy node schema. E and P advertise the context ID as a virtual proxy node
(i.e. a logical node) connected to the two routers, with the link (i.e. a logical node) connected to the two routers, with the link
between the proxy node and E having more preferable IGP and TE between the proxy node and E having more preferable IGP and TE
metrics than the link between the proxy node and P. Therefore, metrics than the link between the proxy node and P. Therefore,
all egress-protected tunnels destined for the context ID should all egress-protected tunnels destined for the context ID will
automatically follow the IGP or TE paths to E. Each PLR will no automatically follow the IGP or TE paths to E. Each PLR will no
longer view itself as a penultimate-hop, but rather two hops away 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 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 bypass path via P to the proxy node, while the bypass tunnel is
should actually be terminated by P. actually be terminated by P.
2. The second approach is called "alias mode". It requires P and 2. The second approach is called "alias mode". It requires P and
the PLR, but not E, to have the knowledge of the egress the PLR, but not E, to have the knowledge of the egress
protection schema. E simply advertises the context ID as a protection schema. E simply advertises the context ID as an IP
regular IP address. P advertises the context ID and the context address. P advertises the context ID and the context label by
label by using a "context ID label binding" advertisement. The using a "context ID label binding" advertisement. The
advertisement MUST be understood by the PLR. In both routing advertisement MUST be understood by the PLR. In both routing
domain and TE domain, the context ID is only reachable via E. domain and TE domain, the context ID is only reachable via E.
This ensures that all egress-protected tunnels destined for the Therefore, all egress-protected tunnels destined for the context
context ID should have E as tailend. Based on the "context ID ID will have E as tailend. Based on the "context ID label
label binding" advertisement, the PLR can establish an egress- binding" advertisement, the PLR can establish an egress-
protection bypass tunnel in several manners (Section 5.9). The protection bypass tunnel in several manners (Section 5.9). The
"context ID label binding" advertisement is defined as IGP "context ID label binding" advertisement is defined as IGP
mirroring context segment in [RFC8402], [SR-OSPF] and [SR-ISIS]. mirroring context segment in [RFC8402], [SR-OSPF] and [SR-ISIS].
These IGP extensions are generic in nature, and hence can be used These IGP extensions are generic in nature, and hence can be used
for egress protection purposes. for egress protection purposes.
3. The third approach is called "stub link mode". In this mode, 3. The third approach is called "stub link mode". In this mode,
both E and P advertise the context ID as a link to a stub both E and P advertise the context ID as a link to a stub
network, essentially modelling the context ID as an any-cast IP network, essentially modelling the context ID as an any-cast IP
address owned by the two routers. E, P and the PLR do not need address owned by the two routers. E, P and the PLR do not need
to have the knowledge of the egress protection schema. The to have the knowledge of the egress protection schema. The
correctness of the egress-protected tunnels and the bypass correctness of the egress-protected tunnels and the bypass
tunnels relies on the path computations for the any-cast IP tunnels relies on the path computations for the any-cast IP
skipping to change at page 15, line 16 skipping to change at page 14, line 42
for egress protection purposes. for egress protection purposes.
3. The third approach is called "stub link mode". In this mode, 3. The third approach is called "stub link mode". In this mode,
both E and P advertise the context ID as a link to a stub both E and P advertise the context ID as a link to a stub
network, essentially modelling the context ID as an any-cast IP network, essentially modelling the context ID as an any-cast IP
address owned by the two routers. E, P and the PLR do not need address owned by the two routers. E, P and the PLR do not need
to have the knowledge of the egress protection schema. The to have the knowledge of the egress protection schema. The
correctness of the egress-protected tunnels and the bypass correctness of the egress-protected tunnels and the bypass
tunnels relies on the path computations for the any-cast IP tunnels relies on the path computations for the any-cast IP
address performed by the ingress routers and PLR. Therefore, address performed by the ingress routers and PLR. Therefore,
care MUST be taken for the applicability of this approach to a care MUST be taken for the applicability of this approach to in a
given network topology. network.
This framework considers the approaches as technically equal, and the This framework considers the above approaches as technically equal,
feasibility of each approach in a given network as dependent on the and the feasibility of each approach in a given network as dependent
topology, manageability, and available protocols of the network. For on the topology, manageability, and available protocols of the
a given context ID, all relevant routers, including primary PE, network. For a given context ID, all relevant routers, including
protector, and PLR, must support and agree on the chosen approach. primary PE, protector, and PLR, MUST support and agree on the chosen
The coordination between these routers can be achieved by approach. The coordination between these routers can be achieved by
configuration. configuration.
In a scenario where an egress-protected tunnel is an inter-area or In a scenario where an egress-protected tunnel is an inter-area or
inter-AS tunnel, its associated context ID MUST be propagated from inter-AS tunnel, its associated context ID MUST be propagated by IGP
the original area/AS to other areas/AS' via IGP or BGP, so that the or BGP from the original area/AS to the areas/AS' the ingress router.
ingress router of the tunnel can have the reachability to the context The propagation process of the context ID SHOULD be the same as that
ID. The propagation process of the context ID SHOULD be the same as of an IP address in an inter-area/AS environment.
that of a regular IP address in an inter-area/AS environment.
5.9. Egress-protection bypass tunnel establishment 5.9. Egress-protection bypass tunnel establishment
A PLR MUST know the context ID of a protected egress {E, P} in order A PLR MUST know the context ID of a protected egress {E, P} in order
to establish an egress-protection bypass tunnel. The information is to establish an egress-protection bypass tunnel. The information is
obtained from the signaling or label distribution protocol of the obtained from the signaling or label distribution protocol of the
egress-protected tunnel. The PLR may or may not need to have the egress-protected tunnel. The PLR MAY or MAY NOT need to have the
knowledge of the egress protection schema. All it does is to set up knowledge of the egress protection schema. All it does is to set up
a bypass tunnel to a context ID while avoiding the next-hop router a bypass tunnel to a context ID while avoiding the next-hop router
(i.e. egress router). This is achievable by using a constraint-based (i.e. egress router). This is achievable by using a constraint-based
computation algorithm similar to those which are commonly used in the computation algorithm similar to those commonly used for traffic
computation of traffic engineering paths and loop-free alternate engineering paths and loop-free alternate (LFA) paths. Since the
(LFA) paths. Since the context ID is advertised in the routing context ID is advertised in the routing domain and the TE domain by
domain and the TE domain by IGP according to Section 5.8, the PLR IGP according to Section 5.8, the PLR is able to resolve or establish
should be able to resolve or establish such a bypass path with the such a bypass path with the protector as tailend. In the case of
protector as tailend. In some cases like the proxy mode, the PLR may proxy mode, the PLR MAY do so in the same manner as transit node
do so in the same manner as transit node protection. protection.
An egress-protection bypass tunnel may be established via several An egress-protection bypass tunnel MAY be established via several
methods: methods:
(1) It may be established by a signaling protocol (e.g. RSVP), with (1) It MAY be established by a signaling protocol (e.g. RSVP), with
the context ID as destination. The protector binds the context label the context ID as destination. The protector binds the context label
to the bypass tunnel. to the bypass tunnel.
(2) It may be formed by a topology driven protocol (e.g. LDP with (2) It MAY be formed by a topology driven protocol (e.g. LDP with
various LFA mechanisms). The protector advertises the context ID as various LFA mechanisms). The protector advertises the context ID as
an IP prefix FEC, with the context label bound to it. an IP prefix FEC, with the context label bound to it.
(3) It may be constructed as a hierarchical tunnel. When the (3) It MAY be constructed as a hierarchical tunnel. When the
protector uses the alias mode (Section 5.8), the PLR will have the protector uses the alias mode (Section 5.8), the PLR will have the
knowledge of the context ID, context label, and protector (i.e. the knowledge of the context ID, context label, and protector (i.e. the
advertiser). The PLR can then establish the bypass tunnel in a advertiser). The PLR can then establish the bypass tunnel in a
hierarchical manner, with the context label as a one-hop LSP over a hierarchical manner, with the context label as a one-hop LSP over a
regular bypass tunnel to the protector's IP address (e.g. loopback regular bypass tunnel to the protector's IP address (e.g. loopback
address). This regular bypass tunnel may be established by RSVP, address). This regular bypass tunnel MAY be established by RSVP,
LDP, segment routing, or another protocol. LDP, segment routing, or another protocol.
5.10. Local repair on PLR 5.10. Local repair on PLR
In this framework, a PLR is agnostic to services and service labels. In this framework, a PLR is agnostic to services and service labels.
This obviates the need to maintain bypass forwarding state on a per- This obviates the need to maintain bypass forwarding state on a per-
service basis, and allows bypass tunnel sharing between egress- service basis, and allows bypass tunnel sharing between egress-
protected tunnels. The PLR may share an egress-protection bypass protected tunnels. The PLR MAY share an egress-protection bypass
tunnel for multiple egress-protected tunnels associated with a common tunnel for multiple egress-protected tunnels associated with a common
protected egress {E, P}. During local repair, the PLR reroutes all protected egress {E, P}. During local repair, the PLR reroutes all
service packets received on the egress-protected tunnels via the service packets received on the egress-protected tunnels to the
egress-protection bypass tunnel. Service labels remain intact in egress-protection bypass tunnel. Service labels remain intact in
MPLS service packets. MPLS service packets.
Label operation during the rerouting depends on the bypass tunnel's Label operation performed by PLR depends on the bypass tunnel's
characteristics. If the bypass tunnel is a single level tunnel, the characteristics. If the bypass tunnel is a single level tunnel, the
rerouting will involve swapping the incoming label of an egress- rerouting will involve swapping the incoming label of an egress-
protected tunnel to the outgoing label of the bypass tunnel. If the protected tunnel to the outgoing label of the bypass tunnel. If the
bypass tunnel is a hierarchical tunnel, the rerouting will involve bypass tunnel is a hierarchical tunnel, the rerouting will involve
swapping the incoming label of an egress-protected tunnel to a swapping the incoming label of an egress-protected tunnel to a
context label, and pushing the outgoing label of a regular bypass context label, and pushing the outgoing label of a regular bypass
tunnel. If the bypass tunnel is constructed by segment routing, the tunnel. If the bypass tunnel is constructed by segment routing, the
rerouting will involve swapping the incoming label of an egress- rerouting will involve swapping the incoming label of an egress-
protected tunnel to a context label, and pushing a stack of SID protected tunnel to a context label, and pushing the stack of SID
labels of the bypass tunnel. labels of the bypass tunnel.
5.11. Service label distribution from egress router to protector 5.11. Service label distribution from egress router to protector
When a protector receives a rerouted MPLS service packet, it performs When a protector receives a rerouted MPLS service packet, it performs
context label switching based on the packet's service label which is context label switching based on the packet's service label which is
assigned by the corresponding egress router. In order to achieve assigned by the corresponding egress router. In order to achieve
this, the protector MUST maintain such kind of service labels in this, the protector MUST maintain the labels of egress-protected
dedicated label spaces on a per protected egress {E, P} basis, i.e. services in dedicated label spaces on a per protected egress {E, P}
one label space for each egress router that it protects. basis, i.e. one label space for each egress router that it protects.
Also, there MUST be a service label distribution protocol session Also, there MUST be a service label distribution protocol session
between each egress router and the protector. Through this protocol, between each egress router and the protector. Through this protocol,
the protector learns the label binding of each egress-protected the protector learns the label binding of each egress-protected
service. This is the same label binding that the egress router service. This is the same label binding that the egress router
advertises to the service's ingress router, which is attached with a advertises to the service's ingress router, which includes a context
context ID. The corresponding protection service instance on the ID. The corresponding protection service instance on the protector
protector recognizes the service, and resolves forwarding state based recognizes the service, and resolves forwarding state based on its
on its own connectivity with the service's destination. It then own connectivity with the service's destination. It then installs
installs the service label with the forwarding state in the label the service label with the forwarding state in the label space of the
space of the egress router, which is indicated by the context ID egress router, which is indicated by the context ID (i.e. context
(i.e. context label). label).
Different service protocols may use different mechanisms for such Different service protocols may use different mechanisms for such
kind of label distribution. Specific protocol extensions may be kind of label distribution. Specific extensions MAY be needed on a
needed on a per-protocol basis or per-service-type basis. The per-protocol basis or per-service-type basis. The details of the
details of the extensions SHOULD be specified in separate documents. extensions SHOULD be specified in separate documents. As an example,
As an example, [RFC8104] specifies the LDP extensions for pseudowire [RFC8104] specifies the LDP extensions for pseudowire services.
services.
5.12. Centralized protector mode 5.12. Centralized protector mode
In this framework, it is assumed that the service destination of an In this framework, it is assumed that the service destination of an
egress-protected service MUST be dual-homed to two edge routers of an egress-protected service MUST be dual-homed to two edge routers of an
MPLS network. One of them is the protected egress router, and the MPLS network. One of them is the protected egress router, and the
other is a backup egress router. So far in this document, the other is a backup egress router. So far in this document, the
discussion has been focusing on the scenario where a protector and a discussion has been focusing on the scenario where a protector and a
backup egress router are co-located as one router. Therefore, the backup egress router are co-located as one router. Therefore, the
number of protectors in a network is equal to the number of backup number of protectors in a network is equal to the number of backup
egress routers. As another scenario, a network may assign a small egress routers. As another scenario, a network MAY assign a small
number of routers to serve as dedicated protectors, each protecting a number of routers to serve as dedicated protectors, each protecting a
subset of egress routers. These protectors are called centralized subset of egress routers. These protectors are called centralized
protectors. protectors.
Topologically, a centralized protector may be decoupled from all Topologically, a centralized protector MAY be decoupled from all
backup egress routers, or it may be co-located with one backup egress backup egress routers, or it MAY be co-located with one backup egress
router while decoupled from the other backup egress routers. The router while decoupled from the other backup egress routers. The
procedures in this section assume that a protector and a backup procedures in this section assume that a protector and a backup
egress router are decoupled. egress router are decoupled.
services 1, ..., N services 1, ..., N
=====================================> tunnel =====================================> tunnel
I ------ R1 ------- PLR --------------- E ---- I ------ R1 ------- PLR --------------- E ----
ingress penultimate-hop egress \ ingress penultimate-hop egress \
| . (primary \ | . (primary \
skipping to change at page 18, line 37 skipping to change at page 18, line 12
Figure 2 Figure 2
Like a co-located protector, a centralized protector hosts protection Like a co-located protector, a centralized protector hosts protection
service instances, receives rerouted service packets from PLRs, and service instances, receives rerouted service packets from PLRs, and
performs context label switching and/or context IP forwarding. For performs context label switching and/or context IP forwarding. For
each service, instead of sending service packets directly to the each service, instead of sending service packets directly to the
service destination, the protector MUST send them via another service destination, the protector MUST send them via another
transport tunnel to the corresponding backup service instance on a transport tunnel to the corresponding backup service instance on a
backup egress router. The backup service instance in turn forwards backup egress router. The backup service instance in turn forwards
them to the service destination. Specifically, in the case of an the service packets to the service destination. Specifically, in the
MPLS service, the protector MUST swap the service label in each service is an MPLS service, the protector MUST swap the service label
received service packet to the label of the backup service advertised in each received service packet to the label of the backup service
by the backup egress router, and then push the label (or label stack) advertised by the backup egress router, and then push the label (or
of the transport tunnel. label stack) of the transport tunnel.
In order for a centralized protector to map an egress-protected MPLS In order for a centralized protector to map an egress-protected MPLS
service to a service hosted on a backup egress router, there MUST be service to a service hosted on a backup egress router, there MUST be
a service label distribution protocol session between the backup a service label distribution protocol session between the backup
egress router and the protector. Through this session, the backup egress router and the protector. Through this session, the backup
egress router advertises the service label of the backup service, egress router advertises the service label of the backup service,
attached with the FEC of the egress-protected service and the context attached with the FEC of the egress-protected service and the context
ID of the protected egress {E, P}. Based on this information, the ID of the protected egress {E, P}. Based on this information, the
protector associates the egress-protected service with the backup protector associates the egress-protected service with the backup
service, resolves or establishes a transport tunnel to the backup service, resolves or establishes a transport tunnel to the backup
egress router, and accordingly sets up forwarding state for the label egress router, and sets up forwarding state for the label of the
of the egress-protected service in the label space of the egress egress-protected service in the label space of the egress router.
router.
The service label which the backup egress router advertises to the The service label which the backup egress router advertises to the
protector can be the same as the label which the backup egress router protector can be the same as the label which the backup egress router
advertises to the ingress router(s), if and only if the forwarding advertises to the ingress router(s), if and only if the forwarding
state of the label does not direct service packets towards the state of the label does not direct service packets towards the
protected egress router. Otherwise, the label cannot be used for protected egress router. Otherwise, the label MUST NOT be used for
egress protection, because it will create a loop for the service egress protection, because it would create a loop for the service
packets. In this case, the backup egress router MUST advertise a packets. In this case, the backup egress router MUST advertise a
unique service label for egress protection, and set up the forwarding unique service label for egress protection, and set up the forwarding
state of the label to use the backup egress router's own connectivity state of the label to use the backup egress router's own connectivity
with the service destination. with the service destination.
6. Egress link protection 6. Egress link protection
Egress link protection is achievable through procedures similar to Egress link protection is achievable through procedures similar to
that of egress node protection. In normal situations, an egress that of egress node protection. In normal situations, an egress
router forwards service packets to a service destination based on a router forwards service packets to a service destination based on a
skipping to change at page 21, line 36 skipping to change at page 20, line 36
service service service service
instance) instance) instance) instance)
Figure 4 Figure 4
There are two approaches to set up the bypass forwarding state on the There are two approaches to set up the bypass forwarding state on the
egress router, depending on whether the egress router knows the egress router, depending on whether the egress router knows the
service label allocated by the backup egress router. The difference service label allocated by the backup egress router. The difference
is that one approach requires the protector to perform context label is that one approach requires the protector to perform context label
switching, and the other one does not. Both approaches are equally switching, and the other one does not. Both approaches are equally
supported by this framework, and may be used in parallel. supported by this framework.
(1) The first approach applies when the egress router does not (1) The first approach applies when the egress router does not
know the service label allocated by the backup egress router. In know the service label allocated by the backup egress router. In
this case, the egress router sets up the bypass forwarding state this case, the egress router sets up the bypass forwarding state
as a label push with the outgoing label of the egress-protection as a label push with the outgoing label of the egress-protection
bypass tunnel. Rerouted packets will have the egress router's bypass tunnel. Rerouted packets will have the egress router's
service label intact. Therefore, the protector MUST perform service label intact. Therefore, the protector MUST perform
context label switching, and the bypass tunnel MUST be destined context label switching, and the bypass tunnel MUST be destined
for the context ID of the {E, P} and established as described in for the context ID of the protected egress {E, P} and established
Section 5.9. This approach is consistent with egress node as described in Section 5.9. This approach is consistent with
protection. Hence, a protector can serve in egress node egress node protection. Hence, a protector can serve in egress
protection and egress link protection in a consistent manner, and node protection and egress link protection in a consistent manner,
both the co-located protector mode and the centralized protector and both the co-located protector mode and the centralized
mode may be used (Figure-3 and Figure-4). protector mode are supported (Figure-3 and Figure-4).
(2) The second approach applies when the egress router knows the (2) The second approach applies when the egress router knows the
service label allocated by the backup egress router, via a label service label allocated by the backup egress router, via a label
distribution protocol session. In this case, the backup egress distribution protocol session. In this case, the backup egress
router serves as the protector for egress link protection, router serves as the protector for egress link protection,
regardless of the protector of egress node protection, which regardless of the protector of egress node protection, which will
should be the same router in the co-located protector mode but a be the same router in the co-located protector mode but a
different router in the centralized protector mode. The egress different router in the centralized protector mode. The egress
router sets up the bypass forwarding state as a label swap from router sets up the bypass forwarding state as a label swap from
the incoming service label to the service label of the backup the incoming service label to the service label of the backup
egress router (i.e. protector), followed by a push with the egress router (i.e. protector), followed by a push with the
outgoing label (or label stack) of the egress link protection outgoing label (or label stack) of the egress link protection
bypass tunnel. The bypass tunnel is a regular tunnel destined for bypass tunnel. The bypass tunnel is a regular tunnel destined for
an IP address of the protector, instead of the context ID of the an IP address of the protector, instead of the context ID of the
{E, P}. The protector simply forwards rerouted service packets protected egress {E, P}. The protector simply forwards rerouted
based on its own service label, rather than performing context service packets based on its own service label, rather than
label switching. In this approach, only the co-located protector performing context label switching. In this approach, only the
mode is applicable. co-located protector mode is applicable.
Note that for a bidirectional service, the physical link of an egress Note that for a bidirectional service, the physical link of an egress
link may carry service traffic bi-directionally. Therefore, an link may carry service traffic bi-directionally. Therefore, an
egress link failure may simultaneously be an ingress link failure for egress link failure may simultaneously be an ingress link failure for
the traffic in the opposite direction. However, protection for the traffic in the opposite direction. Protection for ingress link
ingress link failure SHOULD be provided by a separate mechanism, and failure SHOULD be provided by a separate mechanism, and hence is out
hence is out of the scope of this document. of the scope of this document.
7. Global repair 7. Global repair
This framework provides a fast but temporary repair for egress node This framework provides a fast but temporary repair for egress node
and egress link failures. For permanent repair, it is RECOMMENDED and egress link failures. For permanent repair, it is RECOMMENDED
that the services affected by a failure SHOULD be moved to an that the services affected by a failure SHOULD be moved to an
alternative tunnel, or replaced by alternative services, which are alternative tunnel, or replaced by alternative services, which are
fully functional. This is referred to as global repair. Possible fully functional. This is referred to as global repair. Possible
triggers of global repair include control plane notifications of triggers of global repair include control plane notifications of
tunnel and service status, end-to-end OAM and fault detection at tunnel status and service status, end-to-end OAM and fault detection
tunnel or service level, and others. The alternative tunnel and at tunnel and service level, and others. The alternative tunnel and
services may be pre-established in standby state, or dynamically services MAY be pre-established in standby state, or dynamically
established as a result of the triggers or network protocol established as a result of the triggers or network protocol
convergence. convergence.
8. General context-based forwarding 8. General context-based forwarding
So far this document has been focusing on the cases where service So far this document has been focusing on the cases where service
packets are MPLS or IP packets and protectors perform context label packets are MPLS or IP packets and protectors perform context label
switching or context IP forwarding. Although this should cover most switching or context IP forwarding. Although this should cover most
common services, it is worth mentioning that the framework is also common services, it is worth mentioning that the framework is also
applicable to services or sub-modes of services where service packets applicable to services or sub-modes of services where service packets
skipping to change at page 23, line 40 skipping to change at page 22, line 40
to exchange VPN prefixes and VPN labels between each other. to exchange VPN prefixes and VPN labels between each other.
Using the framework in this document, the network assigns PE3 to be a 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 protector for PE2 to protect the VPN traffic in the direction from
site 1 to site 2. This is the co-located protector mode. Hence, PE2 site 1 to site 2. This is the co-located protector mode. Hence, PE2
and PE3 form a protected egress {PE2, PE3}. A context ID 198.51.100.1 and PE3 form a protected egress {PE2, PE3}. A context ID 198.51.100.1
is assigned to the protected egress {PE2, PE3}. The VPN instance on is assigned to the protected egress {PE2, PE3}. The VPN instance on
PE3 serves as a protection instance for the VPN instance on PE2. On PE3 serves as a protection instance for the VPN instance on PE2. On
PE3, a context label 100 is assigned to the context ID, and a label 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 table pe2.mpls is created to represent PE2's label space. PE3
installs the label 100 in its default MPLS forwarding table, with installs the label 100 in its MPLS forwarding table, with nexthop
nexthop pointing to the label table pe2.mpls. PE2 and PE3 are pointing to the label table pe2.mpls. PE2 and PE3 are coordinated to
coordinated to use the proxy mode to advertise the context ID in the use the proxy mode to advertise the context ID in the routing domain
routing domain and the TE domain. and the TE domain.
PE2 uses per-VRF VPN label allocation mode. It assigns a single PE2 uses per-VRF VPN label allocation mode. It assigns a single
label 9000 to the VRF of the VPN. For a given VPN prefix label 9000 to the VRF of the VPN. For a given VPN prefix
203.0.113.128/26 in site 2, PE2 advertises it along with the label 203.0.113.128/26 in site 2, PE2 advertises it along with the label
9000 and other attributes to PE1 and PE3 via BGP. In particular, the 9000 to PE1 and PE3 via BGP. The NEXT_HOP attribute is set to the
NEXT_HOP attribute is set to the context ID 198.51.100.1. context ID 198.51.100.1.
Similarly, PE3 also uses per-VRF VPN label allocation mode. It Similarly, PE3 also uses per-VRF VPN label allocation mode. It
assigns a single label 10000 to the VRF of the VPN. For the VPN assigns a single label 10000 to the VRF of the VPN. For the VPN
prefix 203.0.113.128/26 in site 2, PE3 advertises it along with the prefix 203.0.113.128/26 in site 2, PE3 advertises it along with the
label 10000 and other attributes to PE1 and PE2 via BGP. In label 10000 to PE1 and PE2 via BGP. The NEXT_HOP attribute is set to
particular, the NEXT_HOP attribute is set to an IP address of PE3. an IP address of PE3.
Upon receipt and acceptance of the BGP advertisement, PE1 uses the Upon receipt and acceptance of the BGP advertisement, PE1 uses the
context ID 198.51.100.1 as destination to compute a TE path for an context ID 198.51.100.1 as destination to compute a TE path for an
egress-protected tunnel. The resulted path is PE1->R1->PE2. PE1 egress-protected tunnel. The resultant path is PE1->R1->PE2. PE1
then uses RSVP to signal the tunnel, with the context ID 198.51.100.1 then uses RSVP to signal the tunnel, with the context ID 198.51.100.1
as destination, and with the "node protection desired" flag set in as destination, and with the "node protection desired" flag set in
the SESSION_ATTRIBUTE of RSVP Path message. Once the tunnel comes the SESSION_ATTRIBUTE of RSVP Path message. Once the tunnel comes
up, PE1 maps the VPN prefix 203.0.113.128/26 to the tunnel and up, PE1 maps the VPN prefix 203.0.113.128/26 to the tunnel and
installs a route for the prefix in the corresponding VRF. The installs a route for the prefix in the corresponding VRF. The
route's nexthop is a push with the VPN label 9000, followed by a push route's nexthop is a push of the VPN label 9000, followed by a push
with the outgoing label of the egress-protected tunnel. of the outgoing label of the egress-protected tunnel.
Upon receipt of the above BGP advertisement from PE2, PE3 (i.e. the Upon receipt of the above BGP advertisement from PE2, PE3 recognizes
protector) recognizes the context ID 198.51.100.1 in the NEXT_HOP the context ID 198.51.100.1 in the NEXT_HOP attribute, and installs a
attribute, and installs a route for label 9000 in the label table route for label 9000 in the label table pe2.mpls. PE3 sets the
pe2.mpls. PE3 sets the route's nexthop to a "protection VRF". This route's nexthop to a "protection VRF". This protection VRF contains
protection VRF contains IP routes corresponding to the IP prefixes in IP routes of the IP prefixes in the dual-homed site 2, including
the dual-homed site 2, including 203.0.113.128/26. The nexthops of 203.0.113.128/26. The nexthops of these routes MUST be based on
these routes MUST be based on PE3's connectivity with site 2, even if PE3's connectivity with site 2, even if this connectivity may not
this connectivity is not the best path in PE3's VRF due to metrics have the best metrics (e.g. MED, local preference, etc.) for PE3 to
(e.g. MED, local preference, etc.), and MUST NOT use any path use in its own VRF. The nexthops MUST NOT use any path traversing
traversing PE2. Note that the protection VRF is a logical concept, PE2. Note that the protection VRF is a logical concept, and it may
and it may simply be PE3's own VRF if the VRF satisfies the simply be PE3's own VRF if the VRF satisfies the requirement.
requirement.
9.1. Egress node protection 9.1. Egress node protection
R1, i.e. the penultimate-hop router of the egress-protected tunnel, R1, i.e. the penultimate-hop router of the egress-protected tunnel,
serves as the PLR for egress node protection. Based on the "node serves as the PLR for egress node protection. Based on the "node
protection desired" flag and the destination address (i.e. context ID protection desired" flag and the destination address (i.e. context ID
198.51.100.1) of the tunnel, R1 computes a bypass path to 198.51.100.1) of the tunnel, R1 computes a bypass path to
198.51.100.1 while avoiding PE2. The resulted bypass path is 198.51.100.1 while avoiding PE2. The resultant bypass path is
R1->R2->PE3. R1 then signals the path (i.e. egress-protection bypass R1->R2->PE3. R1 then signals the path (i.e. egress-protection bypass
tunnel), with 198.51.100.1 as destination. tunnel), with 198.51.100.1 as destination.
Upon receipt of an RSVP Path message of the egress-protection bypass Upon receipt of an RSVP Path message of the egress-protection bypass
tunnel, PE3 recognizes the context ID 198.51.100.1 as the tunnel, PE3 recognizes the context ID 198.51.100.1 as the
destination, and hence responds with the context label 100 in an RSVP destination, and hence responds with the context label 100 in an RSVP
Resv message. Resv message.
After the egress-protection bypass tunnel comes up, R1 installs a After the egress-protection bypass tunnel comes up, R1 installs a
bypass nexthop for the egress-protected tunnel. The bypass nexthop bypass nexthop for the egress-protected tunnel. The bypass nexthop
is a swap from the incoming label of the egress-protected tunnel to is a label swap from the incoming label of the egress-protected
the outgoing label of the egress-protection bypass tunnel. tunnel to the outgoing label of the egress-protection bypass tunnel.
When R1 detects a failure of PE2, it will invoke the above bypass When R1 detects a failure of PE2, it will invoke the above bypass
nexthop to reroute VPN service packets. The packets will have the 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 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 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 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. 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 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 cause the VPN label to be popped, and the IP packets to be forwarded
forwarded to site 2 based on the protection VRF. to site 2 based on the protection VRF.
9.2. Egress link protection 9.2. Egress link protection
PE2 serves as the PLR for egress link protection. It has already PE2 serves as the PLR for egress link protection. It has already
learned the VPN label 10000 from PE3, and hence it uses the approach learned the VPN label 10000 from PE3, and hence it uses the approach
(2) described in Section 6 to set up bypass forwarding state. It (2) described in Section 6 to set up bypass forwarding state. It
signals an egress-protection bypass tunnel to PE3, by using the path signals an egress-protection bypass tunnel to PE3, by using the path
PE2->R3->PE3, and PE3's IP address as destination. After the bypass PE2->R3->PE3, and PE3's IP address as destination. After the bypass
tunnel comes up, PE2 installs a bypass nexthop for the VPN label tunnel comes up, PE2 installs a bypass nexthop for the VPN label
9000. The bypass nexthop is a label swap from the incoming label 9000. The bypass nexthop is a label swap from the incoming label
9000 to the VPN label 10000 of PE3, followed by a label push with the 9000 to the VPN label 10000 of PE3, followed by a label push with the
outgoing label of the bypass tunnel. outgoing label of the bypass tunnel.
When PE2 detects a failure of the egress link, it will invoke the When PE2 detects a failure of the egress link, it will invoke the
above bypass nexthop to reroute VPN service packets. The packets above bypass nexthop to reroute VPN service packets. The packets
will have the label of the bypass tunnel as outer label, and the VPN will have the label of the bypass tunnel as outer label, and the VPN
label 10000 as inner label. When the packets arrive at PE3, the VPN label 10000 as inner label. When the packets arrive at PE3, the VPN
label 10000 will be popped, and the IP packets will be forwarded label 10000 will be popped, and the IP packets to be forwarded based
based on the VRF indicated by on the VPN label 10000. on the VRF indicated by on the VPN label 10000.
9.3. Global repair 9.3. Global repair
Eventually, global repair will take effect, as control plane Eventually, global repair will take effect, as control plane
protocols converge on the new topology. PE1 will choose PE3 as new protocols converge on the new topology. PE1 will choose PE3 as a new
entrance to site 2. Before that happens, the VPN traffic has been entrance to site 2. Before that happens, the VPN traffic has been
protected by the above local repair. protected by the above local repair.
9.4. Other modes of VPN label allocation 9.4. Other modes of VPN label allocation
In the above example, PE2 uses per-VRF VPN label allocation mode, and In the above example, PE2 uses per-VRF VPN label allocation mode, and
binds a common VPN label to all the VPN prefixes which it originates. binds a common VPN label to all the VPN prefixes which it advertises.
When PE3 processes the VPN label in the redirected packets, it When PE3 processes the VPN label in the redirected packets, it
follows the nexthop of the label route in the pe2.mpls table, by follows the nexthop of the label route in the pe2.mpls table, by
popping the VPN label and performing an IP lookup in the protection popping the VPN label and performing an IP lookup in the protection
VRF. VRF.
It is also possible that PE2 may use per-route or per-interface VPN It is also possible that PE2 may use per-route or per-interface VPN
label allocation mode. In either case, PE3 will have multiple label label allocation mode. In either case, PE3 will have multiple label
routes in the pe2.mpls table, corresponding to the VPN labels routes in the pe2.mpls table, corresponding to the VPN labels
advertised by PE2. PE3 may use the same nexthop as the above for all advertised by PE2. PE3 may use the same nexthop as the above for all
the label routes, so that PE3 will process the redirected packets by the label routes, to process redirected packets by popping a VPN
popping a VPN label and performing an IP lookup in the protection label and performing an IP lookup in the protection VRF. Therefore,
VRF. By using this universal nexthop, PE3 does not need to learn PE3 does not need to learn PE2's VPN label allocation mode or
PE2's VPN label allocation mode or construct a specific nexthop for construct a specific nexthop for each label route in the pe2.mpls
each label route in the pe2.mpls table. table.
10. IANA Considerations 10. IANA Considerations
This document has no request for new IANA allocation. This document has no request for new IANA allocation.
11. Security Considerations 11. Security Considerations
The framework in this document relies on fast reroute around a The framework in this document involves rerouting traffic around an
network failure. Specifically, service traffic is temporarily egress node or link failure, via a bypass path from a PLR to a
rerouted from a PLR to a protector. In the centralized protector protector, and ultimately to a backup egress router. Some control
mode, the traffic is further rerouted from the protector to a backup plane protocols MAY be used between these routers to facilitate the
egress router. Such kind of fast reroute is planned and anticipated, establishment of egress protection. The general security measures of
and hence it should not be viewed as a new security threat. the protocols SHOULD be used whenever applicable. In particular, the
framework requires a service label distribution protocol to run
The framework requires a service label distribution protocol to run
between an egress router and a protector. The available security between an egress router and a protector. The available security
measures of the protocol MAY be used to achieve a secured session measures of the chosen protocol SHOULD be used to achieve a secured
between the two routers. session between the two routers.
PLR, protector, and backup egress router are located close to the
protected egress router, and normally in the same administrative
domain. In the case where the routers are not in the same
administrative domain, a certain level trust MUST be established
between the routers in order for the protocols to run securely. The
forwarding performed by the routers in the data plane is also
anticipated, as part of egress protection planning. Therefore, the
framework should not introduce any new security threat to the
network.
12. Acknowledgements 12. Acknowledgements
This document leverages work done by Yakov Rekhter, Kevin Wang and This document leverages work done by Yakov Rekhter, Kevin Wang and
Zhaohui Zhang on MPLS egress protection. Thanks to Alexander Zhaohui Zhang on MPLS egress protection. Thanks to Alexander
Vainshtein, Rolf Winter, Lizhong Jin, and Krzysztof Szarkowicz for Vainshtein, Rolf Winter, Lizhong Jin, Krzysztof Szarkowicz, and
their valuable comments that helped to shape this document and Yuanlong Jiang for their valuable comments that helped to shape this
improve its clarity. document and improve its clarity.
13. References 13. References
13.1. Normative References 13.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
skipping to change at page 28, line 38 skipping to change at page 28, line 4
Sunnyvale, CA 94089 Sunnyvale, CA 94089
USA USA
Phone: +1 4089367563 Phone: +1 4089367563
Email: minto@juniper.net Email: minto@juniper.net
Bruno Decraene Bruno Decraene
Orange Orange
Email: bruno.decraene@orange.com Email: bruno.decraene@orange.com
Hannes Gredler Hannes Gredler
RtBrick Inc RtBrick Inc
Email: hannes@rtbrick.com Email: hannes@rtbrick.com
Carsten Michel Carsten Michel
Deutsche Telekom Deutsche Telekom
Email: c.michel@telekom.de Email: c.michel@telekom.de
Huaimo Chen Huaimo Chen
Huawei Technologies Co., Ltd. Huawei Technologies Co., Ltd.
Email: huaimo.chen@huawei.com Email: huaimo.chen@huawei.com
Yuanlong Jiang
Huawei Technologies Co., Ltd.
Bantian, Longgang district
Shenzhen 518129
China
Email: jiangyuanlong@huawei.com
 End of changes. 114 change blocks. 
352 lines changed or deleted 339 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/