[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-muley-pwe3-redundancy) 00 01 02 03 04 05 06 07 08 09 RFC 6718

Network Working Group                               Praveen Muley, Ed.
Internet Draft                                  Mustapha Aissaoui, Ed.
Intended Status: Informational                         Alcatel-Lucent
Expires: November 2010
                                                           May 14, 2010

                      Pseudowire (PW) Redundancy
                   draft-ietf-pwe3-redundancy-03.txt


Abstract

   This document describes a framework comprised of few scenarios and
   associated requirements where PW redundancy is needed. A set of
   redundant PWs is configured between PE nodes in SS-PW applications,
   or between T-PE nodes in MS-PW applications. In order for the PE/T-PE
   nodes to indicate the preferred PW to forward to one another, a new
   status is needed to indicate the preferential forwarding status of
   active or standby for each PW in the redundancy set.



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 November 14, 2010.



Copyright Notice

   Copyright (c) 2010 IETF Trust and the persons identified as the
   document authors. All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents



Muley et al.          Expires November 14, 2010               [Page 1]


Internet-Draft       Pseudowire (PW) Redundancy               May 2010


   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.



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



Table of Contents

   1. Terminology .............................................. 2
   2. Introduction.............................................. 3
   3. Reference Model........................................... 4
      3.1. PE Architecture...................................... 4
      3.2. Multiple Multi-homed................................. 5
      3.3. Single Homed CE with MS-PW redundancy................ 7
      3.4. PW redundancy between MTU-s.......................... 8
      3.5. PW redundancy between n-PEs.......................... 9
      3.6. PW redundancy in Bridge Module Model................. 10
   4. Generic PW redundancy requirements........................ 11
      4.1. Protection switching requirements.................... 11
      4.2. Operational requirements............................. 11
   5. Security Considerations................................... 12
   6. IANA considerations....................................... 12
   7. Major Contributing Authors................................ 12
   8. Acknowledgments........................................... 13
   9. References................................................ 14
      9.1. Normative References................................. 14
      9.2. Informative References............................... 14
   Author's Addresses........................................... 14

1. Terminology

   o Active PW.  A PW whose preferential status is set to Active and
      Operational status is UP and is used for forwarding user and OAM
      traffic.





Muley et al.          Expires November 14, 2010               [Page 2]


Internet-Draft       Pseudowire (PW) Redundancy               May 2010


   o Standby PW. A PW whose preferential status is set to Standby and
      Operational status is UP and is not used for forwarding user
      traffic but may forward OAM traffic.

   o PW Endpoint: A PE where a PW terminates on a point where Native
      Service Processing is performed, e.g., A SS-PW PE, an MS-PW T-PE,
      or an H-VPLS MTU-s or PE-rs.

   o Primary PW: the PW which a PW endpoint activates in preference to
      any other PW when more than one PW qualify for active state. When
      the primary PW comes back up after a failure and qualifies for
      active state, the PW endpoint always reverts to it. The
      designation of Primary is performed by local configuration for
      the PW at the PE.

   o Secondary PW: when it qualifies for 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.

   o Revertive protection switching. Traffic will be carried by
      primary PW if it is Operationally UP and the wait-to-restore
      timer expires and 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
      Operationally DOWN state.

   o Manual selection of PW . Ability for the operator to manually
      select the primary/secondary PWs.

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

   This document uses the term 'PW' to be synonymous with both PWs as
           per RFC3985 and SS-PWs, MS-PWs, S-PEs, PW-segment and  PW
           switching point as per RFC5659.



2. Introduction

   In single-segment PW (SS-PW) applications, protection for the PW is
   provided by the PSN layer. This may be an Resource Reservation
   Protocol traffic engineered (RSVP-TE) labeled switch (LSP) with a
   fast-Reroute (FRR) backup and/or an end-to-end backup LSP. There are


Muley et al.          Expires November 14, 2010               [Page 3]


Internet-Draft       Pseudowire (PW) Redundancy               May 2010


   applications however where the backup PW terminates on a different
   target PE node. PSN protection mechanisms cannot protect against
   failure of the target PE node or the failure of the remote AC.

   In multi-segment PW (MS-PW) applications, a primary and one or more
   secondary PWs in standby mode are configured in the network. The
   paths of these PWs are diverse in the sense that they are switched at
   different S-PE nodes. In these applications, PW redundancy is
   important for the service resilience.

   In some deployments, it is important for operators that particular PW
   is preferred if it is available. For example, PW path with least
   latency may be preferred.

   This document describes framework for these applications and its
   associated operational requirements. The framework comprises of new
   required status called preferential status to PW apart from the
   operational status already defined in the PWE3 control protocol [2].



3. Reference Model

   Following figures shows the reference architecture of PE for the PW
   redundancy and its usage 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 [3]. The forwarder
   selects which of the redundant PWs to using the criteria described in
   this document.













