Internet Engineering Task Force                             Y. Shen, Ed.
Internet-Draft                                          Juniper Networks
Intended status: Standards Track                             R. Aggarwal
Expires: December 27, 2012                                   Arktan, Inc
                                                           W. Henderickx
                                                          Alcatel-Lucent
                                                           June 25, 2012


                  PW Endpoint Fast Failure Protection
              draft-shen-pwe3-endpoint-fast-protection-02

Abstract

   This document specifies a fast protection mechanism for pseudowires
   (PWs) against egress attachment circuit failure, egress PE failure
   (including multi-segment PW terminating PE failure), and multi-
   segment PW switching PE failure.  Designed on the basis of multi-
   homed CE, PW redundancy, upstream label assignment and context
   specific label switching, the mechanism enables local repair to be
   performed by a router adjacent to a failure.  In particular, the
   router can restore PW traffic in the order of tens of milliseconds,
   by transmitting the traffic to a protector through a pre-established
   bypass tunnel.  Therefore, the mechanism is usable to reduce the
   packet loss that may happen before any global repair mechanism reacts
   to the failure or routers converge on the topology changes due to the
   failure.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on December 27, 2012.

Copyright Notice

   Copyright (c) 2012 IETF Trust and the persons identified as the



Shen, et al.            Expires December 27, 2012               [Page 1]


Internet-Draft     PW Endpoint Fast Failure Protection         June 2012


   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Specification of Requirements  . . . . . . . . . . . . . . . .  4
   3.  Reference Models and Failure Cases . . . . . . . . . . . . . .  4
     3.1.  Single-Segment PW  . . . . . . . . . . . . . . . . . . . .  5
     3.2.  Multi-Segment PW . . . . . . . . . . . . . . . . . . . . .  7
   4.  Theory of Operation  . . . . . . . . . . . . . . . . . . . . .  8
     4.1.  Local Repair and Protector . . . . . . . . . . . . . . . .  8
     4.2.  Context Identifier . . . . . . . . . . . . . . . . . . . . 11
       4.2.1.  Uses of Context Identifier . . . . . . . . . . . . . . 11
       4.2.2.  Advertisement and Path Computation . . . . . . . . . . 12
     4.3.  Protection Models  . . . . . . . . . . . . . . . . . . . . 14
     4.4.  Transport Tunnel . . . . . . . . . . . . . . . . . . . . . 17
     4.5.  Bypass Tunnel  . . . . . . . . . . . . . . . . . . . . . . 18
     4.6.  PW Forwarding State on Protector . . . . . . . . . . . . . 18
       4.6.1.  Co-located Protector . . . . . . . . . . . . . . . . . 19
       4.6.2.  Centralized Protector  . . . . . . . . . . . . . . . . 20
     4.7.  PW Label Distribution from Primary PE to Protector . . . . 22
       4.7.1.  Protection FEC Element Encoding for PWid . . . . . . . 24
       4.7.2.  Protection FEC Element Encoding for Generalized
               PWid . . . . . . . . . . . . . . . . . . . . . . . . . 25
     4.8.  PW Label Distribution from Backup PE to Protector  . . . . 26
     4.9.  Revertive Behavior . . . . . . . . . . . . . . . . . . . . 27
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 28
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 28
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 28
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 30
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30







Shen, et al.            Expires December 27, 2012               [Page 2]


Internet-Draft     PW Endpoint Fast Failure Protection         June 2012


1.  Introduction

   Per RFC 3985, RFC 4447 and RFC 5659, a pseudowire (PW) or PW segment
   can be thought of as a connection between a pair of forwarders hosted
   by two PEs, carrying an emulated layer-2 service over a packet
   switched network (PSN).  In the single-segment PW (SS-PW) case, a
   forwarder binds a PW to an attachment circuit (AC).  In the multi-
   segment PW (MS-PW) case, a forwarder on a terminating PE (T-PE) binds
   a PW segment to an AC, while a forwarder on a switching PE (S-PE)
   binds one PW segment to another PW segment.  In each direction
   between the PEs, PW packets are transported by a PSN tunnel, which is
   called a transport tunnel.

   In order to protect a layer-2 service against network failures, it is
   necessary to protect every link and node along the entire data path,
   including ingress AC, ingress (T-)PE, intermediate routers of
   transport tunnel, S-PEs, egress (T-)PE, and egress AC.  To minimize
   service disruption, it is also desirable that each of these
   components is protected by a fast protection mechanism based on local
   repair.  Such a mechanism generally involves a bypass path that is
   pre-computed and pre-installed on a router adjacent to a failure.
   The bypass path has the property that it can guide traffic around the
   failure, while remaining unaffected by the topology changes resulting
   from the failure.  When the failure happens, the router can invoke
   the bypass path to redirect the traffic, achieving fast restoration
   for the service.

   Today, fast protection against ingress AC failure and ingress (T-)PE
   failure is achievable by using a multi-homed CE and redundant PWs,
   where the CE can detect the failures and move traffic onto a backup
   ingress AC.  Fast protection against failure of intermediate routers
   is achievable through RSVP fast-reroute (RFC 4090) and IP fast-
   reroute (RFC 5714 and RFC 5286).  However, there is a lack of such
   protection against egress AC failure, egress (T-)PE failure, and S-PE
   failure.  In these cases, service restoration has to rely on a global
   repair or control plane repair.  Global repair is normally driven by
   ingress CE or ingress (T-)PE, and dependent on end-to-end OAM.
   Control plane repair is dependent on protocol convergence.
   Therefore, both mechanisms are relatively slow in reacting to
   failures and restoring traffic.

   This document specifies a fast protection mechanism for PWs based on
   local repair technique.  It can protect PWs against the following
   types of failures.

   a.  Egress AC failure.





Shen, et al.            Expires December 27, 2012               [Page 3]


Internet-Draft     PW Endpoint Fast Failure Protection         June 2012


   b.  Egress PE failure: Node failure of egress PE of a SS-PW; Node
       failure of T-PE of an MS-PW.

   c.  Switching PE failure: Node failure of S-PE of an MS-PW.

   The mechanism is relevant to networks with redundant PWs and multi-
   homed CEs.  It is designed on the basis of MPLS upstream label
   assignment and context specific label switching (RFC 5331).  Fast
   protection refers to the ability to restore traffic upon a failure in
   the order of tens of milliseconds.  This is achieved by establishing
   local protection at the router adjacent to the failure.  Compared
   with the existing global repair and control plane repair mechanisms,
   this mechanism can provide faster restoration.  However, it is
   intended to complement those mechanisms, rather than replacing them
   in any way.

   The mechanism is applicable to LDP signaled PWs.


