Network Working Group                                     Praveen Muley 
Internet Draft                                        Mustapha Aissaoui 
Intended status: Standards Track                          Matthew Bocci 
Expires: August 2007                                Pranjal Kumar Dutta 
                                                           Marc Lasserre 
                                                          Alcatel-Lucent  
                                                          
                                                         Jonathan Newton 
                                                        Cable & Wireless 
                                                                         
                                                             Olen Stokes 
                                                        Extreme Networks 
                                                                         
                                                       Hamid Ould-Brahim 
                                                                  Nortel 
                                                                         
 
                                    
                                                       February 25, 2007 
                                      
               Preferential Forwarding Status bit definition 
               draft-muley-dutta-pwe3-redundancy-bit-00.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. 

   This document may only be posted in an Internet-Draft. 

   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 August 25, 2007                 [Page 1] 

Internet-Draft       Preferential forwarding bit          February 2007 
    

   This Internet-Draft will expire on August 25, 2007. 

Abstract 

   This document describes a mechanism for standby status signaling of 
   redundant PWs between its termination points. 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. This draft 
   specifies a new PW status bit for this purpose. 

    

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. Introduction...................................................3 
   2. Motivation.....................................................3 
   3. Signaling procedures of PW State Transition....................4 
      3.1. PW Standby notification procedures in Master/Slave mode...5 
         3.1.1. PW State Machine.....................................6 
      3.2. PW Standby notification procedures in Independent mode....8 
   4. Applicability..................................................8 
   5. Security Considerations........................................8 
   6. IANA Considerations............................................9 
      6.1. Status Code for PW Preferential Forwarding Status.........9 
   7. Acknowledgments................................................9 
   8. References.....................................................9 
      8.1. Normative References......................................9 
      8.2. Informative References....................................9 
   Author's Addresses...............................................10 
   Intellectual Property Statement..................................11 
   Disclaimer of Validity...........................................12 
   Acknowledgment...................................................12 
    
   o    



 
 
Muley et al.           Expires August 25, 2007                 [Page 2] 

Internet-Draft       Preferential forwarding bit          February 2007 
    

1. Introduction 

   In single-segment PW (SS-PW) services such as VPWS and VPLS, 
   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. In a VPWS service, this is used to provide access AC 
   redundancy to a CE device which is dual-homed to target PE nodes. In 
   a HVPLS service, this is used to provide access PW redundancy to the 
   MTU device which is dual-homed to two PE-r devices. More details are 
   provided in [4]. 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 
   nodes. In these applications, PW redundancy is important for the 
   service resilience.  

   This document specifies a new PW status bit to indicate the 
   preferential forwarding status of the PW for the purpose of notifying 
   the remote 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].  

2. Motivation    

   Currently the operational status defined in the PWE3 control protocol 
   [2] introduces two states to AC and PW, Operationally UP or DOWN. The 
   scenarios defined in [4] require more states to make forwarding 
   decision of the traffic. This draft defines a new status bit called 
   preferential forwarding status bit and introduces two additional 
   states to PW, Active and Standby, to indicate the preferred PW path 
   to forward traffic to one another.           

   o  Active State                                                  

   A PW is considered to be in Active state when the PW labels are 
   exchanged between its two terminating points in control plane and the 
   corresponding data path is established. In this state data traffic 
   can flow over the PW in both directions. A PW by default is always in 
   Active state after it is set UP by signaling. 

   o  Standby State 

   A PW is considered to be in Standby state when the PW labels are 
   exchanged between its two terminating points in the control plane but 
 
 
Muley et al.           Expires August 25, 2007                 [Page 3] 

