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

Versions: 00 01 02 draft-ietf-pwe3-redundancy

Network Working Group                                    Praveen Muley
Internet Draft                                       Mustapha Aissaoui
Intended Status: Informational                           Matthew Bocci
Expires: May 2008                                  Pranjal Kumar Dutta
                                                          Marc Lasserre
                                                         Alcatel-Lucent

                                                        Jonathan Newton
                                                       Cable & Wireless

                                                            Olen Stokes
                                                       Extreme Networks

                                                      Hamid Ould-Brahim
                                                                 Nortel



                                                      November 19, 2007

                        Pseudowire (PW) Redundancy
                    draft-muley-pwe3-redundancy-02.txt


Status of this Memo

   By submitting this Internet-Draft, each author represents that
   any applicable patent or other IPR claims of which he or she is
   aware have been or will be disclosed, and any of which he or she
   becomes aware will be disclosed, in accordance with Section 6 of
   BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

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

   The list of current Internet-Drafts can be accessed at
        http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
        http://www.ietf.org/shadow.html




Muley et al.            Expires May 19, 2008                  [Page 1]


Internet-Draft       Pseudowire (PW) Redundancy)         November 2007


   This Internet-Draft will expire on May 19, 20078.

Abstract

   This document describes a few scenarios 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 path to
   forward to one another, a new status bit is needed to indicate the
   preferential forwarding status of active or standby for each PW in
   the redundancy set as defined in [7].

Conventions used in this document

   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.................................................3
   2. Introduction................................................3
   3. Multi-homing Single SS-PW redundancy applications............4
      3.1. One Multi-homed CE with single SS-PW redundancy..........4
      3.2. Multiple Multi-homed CEs with single SS-PW redundancy....6
   4. Multi-homing MS-PW redundancy applications...................7
      4.1. Multi-homed CE with MS-PW redundancy....................7
      4.2. Single Homed CE with MS-PW redundancy...................8
   5. Multi-homing VPLS applications...............................9
      5.1. PW redundancy between MTU-s and PEs.....................9
      5.2. PW redundancy between n-PEs............................11
      5.3. PW redundancy in Bridge Module Model...................11
   6. Design considerations.......................................13
   7. Security Considerations.....................................13
   8. Acknowledgments............................................14
   9. References.................................................14
      9.1. Normative References...................................14
      9.2. Informative References.................................14
   Author's Addresses............................................14
   Intellectual Property Statement................................15
   Disclaimer of Validity........................................16
   Acknowledgment................................................16






Muley et al.            Expires May 19, 2008                  [Page 2]


Internet-Draft       Pseudowire (PW) Redundancy)         November 2007


1. Terminology

   o PW Terminating Provider Edge (T-PE). A PE where the customer-
      facing attachment circuits (ACs) are bound to a PW forwarder. A
      Terminating PE is present in the first and last segments of a MS-
      PW. This incorporates the functionality of a PE as defined in
      RFC3985 [3].

   o Single-Segment Pseudo Wire (SS-PW). A PW setup directly between
      two T-PE devices. Each PW in one direction of a SS-PW traverses
      one PSN tunnel that connects the two T-PEs.

   o Multi-Segment Pseudo Wire (MS-PW). A static or dynamically
      configured set of two or more contiguous PW segments that behave
      and function as a single point-to-point PW. Each end of a MS-PW by
      definition MUST terminate on a T-PE.

   o PW Segment. A part of a single-segment or multi-segment PW, which
      is set up between two PE devices, T-PEs and/or S-PEs.

   o PW Switching Provider Edge (S-PE). A PE capable of switching the
      control and data planes of the preceding and succeeding PW
      segments in a MS-PW. The S-PE terminates the PSN tunnels of the
      preceding and succeeding segments of the MS-PW.

   o PW switching point for a MS-PW. A PW Switching Point is never the
      S-PE and the T-PE for the same MS-PW. A PW switching point runs
      necessary protocols to setup and manage PW segments with other PW
      switching points and terminating PEs

   o Active PW.  A PW whose preferential status is set to Active and
      Operational status is UP.

   o Standby PW. A PW whose preferential status is set to Standby.

2. Introduction

   In single-segment PW (SS-PW) applications, protection for the PW is
   provided by the PSN layer. This may be an RSVP LSP with a FRR backup
   and/or an end-to-end backup LSP. There are however applications 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 multiple
   secondary PWs in standby mode are configured in the network. The
   paths of these PWs are diverse and are switched at different S-PE


Muley et al.            Expires May 19, 2008                  [Page 3]


