Pseudowire Control Word Negotiation Mechanism Update
draft-ietf-pwe3-cbit-negotiation-03

The information below is for an old version of the document
Document Type Active Internet-Draft (pwe3 WG)
Authors Lizhong Jin  , Raymond Key  , Simon DeLord  , Thomas Nadeau  , Vishwas Manral  , Sami Boutros  , Reshad Rahman 
Last updated 2012-06-15 (latest revision 2012-04-13)
Replaces draft-jin-pwe3-cbit-negotiation
Stream Internet Engineering Task Force (IETF)
Formats pdf htmlized (tools) htmlized bibtex
Reviews
Stream WG state Submitted to IESG for Publication
Document shepherd Andy Malis
IESG IESG state Waiting for AD Go-Ahead
Consensus Boilerplate Unknown
Telechat date
Responsible AD Stewart Bryant
IESG note Andrew Malis (amalis@gmail.com) is the document shepherd.
Send notices to pwe3-chairs@tools.ietf.org, draft-ietf-pwe3-cbit-negotiation@tools.ietf.org
Network Working Group                             Lizhong Jin (ed.), ZTE
Internet-Draft                                 Raymond Key (ed.), Huawei
Updates: 4447 (if approved)                 Simon Delord, Alcatel-Lucent
Category: Standards Track                         Thomas Nadeau, Juniper
Expires: October 13, 2012                Vishwas Manral, Hewlett-Packard 
                                                     Sami Boutros, Cisco
                                                    Reshad Rahman, Cisco

                                                          April 13, 2012

          Pseudowire Control Word Negotiation Mechanism Update
                  draft-ietf-pwe3-cbit-negotiation-03

Abstract

   This document 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 document 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 April 13, 2012.

Jin, et al.               Expires October 2012                  [Page 1]
Internet-Draft     draft-ietf-pwe3-cbit-negotiation-03        April 2012

Copyright Notice 
    
   Copyright (c) 2012 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. Backward Compatibility . . . . . . . . . . . . . . . . . . . . . 6
   5. Security Considerations  . . . . . . . . . . . . . . . . . . . . 6
   6. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . . 6
   7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 6
   8. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
   8.1. Normative References . . . . . . . . . . . . . . . . . . . . . 6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 7
   Appendix A. Updated C-bit Handling Procedures Diagram . . . . . . . 8

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 October 2012                  [Page 2]
Internet-Draft     draft-ietf-pwe3-cbit-negotiation-03        April 2012

1. Introduction

   This document 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 document 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 October 2012                  [Page 3]
Internet-Draft     draft-ietf-pwe3-cbit-negotiation-03        April 2012

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 MUST send a label withdraw message to remote PE if 
             it has previously sent a label mapping, and wait until 
             receiving a label release from the remote PE. And it MUST 
             also send a label release message to the remote PE.

        -ii. Local PE MUST send a label request message to remote PE, 
             and wait until receiving a label mapping message containing 
             the remote PE configured control word setting.

       -iii. After receiving remote PE label mapping with control word 
             setting, Local PE MUST follow procedures defined in 
             [RFC4447] section 6 when sending its label mapping message.

   When the peer PE successfully processed the label withdraw and label 
   release, and removed the remote label binding, it MUST reset its 
   local control word with the configured one, and send label mapping as 
   a response of label request with locally configured control word 
   parameter.

   Note: the FEC element in label request message should be the PE's 
   local FEC element.  Only if FEC element in label request message 
   could bind together with peer PE's local FEC element, the peer PE 
   sends label mapping with its bound local FEC element and label as a 
   response.  The label request message format and procedure is 
   described in [RFC5036].

   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 S-PE receives a label release message from 
   remote peer, it MUST send a corresponding label release to the other 
   remote PE.

   As local T-PE will send label withdraw before sending label request 
   to remote peer, the S-PE MUST send the label withdraw upstream before 
   it advertises the label request.  When S-PE receives the label 
   withdraw, it should process this message to send a label release as a 
   response and a label withdraw to upstream S-PE/T-PE, then process the 
   next LDP message, e.g. the label request message.

Jin, et al.               Expires October 2012                  [Page 4]
Internet-Draft     draft-ietf-pwe3-cbit-negotiation-03        April 2012

   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 new 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 and release messages to PE1.

       3. PE1 will send label release in reply to label withdraw message 
          from PE2.  After that and processing the label release from 
          PE2, it would reset local control word to the configured one.

       4. Upon receipt of Label release message from PE1, PE2 would 
          reset local control word to the configured one, and MUST send 
          label request message to PE1.

       5. PE1 MUST send label mapping message with C-bit=1 again to PE2 
          as response of label request.

       6. PE2 receives the label mapping from PE1 and gets the remote 
          label binding information.  PE2 could wait for PE1 label 
          binding before sending its label binding with C-bit set.

       7. PE2 will send label mapping to PE1 with C-bit=1.

   It is to be noted that the above assume that PE1 is configured to 
   support CW, however in step 5 if PE1 doesn't support CW, PE1 would 
   send the label mapping message with C-bit=0, this would result in PE2 
   in step 7 sending a label mapping with C-bit=0 as per [RFC4447] CW 
   negotiation procedure.

   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 document updates the control word 
   negotiation diagram in [RFC4447] Appendix A.

Jin, et al.               Expires October 2012                  [Page 5]
Internet-Draft     draft-ietf-pwe3-cbit-negotiation-03        April 2012

4. Backward Compatibility

   Since control word re-negotiation is operated by adding label request 
   message, and still follows the procedure described in [RFC4447] 
   section 6, it is fully compatible with existing implementations.  The 
   remote PE (PE1 in figure 1) which already implement label request 
   message could be compatible with the PE (PE2 in figure 1) following 
   the mechanism of this document.

5. Security Considerations

   This document does not introduce any additional security constraints.

6. IANA Considerations

   This document does not require IANA assignment.

7. Acknowledgements

   The authors would like to thank Stewart Bryant, Andrew Malis, Nick 
   Del Regno, Luca Martini, Venkatesan Mahalingam, Alexander Vainshtein, 
   Adrian Farrel and Spike Curtis for their discussion and comments.

8. References

8.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), RFC 4447,
                April 2006

   [RFC5036]    Andersson, L., Minei, I., and Thomas B., 
                LDP Specification, RFC 5036, October 2007

Jin, et al.               Expires October 2012                  [Page 6]
Internet-Draft     draft-ietf-pwe3-cbit-negotiation-03        April 2012

Authors' Addresses

   Lizhong Jin (editor)
   ZTE Corporation
   889, Bibo Road
   Shanghai, 201203, China
   Email: lizhong.jin@zte.com.cn

   Raymond Key (editor)
   Huawei
   Email: raymond.key@ieee.org

   Simon Delord
   Alcatel-Lucent
   Email: simon.delord@gmail.com

   Thomas Nadeau
   Juniper
   Email: tnadeau@juniper.net

   Vishwas Manral 
   Hewlett-Packard Co. 
   19111 Pruneridge Ave, Bldg 44, 
   Cupertino, CA 95014-0691
   Email: vishwas.manral@hp.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 October 2012                  [Page 7]
Internet-Draft     draft-ietf-pwe3-cbit-negotiation-03        April 2012

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   |
    |  | release message |              ------------------- -----------
    |  -------------------                       |               |
    |           |                          Wait for the        Send
    |  -------------------                 next message     Wrong C-bit
    |  | Send label      |                                       |
    |  | request message |                                  Send Label
    |  -------------------                               Mapping Message
    |           |
    -------------

Jin, et al.               Expires October 2012                  [Page 8]