Network Working Group Lizhong Jin (ed.), ZTE
Internet-Draft Raymond Key (ed.), Telstra
Updates: 4447 (if approved) Simon Delord, Alcatel-Lucent
Category: Standards Track Thomas Nadeau, Huawei
Expires: October 12, 2011 Vishwas Manral, IPInfusion
Sami Boutros, Cisco
Reshad Rahman, Cisco
April 12, 2011
Pseudowire Control Word Negotiation Mechanism Update
draft-ietf-pwe3-cbit-negotiation-00
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 October 12, 2011.
Jin, et al. Expires October 2011 [Page 1]
Internet-Draft draft-ietf-pwe3-cbit-negotiation-00 April 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 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
Appendix B. Alternative proposal by "Label Release" message . . . . 9
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 2011 [Page 2]
Internet-Draft draft-ietf-pwe3-cbit-negotiation-00 April 2011
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 2011 [Page 3]
Internet-Draft draft-ietf-pwe3-cbit-negotiation-00 April 2011
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.
-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
removed the remote label binding, it MUST 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.
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 2011 [Page 4]
Internet-Draft draft-ietf-pwe3-cbit-negotiation-00 April 2011
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 message to PE1.
3. PE1 will send label release in reply to label withdraw message
from PE2.
4. Upon receipt of Label release message from PE1, PE2 MUST send
label request messages to PE1 although it already received the
label mapping with C-bit=0.
5. PE1 MUST 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.
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 2011 [Page 5]
Internet-Draft draft-ietf-pwe3-cbit-negotiation-00 April 2011
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 2011 [Page 6]
Internet-Draft draft-ietf-pwe3-cbit-negotiation-00 April 2011
Authors' Addresses
Lizhong Jin (editor)
ZTE Corporation
889, Bibo Road
Shanghai, 201203, China
Email: lizhong.jin@zte.com.cn
Raymond Key (editor)
Telstra
Email: raymond.key@ieee.org
Simon Delord
Alcatel-Lucent
Email: simon.delord@gmail.com
Thomas Nadeau
Huawei
Email: tnadeau@lucidvision.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 October 2011 [Page 7]
Internet-Draft draft-ietf-pwe3-cbit-negotiation-00 April 2011
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, | ----------------------------------
| | and wait until | | | | |
| | receiving label | ------------------- -----------
| | release | | Receive | | Receive |
| ------------------- | C=1 | | C=0 |
| | ------------------- -----------
| ------------------- | |
| | Send label | Wait for the Send
| | request message | next message Wrong C-bit
| ------------------- |
| | Send Label
| | Mapping Message
-------------
Jin, et al. Expires October 2011 [Page 8]
Internet-Draft draft-ietf-pwe3-cbit-negotiation-00 April 2011
Appendix B. Alternative proposal by "Label Release" message
We refer to the proposal in section 3 as "Label Request" message
proposal. There is an alternative proposal to re-negotiate control
word by sending label release with a new LDP status error code "PW
Reset C-bit negotiation". When this label release is received by the
S-PE in MS-PW case, it must forward it back to the T-PE. When the
T-PE receives the label release with this error code, it must send a
label withdraw followed by a new label mapping even if its C-bit
remains the same.
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, and label
release with a new LDP status error code "PW Reset C-bit
negotiation" to PE1.
3. PE2 will then send label mapping with C-bit=1 as per RFC4447.
4. PE1 will send label release in reply to label withdraw message
from PE2.
5. Upon receipt of label release with error code "PW Reset C-bit
negotiation" from PE2, PE1 MUST withdraw its label mapping and
re-advertise with the configured C-bit=1.
6. PE2 receives the label mapping from PE1 with C-bit=1, and
re-negotiates to get the result of C-bit=1 as per RFC4447.
Both "Label Request" and "Label Release" message proposals work to
resolve the control word negotiation problem described in this
document. We do not choose the "Label Release" message proposal for
the following backward compatible reasons:
1. PE1 always needs to be updated, while the "label request"
message proposal has better backward compatibility as
described in section 4.
2. S-PE needs to be updated in MS-PW case, while it is not
necessary in the "label request" message proposal.
Jin, et al. Expires October 2011 [Page 9]
Internet-Draft draft-ietf-pwe3-cbit-negotiation-00 April 2011
The following table makes a simple comparison between the two
proposals.
+---------+------------+-----------+---------+---------+
| Has new | Change | PE1 | PE2 | S-PE |
| Defined | LDP | need | need | need |
| Status? | RFC5036? | update? | update? | update? |
+----------+---------+------------+-----------+---------+---------+
| Label | | Yes (add | No (see | | |
| Request | No | FEC update | section 4)| Yes | No |
| Proposal | | at PE2) | | | |
+----------+---------+------------+-----------+---------+---------+
| Label | | Yes (change| | | |
| Release | Yes | label-rel | Yes | Yes | Yes |
| Proposal | | procedure) | | | |
+----------+---------+------------+-----------+---------+---------+
Jin, et al. Expires October 2011 [Page 10]