Internet DRAFT - draft-ietf-pwe3-redundancy

draft-ietf-pwe3-redundancy






Network Working Group                                           P. Muley
Internet-Draft                                               M. Aissaoui
Intended status: Informational                                  M. Bocci
Expires: December 29, 2012                                Alcatel-Lucent
                                                           June 27, 2012


                         Pseudowire Redundancy
                     draft-ietf-pwe3-redundancy-09

Abstract

   This document describes a framework comprised of a number of
   scenarios and associated requirements for pseudowire (PW) redundancy.
   A set of redundant PWs is configured between provider edge (PE) nodes
   in single -segment PW applications, or between terminating PE (T-PE)
   nodes in multi-segment PW applications.  In order for the PE/T-PE
   nodes to indicate the preferred PW to use for forwarding PW packets
   to one another, a new PW status is required to indicate the
   preferential forwarding status of active or standby for each PW in
   the redundant set.

Requirements Language

   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 [RFC2119].

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 29, 2012.

Copyright Notice

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



Muley, et al.           Expires December 29, 2012               [Page 1]

Internet-Draft                PW Redundancy                    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.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Reference Models . . . . . . . . . . . . . . . . . . . . . . .  5
     3.1.  PE Architecture  . . . . . . . . . . . . . . . . . . . . .  6
     3.2.  PW Redundancy Network Reference Scenarios  . . . . . . . .  6
       3.2.1.  PW Redundancy for AC and PE Protection: One
               Dual-Homed CE with Redundant SS-PWs  . . . . . . . . .  6
       3.2.2.  PW Redundancy for AC and PE Protection: Two
               Dual-Homed CEs with Redundant SS-PWs . . . . . . . . .  8
       3.2.3.  PW Redundancy for S-PE Protection: Single-Homed
               CEs with Redundant MS-PWs  . . . . . . . . . . . . . .  9
       3.2.4.  PW Redundancy for PE-rs Protection in H-VPLS using
               SS-PWs . . . . . . . . . . . . . . . . . . . . . . . . 11
       3.2.5.  PW Redundancy for PE Protection in a VPLS Ring
               using SS-PWs . . . . . . . . . . . . . . . . . . . . . 12
       3.2.6.  PW Redundancy for VPLS n-PE Protection using SS-PWs  . 13
   4.  Generic PW Redundancy Requirements . . . . . . . . . . . . . . 15
     4.1.  Protection Switching Requirements  . . . . . . . . . . . . 15
     4.2.  Operational Requirements . . . . . . . . . . . . . . . . . 15
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 16
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 16
   7.  Major Contributing Authors . . . . . . . . . . . . . . . . . . 16
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 17
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 18
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18









Muley, et al.           Expires December 29, 2012               [Page 2]

Internet-Draft                PW Redundancy                    June 2012


1.  Introduction

   The objective of pseudowire (PW) redundancy is to maintain
   connectivity across the packet switched network (PSN) used by the
   emulated service if a component in the path of the emulated service
   fails or a backup component is activated.  For example, PW redundancy
   will enable the correct PW to be used for forwarding emulated service
   packets when the connectivity of an attachment circuit (AC) changes
   due to the failure of an AC, or when a pseudowire (PW) or packet
   switched network (PSN) tunnel fails due to the failure of a provider
   edge (PE) node.

   PW redundancy uses redundant ACs, PEs, and PWs to eliminate single
   points of failure in the path of an emulated service.  This is
   achieved while ensuring that only one path between a pair of customer
   edge nodes (CEs) is active at any given time.  Mechanisms that rely
   on more than one active path between the CEs e.g. 1+1 protection
   switching, are out of scope of this document because they may require
   a permanent bridge to provide traffic replication as well as support
   for a 1+1 protection switching protocol in the CEs.

   Protection for a PW segment can be provided by the PSN layer.  This
   may be a resource reservation protocol with traffic engineering
   (RSVP-TE) labeled switched path (LSP) with a fast-reroute (FRR)
   backup or an end-to-end backup LSP.  These mechanisms can restore PSN
   connectivity rapidly enough to avoid triggering protection by PW
   redundancy.  PSN protection mechanisms cannot protect against the
   failure of a PE node or the failure of the remote AC.  Typically,
   this is supported by dual-homing a customer edge (CE) node to
   different PE nodes which provide a pseudowire emulated service across
   the PSN.  A set of PW mechanisms is therefore required that enables a
   primary and one or more backup PWs to terminate on different PE
   nodes.  An important requirement is that changes occurring on the
   dual-homed side of the network due to the failure of an AC or PE are
   not propagated to the ACs on the other side of the network.
   Furthermore, failures in the PSN are not propagated to the attached
   CEs.

   In cases where PSN protection mechanisms are not able to recover from
   a PSN failure, or where a failure of a switching PE (S-PE) may occur,
   a set of mechanisms that support the operation of a primary and one
   or more backup PWs via a different set of S-PEs or diverse PSN
   tunnels is therefore required.  For multi-segment PWs (MS-PWs), the
   paths of these PWs are diverse in that they are switched at different
   S-PE nodes.

   In both of these cases, PW redundancy is important to maximise the
   resiliency of the emulated service.  It supplements PSN protection



