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]