Internet-Draft       Pseudowire (PW) Redundancy)         November 2007


   nodes. In these applications, PW redundancy is important for the
   service resilience.

   This document describes these applications and uses a new PW status
   bit defined in [7] to indicate the preferential forwarding status of
   the PW for the purpose of notifying the remote T-PE of the
   active/standby state of each PW in the redundancy set. This status
   bit is different from the operational status bits already defined in
   the PWE3 control protocol [2]. The PW with both local and remote
   operational UP status and local and remote preferential active status
   is selected to forward traffic.

3. Multi-homing Single SS-PW redundancy applications

3.1. One Multi-homed CE with single SS-PW redundancy

   The following figure illustrates an application of single segment
   pseudo-wire redundancy.

         |<-------------- 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 1                  Multi-homed CE with single SS-PW redundancy

   In figure 1, CE1 is dual homed to PE1 and to PE3 by attachment
   circuits. The method for dual-homing of CE1 to PE1 and PE3 nodes and
   the used protocols such as Multi-chassis Link Aggregation Group (MC-
   LAG), are outside the scope of this document. PE2 has an attachment
   circuit from CE2. Two pseudo-wires pw1 and pw2 are established, one
   connects PE1 to PE2 and the other one connects PE3 to PE2. On PE2,
   PW1 has a higher priority than PW2 by local configuration. In case of


Muley et al.            Expires May 19, 2008                  [Page 4]


Internet-Draft       Pseudowire (PW) Redundancy)         November 2007


   MC-LAG Active/Standby status is derived by the Link Aggregation
   Control protocol (LACP) negotiation which is used in determining the
   priority of the PW.

   In normal operation, PE1 and PE3 will advertise "Active" and
   "Standby" preferential forwarding status (apart from operational
   status) respectively to PE2. This status reflects the forwarding
   state of the two AC's to CE1. PE2 advertises preferential status of
   "Active" on both PW1 and PW2. As both the local and remote
   operational and administrative status for PW1 are UP and Active,
   traffic is forwarded over PW1 in both directions.

   On failure of AC to PE1, PE1 sends a PW status notification to PE2
   indicating that the AC operational status changed to DOWN. It will
   also set the forwarding status of PW1 to "standby". PE3 AC will
   change preferential status to active and this status is also
   communicated to PE2 using the newly proposed forwarding status bit in
   the PW status TLV notification message. The changing of preferential
   status on PE3 due to failure of AC at PE1 is achieved by various
   methods depending of the used dual-homing protocol and is outside the
   scope of this draft. For example the MC-LAG control protocol changes
   the link status on PE3 to active.  On receipt of the status
   notifications, PE2 switches the path to the standby pseudo-wire PW2
   as the newly changed status turns PW2 as Active PW. Note in this
   example, the receipt of the operational status of the AC on the CE1-
   PE1 link is normally sufficient to have PE2 switch the path to PW2.
   However, the operator may want to trigger the switchover of the path
   of the PW for administrative reasons, i.e., maintenance, and thus the
   proposed PW forwarding active/standby bit is required to notify PE2
   to trigger the switchover.


















Muley et al.            Expires May 19, 2008                  [Page 5]


Internet-Draft       Pseudowire (PW) Redundancy)         November 2007


3.2. Multiple Multi-homed CEs with single SS-PW redundancy

             |<-------------- 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 such as Multi-chassis Link
   Aggregation Group (MC-LAG) 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 advertises the preferential status "active" and operational
   status "UP" for pseudo-wires PW1 and PW4 connected to PE3 and PE4.
   This status reflects the forwarding state of the AC attached to PE1.
   PE2 advertises preferential status "standby" where as operational
   status "UP" for pseudo-wires PW2 and PW3 to PE3 and PE4. PE3
   advertises preferential status "standby" where as operational status
   "UP" for pseudo-wires PW1 and PW3 to PE1 and PE2. PE4 advertise the
   preferential status "active" and operational status "UP" for pseudo-
   wires PW2 and PW4 to PE2 and PE1 respectively. The method of
   deriving Active/Standby status of the AC is outside the scope of
   this document. In case of MC-LAG it is derived by the Link
   Aggregation Control protocol (LACP) negotiation. Thus by matching
   the local and remote preferential status "active" and operational
   status "Up" of pseudo-wire the active pseudo-wire is selected. In
   this case it is the PW4 that will be selected.





Muley et al.            Expires May 19, 2008                  [Page 6]


Internet-Draft       Pseudowire (PW) Redundancy)         November 2007


                        On failure of AC between the CE1 and PE1 the
   preferential status on PE2 is changed. Different
   mechanisms/protocols can be used to achieve this and these are
   beyond the scope of this document. For example the MC-LAG control
   protocol changes the link status on PE2 to active. PE2 then
   announces the newly changed preferential status "active" to PE3 and
   PE4. PE1 will advertise a PW status notification message indicating
   that the AC between CE1 and PE1 is operationally down. PE2 and PE4
   checks the local and remote preferential status "active" and
   operational status "Up" and selects PW2 as the new active pseudo-
   wire to send 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.