Muley, et al.           Expires December 29, 2012               [Page 3]

Internet-Draft                PW Redundancy                    June 2012


   techniques and can operate in addition to, or instead of those
   techniques when they are not available.

   This document describes a framework for these applications and its
   associated operational requirements.  The framework utilizes a new PW
   status, called the Preferential Forwarding Status of the PW.  This is
   separate from the operational states defined in RFC4446 [RFC4446].
   The mechanisms for PW redundancy are modeled on general protection
   switching principles.


2.  Terminology

   o  Up PW: A PW which has been configured (label mapping exchanged
      between PEs) and is not in any of the PW or AC defect states
      specified in [RFC4446].  Such a PW is available for forwarding
      traffic.

   o  Down PW: A PW that has either not been fully configured, or has
      been configured and is in any one of the PW or AC defect states
      specified in [RFC4446].  Such a PW is not available for forwarding
      traffic.

   o  Active PW: An up PW used for forwarding Operations, Administration
      and Maintenance (OAM), user plane and control plane traffic.

   o  Standby PW: An up PW that is not used for forwarding user traffic
      but may forward OAM and specific control plane traffic.

   o  PW Endpoint: A PE where a PW terminates on a point where native
      service processing is performed, e.g., A single-segment PW (SS-PW)
      PE, a multi-segment pseudowire (MS-PW) terminating PE (T-PE), or a
      hierarchical VPLS MTU-s or PE-rs.

   o  Primary PW: The PW which a PW endpoint activates (i.e. uses for
      forwarding) in preference to any other PW when more than one PW
      qualifies for the active state.  When the primary PW comes back up
      after a failure and qualifies for the active state, the PW
      endpoint always reverts to it.  The designation of primary is
      performed by local configuration for the PW at the PE and is only
      required when revertive behaviour is used and is not applicable
      when non-revertive protection switching is used.

   o  Secondary PW: When it qualifies for the active state, a secondary
      PW is only selected if no primary PW is configured or if the
      configured primary PW does not qualify for active state (e.g., is
      down).  By default, a PW in a redundancy PW set is considered
      secondary.  There is no revertive mechanism among secondary PWs.



Muley, et al.           Expires December 29, 2012               [Page 4]

Internet-Draft                PW Redundancy                    June 2012


   o  Revertive protection switching: Traffic will be carried by the
      primary PW if all of the following is true: It is up, a wait-to-
      restore timer expires, and the primary PW is made the active PW.

   o  Non-revertive protection switching: Traffic will be carried by the
      last PW selected as a result of previous active PW entering the
      operationally down state.

   o  Manual selection of a PW: The ability to manually select the
      primary/secondary PWs.

   o  MTU-s: A hierarchical virtual private LAN service multi-tenant
      unit switch, as defined in RFC4762 [RFC4762].

   o  PE-rs: A hierarchical virtual private LAN service switch, as
      defined in RFC4762.

   o  n-PE: A network facing provider edge node, as defined in RFC4026
      [RFC4026].

   o  1:1 protection: One specific subset of a path for an emulated
      service, consisting of a standby PW and/or AC, protects another
      specific subset of a path for the emulated service.  User traffic
      is transmitted over only one specific subset of the path at a
      time.

   o  N:1 protection: N specific subsets of paths for an emulated
      service, consisting of standby PWs and/or ACs, protect another
      specific subset of the path for the emulated service.  User
      traffic is transmitted over only one specific subset of the path
      at a time.

   o  1+1 protection: One specific subset of a path for an emulated
      service, consisting of a standby PW and/or AC, protects another
      specific subset of a path for the emulated service.  Traffic is
      permanently duplicated at the ingress node on both the currently
      active and standby subsets of the paths.

   This document uses the term 'PE' to be synonymous with both PEs as
   per RFC3985[RFC3985] and T-PEs as per RFC5659 [RFC5659].

   This document uses the term 'PW' to be synonymous with both PWs as
   per RFC3985 and SS-PWs, MS-PWs, and PW segments as per RFC5659.