2.  Specification of Requirements

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119.


3.  Reference Models and Failure Cases

   This document refers to the following topologies to describe PW
   endpoint failures and protection procedures.  These topologies are
   commonly seen in an environment with multi-homed CEs and redundant
   PWs for global repair.  In this document the fast protection
   mechanism also use them for the local repair purposes.  This SHALL
   enable local repair and global repair to work in tandem to achieve
   broader scope of protection with better performance.
















Shen, et al.            Expires December 27, 2012               [Page 4]


Internet-Draft     PW Endpoint Fast Failure Protection         June 2012


3.1.  Single-Segment PW


                   |<-------------- PW1 --------------->|

               - PE1 -------------- P1 ---------------- PE2 -
              /                                              \
             /                                                \
          CE1                                                  CE2
             \                                                /
              \                                              /
               - PE3 -------------- P2 ---------------- PE4 -

                   |<-------------- PW2 --------------->|

                                 Figure 1

   In Figure 1, the IP/MPLS network consists of PE-routers and
   P-routers.  It provides an emulation of a layer-2 service between CE1
   and CE2.

   Each CE is multi-homed to two PEs.  Hence, there are two divergent
   paths between the CEs.  The first path uses PW1 established between
   PE1 and PE2, connecting the AC CE1-PE1 and the AC CE2-PE2.  The
   second path uses PW2 established between PE3 and PE4, connecting the
   AC CE1-PE3 and the AC CE2-PE4.  The operational states of all the PWs
   and ACs are up.  The transport tunnels of the PWs are not shown in
   this figure for clarity.

   At any given time, each CE sends traffic via only one AC and receives
   traffic via only one AC.  The two ACs MAY or MAY NOT be the same.
   The AC used to send traffic is determined by the CE, and MAY rely on
   an end-to-end OAM mechanism between the CEs.  The AC used for the CE
   to receive traffic is determined by the state of the network and the
   protection mechanism in use, as described later in this document.

   From the perspective of traffic towards a given CE, the set of PWs,
   PEs and ACs involved can be viewed to serve primary and backup (or
   active and standby) roles.  When the network is in a steady state,
   the PW that is intended to carry the traffic is referred to as a
   primary PW.  The PE at the egress of the primary PW is a primary PE.
   The AC connecting the CE and the primary PE is a primary AC.  The
   other PW that may be used to carry the traffic upon a network failure
   are referred to as a backup PW.  The PE at the egress of the backup
   PW is a backup PE.  The AC connecting the CE and the backup PE is a
   backup AC.

   In this document, the following primary and backup roles are assigned



Shen, et al.            Expires December 27, 2012               [Page 5]


Internet-Draft     PW Endpoint Fast Failure Protection         June 2012


   for the traffic going from CE1 to CE2:

      Primary PW: PW1

      Primary PE: PE2

      Primary AC: CE2-PE2

      Backup PW: PW2

      Backup PE: PE4

      Backup AC: CE2-PE4

   In this case, an egress AC failure refers to the failure of the
   primary AC, i.e. the AC CE2-PE2.  An egress node failure refers to
   the failure of the primary PE, i.e.  PE2.

   The backup PE, backup PW and backup AC may be used to carry the
   traffic when CE1 and CE2 switches traffic to PW2 during a global
   repair, or when a local repair takes effect, as described later in
   this document.


                   |<-------------- PW1 --------------->|

                      ------------- P1 ---------------- PE2 -
                     /                                       \
                    /                                         \
          CE1 -- PE1                                          CE2
                    \                                         /
                     \                                       /
                      ------------- P2 ---------------- PE4 -

                    |<-------------- PW2 --------------->|

                                 Figure 2

   Figure 2 shows another possible scenario, where CE1 is single-homed
   to PE1, while CE2 remains multi-homed to PE2 and PE4.  From the
   perspective of egress protection for the traffic from CE1 to CE2,
   this topology is not much different than Figure 1.  However, for the
   traffic in the opposite direction, i.e. from CE2 to CE1, PE1 must
   anticipate the traffic on PW1 and PW2, and sends it to CE1 over the
   AC CE1-PE1 in both cases.






Shen, et al.            Expires December 27, 2012               [Page 6]


Internet-Draft     PW Endpoint Fast Failure Protection         June 2012


3.2.  Multi-Segment PW


                  |<--------------- PW1 --------------->|
                  |<----- SEG1 ----->|<----- SEG2 ----->|

             - TPE1 -------------- SPE1 --------------- TPE2 -
            /                                                 \
           /                                                   \
        CE1                                                     CE2
           \                                                   /
            \                                                 /
             - TPE3 -------------- SPE2 --------------- TPE4 -

                  |<----- SEG3 ----->|<----- SEG4 ----->|
                  |<--------------- PW2 --------------->|

                                 Figure 3

   Figure 3 shows a topology that is similar to Figure 1 but in an MS-PW
   environment.  PW1 and PW2 are both MS-PWs.  PW1 is established
   between TPE1 and TPE2, and switched between segments SEG1 and SEG2 at
   SPE1.  PW2 is established between TPE3 and TPE4, and switched between
   segments SEG3 and SEG4 at SPE2.  CE1 is multi-homed to TPE1 and TPE3.
   CE2 is multi-homed to TPE2 and TPE4.  The transport tunnels of the PW
   segments are not shown in this figure for clarity.

   In this document, the following primary and backup roles are assigned
   for the traffic going from CE1 to CE2:

      Primary PW: PW1

      Primary T-PE: TPE2

      Primary S-PE: SPE1

      Primary AC: CE2-TPE2

      Backup PW: PW2

      Backup T-PE: TPE4

      Backup S-PE: SPE2

      Backup AC: CE2-TPE4

   In this case, an egress AC failure refers to the failure of the
   primary AC, i.e. the AC CE2-TPE2.  An egress node failure refers to



Shen, et al.            Expires December 27, 2012               [Page 7]


Internet-Draft     PW Endpoint Fast Failure Protection         June 2012


   the failure of the primary T-PE, i.e.  TPE2.  In addition, an
   switching node failure refers to the failure of the primary S-PE,
   i.e.  SPE1.

   The backup T-PE, backup PW and backup AC are used for protecting the
   primary PW against egress AC failure and egress node failure.  The
   backup S-PE and the backup PW are used for protecting the primary PW
   against switching node failure, as described later in this document.

   For consistency with the SS-PW scenario, primary T-PEs and a primary
   S-PEs may simply be referred to as primary PEs in this document,
   where specifics is not required.  Similarly, backup T-PEs and backup
   S-PEs may be referred to as backup PEs.