4. Multi-homing MS-PW redundancy applications

4.1. Multi-homed CE with MS-PW redundancy

   The following figure illustrates an application of multi-segment
   pseudo-wire redundancy.

           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|=========|T-PE4|   |   +----+
                                    +-----+         +-----+   AC



             Figure 3                            Multi-homed CE with MS-PW redundancy

   In figure 3, the PEs that provide PWE3 to CE1 and CE2 are
   Terminating-PE1 (T-PE1) and Terminating-PE2 (T-PE2) respectively. A


Muley et al.            Expires May 19, 2008                  [Page 7]


Internet-Draft       Pseudowire (PW) Redundancy)         November 2007


   PSN tunnel extends from T-PE1 to switching-PE1 (S-PE1) across PSN1,
   and a second PSN tunnel extends from S-PE1 to T-PE2 across PSN2. PW1
   and PW2 are used to connect the attachment circuits (ACs) between T-
   PE1 and T-PE2. Each PW segment on the tunnel across PSN1 is switched
   to a PW segment in the tunnel across PSN2 at S-PE1 to complete the
   multi-segment PW (MS-PW) between T-PE1 and T-PE2. S-PE1 is therefore
   the PW switching point. PW1 has two segments and is active pseudo-
   wire while PW2 has two segments and is a standby pseudo-wire. This
   application requires support for MS-PW with segments of the same type
   as described in [6]. The operation in this case is the same as in the
   case of SS-PW. The only difference is that the S-PW nodes need to
   relay the PW status notification containing both the operational and
   forwarding status to the T-PE nodes.

4.2. Single Homed CE with MS-PW redundancy

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

           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 4 Single homed CE with multi-segment pseudo-wire redundancy

   In figure 4, CE1 is connected to PE1 in provider Edge 1 and CE2 to
   PE2 in provider edge 2 respectively. There are three segmented PWs. A
   primary PW, PW1, is switched at S-PE1 with priority 0. A standby PW,
   PW2, which is switched at S-PE2 and has a priority of 1. Finally,
   another standby PW, PW3, is switched at S-PE3 and has a priority of


Muley et al.            Expires May 19, 2008                  [Page 8]


Internet-Draft       Pseudowire (PW) Redundancy)         November 2007


   2. The priority can be configuration or derivation from the PWid.
   Lower the PWid higher the priority.

                   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. This means T-PE1 and T-PE2 will select the PW1 over
   PW2 and PW2 over PW3. Thus PW1 status will be 'active' where as PW2
   and PW3 will be standby. However this does not guarantee that paths
   of the PW are synchronized because for example of mismatch of the
   configuration of the PW priority in each T-PE.The intent of this
   application is to have T-PE1 and T-PE2 synchronize the transmit and
   receive paths of the PW over the network. In other words, both T-PE
   nodes will transmit over the PW segment which is switched by the same
   S-PE. This is desirable for ease of operation and troubleshooting.

                        This application uses the newly defined 'request
   switchover' status bit as defined in [7], to address synchronization
   of the PW paths. In event of failure of PW1 in Figure 4, the T-PEs
   will select new PW to forward the traffic. If T-PE1 detects the
   failure first, it will select the PW2 based on priority and will
   advertise status notification with preferential status bit set to
   'active' and the 'request switchover bit' set. T-PE2 on receiving the
   status update, clears the request switchover bit and changes its
   local status of PW2 to 'active' by sending status notification with
   preferential bit set to 'active'. Thus the local and remote status
   for PW2 is 'active' making it preferred PW.

                            In case of detection of failure by both ends
   simultaneously, both T-PEs send status notification with the newly
   selected PW with 'request switchover' bit set, waiting for response
   from the other end. In such situation, the T-PE with greater system
   address request is given preference. This helps in synchronizing
   paths in event of mismatch of priority configuration as well. Details
   of this procedure are covered in [7]

5. Multi-homing VPLS applications

5.1. PW redundancy between MTU-s and PEs

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








Muley et al.            Expires May 19, 2008                  [Page 9]


