Network Working Group L. Jin Internet-Draft B. Khasnabish Intended status: Standards Track ZTE Expires: January 6, 2011 July 5, 2010 Pseudowire freeze mechanism draft-jin-pwe3-pw-freeze-00.txt Abstract This draft introduces a pseudowire freeze mechanism, which enables pseudowire control plane and data plane separation. When the PW is working in freeze state, the data transmission will not be influenced by turbulence of control plane. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on January 6, 2011. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect Jin, et al. Expires January 6, 2011 [Page 1] Internet-Draft draft-jin-pwe3-pw-freeze-00 July 2010 to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Problem statement . . . . . . . . . . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. PW freeze mechanism . . . . . . . . . . . . . . . . . . . . . . 5 4.1. PW freeze status encoding and signaling . . . . . . . . . . 5 4.1.1. PW freeze status definition and encoding . . . . . . . 5 4.1.2. PW freeze status signaling . . . . . . . . . . . . . . 6 4.2. PE operation . . . . . . . . . . . . . . . . . . . . . . . 6 4.3. Multi-Segment PW freeze function . . . . . . . . . . . . . 7 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 6. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . . 7 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 7.1. Normative references . . . . . . . . . . . . . . . . . . . 8 7.2. Informative References . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 Jin, et al. Expires January 6, 2011 [Page 2] Internet-Draft draft-jin-pwe3-pw-freeze-00 July 2010 1. Introduction This draft introduces a pseudowire freeze mechanism, which enables pseudowire control plane and data plane separation. When the PW is working in freeze state, the data transmission will not be influenced by turbulence of control plane (including signaling and PW control component), so as to offer to pseudowire [RFC4447] more high availability, but with low provisioning cost compared with current mechanisms. High availability is one of the key requirements in current carrier MPLS network. Pseudowire is now widely used for network converging, or layer2 VPN service, e.g, VPWS and VPLS. The L2VPN are now used to transport traffic of some important customers, which requires pseudowire with high availability (including both control plane and data plane high availability). Using pseudowire redundancy [I-D. draft-ietf-pwe3-redundancy] mechanism or some PSN tunnel protection technology can improve high availability to protect traffic down from link or node failure. These technologies are usually used to protect node data plane failure or traffic link failure as well as control plane failure, and will use additional resources to backup. They will also bring high provisioning cost, for example, provider needs to plan the backup path for the protected path, and also needs to plan the network resources, e.g, bandwidth. If the pseudowire failure is due to a signaling failure, and PW redundancy or PSN tunnel protection technology is used to do PW protection, it will cost much more for the network (both additional network resources and operational cost). In the worse case, many PWs are down due to signaling failure which is coursed by sharing same fate of signaling session, e.g, session sharing same node or link, then it is a burden or pressure for the network to switch all affected PWs to the backup at the same time. In another case, the network has not enough resources to do resource backup for data plane high availability, but control plane high availability is still required, then a way to only improve control plane high availability with low provisioning cost is preferred. In MPLS-TP [I-D. draft-ietf-ccamp-mpls-tp-cp-framework-01], it is required that the data and control planes are both logically and physically separated, which ensures that in the case of control plane failures the data plane is not affected and can continue to operate normally. While in normal MPLS environment, when PW control plane is DOWN, the PW traffic will be interrupted. Jin, et al. Expires January 6, 2011 [Page 3] Internet-Draft draft-jin-pwe3-pw-freeze-00 July 2010 2. Problem statement |<-------------- Emulated Service ----------------->| | | | |<------- Pseudo Wire ------->| | | | | | | | |<-- PSN Tunnel --->| | | | V V V V | V AC +----+ +---+ +----+ AC V +-----+ | | PE1|=======| P |=======| PE2| | +-----+ | |----------|.............................|----------| | | CE1 | | | | | | | | | | CE2 | | |----------|.............................|----------| | +-----+ | | |=======| |=======| | | +-----+ +----+ +---+ +----+ | | | | \ / \ +--------+ / ----| Router |----- +--------+ Figure 1 In some network of deploying pseudowire, the PW signaling path is different from the data transmission path. See figure 1, the PSN Tunnel is setup along the path of PE1, P and PE2, while the T-LDP session is setup along the path of PE1, Router and PE2. This is possible if the PSN tunnel is initiated by RSVP-TE which will calculate the path with explicit route, or the path is an inter-area/ inter-as one. In this case, the failure of T-LDP session should not influence the pseudowire data traffic. For example, if the Router in figure 1 fails and T-LDP session is DOWN, then PW traffic corresponding to this T-LDP session should not be interrupted. According to the LDP procedure [RFC5036], if the T-LDP session is DOWN, the received label from this session should be deleted and corresponding traffic is interrupted. When graceful restart [RFC3478] is enabled on this T-LDP session, PE will not interrupt the PW traffic for a time with the value of "reconnect time" defined in [RFC3478]. The maximum value of "reconnect time" is 4294967295 milliseconds, or 49.7 days. For the case of T-LDP session which is not necessary to be recovered in a short time, it is not correct to keep the PW traffic within a limited time. Moreover when T-LDP restart is enabled, all the applications over this session, e.g, PW and LDP LSP, are forced to be graceful restarted. But sometimes, operators need more flexible configuration, and only want some of the Jin, et al. Expires January 6, 2011 [Page 4] Internet-Draft draft-jin-pwe3-pw-freeze-00 July 2010 PWs not to be influenced by T-LDP session status, so as to provide different availability level of service. It is necessary to define a freeze mechanism for PW, which can prevent the PW traffic to be interrupted when T-LDP session is DOWN or the PW control component on PE is corrupted, but PW forwarding engine remains working. 3. Terminology T-LDP: Target LDP. PW control component: The processing component on PE, which is responsible for PW signaling and management. Freezed PW: A PW whose control plane is separated from data plane. 4. PW freeze mechanism The PW freeze mechanism aims to provide a function for PW not to be influenced by the turbulence of control plane, which will improve the high availability of the PW. When the PW supports !ofreeze" function, once PW is operational UP, it will not be influenced by the turbulence of control plane. When the freezed PW is unfreezed, the PW will behave as defined in [RFC4447] and [RFC5036]. The turbulence of control plane will include instability of signaling session and PW control component. When PW is in "freezed" state, PE should have the capability of continuing PW data forwarding without PW control component. In this case, before PW control component is failed, PE SHOULD store the PW information in the backup PW control component or non-volatile ROM, which is an implementation issue. When PW control component is initialized, it SHOULD restore the PW information from the backup component. The specific of above procedure depends on implementation and is out of scope of this draft. This draft only deals with the control plane of PW signaling session, T-LDP session. This version of draft only describes the case of point-to-point PW, and unidirectional point-to-multipoint PW will be studied in future version. 4.1. PW freeze status encoding and signaling 4.1.1. PW freeze status definition and encoding There will be two state defined for PW in this draft, freezed and normal state. In the freezed state, PW will not be influenced by the Jin, et al. Expires January 6, 2011 [Page 5] Internet-Draft draft-jin-pwe3-pw-freeze-00 July 2010 control plane and continue working and transmitting traffic if control plane is DOWN. In the normal state, also known as unfreezed state, the PW will behave as defined in [RFC4447] and [RFC5036], and the PW traffic will be interrupted when T-LDP session is DOWN. The PW freeze status is encoded in PW status TLV. The status code definition (IANA, TBD) is pre-allocated as 0x00000080. When the PW freeze bit is set, it indicates that the PW supports "freeze" function, and will be in "freeze" state. When the PW freeze bit is cleared, it indicates that the PW will be in "unfreeze" status. 4.1.2. PW freeze status signaling When the PW is configured as "freeze", PE SHOULD advertise the capability by sending label mapping message carrying the PW status TLV with "PW freeze bit" set, or by sending LDP notification message carrying the PW status TLV with "PW freeze bit" set. The PW freeze function will be effective only when both endpoints of PW signal the "PW freeze" status. When one of the PW endpoint signals PW status with PW freeze bit cleared, both of the two endpoints should unfreeze the PW. When PW is already in "freeze" state, the PW status should be transmitted through generic associated channel, as defined in [I-D. draft-ietf-pwe3-static-pw-status-00]. 4.2. PE operation If PW supports "freeze" function through negotiation, as in section 4.1.2: 1. When PW is operational UP, PW will enter into the freezed state. The PE should locally store the PW information that received from the peer node, including PW type, PW label and etc. For more detail of the PW information, please refer to [RFC4447]. When T-LDP session is DOWN, the PE should continue the PW data forwarding. In this case, if the PW on one PE will be deleted or not provisioned, before deleting the PW, PE should send PW down status bit to peer node through G-ACH. 1.b. When T-LDP session switches from DOWN to UP status, and if local PW status is DOWN, PE should send PW label mapping message to peer node again, with the PW information stored locally. If peer node receives a PW label mapping message with different information Jin, et al. Expires January 6, 2011 [Page 6] Internet-Draft draft-jin-pwe3-pw-freeze-00 July 2010 as stored locally, it should update the PW information. If local PW status is UP, there is no operation for PE. 2. When PW is operational DOWN, PW will still in normal state, and not enter into the freezed state. If PW is configured or signaled to "unfreeze", as in section 4.1.2: When PW corresponding T-LDP session is DOWN, PE should delete the corresponding PW, and stop forwarding traffic. To be noted: PE should send PW status TLV with !oPW not forwarding!+/- status bit set to peer node through G-ACH before completely delete PW locally. 2. When PW corresponding T-LDP session is UP, there is no operation for PE. 4.3. Multi-Segment PW freeze function For the case of multi-segment PW, only when each PW segment support "freeze" function, the MS-PW will support freeze function. When S-PE receives PW status with "PW freeze" bit set, and if the PW segment on this S-PE does not support "freeze" function, S-PE will forward this PW status with "PW freeze" bit cleared. 5. IANA Considerations This document defines the PW freeze status code for the PW freeze mechanism. IANA is requested to allocate these from the PW Status Codes registry. The PW freeze status code definition is pre- allocated as 0x00000080. When the PW freeze bit is set, it indicates that the PW supports "freeze" function, and will be in "freeze" status. When the PW freeze bit is cleared, it indicates that the PW will be in "unfreeze" status. 6. Acknowledgement [Editor's note] Will be added in future. 7. References Jin, et al. Expires January 6, 2011 [Page 7] Internet-Draft draft-jin-pwe3-pw-freeze-00 July 2010 7.1. Normative references [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3478] Leelanivas, M., Rekhter, Y., and R. Aggarwal, "Graceful Restart Mechanism for Label Distribution Protocol", RFC 3478 , February 2003. [RFC4447] Martini, L., "Multiprotocol Extensions for BGP-4", RFC 4447 , April 2006. [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP Specification", RFC 5036 , October 2007. 7.2. Informative References [I-D. draft-ietf-ccamp-mpls-tp-cp-framework-01] Andersson, L., Berger, L., Fang, L., and N. Bitar, "MPLS-TP Control Plane Framework", draft-ietf-ccamp-mpls-tp-cp-framework-01 (work in progress), March 2010. [I-D. draft-ietf-pwe3-static-pw-status-00] Martini, L., Swallow, G., and M. Bocci, "Pseudowire Status for Static Pseudowires", draft-ietf-pwe3-static-pw-status-00 (work in progress), February 2010. Authors' Addresses Lizhong Jin ZTE Corporation 889, Bibo Road Shanghai, 201203, China Email: lizhong.jin@zte.com.cn Bhumip Khasnabish ZTE USA Email: bhumip.khasnabish@zteusa.com Jin, et al. Expires January 6, 2011 [Page 8] Internet-Draft draft-jin-pwe3-pw-freeze-00 July 2010 Kan Hu ZTE Corporation 68, Zijinghua Road Nanjing, 210012, China Email: hu.kan@zte.com.cn Baojun Chen ZTE Corporation 68, Zijinghua Road Nanjing, 210012, China Email: chen.baojun@zte.com.cn Jian Feng ZTE Corporation 68, Zijinghua Road Nanjing, 210012, China Email: feng.jian@zte.com.cn Jin, et al. Expires January 6, 2011 [Page 9]