3.  Reference Models

   The following sections show the reference architecture of the PE for



Muley, et al.           Expires December 29, 2012               [Page 5]

Internet-Draft                PW Redundancy                    June 2012


   PW redundancy and the usage of the architecture in different
   topologies and applications.

3.1.  PE Architecture

   Figure 1 shows the PE architecture for PW redundancy when more than
   one PW in a redundant set is associated with a single AC.  This is
   based on the architecture in Figure 4b of RFC3985 [RFC3985].  The
   forwarder selects which of the redundant PWs to use based on the
   criteria described in this document.

              +----------------------------------------+
              |                PE Device               |
              +----------------------------------------+
     Single   |                 |        Single        | PW Instance
      AC      |                 +      PW Instance     X<===========>
              |                 |                      |
              |                 |----------------------|
      <------>o                 |        Single        | PW Instance
              |    Forwarder    +      PW Instance     X<===========>
              |                 |                      |
              |                 |----------------------|
              |                 |        Single        | PW Instance
              |                 +      PW Instance     X<===========>
              |                 |                      |
              +----------------------------------------+

                Figure 1: PE Architecture for PW redundancy

3.2.  PW Redundancy Network Reference Scenarios

   This section presents a set of reference scenarios for PW redundancy.
   These reference scenarios represent example network topologies that
   illustrate the use of PW redundancy.  They can be combined together
   to create more complex or comprehensive topologies, as required by a
   particular application or deployment.

3.2.1.  PW Redundancy for AC and PE Protection: One Dual-Homed CE with
        Redundant SS-PWs

   Figure 2 illustrates an application of single segment pseudowire
   redundancy where one of the CEs is dual-homed.  This scenario is
   designed to protect the emulated service against a failure of one of
   the PEs or ACs attached to the multi-homed CE.  Protection against
   failures of the PSN tunnels is provided using PSN mechanisms such as
   MPLS fast reroute, so that these failures do not impact the PW.

   CE1 is dual-homed to PE1 and PE3.  A dual homing control protocol,



Muley, et al.           Expires December 29, 2012               [Page 6]

Internet-Draft                PW Redundancy                    June 2012


   the details of which are outside the scope of this document, enables
   the PEs and CEs to determine which PE (PE1 or PE3) should forward
   towards CE1, and therefore which AC CE1 should use to forward towards
   the PSN.

            |<-------------- Emulated Service ---------------->|
            |                                                  |
            |          |<------- Pseudo Wire ------>|          |
            |          |                            |          |
            |          |    |<-- PSN Tunnels-->|    |          |
            |          V    V                  V    V          |
            V    AC    +----+                  +----+     AC   V
      +-----+    |     | PE1|==================|    |     |    +-----+
      |     |----------|....|...PW1.(active)...|....|----------|     |
      |     |          |    |==================|    |          | CE2 |
      | CE1 |          +----+                  |PE2 |          |     |
      |     |          +----+                  |    |          +-----+
      |     |          |    |==================|    |
      |     |----------|....|...PW2.(standby)..|    |
      +-----+    |     | PE3|==================|    |
                 AC    +----+                  +----+

             Figure 2: One Dual-Homed CE and Redundant SS-PWs

   In this scenario, only one of the PWs should be used for forwarding
   between PE1 / PE3, and PE2.  PW redundancy determines which PW to
   make active based on the forwarding state of the ACs so that only one
   path is available from CE1 to CE2.  This requires an additional PW
   state that reflects this forwarding state, which is separate from the
   operational status of the PW.  This is the 'Preferential Forwarding
   Status'.

   Consider the example where the AC from CE1 to PE1 is initially active
   and the AC from CE1 to PE3 is initially standby.  PW1 is made active
   and PW2 is made standby in order to complete the path to CE2.

   On failure of the AC between CE1 and PE1, the forwarding state of the
   AC on PE3 transitions to active.  The preferential forwarding state
   of PW2 therefore needs to become active, and PW1 standby, in order to
   reestablish connectivity between CE1 and CE2.  PE3 therefore uses PW2
   to forward towards CE2, and PE2 uses PW2 instead of PW1 to forward
   towards CE1.  PW redundancy in this scenario requires that the
   forwarding status of the ACs at PE1 and PE3 be signaled to PE2 so
   that PE2 can choose which PW to make active.

   Changes occurring on the dual-homed side of the network due to a
   failure of the AC or PE are not propagated to the ACs on the other
   side of the network.  Furthermore, failures in the PSN are not