Internet-Draft       Preferential forwarding bit          February 2007 
    

   the data traffic is blocked at either or both the ends. In this state 
   the blocked end(s) of the PW SHOULD NOT forward data traffic over the 
   PW but MUST allow PW OAM packets (e.g, VCCV) to be sent and received. 
   How a PW should be blocked only for data traffic is implementation 
   specific and is out of scope of this document. In the context of this 
   document "blocking" a PW means blocking data traffic only and 
   "unblocking" as vice versa unless specified otherwise. 

   The preferential forwarding status of active or standby for each PW 
   in the redundancy set determines the selection of the PW a PE/T-PE 
   forwards traffic to. There are two modes of operation for the PW 
   redundancy: 

   1. Synchronization of PW paths not mandatory (Independent Mode): 

   PW endpoint nodes advertise independently their Active/Standby states 
   and each compares local and remote status and select the PW which is 
   operationally UP and shows both local Active and remote Active in 
   preference to the other combination of states. If such PW is not 
   found, then a PE/T-PE MAY forward over a PW which is Active locally 
   and Standby remotely. No error condition is generated and thus 
   asymmetric PW path forwarding is allowed.  

   2. Synchronization of PW paths mandatory (Master/Slave Mode): 

   A Master/Slave operation is required between the endpoint nodes of 
   the PWs. There is a single PE/T-PE Master node and one or many PE/T-
   PE Slave nodes. The assignment of Master/Slave roles to the nodes is 
   performed by local configuration.   

   The Master node ignores the Active/Standby status bits received from 
   the Slave nodes. The Slave nodes are required to act on the status 
   bits received from the Master node. When the received status bit 
   transitions from Active to Standby, a Slave node SHOULD block 
   forwarding over the PW. If it fails to block it, it does nothing. 
   When the received status bit transitions from Standby to Active, the 
   Slave node MUST unblock forwarding over the PW. It fails to block it, 
   it generates a status bit of "PW not forwarding" back to the Master. 

   The Master node then unblocks another PW and if successful will reset 
   the status bit to Standby towards the Slave node that advertised "PW 
   not forwarding".  

3. Signaling procedures of PW State Transition 

   This section describes the extensions proposed and the processing 
   rules for the extensions. It defines a new "PW preferential 
 
 
Muley et al.           Expires August 25, 2007                 [Page 4] 

Internet-Draft       Preferential forwarding bit          February 2007 
    

   forwarding" bit in Status Code that is to be used with PW Status TLV 
   proposed in [2]. The PW preferential forwarding bit when set is used 
   to signal Standby state of PW by one terminating point to the other 
   end. An implementation that uses this mechanism MUST negotiate the 
   usage of PW status TLV between its T-LDP peers as per [2]. If PW 
   Status TLV is found to be not supported by either of its endpoint 
   after status negotiation procedures then the mechanism proposed in 
   this document SHOULD NOT be used. 

3.1. PW Standby notification procedures in Master/Slave mode 

   The central concept of this mechanism is that whenever the Master PW 
   termination point "actively" blocks or unblocks the PW at its end, it 
   explicitly notifies the event to the remote Slave termination point.  
   The slave point carries out the corresponding action on receiving the 
   PW state change notification. Presence of the PW Standby bit in PW 
   Status TLV indicates that the PW at the disposing end is blocked and 
   kept in Standby state, and the PW SHOULD also be blocked at receiving 
   end. Clearance of the PW Standby bit in PW Status TLV indicates that 
   the PW at the disposing end is unblocked and is in Active state, and 
   the receiving end SHOULD make the PW Active if it is blocked earlier. 
   If the receiving end (slave node) is successful in carrying out the 
   required action it SHOULD NOT notify disposing end as its role in 
   this event is passive. If the receiving end fails to block the PW at 
   its end it SHOULD NOT notify about its failure as anyway the PW is 
   blocked at disposing end. If the receiving end fails to unblock the 
   PW it SHOULD notify it as fatal error to the disposing end. The 
   status bit proposed for this notification is the "PW not forwarding". 
   This mode of signaling is necessary to keep the termination points of 
   a PW synchronized in states with respect to each other.  

                The mechanism is RECOMMENDED to be used with PWs 
   signaled in groups with common group-id in PWid FEC Element or 
   Grouping TLV in Generalized PWid FEC Element defined in [2]. When PWs 
   are provisioned with such grouping a termination point sends a single 
   "wildcard" Notification message using a PW FEC TLV with only the 
   group ID set, to denote this change in status for all affected PW 
   connections. This status message contains either the PW FEC TLV with 
   only the Group ID set, or else it contains the PW Generalized FEC TLV 
   with only the PW Grouping ID TLV. As mentioned in [2], the Group ID 
   field of the PWid FEC Element, or the PW Grouping TLV used with the 
   Generalized ID FEC Element, can be used to send status notification 
   for all arbitrary set of PWs. For example, Group-ID in PWiD may be 
   used to send wildcard status notification message for a group of PWs 
   when PWid FEC element is used for PW state signaling. When 
   Generalized PWiD FEC Element defined is used in PW state signaling, 

 
 
Muley et al.           Expires August 25, 2007                 [Page 5] 

Internet-Draft       Preferential forwarding bit          February 2007 
    

   PW Grouping TLV may be used for wildcard status notification for a 
   group of PWs. 

                  In MS-PW application, the S-PE nodes relay the PW 
   status notification containing both the operational and preferential 
   forwarding status to the T-PE nodes. 