4.  Theory of Operation

   The fast protection mechanism in this document provides three types
   of protection for PWs, corresponding to the three types of failures
   described in Section 1.

   a.  Egress AC protection

   b.  Egress (T-)PE node protection

   c.  S-PE node protection

   The mechanism is only relevant when the target CE is multi-homed to a
   primary PE and a backup PE, and when there is a backup PW in the
   network.  In S-PE node protection, it is also assumed that there is a
   backup S-PE on the backup PW.

4.1.  Local Repair and Protector

   The mechanism relies on local repair to be performed by routers
   adjacent to failures.  Each of these routers is referred to as a
   "point of local repair" (PLR).  A PLR MUST be able to detect a
   failure by using a rapid mechanism, such as physical layer failure
   detection, Bidirectional Failure Detection (BFD) (RFC 5880), etc.  In
   anticipation of the failure, the PLR MUST also pre-establish a bypass
   PSN tunnel to a "protector", and pre-install a bypass route in the
   FIB (forwarding information base).  The bypass tunnel has the
   property that it is not affected by the topology changes caused by
   the failure.  Upon detecting the failure, the PLR MUST invoke the
   bypass route and forward traffic to the protector through the bypass
   tunnel.  The protector MUST in turn forward the traffic towards the
   target CE, which may or may not be directly attached to the
   protector.  This procedure is referred to as local repair.



Shen, et al.            Expires December 27, 2012               [Page 8]


Internet-Draft     PW Endpoint Fast Failure Protection         June 2012


   Different routers may serve as PLRs and protectors in different
   scenarios.

   o  In egress AC protection, the PLR is the primary PE that hosts the
      primary AC, and the protector is the backup PE (Figure 4).


                   |<-------------- PW1 --------------->|

               - PE1 -------------- P1 ---------------- PE2 -
              /                                         PLR  \
             /                                           |    \
          CE1                                      bypass|     CE2
             \                                           |    /
              \                                          |   /
               - PE3 -------------- P2 ---------------- PE4 -
                                                     protector

                   |<-------------- PW2 --------------->|

                                   Figure 4

   o  In egress PE node protection, the PLR is the penultimate hop
      router of transport tunnel of primary PW, and the protector is the
      backup PE (Figure 5).


                   |<-------------- PW1 --------------->|

               - PE1 -------------- P1 ------- P3 ----- PE2 -
              /                               PLR \          \
             /                                     \          \
          CE1                                 bypass\          CE2
             \                                       \        /
              \                                       \      /
               - PE3 -------------- P2 ---------------- PE4 -
                                                     protector

                   |<-------------- PW2 --------------->|

                                   Figure 5

   o  In S-PE node protection, the PLR is the penultimate hop router of
      transport tunnel of primary PW segment, and the protector is the
      backup S-PE (Figure 6).






Shen, et al.            Expires December 27, 2012               [Page 9]


Internet-Draft     PW Endpoint Fast Failure Protection         June 2012


                  |<--------------- PW1 --------------->|
                  |<----- SEG1 ----->|<----- SEG2 ----->|

             - TPE1 ----- P4  ----- SPE1 -------------- TPE2 -
            /             PLR \                               \
           /                   \                               \
        CE1               bypass\                               CE2
           \                     \                             /
            \                     \                           /
             - TPE3 --------------- SPE2 -------------- TPE4 -
                                 protector

                  |<----- SEG3 ----->|<----- SEG4 ----->|
                  |<--------------- PW2 --------------->|

                                   Figure 6

   When a PLR forwards traffic through a bypass tunnel to a protector,
   it MUST keep the original PW label intact.  In particular, it SHOULD
   NOT forward the traffic based on the PW label or modify the PW label.
   Such forwarding state on the PLR has the advantages that it
   represents simple forwarding operations and it is easy to set up.
   The PLR does not need to learn PW labels or install bypass routes on
   a per PW label basis.

   This also means that the protector MUST forward the traffic based on
   a PW label that is assigned by the primary PE, and ensure that the
   traffic can eventually reach the target CE.  From the protector's
   perspective, this PW label is an upstream assigned label (RFC 5331).
   This is accomplished by learning the PW label from the primary PE,
   installing the proper forwarding state for the PW label in the label
   space associated with the primary PE, and performing PW label lookup
   in this label space.

   A protector MAY be a backup (S-)PE as illustrated in the above
   examples, or a dedicated router that assumes such a role.  In the
   later case, the protector is not necessarily the backup (S-)PE of a
   given primary PW.  During a local repair, the PLR still forwards
   traffic to the protector through a bypass tunnel, and the protector
   MUST then forward the traffic to the backup (S-)PE, which finally
   forwards the traffic to the target CE via a backup AC or a backup PW
   segment.  More detail will be provided in Section 4.3.

   A protector MAY protect primary PWs for one or multiple primary PEs.
   The protector MUST maintain a separate label space for each primary
   PE.  Likewise, the primary PWs hosted by a primary PE MAY be
   protected by multiple protectors, each for a subset of the PWs.  In
   any case, a primary PW is associated with one and only one pair of



Shen, et al.            Expires December 27, 2012              [Page 10]


Internet-Draft     PW Endpoint Fast Failure Protection         June 2012


   {primary PE, protector}.

4.2.  Context Identifier

   An IPv4/v6 address is assigned to each ordered pair of {primary PE,
   protector} to facilitate protection establishment.  This address is
   referred to as a "context identifier".  It MUST be globally unique,
   or unique within the address space of the network where the primary
   PE and the protector reside.

4.2.1.  Uses of Context Identifier

   A context identifier serves two purposes.

   o  It identifies a primary PE and an associated protector.  In other
      words, it identifies a primary PE on a per protector basis.  A
      given primary PE may be protected by multiple protectors, each for
      a subset of the primary PWs hosted by the primary PE.  Therefore,
      a distinct context identifier MUST be assigned to the primary PE
      for each protector.

      For a primary PW, its transport tunnel MUST be destined for the
      context identifier of its {primary PE, protector}, rather than an
      IP address of the primary PE.  This not only enables the transport
      tunnel to follow a path to the primary PE, but also indicates the
      protector to the PLR(s).

   o  It indicates the primary PE's label space to a protector.  The
      protector may protect primary PWs for multiple primary PEs.  It
      MUST maintain a separate label space for each primary PE.  PW
      labels assigned by a given primary PE MUST be associated with the
      label space indicated by the context identifier of the {primary
      PE, protector}.  The association is accomplished as below.

      When the primary PE advertises the label of a primary PW to the
      protector, it MUST attach the information of the context
      identifier (Section 4.7).  Upon receiving the advertisement, the
      protector MUST install the PW label in the label space
      corresponding to the context identifier.

      A bypass tunnel MUST be destined for the context identifier,
      rather than an IP address of the protector.  Therefore, the bypass
      tunnel (either MPLS tunnel label or IP tunnel destination address)
      is equivalent to the context identifier.  All packets received on
      the bypass tunnel MUST be forwarded in the label space indicated
      by the bypass tunnel.