Muley et al.          Expires November 14, 2010               [Page 4]


Internet-Draft       Pseudowire (PW) Redundancy               May 2010


              +----------------------------------------+
              |                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. Multiple Multi-homed

         |<-------------- Emulated Service ---------------->|
         |                                                  |
         |          |<------- Pseudo Wire ------>|          |
         |          |                            |          |
         |          |    |<-- PSN Tunnels-->|    |          |
         |          V    V                  V    V          |
         V    AC    +----+                  +----+     AC   V
   +-----+    |     |....|.......PW1........|....|     |    +-----+
   |     |----------| PE1|......   .........| PE3|----------|     |
   | CE1 |          +----+      \ /  PW3    +----+          | CE2 |
   |     |          +----+       X          +----+          |     |
   |     |          |    |....../ \..PW4....|    |          |     |
   |     |----------| PE2|                  | PE4|--------- |     |
   +-----+    |     |....|.....PW2..........|....|     |    +-----+
              AC    +----+                  +----+    AC


    Figure 2                  Multiple Multi-homed CEs with single SS-PW redundancy

   In the Figure 2 illustrated above both CEs, CE1 and CE2 are dual-
   homed with PEs, PE1, PE2 and PE3, PE4 respectively. The method for
   dual-homing and the used protocols are outside the scope of this
   document.  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.

   PE1 has PW1 and PW4 service connecting PE3 and PE4 respectively.
   Similarly PE2 has PW2 and Pw3 pseudo wire service connecting PE4 and


Muley et al.          Expires November 14, 2010               [Page 5]


Internet-Draft       Pseudowire (PW) Redundancy               May 2010


   PE3 respectively. PW1, PW2, PW3 and PW4 are all operationally UP. In
   order to support N:1 or 1:1 only one PW is required to be selected to
   forward the traffic. Thus the PW needs to reflect its new status
   apart from the operational status. We call this as preferential
   forwarding status with state representing 'active' the one carrying
   traffic while the other 'standby' which is operationally UP but not
   forwarding traffic. The method of deriving Active/Standby status of
   the AC is outside the scope of this document.

   A new algorithm needs to be developed using the preferential
   forwarding state of PW and select only one PW to forward.

   On failure of AC between the dual homed CE1 in this case lets say PE1
   the preferential status on PE2 needs to be changed. Different
   mechanisms/protocols can be used to achieve this and these are beyond
   the scope of this document. After the change in status the algorithm
   for selection of PW needs to revaluate and select PW to forward the
   traffic. In this application, because each dual-homing algorithm
   running on the two node sets, i.e., {CE1, PE1, PE2} and {CE2, PE3,
   PE4}, selects the active AC independently, there is a need to signal
   the active status of the AC such that the PE nodes can select a
   common active PW path for end-to-end forwarding between CE1 and CE2.
   This helps in restricting the changes occurring on one side of
   network due to failure to the other side of the network.

   Also the failures in the carrier core network MUST NOT be propagated
   to customer network. Hence network operator should take this
   consideration while designing the network. For ex. if there is
   failure of LSP tunnel, operator should have rely on FRR or an
   alternate LSP path/tunnel which will be seamless to the PW service.
   Note this method also protects against any single PE failure or some
   dual PE failures.

   One Multi-homed CE with single SS-PW redundancy application is a
   subset of above. Only PW1 and PW3 exist in this case. This helps
   against AC failure and PE failure of dual homed AC. Similar
   requirements applies in usage MS-PW redundancy as well. An additional
   requirement applicable to MS-PW is forwarding of status notification
   through S-PE. In general from customer view, SS-PW and MS-PW has
   similar resiliency requirement.

   There is also a 1:1 protection switching case that is a subset of the
   above where PW3 and PW4 are not present.

   o If the CEs do not perform native service protection switching, but
      instead may use load balancing. This protects against AC failures
      and can use the native service to indicate active/failed state.


Muley et al.          Expires November 14, 2010               [Page 6]


Internet-Draft       Pseudowire (PW) Redundancy               May 2010


   o If each CE homes to different PEs, then the CEs can implement
      native service protection switching, without any PW redundancy
      functions. All that the PW needs to do is detect AC, PE, or PSN
      tunnel failures and convey that information to both PEs at the end
      of the PW. This is applicable to MS-PW as well.