Muley, et al.           Expires December 29, 2012               [Page 7]

Internet-Draft                PW Redundancy                    June 2012


   propagated to the attached CEs.

3.2.2.  PW Redundancy for AC and PE Protection: Two Dual-Homed CEs with
        Redundant SS-PWs

   Figure 3 illustrates an application of single segment pseudowire
   redundancy where both of the CEs are dual-homed.  This scenario is
   also designed to protect the emulated service against failures of the
   ACs and failures of the PEs.  Both CE1 and CE2, are dual-homed to
   their respective PEs, PE1 and PE2, and PE3 and PE4.  A dual homing
   control protocol, the details of which are outside the scope of this
   document, enables the PEs and CEs to determine which PEs should
   forward towards the CEs, and therefore which ACs the CEs should use
   to forward towards the PSN.

   Note that the PSN tunnels are not shown in this figure for clarity.
   However, it can be assumed that each of the PWs shown is encapsulated
   in a separate PSN tunnel.  Protection against failures of the PSN
   tunnels is provided using PSN mechanisms such as MPLS fast reroute,
   so that these failures do not impact the PW.
         |<-------------- Emulated Service ---------------->|
         |                                                  |
         |          |<------- Pseudowire ------->|          |
         |          |                            |          |
         |          |    |<-- PSN Tunnels-->|    |          |
         |          V    V                  V    V          |
         V    AC    +----+                  +----+     AC   V
   +-----+    |     |....|.......PW1........|....|     |    +-----+
   |     |----------| PE1|......   .........| PE3|----------|     |
   | CE1 |          +----+      \ /  PW3    +----+          | CE2 |
   |     |          +----+       X          +----+          |     |
   |     |          |    |....../ \..PW4....|    |          |     |
   |     |----------| PE2|                  | PE4|--------- |     |
   +-----+    |     |....|.....PW2..........|....|     |    +-----+
              AC    +----+                  +----+     AC

             Figure 3: Two Dual-Homed CEs and Redundant SS-PWs

   PW1 and PW4 connect PE1 to PE3 and PE4, respectively.  Similarly, PW2
   and PW3 connect PE2 to PE4 and PE3.  PW1, PW2, PW3 and PW4 are all
   up.  In order to support protection for the emulated service, only
   one PW MUST be selected to forward traffic.

   If a PW has a preferential forwarding status of 'active', it can be
   used for forwarding traffic.  The actual up PW chosen by the combined
   set of PEs connected to the CEs is determined by considering the
   preferential forwarding status of each PW at each PE.  The mechanisms
   for communicating the preferential forwarding status are outside the



Muley, et al.           Expires December 29, 2012               [Page 8]