Shen, et al.            Expires December 27, 2012              [Page 11]


Internet-Draft     PW Endpoint Fast Failure Protection         June 2012


4.2.2.  Advertisement and Path Computation

   Using a context identifier as destination for both transport and
   bypass tunnels imposes the following requirements on path computation
   for these tunnels.

   o  On the ingress PE, path computation for a transport tunnel MUST
      choose the primary PE as the endpoint.

   o  On a PLR, path computation for a bypass tunnel MUST avoid the
      primary PE and choose the protector as the endpoint.  The path
      MUST NOT traverse the primary PE.

   In order to satisfy these requirements, a context identifier SHOULD
   be advertised by IGP and/or IGP-TE in the routing domain and/or the
   TE domain, depending on the tunnel technologies of the network.

   o  If RSVP-TE is used to establish both transport and bypass tunnels,
      the context identifier MUST be advertised by IGP-TE.

   o  If IP or LDP is used to establish both transport and bypass
      tunnels, the context identifier MUST be advertised by IGP.

   o  If IP or LDP is used for transport tunnels while RSVP-TE is used
      for bypass tunnels, or vice versa, the context identifier MUST be
      advertised by both IGP and IGP-TE.

   In any case, it is recommended that the context identifier SHOULD be
   advertised as a proxy node that is dual-attached to the primary PE
   and the protector via unnumbered point-to-point interfaces, as shown
   in Figure 7.  This schema ensures that the CSPF (constrained shortest
   path first), LFA (loop free alternate; RFC 5286) and MRT (maximally
   redundant trees; [IP-LDP-FRR-MRT]) algorithms can compute the
   expected paths for the transport tunnel and bypass tunnel, whether
   the tunnels are MPLS tunnels or IP tunnels.
















Shen, et al.            Expires December 27, 2012              [Page 12]


Internet-Draft     PW Endpoint Fast Failure Protection         June 2012


          primary PE -
                      \ metric 1, TE metric 1, bandwidth max
                       \
                        \
                         \
                          \ metric max, TE metric max, bandwidth 0
                           |
                      proxy node
                           |
                          / metric max, TE metric max, bandwidth 0
                         /
                        /
                       /
                      / metric X, TE metric Y, bandwidth max
           protector -

                                 Figure 7

   o  The primary PE advertises an unnumbered link to the proxy node,
      with metric 1, TE metric 1, and maximum bandwidth.

   o  The protector advertises an unnumbered link to the proxy node,
      with metric X, TE metric Y, and maximum bandwidth.  X SHOULD be
      carefully chosen so that the path from any given source node
      (ingress PE or PLR) via the protector to the proxy node will have
      a higher metric than the corresponding path from the source node
      via the primary PE to the proxy node.  The same requirement
      applies to Y as well for TE paths.

   o  The primary PE advertises the proxy node with two unnumbered links
      to the primary PE and the protector, respectively.  The router ID
      of the proxy node is the context identifier.  Both unnumbered
      links are advertised with maximum metric, maximum TE metric, and
      zero bandwidth.  This ensures that the proxy node does not serve
      as a transit node for any paths.

      In the case of ISIS [ISO10589], the system ID is derived from the
      context identifier with Binary Coded Decimal (BCD) encoding.  The
      resulting system-ID MUST be unique.  The LSP (Link State Packet)
      MUST include an Area Address TLV, and MAY include a Dynamic
      Hostname TLV.  The area addresses MUST be a subset of or
      preferably identical to those advertised by the primary PE at the
      corresponding level.  The hostname MAY be derived from the context
      identifier and the primary PE's hostname.  The Overload bit MUST
      be set to 1.  The Attached and the Partition Repair bits MUST be
      set to 0.

      In the case of OSPF (RFC 2328), the Advertising Router and Link



Shen, et al.            Expires December 27, 2012              [Page 13]


Internet-Draft     PW Endpoint Fast Failure Protection         June 2012


      State ID of the router LSA (Link State Advertisement) MUST both be
      the context identifier.  All options bits in the router LSA MUST
      be set to zero.

   With this schema, the proxy node is reachable via both the primary PE
   and the protector in the routing domain and the TE domain.  For any
   given ingress PE or PLR, the path via the primary PE to the proxy
   node is considered to have a higher preference than the path via the
   protector, due to the lower metric.  Therefore, in path computation
   for a transport tunnel, a path via the primary PE SHOULD always be
   selected.  However, in path computation for a bypass tunnel, where
   the primary PE must be avoided, a path via the protector SHOULD be
   selected.

4.3.  Protection Models

   There are two protection models based on the location and role of a
   protector.  A network MAY use either protection model, or a
   combination of both.

   1.  Co-located protector

       In this model, the protector is a backup PE that is directly
       connected to the target CE via a backup AC, or it is a backup
       S-PE on a backup PW.  That is, the protector is co-located with
       the backup (S-)PE.  Examples of this model have been introduced
       in Figure 4, Figure 5 and Figure 6 in Section 4.1.

       In egress AC protection and egress PE node protection, when a
       protector receives traffic from the PLR, it forwards the traffic
       to the CE via the backup AC.  This is shown in Figure 8, where
       PE2 is the PLR for egress AC failure, P3 is the PLR for PE2
       failure, and PE4 (the backup PE) is the protector.


















Shen, et al.            Expires December 27, 2012              [Page 14]


