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]