Network Working Group L. Jin Internet-Draft B. Khasnabish Intended status: Standards Track ZTE Expires: September 12, 2011 March 11, 2011 Pseudowire freeze mechanism draft-jin-pwe3-pw-freeze-01.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 September 12, 2011. Copyright Notice Copyright (c) 2011 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 September 12, 2011 [Page 1] Internet-Draft draft-jin-pwe3-pw-freeze-01 March 2011 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 . . . . . . . . . . 6 4.1.1. PW freeze status definition and encoding . . . . . . . 6 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. Backward compatibility . . . . . . . . . . . . . . . . . . . . 8 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 7.1. Normative references . . . . . . . . . . . . . . . . . . . 8 7.2. Informative References . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 Jin, et al. Expires September 12, 2011 [Page 2] Internet-Draft draft-jin-pwe3-pw-freeze-01 March 2011 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. PWE3 technology has been used as a transport technology, and deployed in mobile backhaul or other access/aggregation network. Most of the pizza boxes supporting PWE3 in access network have lower CPU performance than that in aggregation/metro/core network, so as to reduce the hardware cost. What!_s more, sometimes the boxes in aggregation network also have low CPU performance. From the currently deployed network, in order to run LDP and other routing protocols, we observe that the main controller CPU in pizza box is sometimes overloaded. When LDP session is established, the T-LDP hello adjacency may expire because of main controller CPU overload, which results the corresponding PW traffic being interrupted. In MPLS-TP [I-D.ietf-ccamp-mpls-tp-cp-framework], 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 September 12, 2011 [Page 3] Internet-Draft draft-jin-pwe3-pw-freeze-01 March 2011 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]. However when T-LDP graceful restart is enabled, all the applications over this session, e.g, PW and LDP-Prefix LSP (e.g, the LDP-Prefix for LDP over RSVP-TE LSP), are forced to be graceful restarted. But sometimes, operators do not want to enable the graceful restart of all applications, e.g, LDP-Prefix graceful restart, but still want the PW to be separated from the control plane Jin, et al. Expires September 12, 2011 [Page 4] Internet-Draft draft-jin-pwe3-pw-freeze-01 March 2011 For MPLS-TP network, there are also some network maintenance motivations to make PW to be independent from LDP signaling after PW being setup successfully. For example, if the service provider wants to adjust some part of the network without influencing the traffic, it only needs to care about the transport path of PW without considering the dynamic IP path of LDP signaling, which will bring the network adjustment to be much easier. Then, 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. Jin, et al. Expires September 12, 2011 [Page 5] Internet-Draft draft-jin-pwe3-pw-freeze-01 March 2011 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 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.ietf-pwe3-static-pw-status], the MAC withdraw message transmission should follow [I-D.boutros-pwe3-mpls-tp-mac-wd]. 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]. 1.a. 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 Jin, et al. Expires September 12, 2011 [Page 6] Internet-Draft draft-jin-pwe3-pw-freeze-01 March 2011 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 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. Jin, et al. Expires September 12, 2011 [Page 7] Internet-Draft draft-jin-pwe3-pw-freeze-01 March 2011 6. Backward compatibility The PE that does not support the PW freeze bit in status TLV will ignore this bit, and the PW will not enter into freeze status. 7. References 7.1. Normative references [RFC3478] Leelanivas, M., Rekhter, Y., and R. Aggarwal, "Graceful Restart Mechanism for Label Distribution Protocol", RFC 3478, February 2003. [RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. Heron, "Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)", RFC 4447, April 2006. [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP Specification", RFC 5036, October 2007. 7.2. Informative References [I-D.boutros-pwe3-mpls-tp-mac-wd] Sivabalan, S., Boutros, S., and L. Martini, "MAC Address Withdrawal over Static Pseudowire", draft-boutros-pwe3-mpls-tp-mac-wd-01 (work in progress), March 2011. [I-D.ietf-ccamp-mpls-tp-cp-framework] Andersson, L., Berger, L., Fang, L., Bitar, N., Gray, E., Takacs, A., Vigoureux, M., and E. Bellagamba, "MPLS-TP Control Plane Framework", draft-ietf-ccamp-mpls-tp-cp-framework-06 (work in progress), February 2011. [I-D.ietf-pwe3-static-pw-status] Martini, L., Swallow, G., Heron, G., and M. Bocci, "Pseudowire Status for Static Pseudowires", draft-ietf-pwe3-static-pw-status-02 (work in progress), March 2011. Jin, et al. Expires September 12, 2011 [Page 8] Internet-Draft draft-jin-pwe3-pw-freeze-01 March 2011 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 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 September 12, 2011 [Page 9]