Internet-Draft     PW Endpoint Fast Failure Protection         June 2012


                 |<-------------- PW1 --------------->|

             - PE1 -------------- P1 ------- P3 ----- PE2 ----
            /                               PLR \     PLR     \
           /                                     \     |       \
        CE1                                 bypass\    |bypass  CE2
           \                                       \   |       /
            \                                       \  |      /
             - PE3 -------------- P2 ---------------- PE4 ----
                                                   protector

                 |<-------------- PW2 --------------->|

                                   Figure 8


       In S-PE node protection, when a protector receives traffic from
       the PLR, it MUST forward the traffic via the next segment of the
       backup PW.  The T-PE of the backup PW MUST forward the traffic to
       the CE via a backup AC.  This is shown in Figure 9, where P4 is
       the PLR for SPE1 failure, and SPE2 (the backup S-PE) is the
       protector for SPE1 (the primary S-PE).


                  |<--------------- PW1 --------------->|
                  |<----- SEG1 ----->|<----- SEG2 ----->|

             - TPE1 ----- P4  ----- SPE1 -------------- TPE2 -
            /             PLR \                               \
           /                   \                               \
        CE1               bypass\                               CE2
           \                     \                             /
            \                     \                           /
             - TPE3 --------------- SPE2 -------------- TPE4 -
                                 protector

                  |<----- SEG3 ----->|<----- SEG4 ----->|
                  |<--------------- PW2 --------------->|

                                   Figure 9


       In the co-located protector model, the number of context
       identifiers required by a network is the number of distinct
       {primary PE, backup PE} pairs.  Therefore, the model is suitable
       for scenarios where the number backup PEs for any given primary
       PE is relatively small.




Shen, et al.            Expires December 27, 2012              [Page 15]


Internet-Draft     PW Endpoint Fast Failure Protection         June 2012


   2.  Centralized protector

       In this model, the protector is a dedicated P router or PE router
       that protects all the primary PWs for one or multiple primary
       PEs.  In egress AC protection and egress PE node protection, the
       protector MAY or MAY NOT be a backup PE with a direct connection
       to the target CE.  In S-PE node protection, it MAY or MAY NOT be
       a backup S-PE of the backup PW.

       In egress AC protection and egress PE node protection, when the
       protector receives traffic from the PLR, if the protector has a
       direct connection (i.e. backup AC) to the CE, it MUST forward the
       traffic to the CE via the backup AC, which is similar to
       Figure 8.  Otherwise, it MUST forward the traffic to a backup PE,
       which MUST then forward the traffic to the CE via a backup AC.
       This is shown in Figure 10, where the protector receives traffic
       from P3 or PE2 (the PLRs) and forwards the traffic to PE4 (the
       backup PE).  The protector may be protecting other PWs as well,
       which are not shown in this figure.


                   |<------------- PW1 --------------->|

               - PE1 ------------- P1 ------- P3 ----- PE2 --
              /                              PLR \     PLR   \
             /                                    \     /     \
            /                                bypass\   /bypass \
           /                                        \ /         \
        CE1                                      protector       CE2
           \                                         \          /
            \                                         \        /
             \                                         \      /
              \                                         \    /
               - PE3 ------------- P2 -----------------PE4 --

                   |<------------- PW2 --------------->|

                                   Figure 10


       In S-PE node protection, when the protector receives traffic from
       the PLR, if the protector is a backup S-PE of the backup PW, it
       MUST forward the traffic via the next segment of the backup PW,
       and the T-PE of the backup PW MUST forward the traffic to the CE
       via a backup AC, which is similar to Figure 9.  Otherwise, the
       protector MUST first forward the traffic to the backup S-PE,
       which MUST then forward the traffic via the next segment of the
       backup PW.  Finally, the T-PE of the backup PW MUST forward the



Shen, et al.            Expires December 27, 2012              [Page 16]


Internet-Draft     PW Endpoint Fast Failure Protection         June 2012


       traffic to the CE via a backup AC.  This is shown in Figure 11,
       where the protector forwards traffic to SPE2 (the backup S-PE).
       The protector may be protecting other PW segments as well, which
       are not shown in this figure.


                  |<--------------- PW1 --------------->|
                  |<----- SEG1 ----->|<----- SEG2 ----->|

             - TPE1 ----- P4  ----- SPE1 -------------- TPE2 -
            /             PLR \                               \
           /                   \                               \
          /               bypass\                               \
         /                       \                               \
      CE1                     protector                           CE2
         \                        \                              /
          \                        \                            /
           \                        \                          /
            \                        \                        /
             - TPE3 --------------- SPE2 -------------- TPE4 -

                  |<----- SEG3 ----->|<----- SEG4 ----->|
                  |<--------------- PW2 --------------->|

                                   Figure 11


       In the centralized protector model, each primary PE MAY only need
       one protector to protect all of its PWs.  Therefore, the number
       of context identifiers required by a network can be as low as the
       number of primary PEs.

4.4.  Transport Tunnel

   The ingress PE of a primary PW (or PW segment) associates the PW with
   the primary egress PE through LDP signaling.  The ingress PE MUST
   also associate the transport tunnel of the PW with the context
   identifier of the {primary PE, protector} of the PW.  In particular,
   the destination of the transport tunnel MUST be the context
   identifier (Section 4.2.1).  This not only ensures PW traffic to be
   transported to the primary PE, but also facilitates bypass tunnel
   establishment for PLR(s), as the context identifier implies both the
   primary PE and the protector.

   The association between the transport tunnel and the context
   identifier MAY be achieved by configuration or an auto-discovery
   mechanism.  In the later case, the ingress PE MAY learn the context
   identifier from the primary PE, if the primary PE advertises the



Shen, et al.            Expires December 27, 2012              [Page 17]


Internet-Draft     PW Endpoint Fast Failure Protection         June 2012


   context identifier as "third party next hop" in an IPv4/v6
   Interface_ID TLV (RFC 3471, RFC 3472) in LDP Label Mapping message.

4.5.  Bypass Tunnel

   A PLR may provide protection for multiple primary PWs associated with
   one or multiple pairs of {primary PE, protector}.  The PLR MUST
   establish a bypass tunnel to each protector for each distinct context
   identifier associated with the protector.  The destination of the
   bypass tunnel MUST be the context identifier, as described in
   Section 4.2.1.  The association between the destination and the
   context identifier can be achieved by PLR learning or inheriting
   destination address from the transport tunnel.

   For examples, in Figure 8 and Figure 10, a bypass tunnel is
   established from PE2 (PLR for egress AC failure) to the protector,
   and another bypass tunnel is established from P3 (PLR for egress node
   failure) to the protector.  In Figure 9 and Figure 11, a bypass
   tunnel is established from P4 (PLR for switching node failure) to the
   protector.

   During a local repair, the PLR forwards traffic to the protector
   through the bypass tunnel with PW label intact.  This normally
   involves pushing an MPLS label to the label stack, if the bypass
   tunnel is an MPLS tunnel, or pushing an IP header to the packet, if
   the bypass tunnel is an IP tunnel.  The protector MUST then forward
   the traffic based on this PW label, i.e. an upstream assigned label.
   In order to perform such forwarding, the protector MUST treat the
   bypass tunnel as a context to determine the primary PE's label space.
   Specifically, if the bypass tunnel is an MPLS tunnel, the protector
   MUST assign a non-reserved label for the bypass tunnel, and use this
   label as the context.  If the bypass tunnel is an IP tunnel, the
   destination address in its IP header should be the context
   identifier.

   A bypass tunnel MUST have the property that it is not affected by the
   topology changes caused by the failure that the bypass tunnel
   protects against.  Therefore, it can be used to transmit traffic
   during the convergence period of routing protocols and the delay of
   global repair.  It will remain effective, until the current transport
   tunnel is rerouted around the failure, or the traffic is moved to
   another PW or transport tunnel.

