Network Working Group L. Jin Internet-Draft ZTE Intended status: Standards Track B. Khasnabish Expires: January 9, 2012 ZTE USA M. Venkatesan Aricent July 8, 2011 Pseudowire freeze mechanism draft-jin-pwe3-pw-freeze-02.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 9, 2012. 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 Jin, et al. Expires January 9, 2012 [Page 1] Internet-Draft draft-jin-pwe3-pw-freeze-01 July 2011 publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect 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. Backward compatibility . . . . . . . . . . . . . . . . . . . . 7 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 7.1. Normative references . . . . . . . . . . . . . . . . . . . 8 7.2. Informative References . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 Jin, et al. Expires January 9, 2012 [Page 2] Internet-Draft draft-jin-pwe3-pw-freeze-01 July 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 static pseudowire. Note that the pseudowire freeze mechanism only applys for pseudowire with LDP control plane. 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 IP forwarding 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 January 9, 2012 [Page 3] Internet-Draft draft-jin-pwe3-pw-freeze-01 July 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/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. LDP graceful restart defined in [RFC3478] is more appliable for IP Prefix, not PW FEC. The PW information in MPLS forwarding state defined in [RFC3478] section 1 is not enought for a restarting PE to recover. And it is also a bit complicated for a pizza boxe to implement LDP graceful restart. 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, Jin, et al. Expires January 9, 2012 [Page 4] Internet-Draft draft-jin-pwe3-pw-freeze-01 July 2011 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. The PW freeze mechanism 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 continues 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 9, 2012 [Page 5] Internet-Draft draft-jin-pwe3-pw-freeze-01 July 2011 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 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 Jin, et al. Expires January 9, 2012 [Page 6] Internet-Draft draft-jin-pwe3-pw-freeze-01 July 2011 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. 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 Jin, et al. Expires January 9, 2012 [Page 7] Internet-Draft draft-jin-pwe3-pw-freeze-01 July 2011 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-05 (work in progress), June 2011. Authors' Addresses Lizhong Jin ZTE Corporation 889, Bibo Road Shanghai, 201203, China Email: lizhong.jin@zte.com.cn Jin, et al. Expires January 9, 2012 [Page 8] Internet-Draft draft-jin-pwe3-pw-freeze-01 July 2011 Bhumip Khasnabish ZTE USA Email: bhumip.khasnabish@zteusa.com Mahalingam Venkatesan Aricent India Email: venkatesan.mahalingam@aricent.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 January 9, 2012 [Page 9]