Network Working Group Lizhong Jin (ed.), ZTE Internet-Draft Raymond Key (ed.), Telstra Updates: 4447 Simon Delord, Alcatel-Lucent Category: Standards Track Thomas Nadeau, Huawei Expires: June 8, 2011 Vishwas Manral, IPInfusion Sami Boutros, Cisco Reshad Rahman, Cisco December 8, 2010 Pseudowire Control Word Negotiation Mechanism Update draft-jin-pwe3-cbit-negotiation-02.txt Abstract This draft describes the problem of control word negotiation mechanism specified in [RFC4447]. Based on the problem analysis, a message exchanging mechanism is introduced to solve this control word negotiation issue. This draft is to update [RFC4447] control word negotiation mechanism. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. 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. This Internet-Draft will expire on June 8, 2011. Jin, et al. Expires June 2011 [Page 1] Internet-Draft draft-jin-pwe3-cbit-negotiation-02 December 2010 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 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 . . . . . . . . . . . . . . . . . . . . . . . 3 3. Control word re-negotiation by label request message . . . . . . 4 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 5 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 7.1. Normative References . . . . . . . . . . . . . . . . . . . . . 5 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 Appendix A. Updated C-bit Handling Procedures Diagram . . . . . . . 7 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 [RFC2119]. Jin, et al. Expires June 2011 [Page 2] Internet-Draft draft-jin-pwe3-cbit-negotiation-02 December 2010 1. Introduction This draft describes the problem of control word negotiation mechanism specified in [RFC4447]. Based on the problem analysis, a message exchanging mechanism is introduced to solve this negotiation issue. The control word negotiation mechanism in this draft is to update [RFC4447] section 6.2 "PW Types for Which the Control Word is NOT Mandatory". 2. Problem Statement [RFC4447] section 6 describes the control word negotiation mechanism. Each PW endpoint has the capability of being configurable with a parameter that specifies whether the use of the control word is PREFERRED or NOT PREFERRED. While in some case of control word negotiation, PE will advertise C-bit=0 in label mapping message with its locally configured control word PREFERRED. This kind of behavior will cause some problem when peer PE changes its control word from NOT PREFERRED to PREFERRED. This following case will describe the negotiation problem in detail: +-------+ +-------+ | | PW | | | PE1 |====================| PE2 | | | | | +-------+ +-------+ Figure 1 1. Initially, the control word on PE1 is configured to PREFERRED, and on PE2 to NOT PREFERRED. 2. The negotiation result for the control word for this PW is "not supported", and PE1 send label mapping with C-bit=0 finally. 3. PE2 then changes its control word configuration to PREFERRED. 4. PE2 will then send label withdraw message to PE1. 5. According to the control word negotiation mechanism, the received label mapping on PE2 from PE1 indicates C-bit=0, therefore PE2 will still send label mapping with C-bit=0. The negotiation result for the PW control word is still "not supported", even though the control word configuration on both PE1 and PE2 is set to PREFERRED. Jin, et al. Expires June 2011 [Page 3] Internet-Draft draft-jin-pwe3-cbit-negotiation-02 December 2010 3. Control word re-negotiation by label request message In order to solve this problem, the control word re-negotiation is operated by adding label request message. The control word negotiation mechanism can still follow the procedure described in [RFC4447] section 6. When Local PE changes its control word from NOT PREFERRED to PREFERRED and only if it already received the remote label mapping message with C-bit=0, additional procedure will be added as follow: -i. Local PE sends label withdraw message to the remote if it already sends label mapping message, for it has changed its control word parameter. -ii. Local PE MUST send a label request messages to peer PE to get peer's configured control word parameter before sending new label mapping message to peer PE. -iii. After receiving the new label mapping message from peer PE and updating the remote label binding information, the Local PE should send label mapping to peer PE according to procedures defined in [RFC4447]. When the peer PE receives a label request message, it MUST send label mapping with locally configured control word parameter. The multi-segment PW case for T-PE is same, and the request message MUST be processed in ordered mode. When S-PE receives a label request message from a remote peer, it MUST advertise the request message to the other remote PE. This is necessary since S-PE does not have full information of interface parameter field in the FEC advertisement. When Local PE changes its control word from PREFERRED to NOT PREFERRED, Local PE would be able to re-negotiate the Control Word to be NOT PREFERRED following the procedures defined in [RFC4447], and no label request message to peer PE will be needed. In that case, Local PE will always send label mapping with C-bit reflecting the local Control Word configuration. The procedure of PE1 and PE2 for the case in figure 1 should be as follows: 1. PE2 changes locally configured control word to PREFERRED. 2. PE2 will then send label withdraw message to PE1. 3. PE2 MUST send label request messages to PE1 although it already received the label mapping with C-bit=0. Jin, et al. Expires June 2011 [Page 4] Internet-Draft draft-jin-pwe3-cbit-negotiation-02 December 2010 4. PE1 will send label release in reply to label withdraw message from PE2. 5. PE1 will send label mapping message with C-bit=1 again to PE2 (Note: PE1 MUST send label mapping with locally configured CW parameter). 6. PE2 receives the label mapping from PE1 and updates the remote label binding information. PE2 MUST wait for PE1 label binding before sending its label binding with C-bit set, only if it previously had a label binding with C-bit = 0 from PE1. 7. PE2 will send label mapping to PE1 with C-bit=1. By sending label request message, PE2 will get the configured CW parameter of peer PE1 in the received label mapping message. By using the new CW parameter from label mapping message received from peer PE1 and locally configured CW, PE2 should determine the PW CW parameter according to [RFC4447] section 6. The diagram in Appendix A in this draft updates the control word negotiation diagram in [RFC4447] Appendix A. 4. Security Considerations This document does not introduce any additional security constraints. 5. IANA Considerations This document does not require IANA assignment. 6. Acknowledgements The authors would like to thank Stewart Bryant, Andrew Malis, Nick Del Regno, Luca Martini, Venkatesan Mahalingam, Alexander Vainshtein and Adrian Farrel for their discussion and comments. 7. References 7.1. Normative References [RFC2119] Bradner, S., Key words for use in RFCs to Indicate Requirement Levels, BCP 14, RFC 2119, March 1997 [RFC4447] Martini, L., and al, Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP), April 2006 Jin, et al. Expires June 2011 [Page 5] Internet-Draft draft-jin-pwe3-cbit-negotiation-02 December 2010 Authors' Addresses Lizhong Jin (editor) ZTE Corporation 889, Bibo Road Shanghai, 201203, China Email: lizhong.jin@zte.com.cn Raymond Key (editor) Telstra 242 Exhibition Street, Melbourne VIC 3000, Australia Email: raymond.key@team.telstra.com Simon Delord Alcatel-Lucent Email: simon.delord@alcatel-lucent.com Thomas Nadeau Huawei Email: Thomas.Nadeau@huawei.com Vishwas Manral IPInfusion Email: vishwas@ipinfusion.com Sami Boutros Cisco Systems, Inc. 3750 Cisco Way San Jose, California 95134 USA Email: sboutros@cisco.com Reshad Rahman Cisco Systems, Inc. 2000 Innovation Drive Ottawa, Ontario K2K 3E8 CANADA Email: rrahman@cisco.com Jin, et al. Expires June 2011 [Page 6] Internet-Draft draft-jin-pwe3-cbit-negotiation-02 December 2010 Appendix A. Updated C-bit Handling Procedures Diagram ----------------------------------- | | | ------------------ | Y | Received Label | N | -------| Mapping Msg? |-------------- | | ------------------ | | -------------- | | | | | | ------- ------- | | | C=0 | | C=1 | | | ------- ------- | | | | | | | ---------------- | | | | Control Word | N | | | | Capable? |----------- | | | ---------------- | | | | Y | | | | | | | | | | ---------------- | | | | | Control Word | N | | | | | Preferred? |---- | | | | ---------------- | | | | | Y | | | | | --------------------- | | | | | | Control Word | | | | ---------------- | | change Preferred | | | | | Control Word | | | to not-Preferred? | | | | | Preferred? | | --------------------- | | | ---------------- | Y | | N | | | N | Y | | | | | | | | | | | Send Send Send Send Send Send | | C=0 C=1 C=0 C=0 C=0 C=1 | | | | | | | ------------------- ---------------------------------- | | Send withdraw | | If receive the same as sent, | | | if already sent | | PW setup is complete. If not: | | | label mapping | ---------------------------------- | ------------------- | | | | | | ------------------- ----------- | ------------------- | Receive | | Receive | | |Send label | | C=1 | | C=0 | | |request message | ------------------- ----------- | ------------------- | | | | Wait for the Send | | next message Wrong C-Bit ------------- | Send Label Mapping Message Jin, et al. Expires June 2011 [Page 7]