4.6.  PW Forwarding State on Protector

   A protector MUST be able to forward traffic based on the PW label
   assigned by a primary PE.  Therefore, it MUST learn the PW labels
   from all the primary PEs that it protects (Section 4.7), and maintain



Shen, et al.            Expires December 27, 2012              [Page 18]


Internet-Draft     PW Endpoint Fast Failure Protection         June 2012


   the PW labels in separate label spaces for the primary PEs.

   In the control plane, a primary PE's label space is identified by the
   context identifier of the {primary PE, protector}.  When the
   protector learns a PW label from the primary PE, it MUST associate
   the PW label with the label space via this context identifier.  In
   the forwarding plane, the label space is indicated by bypass tunnels
   that are destined for the context identifier.

4.6.1.  Co-located Protector

   In Figure 12, PE4 is a co-located protector that protects PW1 against
   egress AC failure and egress node failure.  It maintains a label
   space for PE2, which is identified by the context identifier of {PE2,
   PE4}.  It learns from PE2 the label that PE2 has assigned to PW1, and
   installs an forwarding entry for the label in the label space.  The
   nexthop of the forwarding entry indicates a label pop with outgoing
   interface pointing to the backup AC CE2-PE4.


                 |<-------------- PW1 --------------->|

             - PE1 -------------- P1 ------- P3 ----- PE2 ----
            /                               PLR \     PLR     \
           /                                     \     |       \
        CE1                                 bypass\    |bypass  CE2
           \                                       \   |       /
            \                                       \  |      /
             - PE3 -------------- P2 ---------------- PE4 ----
                                                   protector

                 |<-------------- PW2 --------------->|

                                 Figure 12

   In Figure 13, SPE2 is a co-located protector that protects PW1
   against switching node failure.  It maintains a label space for SPE1,
   which is identified by the context identifier of {SPE1, SPE2}.  It
   learns the label that SPE1 has assigned to the PW segment SEG1, and
   installs a forwarding entry in the label space.  The nexthop of the
   forwarding entry indicates a label swap to the label of the PW
   segment SEG4.









Shen, et al.            Expires December 27, 2012              [Page 19]


Internet-Draft     PW Endpoint Fast Failure Protection         June 2012


                  |<--------------- PW1 --------------->|
                  |<----- SEG1 ----->|<----- SEG2 ----->|

             - TPE1 ----- P4  ----- SPE1 --------------- TPE2 -
            /             PLR \                                \
           /                   \                                \
        CE1               bypass\                                CE2
           \                     \                              /
            \                     \                            /
             - TPE3 --------------- SPE2 --------------- TPE4 -
                                 protector

                  |<----- SEG3 ----->|<----- SEG4 ----->|
                  |<--------------- PW2 --------------->|

                                 Figure 13

4.6.2.  Centralized Protector

   In the centralized protector model, for each primary PW of which the
   protector is not a backup (S-)PE, the protector MUST also learn the
   label of the backup PW from the backup (S-)PE (Section 4.8).  This is
   the backup (S-)PE that the protector will forward traffic to.  The
   protector MUST use the label as the outgoing label for the forwarding
   entry of the primary PW label.

   In Figure 14, the protector is a centralized protector that protects
   PW1 against egress AC failure and egress node failure.  It maintains
   a label space for PE2, which is identified by the context identifier
   of {PE2, protector}.  It learns from PE2 the label that PE2 has
   assigned to PW1, and learns from PE4 the label that PE4 has assigned
   to PW2.  It installs a forwarding entry for PW1's label in the label
   space.  The nexthop of the forwarding entry indicates a label swap to
   PW2's label.

















Shen, et al.            Expires December 27, 2012              [Page 20]


Internet-Draft     PW Endpoint Fast Failure Protection         June 2012


                   |<------------- PW1 --------------->|

               - PE1 ------------- P1 ------- P3 ----- PE2 --
              /                              PLR \     PLR   \
             /                                    \     /     \
            /                                bypass\   /bypass \
           /                                        \ /         \
        CE1                                      protector       CE2
           \                                         \          /
            \                                         \        /
             \                                         \      /
              \                                         \    /
               - PE3 ------------- P2 -----------------PE4 --

                   |<------------- PW2 --------------->|

                                 Figure 14

   In Figure 15, the protector is a centralized protector that protects
   the PW segment SEG1 of PW1 against switching node failure of SPE1.
   It maintains a label space for SPE1, which is identified by the
   context identifier of {SPE1, protector}.  It learns from SPE1 the
   label that SPE1 has assigned to SEG1, and learns from SPE2 the label
   that SPE2 has assigned to SEG3.  It installs a forwarding entry for
   SEG1's label in the label space.  The nexthop of the forwarding entry
   indicates a label swap to SEG3's label.

























Shen, et al.            Expires December 27, 2012              [Page 21]


Internet-Draft     PW Endpoint Fast Failure Protection         June 2012


                  |<--------------- PW1 --------------->|
                  |<----- SEG1 ----->|<----- SEG2 ----->|

             - TPE1 ----- P4  ----- SPE1 -------------- TPE2 -
            /             PLR \                               \
           /                   \                               \
          /               bypass\                               \
         /                       \                               \
      CE1                     protector                           CE2
         \                        \                              /
          \                        \                            /
           \                        \                          /
            \                        \                        /
             - TPE3 --------------- SPE2 -------------- TPE4 -

                  |<----- SEG3 ----->|<----- SEG4 ----->|
                  |<--------------- PW2 --------------->|

                                 Figure 15