Internet-Draft                PW Redundancy                    June 2012


   scope of this document.  Only one PW is used for forwarding.

   The following failure scenario illustrates the operation of PW
   redundancy in Figure 3.  In the initial steady state, when there are
   no failures of the ACs, one of the PWs is chosen as the active PW,
   and all others are chosen as standby.  The dual-homing protocol
   between CE1 and PE1/PE2 chooses to use the AC to PE2, while the
   protocol between CE2 and PE3/PE4 chooses to use the AC to PE4.
   Therefore the PW between PE2 and PE4 is chosen as the active PW to
   complete the path between CE1 and CE2.

   On failure of the AC between the dual-homed CE1 and PE2, the
   preferential forwarding status of the PWs at PE1, PE2, PE3 and PE4
   needs to change so as to re-establish a path from CE1 to CE2.
   Different mechanisms can be used to achieve this and these are beyond
   the scope of this document.  After the change in status, the
   algorithm needs to evaluate and select which PW to forward traffic
   on.  In this application, each dual-homing algorithm, i.e., {CE1,
   PE1, PE2} and {CE2, PE3, PE4}, selects the active AC independently.
   There is therefore a need to signal the active status of each AC such
   that the PEs can select a common active PW for forwarding between CE1
   and CE2.

   Changes occurring on one side of network due to a failure of the AC
   or PE are not propagated to the ACs on the other side of the network.
   Furthermore, failures in the PSN are not propagated to the attached
   CEs.  Note that end-to-end native service protection switching can
   also be used to protect the emulated service in this scenario.  In
   this case, PW3 and PW4 are not necessary.

   If the CEs do not perform native service protection switching, they
   may instead use load balancing across the paths between the CEs.

3.2.3.  PW Redundancy for S-PE Protection: Single-Homed CEs with
        Redundant MS-PWs

   Figure 4 shows a scenario where both CEs are single homed, and MS-PW
   redundancy is used.  The main objective is to protect the emulated
   service against failures of the S-PEs.












Muley, et al.           Expires December 29, 2012               [Page 9]

Internet-Draft                PW Redundancy                    June 2012


       Native   |<----------- Pseudowires ----------->|  Native
       Service  |                                     |  Service
        (AC)    |     |<-PSN1-->|     |<-PSN2-->|     |  (AC)
          |     V     V         V     V         V     V   |
          |     +-----+         +-----+         +-----+   |
   +----+ |     |T-PE1|=========|S-PE1|=========|T-PE2|   |   +----+
   |    |-------|......PW1-Seg1.......|.PW1-Seg2......|-------|    |
   | CE1|       |     |=========|     |=========|     |       | CE2|
   |    |       +-----+         +-----+         +-----+       |    |
   +----+        |.||.|                          |.||.|       +----+
                 |.||.|         +-----+          |.||.|
                 |.||.|=========|     |========== .||.|
                 |.||...PW2-Seg1......|.PW2-Seg2...||.|
                 |.| ===========|S-PE2|============ |.|
                 |.|            +-----+             |.|
                 |.|============+-----+============= .|
                 |.....PW3-Seg1.|     | PW3-Seg2......|
                  ==============|S-PE3|===============
                                |     |
                                +-----+

              Figure 4: Single-Homed CE with Redundant MS-PWs

   CE1 is connected to PE1 and CE2 is connected to PE2.  There are three
   multi-segment PWs.  PW1 is switched at S-PE1, PW2 is switched at
   S-PE2, and PW3 is switched at S-PE3.  This scenario provides N:1
   protection for the subset of the path of the emulated service from
   T-PE1 to T-PE2.

   Since there is no multi-homing running on the ACs, the T-PE nodes
   advertise 'active' for the preferential forwarding status based on a
   priority for the PW.  The priority associates a meaning of 'primary
   PW' and 'secondary PW' to a PW.  These priorities MUST be used if
   revertive mode is used and the active PW to use for forwarding
   determined accordingly.  The priority can be derived via
   configuration or based on the value of the PW forwarding equivalence
   class (FEC).  For example, a lower value of PWid FEC can be taken as
   a higher priority.  However, this does not guarantee selection of
   same PW by the T-PEs because of, for example, a mismatch in the
   configuration of the PW priority at each T-PE.  The intent of this
   application is for T-PE1 and T-PE2 to synchronize the transmit and
   receive paths of the PW over the network.  In other words, both T-PE
   nodes are required to transmit over the PW segment which is switched
   by the same S-PE.  This is desirable for ease of operation and
   troubleshooting.






Muley, et al.           Expires December 29, 2012              [Page 10]

Internet-Draft                PW Redundancy                    June 2012


