Internet DRAFT - draft-muley-pwe3-redundancy

draft-muley-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]