4.7.  PW Label Distribution from Primary PE to Protector

   A primary PE MUST distribute the label of each primary PW to the
   protector that protects the PW.  To achieve this, the primary PE MUST
   establish a targeted LDP session with the protector.  For each
   primary PW, the primary PE SHOULD advertise over that session a
   Protection FEC Element via Label Mapping message.  The Protection FEC
   Element is a new LDP FEC, and its encoding is described below.  The
   PW's label is encoded in the message using the Upstream-Assigned
   Label TLV defined in (RFC 6389).  The Protection FEC Element and the
   PW label combined represent the primary PE's forwarding state for the
   PW.  The Label Mapping message SHOULD also carry an IPv4/v6
   Interface_ID TLV (RFC 6389, RFC 3471) encoded with the context
   identifier of the {primary PE, protector}.

   The protector that receives this Label Mapping message SHOULD install
   a forwarding entry for the PW label in the label space identified by
   the context identifier.  The nexthop of the forwarding entry SHOULD
   allow packets to be sent towards the target CE via a backup AC or a
   backup (S-)PE, depending on the protection model and SS-PW or MS-PW
   scenario involved.

   The Protection FEC Element has type 0x83.  It is defined as below:








Shen, et al.            Expires December 27, 2012              [Page 22]


Internet-Draft     PW Endpoint Fast Failure Protection         June 2012


      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Type(0x83)  |    Reserved   | Encoding Type |    Length     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     |                                                               |
     ~                         PW Information                        ~
     |                                                               |
     |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                                 Figure 16

   - Encoding Type

      Type of format that PW Information field is encoded.

   - Length

      Length of PW Information field in octets.

   - PW Information

      Field of variable length that specifies a PW

   For Encoding Type, 1 is defined for the PWid FEC Element format, and
   2 is defined for the Generalized PWid FEC Element format (RFC 4447).






















Shen, et al.            Expires December 27, 2012              [Page 23]


Internet-Draft     PW Endpoint Fast Failure Protection         June 2012


4.7.1.  Protection FEC Element Encoding for PWid


      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Type(0x83)  |    Reserved   |  Enc Type(1)  |   Length(16)  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                      Ingress PE Address                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                       Egress PE Address                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                            Group ID                           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                             PW ID                             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |C|           PW Type           |           Reserved            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                                 Figure 17

   - Ingress PE Address

      IP address of the ingress PE of PW.

   - Egress PE Address

      IP address of the egress PE of PW.

   - Group ID

      An arbitrary 32-bit value that represents a group of PWs and that
      is used to create groups in the PW space.

   - PW ID

      A non-zero 32-bit connection ID that, together with the PW Type
      field, identifies a particular PW.

   - Control word bit (C)

      A bit that flags the presence of a control word on this PW.  If C
      = 1, control word is present; If C = 0, control word is not
      present.

   - PW Type





Shen, et al.            Expires December 27, 2012              [Page 24]


Internet-Draft     PW Endpoint Fast Failure Protection         June 2012


      A 15-bit quantity that represents the type of PW.

4.7.2.  Protection FEC Element Encoding for Generalized PWid


      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Type(0x83)  |    Reserved   |  Enc Type(2)  |   Length      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                      Ingress PE Address                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                       Egress PE Address                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |C|           PW Type           |           Reserved            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   AGI Type    |    Length     |      Value                    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ~                    AGI  Value (contd.)                        ~
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   AII Type    |    Length     |      Value                    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ~                   SAII  Value (contd.)                        ~
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   AII Type    |    Length     |      Value                    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ~                   TAII Value (contd.)                         ~
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                                 Figure 18

   - Ingress PE Address

      IP address of the ingress PE of PW.

   - Egress PE Address

      IP address of the egress PE of PW.

   - Control word bit (C)

      A bit that flags the presence of a control word on this PW.  If C
      = 1, control word is present; If C = 0, control word is not
      present.




Shen, et al.            Expires December 27, 2012              [Page 25]


Internet-Draft     PW Endpoint Fast Failure Protection         June 2012


   - PW Type

      A 15-bit quantity that represents the type of PW.

   - AGI Type, Length, Value, AGI Value

      Attachment Group Identifier of PW.

   - SAII Type, Length, Value, SAII Value

      Source Attachment Individual Identifier of PW.

   - TAII Type, Length, Value, TAII Value

      Target Attachment Individual Identifier of PW.

4.8.  PW Label Distribution from Backup PE to Protector

   In the centralized protector model, a protector may not be a backup
   (S-)PE for some primary PWs.  For these PWs, in addition to learning
   PW labels from the primary PEs, the protector MUST also learn the
   labels of backup PWs and backup PW segments from backup (S-)PEs.

   To achieve this, each backup (S-)PE MUST establish a targeted LDP
   session with the protector.  The backup PE SHOULD advertise over that
   session a Protection FEC Element for the backup PW via Label Mapping
   message.  The content of this Protection FEC Element MUST match the
   Protection FEC Element that the primary PE advertises to the
   protector (section 4.8).  The Label Mapping message SHOULD also
   include a Generic Label TLV encoded with the backup PW's label.  The
   context identifier SHOULD NOT be encoded in Interface_ID TLV in this
   message.  The Protection FEC Element and the backup PW's label
   combined represent the backup PE's forwarding state for the backup
   PW.

   The protector that receives this Label Mapping message SHOULD
   associate the backup PW with the primary PW, based on the common
   Protection FEC Element.  It SHOULD distinguish between the message
   from the primary PE and the message from the backup PE based on the
   presence and absence of context identifier in Interface_ID TLV.  It
   SHOULD install a forwarding entry for the primary PW's label in the
   label space identified by the context identifier.  The nexthop of the
   forwarding entry SHOULD indicate a label swap to the backup PW's
   label.







Shen, et al.            Expires December 27, 2012              [Page 26]


Internet-Draft     PW Endpoint Fast Failure Protection         June 2012