3.1.1. PW State Machine  

   It is convenient to describe the PW state change behavior in terms of 
   a state machine. The PW state machine is explained in detail in the 
   two defined states and the behavior is presented as a state 
   transition table. The same state machine is seamlessly applicable to 
   PW Groups.  

    

                     PW State Transition State Table 

    

      STATE         EVENT                               NEW STATE 

       

      ACTIVE        PW blocked actively                 STANDBY 

                    Action: Transmit PW Standby bit set  

    

                    Receive PW Standby bit set          STANDBY   

                    Action: PW blocked  

    

                    Receive PW Standby bit set          ACTIVE 

                    but PW blocking failed 

                    Action : None 

    

                    Receive PW Standby bit set          ACTIVE 

 
 
Muley et al.           Expires August 25, 2007                 [Page 6] 

Internet-Draft       Preferential forwarding bit          February 2007 
    

                    but PW Standby bit not supported  

                    Action: None 

    

                    Receive PW Standby bit clear        ACTIVE       

                    Action: None. 

    

                    Receive PW Not Forwarding bit set   Applicable state  

                    Action: Applicable as per [2]        as per [2]  

    

      STANDBY       PW unblocked actively               ACTIVE 

                    Action : Transmit PW Standby 

                              bit clear 

    

                    Receive PW Standby bit clear        ACTIVE                 

                    Action: PW unblocked  

    

                    Receive PW Standby bit clear       Applicable state  

                    but PW unblocking failed           as per [2] 

                    Action : Transmit PW Not Forwarding 

                              bit.   

    

                    Receive PW Not Forwarding bit set   Applicable state    

                    Action: Applicable procedure as per [2]   as per [2] 

                           
 
 
Muley et al.           Expires August 25, 2007                 [Page 7] 

Internet-Draft       Preferential forwarding bit          February 2007 
    

    

                     Receive PW Standby bit set          STANDBY  

                     Action :No action 

3.2. PW Standby notification procedures in Independent mode 

   In this mode of operation, each endpoint of the PW selects 
   independently which PW to activate based on the specific application. 
   The endpoints advertise the resulting Active/Standby status over all 
   PWs in the redundancy set.  

   Each endpoint compares local and remote status and MUST select the PW 
   which shows local Active and remote Active in preference to any other 
   combination of local and remote forwarding states. If multiple PWs 
   show Active/Active, then the PW to forward traffic to is a local 
   endpoint decision. Thus, asymmetric forwarding over the PW paths is 
   allowed in this mode. 

   If there is no Active/Active PW, then an endpoint MAY forward over a 
   PW which shows other combination of forwarding states. However, the 
   receiving end may discard the received packets. No error messages are 
   sent in this case. 

   In MS-PW application, the S-PE nodes relay the PW status notification 
   containing both the operational and preferential forwarding status to 
   the T-PE nodes. 

4. Applicability 

   The mechanism defined in this document is OPTIONAL and is applicable 
   to PWE3 applications where standby state signaling of PW or PW group 
   is required. Application of the mechanism for P2MP and MP2MP PW is 
   again outside the scope and is a subject of future study.  

5. 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 [3] 
   and the PW control protocol [2]. 






 
 
Muley et al.           Expires August 25, 2007                 [Page 8] 

Internet-Draft       Preferential forwarding bit          February 2007 
    

6. IANA Considerations   
    

   We have defined the following codes for the pseudo-wire redundancy 
   application.  
    

 
6.1. Status Code for PW Preferential Forwarding Status  
    

   The PE/T-PE nodes need to indicate to each other the preferential 
   forwarding status of active/inactive of the pseudo-wire.  

   0x00000020 When the bit is set, it represents "PW forwarding  

              standby".  

              When the bit is cleared, it represents "PW forwarding 

              active". 

7. Acknowledgments  

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

8. References 

8.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]   Andersson, L., Doolan, P., Feldman, N., Fredette, A., and B. 
         Thomas, "LDP Specification", RFC 3036, January 2001 

8.2. Informative References 

   [4]   Praveen, Pranjal et al., "draft-muley-pwe3-redundancy-01.txt" , 
         August 2007.  

 
 
Muley et al.           Expires August 25, 2007                 [Page 9] 

Internet-Draft       Preferential forwarding bit          February 2007 
    

    

Author's Addresses 

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

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






























 
 
Muley et al.           Expires August 25, 2007                [Page 10] 

Internet-Draft       Preferential forwarding bit          February 2007 
    

   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@cwmsg.cwplc.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 
   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 
 
 
Muley et al.           Expires August 25, 2007                [Page 11] 

Internet-Draft       Preferential forwarding bit          February 2007 
    

   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 August 25, 2007                [Page 12]