3.2.4.  PW Redundancy for PE-rs Protection in H-VPLS using SS-PWs

   The following figure (based on the architecture shown in Figure 3 of
   [RFC4762]) illustrates the application of PW redundancy to
   hierarchical VPLS (H-VPLS).  Note that the PSN tunnels are not shown
   for clarity, and only one PW of a PW group is shown.  A multi-tenant
   unit switch (MTU-s) is dual-homed to two PE router switches (PE-rs).
   The example here uses SS-PWs and the objective is to protect the
   emulated service against failures of a PE-rs.


                                         PE1-rs
                                       +--------+
                                       |  VSI   |
                       Active PW       |   --   |
                        Group..........|../  \..|.
       CE-1                 .          |  \  /  | .
        \                  .           |   --   |  .
         \                .            +--------+   .
          \   MTU-s      .                  .        .     PE3-rs
           +--------+   .                   .         . +--------+
           |   VSI  |  .                    .  H-VPlS  .|  VSI   |
           |   -- ..|..                     .   Core    |.. --   |
           |  /  \  |                       .    PWs    |  /  \  |
           |  \  /..|..                     .           |  \  /  |
           |   --   |  .                    .          .|.. --   |
           +--------+   .                   .         . +--------+
          /              .                  .        .
         /                .            +--------+   .
        /                  .           |  VSI   |  .
       CE-2                 .          |   --   | .
                             ..........|../  \..|.
                       Standby PW      |  \  /  |
                        Group          |   --   |
                                       +--------+
                                         PE2-rs


                Figure 5: MTU-s Dual Homing in H-VPLS Core

   In Figure 5, the MTU-s is dual homed to PE1-rs and PE2-rs and has
   spoke PWs to each of them.  The MTU-s needs to choose only one of the
   spoke PWs (the active PW) to forward traffic to one of the PEs, and
   sets the other PW to standby.  The MTU-s can derive the status of the
   PWs based on local policy configuration.  PE1-rs and PE2-rs are
   connected to the H-VPLS core on the other side of network.  The MTU-s
   communicates the status of its member PWs for a set of virtual
   switching instances (VSIs) that share a common status of active or



Muley, et al.           Expires December 29, 2012              [Page 11]

