PW control word update: Update of the Pseudowire Control-Word Negotiation Mechanism
Fixes a negotiation deadlock when provider edges change their preference for control words.
Jin, L., Ed., Key, R., Ed., Delord, S., Nadeau, T., and S. Boutros, "Update of the Pseudowire Control-Word Negotiation Mechanism", RFC 6723, DOI 10.17487/RFC6723, September 2012, <https://www.rfc-editor.org/info/rfc6723>.
@misc{rfc6723,
series = {Request for Comments},
number = 6723,
howpublished = {RFC 6723},
publisher = {RFC Editor},
doi = {10.17487/RFC6723},
url = {https://www.rfc-editor.org/info/rfc6723},
author = {L. Jin and R. Key and S. Delord and T. Nadeau and S. Boutros},
title = {{Update of the Pseudowire Control-Word Negotiation Mechanism}},
pagetotal = 9,
year = 2012,
month = sep,
} RFC text
Contents
Internet Engineering Task Force (IETF) L. Jin, Ed.
Request for Comments: 6723 ZTE
Updates: 4447, 6073 R. Key, Ed.
Category: Standards Track Huawei
ISSN: 2070-1721 S. Delord
Alcatel-Lucent
T. Nadeau
Juniper
S. Boutros
Cisco Systems, Inc.
September 2012
Update of the Pseudowire Control-Word Negotiation Mechanism
Abstract
The control-word negotiation mechanism specified in RFC 4447 has a
problem when a PE (Provider Edge) changes the preference for the use
of the control word from NOT PREFERRED to PREFERRED. This document
updates RFC 4447 and RFC 6073 by adding the Label Request message to
resolve this control-word negotiation issue for single-segment and
multi-segment pseudowires.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6723.
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 . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions Used in This Document . . . . . . . . . . . . . . . 3
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . . 3
4. Control-Word Renegotiation by Label Request Message . . . . . . 4
4.1. Control-Word Renegotiation for Multi-Segment PW . . . . . . 5
4.2. Control-Word Renegotiation Use Case . . . . . . . . . . . . 5
5. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 7
9. Normative References . . . . . . . . . . . . . . . . . . . . . 7
Appendix A. Updated Diagram of C-Bit Handling Procedures . . . . . 8
1. Introduction
The control-word negotiation mechanism specified in [RFC4447],
Section 6.2, encounters a problem when a PE changes the preference
for the use of the control word from NOT PREFERRED to PREFERRED.
[RFC4447] specifies that if both endpoints prefer the use of the
control word, then the pseudowire control word should be used.
However, in the case where a PE changes its preference from NOT
PREFERRED to PREFERRED and both ends of the PW (pseudowire) PE have
the use of control word set as PREFERRED, an incorrect negotiated
result of the control word as "not used" occurs. This document
updates the control-word negotiation mechanism in [RFC4447] by adding
a Label Request message to resolve this negotiation issue for single-
segment PW. Multi-segment PW in [RFC6073] inherits the control-word
negotiation mechanism in [RFC4447], and this document updates
[RFC6073] by adding the processing of Label Request message on the
S-PE (Switching Provider Edge). When the PE changes the preference
for the use of control word from PREFERRED to NOT PREFERRED, it
should follow [RFC4447], and there is no problem.
2. 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].
3. Problem Statement
[RFC4447], Section 6, describes the control-word negotiation
mechanism. Each PW endpoint has a configurable parameter that
specifies whether the use of the control word is PREFERRED or NOT
PREFERRED. During control-word negotiation, if one PE advertises a C
bit set to 0 in the Label Mapping message with its locally configured
use of control word as PREFERRED, and a corresponding peer PE changes
its use of control word from NOT PREFERRED to PREFERRED, this causes
an incorrect negotiated control-word result of "not used".
The following case will describe the negotiation problem in detail:
+-------+ +-------+
| | PW | |
| PE1 |====================| PE2 |
| | | |
+-------+ +-------+
Figure 1
1. Initially, the use of control word on PE1 is configured as
PREFERRED, and on PE2 as NOT PREFERRED.
2. The negotiation result for the control word of this PW is not
used, and ultimately PE1 sends the Label Mapping message with C
bit set to 0 according to [RFC4447], Section 6.2.
3. PE2 then changes its use of control-word configuration from NOT
PREFERRED to PREFERRED, by deleting PW configuration with NOT
PREFERRED use of control word, and configuring the PW again with
PREFERRED use of control word.
4. PE2 will then send the Label Withdraw message to PE1, and
correspondingly will receive the Label Release message from PE1.
5. According to the control-word negotiation mechanism, the
previously received Label Mapping message on PE2 from PE1 carries
the C bit set to 0; therefore, PE2 will still send the Label
Mapping message with the C bit set to 0.
The negotiation result for the control word is still not used, even
though the use of control-word configuration on both PE1 and PE2 are
PREFERRED.
4. Control-Word Renegotiation by Label Request Message
The control-word negotiation mechanism in [RFC4447], Section 6, is
updated to add the Label Request message described in this section.
The renegotiation process begins when the local PE has received the
remote Label Mapping message with the C bit set to 0, and at the
point its use of control word is changed from NOT PREFERRED to
PREFERRED. The following additional procedure will be carried out:
i. The local PE MUST send a Label Release message to remote PE.
If local PE has previously sent a Label Mapping message, it
MUST send a Label Withdraw message to remote PE and wait until
it has received a Label Release message from the remote PE.
Note: the above-mentioned sending of the Label Release message
and Label Withdraw message does not require a specific
sequence.
ii. The local PE MUST send a Label Request message to the peer PE,
and then MUST wait until it receives a Label Mapping message
containing the peer's current configured preference for use of
control word.
iii. After receiving the remote peer PE Label Mapping message with
the C bit, the local PE MUST follow the procedures defined in
[RFC4447], Section 6, when sending its Label Mapping message.
The remote PE will follow [RFC4447], and once the remote PE has
successfully processed the Label Withdraw message and Label Release
message, it will reset its use of control word with the locally
configured preference. Then, the remote PE will send a Label Mapping
message with locally configured preference for use of control word as
a response to Label Request message as specified in [RFC5036].
Note: for the local PE, before processing new request to change the
configuration, the above message-exchanging process should be
finished. The FEC (Forwarding Equivalence Class) element in the
Label Request message should be the PE's local PW FEC element. As a
response to the Label Request message, the peer PE should send a
Label Mapping message with its own local PW FEC element. The Label
Request message format and procedure is described in [RFC5036].
4.1. Control-Word Renegotiation for Multi-Segment PW
The multi-segment PW case for a T-PE (Terminating Provider Edge)
operates similarly as the PE in single-segment PW described in the
above section. An initial passive role is defined in [RFC6073] for
the S-PE when processing of the Label Mapping message. [RFC6073] is
updated by applying this passive role to the processing of Label
Request message. When an S-PE receives a Label Request message from
one of its adjacent PEs (which may be an S-PE or another T-PE), it
MUST send a matching Label Request message to other adjacent PE
(again, it may be an S-PE or a T-PE). This is necessary since an
S-PE does not have complete information of the interface parameter
field in the FEC advertisement. When the S-PE receives a Label
Release message from remote PE, it MUST send a corresponding Label
Release message to the other remote PE when it holds a label for the
PW from the remote PE.
Note: because the local T-PE will send a Label Withdraw message
before sending a Label Request message to the remote peer, the S-PE
MUST process the Label Withdraw message before the Label Request
message. When the S-PE receives the Label Withdraw message, it
should process this message to send a Label Release message as a
response and a Label Withdraw message to an upstream S-PE/T-PE. The
S-PE will then process the next LDP message, e.g. the Label Request
message.
When the local PE changes the use of control word from PREFERRED to
NOT PREFERRED, the local PE would then renegotiate the control word
so that it is not used by deleting the PW configuration with
PREFERRED use of control word, and configuring the PW again with NOT
PREFERRED use of control word. All of these procedures have been
defined in [RFC4447], Section 5.4.1.
The diagram in Appendix A of this document updates the control-word
negotiation diagram in [RFC4447] Appendix A.
4.2. Control-Word Renegotiation Use Case
The procedure of PE1 and PE2 for the use case in Figure 1 will become
as follows:
1. PE2 changes locally configured preference for use of control word
to PREFERRED.
2. PE2 will then send the Release messages to PE1. PE2 will also
send the Label Withdraw message, and wait until it has received
the Label Release message from PE1.
3. PE1 will send the Label Release message in response to the Label
Withdraw message from PE2. After processing the Label Release
from PE2, PE1 will then reset the use of control word to the
locally configured preference as PREFERRED.
4. Upon receipt of the Label Release message from PE1, PE2 will send
the Label Request message to PE1, and proceed to wait until a
Label Mapping message is received.
5. PE1 will send a Label Mapping message with the C bit set to 1
again to PE2 in response to the Label Request message.
6. PE2 receives the Label Mapping message from PE1 and gets the
remote label binding information. PE2 will wait for the PE1
Label Mapping message before sending its Label Mapping message
with the C bit set.
7. PE2 will send the Label Mapping to PE1 with C bit set to 1, and
follow procedures defined in [RFC4447], Section 6.
While it is assumed that PE1 is configured to prefer the use of the
control word, in step 5, if PE1 doesn't prefer or support the control
word, PE1 would then send the Label Mapping message with the C bit
set to 0. As a result, PE2 in step 7 would send a Label Mapping
message with the C bit set 0 as per [RFC4447], Section 6.
By sending a Label Request message, PE2 will get the locally
configured preference for use of control word of peer PE1 in the
received Label Mapping message. By using the new C bit from the
Label Mapping message received from peer PE1 and the locally
configured preference for use of control word, PE2 should determine
the use of PW control word according to [RFC4447], Section 6.
5. Backward Compatibility
Since control-word negotiation mechanism is updated by adding the
Label Request message, and still follows the basic procedure
described in [RFC4447], Section 6, this document is fully compatible
with existing implementations. For single-segment pseudowire, the
remote PE (PE1 in Figure 1) which already implements [RFC4447], and
the Label Request message as defined in [RFC5036] could be compatible
with the PE (PE2 in Figure 1) following the mechanism of this
document. For the multi-segment pseudowire, the T-PE is the same as
PE in single-segment pseudowire; the S-PE should be upgraded with the
mechanism defined in this document.
6. Security Considerations
The security considerations specified in [RFC4447] and [RFC6073] also
apply to this document, and this document does not introduce any
additional security constraints.
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. Contributors
Vishwas Manral
Hewlett-Packard Co.
19111 Pruneridge Ave., Bldg. 44
Cupertino, CA 95014-0691
US
EMail: vishwas.manral@hp.com
Reshad Rahman
Cisco Systems, Inc.
2000 Innovation Drive
Ottawa, Ontario K2K 3E8
CANADA
EMail: rrahman@cisco.com
9. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[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.
[RFC6073] Martini, L., Metz, C., Nadeau, T., Bocci, M., and M.
Aissaoui, "Segmented Pseudowire", RFC 6073, January 2011.
Appendix A. Updated Diagram of C-Bit Handling Procedures
-----------------------------------
| |
| ------------------
| Y | Received Label | N
| -------| Mapping msg? |--------------
| | ------------------ |
| -------------- |
| | | |
| ------- ------- |
| | C=0 | | C=1 | |
| ------- ------- |
| | | |
| | ---------------- |
| | | Control Word | N |
| | | Capable? |----------- |
| | ---------------- | |
| | Y | | |
| | | | |
| | ---------------- | |
| | | Control Word | N | |
| | | Preferred? |---- | |
| | ---------------- | | |
| | Y | | | |
| --------------------- | | | |
| |Control Word change| | | | ----------------
| |from NOT PREFERRED | | | | | Control Word |
| | to PREFERRED? | | | | | Preferred? |
| --------------------- | | | ----------------
| Y | | N | | | N | Y |
| | Delete, and | | | | |
| | configure Send Send Send Send Send
| | new PW again C=1 C=0 C=0 C=0 C=1
| | | | | |
| ---------------------------- ----------------------------------
| |Send Label Release msg, | | If receive the same as sent, |
| |send Label Withdraw msg if| | PW setup is complete. If not: |
| |has sent Label Mapping msg| ----------------------------------
| ---------------------------- | | | |
| | ------------------- -----------
| ------------------- | Receive | | Receive |
| | Receive Label | | C=1 | | C=0 |
| | Release message | ------------------- -----------
| ------------------- | |
| | Wait for the Send
| ------------------- next message Wrong C-bit
| | Send Label | |
| | Request message | Send Label
| ------------------- Mapping message
| |
-------------
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
Sami Boutros
Cisco Systems, Inc.
3750 Cisco Way
San Jose, California 95134, USA
EMail: sboutros@cisco.com
AI ELI5
On this page
§1Pseudowires and Control Words
A pseudowire is an MPLS mechanism for emulating a point-to-point connection between two provider edge routers. Instead of sending traffic over a direct link, the routers encapsulate it into an MPLS tunnel. Each pseudowire can optionally use a control word—a small header added to each frame to carry flags and sequence information that help with packet ordering and loss detection.
RFC 4447 lets each provider edge configure its preference: "I prefer to use the control word" or "I prefer not to use it." The two endpoints negotiate during session setup: if both prefer control words, they use them; otherwise, they do not. This works well—unless something changes after setup.
A pseudowire is like a virtual tunnel between two routers. They can agree to add a small control label to each packet (the control word) to track ordering and catch lost packets. RFC 4447 says they talk it over at the start and agree on whether to use it.
§2The Negotiation Deadlock
The problem arises when a provider edge router changes its local configuration after the pseudowire is already set up. Suppose PE1 initially prefers control words and PE2 does not. During negotiation, PE1 respects PE2's preference and sends a Label Mapping message with the control-word bit (C-bit) set to 0, meaning "do not use control word." Both routers are now happy with this decision.
Later, PE2 is reconfigured to prefer control words. PE2 deletes and reconfigures the pseudowire with the new preference. RFC 4447 says that after PE2 sends a Label Withdraw, it must examine the previously received Label Mapping from PE1—which still says C-bit equals 0. When PE2 responds with its own Label Mapping, it also sets C-bit to 0, following the negotiation rules. Even though both routers now prefer control words, they remain locked into "do not use control word." This is a deadlock.
When one router changes its mind but the other router remembers the old agreement, they get stuck. They both prefer the control word now, but neither one asks the other to reconsider, so they stay with the old decision.
§3The Label Request Message
RFC 6723 fixes this by adding a Label Request message. When a provider edge detects that it has changed its preference from NOT PREFERRED to PREFERRED, and it previously received a Label Mapping with C-bit set to 0, it triggers renegotiation: send a Label Release message, then a Label Withdraw (if needed), and finally a Label Request message.
The Label Request is already defined in RFC 5036; the update simply specifies that when received, the peer PE resets its locally configured control-word preference and sends a fresh Label Mapping message reflecting its current preference. The requesting PE then applies the standard RFC 4447 negotiation rules to the new pair of preferences. This forces both endpoints to reconsider and settle on the correct outcome.
The new Label Request message is like saying "Let us talk about this again." Each router forgets the old agreement, says what it prefers right now, and they negotiate again from scratch.
§4Multi-Segment Pseudowires
A multi-segment pseudowire stitches together multiple single-segment pseudowires across intermediate switching provider edges. RFC 6073 defines how segment stitching works. RFC 6723 extends the Label Request renegotiation to multi-segment topologies by giving switching PE routers a passive role: when an S-PE receives a Label Request, it forwards a matching Label Request to the adjacent PE on the other side, effectively relaying the renegotiation request through the entire path.
This ensures that all switching PE routers in the path also update their preferences consistently. The order matters: when an S-PE receives a Label Withdraw before a Label Request, it processes the withdraw first, sends the corresponding Label Release, and then handles the Label Request in the next step. Backward compatibility is maintained because the Label Request and Label Release messages are already defined in RFC 5036 and RFC 4447; routers updated to RFC 6723 simply handle them in a new context.
When the tunnel passes through multiple routers, each one in the middle relays the renegotiation request onward so everybody agrees at the same time.
§5Security and Compatibility
RFC 6723 introduces no new security risks. The security model is unchanged from RFC 4447 and RFC 6073: Label Withdraw, Label Release, and Label Request messages are protected by the same LDP authentication mechanisms, and the renegotiation does not bypass any existing checks.
The update is fully backward compatible. A provider edge that has not implemented RFC 6723 will simply ignore the Label Request message (it treats it as unknown) or gracefully handle it according to RFC 5036. In single-segment scenarios, a newer PE can renegotiate with an older PE that does not support this update, because the older PE simply responds to the Label Request with its then-current preference, allowing the newer PE to make the right choice. Operators can deploy RFC 6723 incrementally without disrupting existing pseudowires.
The renegotiation uses the same secure handshakes as before. Routers that do not support this update will still work with routers that do, so operators do not need to upgrade everything at once.