3.3. Single Homed CE with MS-PW redundancy

   This is the main application of interest and the network setup is
   shown in Figure 3

       Native   |<------------Pseudo Wire------------>|  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 3 Single homed CE with multi-segment pseudo-wire redundancy

   In Figure 3, CE1 is connected to PE1 in provider Edge 1 and CE2 to
   PE2 in provider edge 2 respectively. There are three segmented PWs. A
   PW1, is switched at S-PE1, PW2, which is switched at S-PE2 and PW3,
   is switched at S-PE3.

   Since there is no multi-homing running on the AC, the T-PE nodes
   would advertise 'Active' for the forwarding status based on the
   priority. Priorities associate meaning of 'primary PW' and 'secondary
   PW'. These priorities MUST be used in revertive mode as well and
   paths must be switched accordingly. The priority can be configuration
   or derivation from the PWid. Lower the PWid higher the priority.
   However, this does not guarantee selection of same PW by the T-PEs
   because, for example, mismatch of the configuration of the PW


Muley et al.          Expires November 14, 2010               [Page 7]


Internet-Draft       Pseudowire (PW) Redundancy               May 2010


   priority in each T-PE. The intent of this application is to have T-
   PE1 and T-PE2 synchronize the transmit and receive path 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.



3.4. PW redundancy between MTU-s

   Following figure illustrates the application of use of PW redundancy
   in spoke PW by dual homed MTU-s to PEs.


                     |<-PSN1-->|     |<-PSN2-->|
                     V         V     V         V
               +-----+         +-----+
               |MTU-s|=========|PE1  |========
               |..Active PW group....| H-VPLS-core
               |     |=========|     |=========
               +-----+         +-----+
                  |.|
                  |.|           +-----+
                  |.|===========|     |==========
                  |...Standby PW group|.H-VPLS-core
                   =============|  PE2|==========
                                +-----+

               Figure 4  Multi-homed MTU-s in H-VPLS core

   In Figure 4, MTU-s is dual homed to PE1 and PE2 and has spoke PWs to
   each of them. MTU-s needs to choose only one of the spoke PW (active
   PW) to one of the PE to forward the traffic and the other to standby
   status. MTU-s can derive the status of the PWs based on local policy
   configuration. PE1 and PE2 are connected to H-VPLS core on the other
   side of network. MTU-s communicates the status of its member PWs for
   a set of VSIs having common status Active/Standby. Here MTU-s
   controls the selection of PWs to forward the traffic. Signaling
   using PW grouping with common group-id in PWid FEC Element or
   Grouping TLV in Generalized PWid FEC Element as defined in [2] to PE1
   and PE2 respectively, is encouraged to scale better.

   Whenever MTU-s performs a switchover, it needs to communicate to PE2
   for the Standby PW group the changed status of active.

   In this scenario, PE devices are aware of switchovers at MTU-s and
   could generate MAC Withdraw Messages to trigger MAC flushing within


Muley et al.          Expires November 14, 2010               [Page 8]


Internet-Draft       Pseudowire (PW) Redundancy               May 2010


   the H-VPLS full mesh. By default, MTU-s devices should still trigger
   MAC Withdraw messages as currently defined in [5] to prevent two
   copies of MAC withdraws to be sent (one by MTU-s and another one by
   PEs). Mechanisms to disable MAC Withdraw trigger in certain devices
   is out of the scope of this document.

3.5. PW redundancy between n-PEs

   Following figure illustrates the application of use of PW redundancy
   for dual homed connectivity between PE devices in a ring topology.

             +-------+                     +-------+

             |  PE1  |=====================|  PE2  |====...

             +-------+    PW Group 1       +-------+

                 ||                            ||

   VPLS Domain A ||                            || VPLS Domain B

                 ||                            ||

             +-------+                     +-------+

             |  PE3  |=====================|  PE4  |==...

             +-------+    PW Group 2       +-------+

                 Figure 5   Redundancy in Ring topology

   In Figure 5, PE1 and PE3 from VPLS domain A are connected to PE2 and
   PE4 in VPLS domain B via PW group 1 and group 2. Each of the PE in
   respective domain is connected to each other as well to form the ring
   topology. Such scenarios may arise in inter-domain H-VPLS deployments
   where RSTP or other mechanisms may be used to maintain loop free
   connectivity of PW groups.

   Ref.[5] outlines about multi-domain VPLS service without specifying
   how redundant border PEs per domain per VPLS instance can be
   supported. In the example above, PW group1 may be blocked at PE1 by
   RSTP and it is desirable to block the group at PE2 by virtue of
   exchanging the PW preferential status as Standby. How the PW grouping
   should be done here is again deployment specific and is out of scope
   of the solution.




Muley et al.          Expires November 14, 2010               [Page 9]


Internet-Draft       Pseudowire (PW) Redundancy               May 2010