Internet-Draft                PW Redundancy                    June 2012


   standby.  Here, the MTU-s controls the selection of PWs used to
   forward traffic.  Signaling using PW grouping with a common group-id
   in the PWid FEC Element, or a Grouping TLV in Generalized PWid FEC
   Element as defined in [RFC4447], to PE1-rs and PE2-rs, is recommended
   for improved scaling.

   Whenever an MTU-s performs a switchover of the active PW group, it
   needs to communicate this status change the PE2-rs.  That is, it
   informs PE2-rs that the status of the standby PW group has changed to
   active.

   In this scenario, PE devices are aware of switch overs at the MTU-s
   and could generate MAC Withdraw messages to trigger MAC flushing
   within the H-VPLS full-mesh.  By default, MTU-s devices should still
   trigger MAC withdraw messages as defined in [RFC4762] to prevent two
   copies of MAC withdraws to be sent (one by the MTU-s and another one
   by the PE-rs').  Mechanisms to disable the MAC withdraw trigger in
   certain devices are out of the scope of this document.

3.2.5.  PW Redundancy for PE Protection in a VPLS Ring using SS-PWs

   The following figure illustrates the use of PW redundancy for dual-
   homed connectivity between PEs in a VPLS ring topology.  As above,
   PSN tunnels are not shown and only one PW of a PW group is shown for
   clarity.  The example here uses SS-PWs and the objective is to
   protect the emulated service against failures of a PE on the ring.

























Muley, et al.           Expires December 29, 2012              [Page 12]

Internet-Draft                PW Redundancy                    June 2012


               PE1                            PE2
            +--------+                     +--------+
            |  VSI   |                     |  VSI   |
            |   --   |                     |   --   |
      ......|../  \..|.....................|../  \..|.......
            |  \  /  |     PW Group 1      |  \  /  |
            |   --   |                     |   --   |
            +--------+                     +--------+
                 .                              .
                 .                              .
   VPLS Domain A .                              . VPLS Domain B
                 .                              .
                 .                              .
                 .                              .
            +--------+                     +--------+
            |  VSI   |                     |  VSI   |
            |   --   |                     |   --   |
      ......|../  \..|.....................|../  \..|........
            |  \  /  |     PW Group 2      |  \  /  |
            |   --   |                     |   --   |
            +--------+                     +--------+
               PE3                            PE4



               Figure 6: Redundancy in a VPLS Ring Topology

   In Figure 6, PE1 and PE3 from VPLS domain A are connected to PE2 and
   PE4 in VPLS domain B via PW group 1 and PW group 2.  The PEs are
   connected to each other in such a way as to form a ring topology.
   Such scenarios may arise in inter-domain H-VPLS deployments where
   rapid spanning tree (RSTP) or other mechanisms may be used to
   maintain loop free connectivity of the PW groups.

   [RFC4762] outlines multi-domain VPLS services without specifying how
   multiple redundant border PEs per domain and per VPLS instance can be
   supported.  In the example above, PW group 1 may be blocked at PE1 by
   RSTP and it is desirable to block the group at PE2 by exchanging the
   PW preferential forwarding status of standby.  The details of how PW
   grouping is achieved and used is deployment specific and is outside
   the scope of this document.

3.2.6.  PW Redundancy for VPLS n-PE Protection using SS-PWs








Muley, et al.           Expires December 29, 2012              [Page 13]

Internet-Draft                PW Redundancy                    June 2012


                          |<----- Provider ----->|
                                    Core
                   +------+                      +------+
                   | n-PE |::::::::::::::::::::::| n-PE |
        Provider   | (P)  |..........   .........| (P)  |  Provider
        Access     +------+          . .         +------+  Access
        Network                       X                    Network
          (1)      +------+          . .         +------+    (2)
                   | n-PE |..........   .........| n-PE |
                   |  (B) |......................| (B)  |
                   +------+                      +------+



                       Figure 7: Bridge Module Model



                            Bridge Module Model

   Figure 7 shows a scenario with two provider access networks.  The
   example here uses SS-PWs and the objective is to protect the emulated
   service against failures of a network-facing PE (n-PE).

   Each network has two n-Pes.  These n-PEs are connected via a full
   mesh of PWs for a given VPLS instance.  As shown in the figure, only
   one n-PE in each access network serves as the primary PE (P) for that
   VPLS instance and the other n-PE serves as the backup PE (B).  In
   this figure, each primary PE has two active PWs originating from it.
   Therefore, when a multicast, broadcast, or unknown unicast frame
   arrives at the primary n-PE from the access network side, the n-PE
   replicates the frame over both PWs in the core even though it only
   needs to send the frames over a single PW (shown with :::: in the
   figure) to the primary n-PE on the other side.  This is an
   unnecessary replication of the customer frames that consumes core-
   network bandwidth (half of the frames get discarded at the receiving
   n-PE).  This issue gets aggravated when there is three or more n-PEs
   per provider, access network.  For example if there are three n-PEs
   or four n-PEs per access network, then 67% or 75% of core bandwidth
   for multicast, broadcast and unknown unicast are wasted,
   respectively.

   In this scenario, the n-PEs can communicate the active or standby
   status of the PWs among them.  This status can be derived from the
   active or backup state of an n-PE for a given VPLS.






Muley, et al.           Expires December 29, 2012              [Page 14]

Internet-Draft                PW Redundancy                    June 2012


4.  Generic PW Redundancy Requirements

4.1.  Protection Switching Requirements

   o  Protection architectures such as N:1,1:1 or 1+1 are possible. 1:1
      protection MUST be supported.  The N:1 protection case is less
      efficient in terms of the resources that must be allocated and
      hence this SHOULD be supported. 1+1 protection MAY be used in the
      scenarios described in the document.  However, the details of its
      usage are outside the scope of this document, as it MAY require a
      1+1 protection switching protocol between the CEs.

   o  Non-revertive behavior MUST be supported, while revertive behavior
      is OPTIONAL.  This avoids the need to designate one PW as primary
      unless revertive behavior is explicitly required.

   o  Protection switchover can be initiated from a PE e.g. using a
      manual switchover, or a forced switchover, or it may be triggered
      by a signal failure i.e. a defect in the PW or PSN.  Manual
      switchover may be necessary if it is required to disable one PW in
      a redundant set.  Both methods MUST be supported and signal
      failure triggers MUST be treated with a lower priority than any
      local or far-end forced switch or manual trigger.

   o  A PE MAY be able to forward packets received from a PW with a
      standby status in order to avoid black holing of in-flight packets
      during switchover.  However, in the case of use of VPLS, all VPLS
      application packets received from standby PWs MUST be dropped,
      except for OAM and control plane packets.

4.2.  Operational Requirements

   o  (T-)PEs involved in protecting a PW SHOULD automatically discover
      and attempt to resolve inconsistencies in the configuration of
      primary/secondary PW.

   o  (T-)PEs involved in protecting a PW SHOULD automatically discover
      and attempt to resolve inconsistencies in the configuration of
      revertive/non-revertive protection switching mode.

   o  (T-)PEs that do not automatically discover or resolve
      inconsistencies in the configuration of primary/secondary,
      revertive/non-revertive, or other parameters MUST generate an
      alarm upon detection of an inconsistent configuration.

   o  (T-)PEs participating in PW redundancy MUST support the
      configuration of revertive or non-revertive protection switching
      modes if both modes are supported.



Muley, et al.           Expires December 29, 2012              [Page 15]

Internet-Draft                PW Redundancy                    June 2012


   o  The MIB(s) MUST support inter-PSN monitoring of the PW redundancy
      configuration, including the protection switching mode.

   o  (T-)PEs participating in PW redundancy SHOULD support the local
      invocation of protection switching.

   o  (T-)PEs participating in PW redundancy SHOULD support the local
      invocation of a lockout of protection switching.


5.  Security Considerations

   This document requires extensions to the Label Distribution Protocol
   (LDP) that are needed for protecting pseudowires.  These will inherit
   at least the same security properties as LDP [RFC5036] and the PW
   control protocol [RFC4447].


6.  IANA Considerations

   This document has no actions for IANA.


7.  Major Contributing Authors

   The editors would like to thank Pranjal Kumar Dutta, Marc Lasserre,
   Jonathan Newton, Hamid Ould-Brahim, Olen Stokes, Dave Mcdysan, Giles
   Heron and Thomas Nadeau who made a major contribution to the
   development of this document.






















Muley, et al.           Expires December 29, 2012              [Page 16]

Internet-Draft                PW Redundancy                    June 2012


   Pranjal Dutta
   Alcatel-Lucent
   Email: pranjal.dutta@alcatel-lucent.com

   Marc Lasserre
   Alcatel-Lucent
   Email: marc.lasserre@alcatel-lucent.com

   Jonathan Newton
   Cable & Wireless
   Email: Jonathan.Newton@cw.com

   Olen Stokes
   Extreme Networks
   Email: ostokes@extremenetworks.com

   Hamid Ould-Brahim
   Email: ouldh@yahoo.com

   Dave McDysan
   Verizon
   Email: dave.mcdysan@verizon.com

   Giles Heron
   Cisco Systems
   Email: giles.heron@gmail.com

   Thomas Nadeau
   Juniper Networks
   Email: tnadeau@lucidvision.com


8.  Acknowledgements

   The authors would like to thank Vach Kompella, Kendall Harvey,
   Tiberiu Grigoriu, Neil Hart, Kajal Saha, Florin Balus and Philippe
   Niger for their valuable comments and suggestions.


9.  References

9.1.   Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

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



Muley, et al.           Expires December 29, 2012              [Page 17]

Internet-Draft                PW Redundancy                    June 2012


   [RFC4026]  Andersson, L. and T. Madsen, "Provider Provisioned Virtual
              Private Network (VPN) Terminology", RFC 4026, March 2005.

   [RFC4446]  Martini, L., "IANA Allocations for Pseudowire Edge to Edge
              Emulation (PWE3)", BCP 116, RFC 4446, April 2006.

   [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.

   [RFC4762]  Lasserre, M. and V. Kompella, "Virtual Private LAN Service
              (VPLS) Using Label Distribution Protocol (LDP) Signaling",
              RFC 4762, January 2007.

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

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

9.2.  Informative References

   [RFC6073]  Martini, L., Metz, C., Nadeau, T., Bocci, M., and M.
              Aissaoui, "Segmented Pseudowire", RFC 6073, January 2011.


Authors' Addresses

   Praveen Muley
   Alcatel-Lucent


   Email: praveen.muley@alcatel-lucent.com


   Mustapha Aissaoui
   Alcatel-Lucent


   Email: mustapha.aissaoui@alcatel-lucent.com










Muley, et al.           Expires December 29, 2012              [Page 18]

Internet-Draft                PW Redundancy                    June 2012


   Matthew Bocci
   Alcatel-Lucent


   Email: matthew.bocci@alcatel-lucent.com














































Muley, et al.           Expires December 29, 2012              [Page 19]