Internet-Draft       Pseudowire (PW) Redundancy)         November 2007



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

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

   In figure 5, MTU-s is dual homed to PE1 and PE2. The active spoke PWs
   from MTU-s are connected to PE1 while the standby PWs are connected
   to PE2. 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. It is signaled  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, to scale better.  MTU-s derives the status of the PWs
   based on local policy configuration.

                      Whenever MTU-s performs a switchover, it sends a
   wildcard Notification Message to PE2-rs for the Standby PW group
   containing PW Status TLV with PW Standby bit cleared. On receiving
   the notification PE-2 unblocks all member PWs identified by the PW
   group and state of PW group changes from Standby to Active.

                   It is to note that in this mechanism unless there is
   a failure to unblock PW groups at PE2, always a single wildcard
   Notification Message is exchanged per PW group. On failure to unblock
   the PW group PE2 may have to send Notifications of the fatal error
   per PW as PW grouping is unidirectional as per [2](in this case from
   MTU-s to PE2 only).

   The status notification defined here is similar to Topology Change
   Notification in RSTP controlled IEEE Ethernet Bridges in [8] but
   restricted over a single hop. When the mechanism defined in this
   document is implemented, PE devices are aware of switchovers at 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 currently defined in [5] to prevent


Muley et al.            Expires May 19, 2008                 [Page 10]


Internet-Draft       Pseudowire (PW) Redundancy)         November 2007


   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.

5.2. 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 6   Redundancy in 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 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.

5.3. PW redundancy in Bridge Module Model




Muley et al.            Expires May 19, 2008                 [Page 11]


Internet-Draft       Pseudowire (PW) Redundancy)         November 2007




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

                                  .   Core     .

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

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

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

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

           Network                .      \/    .              Network

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

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

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

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

                                  .            .

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

                         Figure 7 Bridge Module Model

   In figure 7, 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
   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.


Muley et al.            Expires May 19, 2008                 [Page 12]


Internet-Draft       Pseudowire (PW) Redundancy)         November 2007


                      In this scenario, Standby PW signaling defined in
   [7] can be used among n-PEs that can disseminate the status of PWs
   (active or blocked) 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.

6. Design considerations

   While using the pseudo-wire redundancy application, the T-LDP peers
   MUST negotiate the usage of PW status TLV. The status code defined
   below carries the active/standby preferential forwarding status of
   the pseudo-wire. The pseudo-wire is only considered active pseudo-
   wire only when both the local PW status and the remote PW status
   indicate preferential status "active" and operational status as Up.
   Any other status combination keeps the pseudo-wire in standby mode.
   The pseudo-wires are given different preference level. In case of
   network failure, the PE/T-PE will first switch to the standby PW with
   a higher preference. Although the configuration of the pseudo-wire
   preference is matter of local policy matter and is outside the scope
   of this, it is desirable to have the preferences configured on both
   end points be similar. In mis-configuration, a method to force the
   synchronization of the PW paths is required is for further study.
   While in standby status, a pseudo-wire can still receive packets in
   order to avoid black holing of the in-flight packets during
   switchover.

           The application of Standby PWs in VPLS redundancy is OPTIONAL
   and is a tradeoff between savings in bandwidth/resources and traffic
   switchover time on PW state change from Standby to Active.
   Implementations SHOULD provide facilities to administratively enable
   or disable this mechanism based on whether the resulting switchover
   time is acceptable to SLA between a provider and its customers or
   not. The target environment of the current solution is H-VPLS
   redundancy scenarios defined in [5] and is equally applicable to
   other possible VPLS redundancy scenarios.

7. Security Considerations

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







Muley et al.            Expires May 19, 2008                 [Page 13]


Internet-Draft       Pseudowire (PW) Redundancy)         November 2007


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.

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", March 2005

   [4]  Andersson, L., Doolan, P., Feldman, N., Fredette, A., and B.
         Thomas, "LDP Specification", RFC 3036, 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-02.txt, March 2006.

   [7]  Muley, P. et al., "Preferential forwarding status bit", draft-
         muley-dutta-pwe3-redundancy-bit-00.txt, August 2007.

   [8]  IEEE Std. 802.1D-2003-Media Access Control (MAC) Bridges.



Author's Addresses

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





Muley et al.            Expires May 19, 2008                 [Page 14]


Internet-Draft       Pseudowire (PW) Redundancy)         November 2007


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


   Matthew Bocci
   Alcatel-Lucent
   Voyager Place, Shoppenhangers Rd
   Maidenhead, Berks, UK SL6 2PJ
   Email: matthew.bocci@alcatel-lucent.co.uk

   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@cw.com

   Olen Stokes
   Extreme Networks
   Email: ostokes@extremenetworks.com

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

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of


Muley et al.            Expires May 19, 2008                 [Page 15]


Internet-Draft       Pseudowire (PW) Redundancy)         November 2007


   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.

Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Copyright Statement

   Copyright (C) The IETF Trust (2007).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.















Muley et al.            Expires May 19, 2008                 [Page 16]


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