3.6. PW redundancy in Bridge Module Model







   ----------------------------+  Provider  +------------------------

                               .   Core     .

                   +------+    .            .    +------+

                   | n-PE |======================| n-PE |

        Provider   | (P)  |---------\    /-------| (P)  |  Provider

        Access     +------+    ._    \  /   .    +------+  Access

        Network                .      \/    .              Network

          (1)      +------+    .      /\    .    +------+     (2)

                   | n-PE |----------/  \--------| n-PE |

                   |  (B) |----------------------| (B)  |_

                   +------+    .            .    +------+

                               .            .

   ----------------------------+            +------------------------

                         Figure 6 Bridge Module Model

   In Figure 6, two provider access networks, each having two n-PEs,
   where the 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 is serving as a Primary PE (P) for that VPLS instance and the
   other n-PE is serving as the backup PE (B).In this figure, each
   primary PE has two active PWs originating from it. Therefore, when a
   multicast, broadcast, and 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


Muley et al.          Expires November 14, 2010              [Page 10]


Internet-Draft       Pseudowire (PW) Redundancy               May 2010


   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-BW for multicast, broadcast
   and unknown unicast are respectively wasted.

   In this scenario, n-PEs can disseminate the status of PWs
   active/standby among themselves and furthermore to have it tied up
   with the redundancy mechanism such that per VPLS instance the status
   of active/backup n-PE gets reflected on the corresponding PWs
   emanating from that n-PE.

4. Generic PW redundancy requirements

4.1. Protection switching requirements

   o Protection architecture such as N:1,1:1 or 1+1 can be used. N:1
      protection case is somewhat inefficient in terms of capacity
      consumption hence implementations SHOULD support this method
      while  1:1 being subset and efficient MUST be supported. 1+1
      protection architecture can be supported but is left for further
      study.

   o Non-revertive mode MUST be supported, while revertive mode is an
      optional one.

   o Protection switchover can be operator driven like Manual
      lockout/force switchover or due to signal failure. Both methods
      MUST be supported and signal failure MUST be given higher
      priority than any local or far end request.

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.



Muley et al.          Expires November 14, 2010              [Page 11]


Internet-Draft       Pseudowire (PW) Redundancy               May 2010


   o (T-)PEs involved with protection switching MUST support the
      configuration of revertive or non-revertive protection switching
      mode.

   o (T-)PEs involved with protection switching SHOULD support the
      local invocation of protection switching.

   o (T-)PEs involved with protection switching SHOULD support the
      local invocation of a lockout of protection switching.

   o In standby status PW can still receive packets in order to avoid
      black holing of in-flight packets during switchover. However in
      case of use of VPLS application packets are dropped in standby
      status except for the OAM packets.



5. Security Considerations

   This document expects extensions to LDP that are needed for
   protecting pseudo-wires. It will have the same security properties as
   in LDP [4] and the PW control protocol [2].

6. IANA considerations

   This document has no actions for IANA.



7. Major Contributing Authors

   The editors would like to thank Matthew Bocci, 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 November 14, 2010              [Page 12]


Internet-Draft       Pseudowire (PW) Redundancy               May 2010


   Matthew Bocci
   Alcatel
   Voyager Place, Shoppenhangers Rd
   Maidenhead, Berks, UK SL6 2PJ
   Email: matthew.bocci@alcatel.com

   Pranjal Kumar Dutta
   Alcatel-Lucent
   Email: pdutta@alcatel-lucent.com

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

   Jonathan Newton
   Cable & Wireless
   Email: Jonathan.Newton@cwmsg.cwplc.com

   Olen Stokes
   Extreme Networks
   Email: ostokes@extremenetworks.com

   Hamid Ould-Brahim
   Nortel
   Email: hbrahim@nortel.com

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

   Giles Heron
   BT
   Email: giles.heron@gmail.com

   Thomas Nadeau
   BT
   Email: tnadeau@lucidvision.com



8. Acknowledgments

   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.




Muley et al.          Expires November 14, 2010              [Page 13]


Internet-Draft       Pseudowire (PW) Redundancy               May 2010


9. References

9.1. Normative References

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

   [2]  Martini, L., et al., "Pseudowire Setup and Maintenance using
         LDP", RFC 4447, April 2006.

   [3]  Bryant, S., et al., " Pseudo Wire Emulation Edge-to-Edge
         (PWE3) Architecture", RFC 3985 March 2005

   [4]  Andersson, L., Minei, I., and B. Thomas, "LDP Specification",
         RFC 5036, January 2001

   [5]  Kompella,V., Lasserrre, M. , et al., "Virtual Private LAN
         Service (VPLS) Using LDP Signalling", RFC 4762, January 2007

9.2. Informative References

   [6]  Martini, L., et al., "Segmented Pseudo Wire", draft-ietf-pwe3-
         segmented-pw-14.txt, October 2010.

Author's Addresses

   Praveen Muley
   Alcatel
   701 E. Middlefiled Road
   Mountain View, CA, USA
   Email: Praveen.muley@alcatel.com

  Mustapha Aissaoui
   Alcatel
   600 March Rd
   Kanata, ON, Canada K2K 2E6
   Email: mustapha.aissaoui@alcatel.com












Muley et al.          Expires November 14, 2010              [Page 14]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/