4.9.  Revertive Behavior

   After a local repair takes effect, PW traffic is redirected from a
   PLR to a protector and then to target CE.  There are three strategies
   for restoring the traffic to a fully working PW.

   o  Global revertive mode

      If the ingress CE is multi-homed (Figure 1), it MAY switch the
      traffic to a backup AC which is bound to a backup PW.  Or, if the
      ingress PE hosts a backup PW (Figure 2), it MAY switch the traffic
      to the backup PW.  These procedures are referred to as global
      repairs, and are driven by ingress CE or ingress PE.  Possible
      triggers of a global repair include PW status, OAM, and BFD.

   o  Control plane revertive mode

      In egress PE node protection and S-PE node protection, it is
      possible that the failure is limited to the link between the PLR
      and the primary (S-)PE, while the primary (S-)PE is still up.  In
      this case, if the PLR or an upstream router along the transport
      tunnel can reach the primary (S-)PE via an alternative route, it
      MAY reroute the transport tunnel around the failed link, so that
      the transport tunnel can continue to carry the PW traffic to the
      primary (S-)PE.  This procedure is driven by control plane
      convergence, and is referred to as control plane repair.

   o  Local revertive mode

      The PLR MAY move traffic back to the primary PW, after the failure
      is resolved.  In egress AC protection, upon detecting that the
      primary AC is restored, the PLR MAY start forwarding traffic via
      the AC again.  Likewise, in egress PE node protection and
      switching node protection, upon detecting that the primary PE is
      restored, the PLR MAY re-establish the primary transport tunnel,
      move the traffic back to the tunnel.  These procedures are
      referred to as local reversion.

   The fast protection mechanism in this document SHOULD always be used
   in tandem with the globally revertive mode.  Particularly in the case
   of egress (S-)PE failure, if the ingress PE or the protector loses
   communication with the (S-)PE for an extensive period of time, the
   LDP session between them may go down.  Consequently, the ingress PE
   may bring down the primary PW, or the protector may delete the
   forwarding entry of the primary PW label from the label space.  In
   either case, the service will be disrupted.  In other words, although
   the fast protection can temporarily repair traffic, control plane
   states may eventually time out if the failure persists.  Therefore,



Shen, et al.            Expires December 27, 2012              [Page 27]


Internet-Draft     PW Endpoint Fast Failure Protection         June 2012


   it is recommended that the global revertive mode SHOULD always be
   established in advance, so that it can move traffic to a fully
   working backup PW shortly after the local repair.

   The control plane revertive mode is optional, because it only applies
   to the specific scenarios of egress PE failure and S-PE failure.

   The local revertive mode is optional.  In the circumstances where the
   failure is caused by resource flapping, local reversion MAY be
   dampened to limit potential disruptions.  Local revertive mode MAY be
   disabled completely by configuration.


5.  IANA Considerations

   IANA maintains a registry of LDP FECs at the registry "Label
   Distribution Protocol" in the sub-registry called "Forwarding
   Equivalence Class (FEC) Type Name Space".

   This document defines a new LDP Protection FEC Element in
   Section 4.7.  IANA has assigned the type value 0x83 to it.


6.  Security Considerations

   The security considerations discussed in RFC 5036, RFC 5331, RFC
   3209, and RFC 4090 apply to this document.


7.  Acknowledgements

   This document leverages work done by Hannes Gredler, Yakov Rekhter,
   Minto Jeyananth and several others on MPLS edge protection.  Thanks
   to Nischal Sheth, Bhupesh Kothari, and Kevin Wang for their
   contribution.  Thanks to Yakov Rekhter and John E Drake for reviewing
   the document.


8.  References

8.1.  Normative References

   [RFC3985]  Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to-
              Edge (PWE3) Architecture", RFC 3985, March 2005.

   [RFC5659]  Bocci, M. and S. Bryant, "An Architecture for Multi-
              Segment Pseudowire Emulation Edge-to-Edge", RFC 5659,
              October 2009.



Shen, et al.            Expires December 27, 2012              [Page 28]


Internet-Draft     PW Endpoint Fast Failure Protection         June 2012


   [RFC4447]  Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G.
              Heron, "Pseudowire Setup and Maintenance Using the Label
              Distribution Protocol (LDP)", RFC 4447, April 2006.

   [RFC5331]  Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream
              Label Assignment and Context-Specific Label Space",
              RFC 5331, August 2008.

   [RFC5036]  Andersson, L., Minei, I., and B. Thomas, "LDP
              Specification", RFC 5036, October 2007.

   [RFC2205]  Braden, B., Zhang, L., Berson, S., Herzog, S., and S.
              Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
              Functional Specification", RFC 2205, September 1997.

   [RFC3209]  Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
              and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
              Tunnels", RFC 3209, December 2001.

   [RFC4090]  Pan, P., Swallow, G., and A. Atlas, "Fast Reroute
              Extensions to RSVP-TE for LSP Tunnels", RFC 4090,
              May 2005.

   [RFC5286]  Atlas, A. and A. Zinin, "Basic Specification for IP Fast
              Reroute: Loop-Free Alternates", RFC 5286, September 2008.

   [RFC5714]  Shand, M. and S. Bryant, "IP Fast Reroute Framework",
              RFC 5714, January 2010.

   [RFC3471]  Berger, L., "Generalized Multi-Protocol Label Switching
              (GMPLS) Signaling Functional Description", RFC 3471,
              January 2003.

   [RFC3472]  Ashwood-Smith, P. and L. Berger, "Generalized Multi-
              Protocol Label Switching (GMPLS) Signaling Constraint-
              based Routed Label Distribution Protocol (CR-LDP)
              Extensions", RFC 3472, January 2003.

   [RFC3031]  Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
              Label Switching Architecture", RFC 3031, January 2001.

   [RFC2328]  Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.

   [RFC5880]  Katz, D. and D. Ward, "Bidirectional Forwarding Detection
              (BFD)", RFC 5880, June 2010.

   [RFC6389]  Aggarwal, R. and JL. Le Roux, "MPLS Upstream Label
              Assignment for LDP", RFC 6389, November 2011.



Shen, et al.            Expires December 27, 2012              [Page 29]


Internet-Draft     PW Endpoint Fast Failure Protection         June 2012


   [IP-LDP-FRR-MRT]
              Atlas, A. and R. Kebler, "An Architecture for IP/LDP Fast-
              Reroute Using Maximally Redundant Trees",
              draft-ietf-rtgwg-mrt-frr-architecture (work in progress),
              2011.

8.2.  Informative References

   [RFC5920]  Fang, L., "Security Framework for MPLS and GMPLS
              Networks", RFC 5920, July 2010.


Authors' Addresses

   Yimin Shen (editor)
   Juniper Networks
   10 Technology Park Drive
   Westford, MA  01886
   USA

   Phone: +1 9785890722
   Email: yshen@juniper.net


   Rahul Aggarwal
   Arktan, Inc

   Email: raggarwa_1@yahoo.com


   Wim Henderickx
   Alcatel-Lucent
   Copernicuslaan 50
   2018 Antwerp
   Belgium

   Email: wim.henderickx@alcatel-lucent.be














Shen, et al.            Expires December 27, 2012              [Page 30]