summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc6723.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc6723.txt')
-rw-r--r--doc/rfc/rfc6723.txt507
1 files changed, 507 insertions, 0 deletions
diff --git a/doc/rfc/rfc6723.txt b/doc/rfc/rfc6723.txt
new file mode 100644
index 0000000..a570ae9
--- /dev/null
+++ b/doc/rfc/rfc6723.txt
@@ -0,0 +1,507 @@
+
+
+
+
+
+
+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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Jin, et al. Standards Track [Page 1]
+
+RFC 6723 Update of PW C-Bit Negotiation September 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 . . . . . . . . . . . . . . . . . . . . . . . . . 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
+
+
+
+
+
+Jin, et al. Standards Track [Page 2]
+
+RFC 6723 Update of PW C-Bit Negotiation September 2012
+
+
+ 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.
+
+
+
+
+
+
+Jin, et al. Standards Track [Page 3]
+
+RFC 6723 Update of PW C-Bit Negotiation September 2012
+
+
+ 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
+
+
+
+Jin, et al. Standards Track [Page 4]
+
+RFC 6723 Update of PW C-Bit Negotiation September 2012
+
+
+ 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.
+
+
+
+
+
+Jin, et al. Standards Track [Page 5]
+
+RFC 6723 Update of PW C-Bit Negotiation September 2012
+
+
+ 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
+
+
+
+
+
+Jin, et al. Standards Track [Page 6]
+
+RFC 6723 Update of PW C-Bit Negotiation September 2012
+
+
+ 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.
+
+
+
+
+
+Jin, et al. Standards Track [Page 7]
+
+RFC 6723 Update of PW C-Bit Negotiation September 2012
+
+
+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 | ------------------- -----------
+ | ------------------- | |
+
+
+
+
+
+
+Jin, et al. Standards Track [Page 8]
+
+RFC 6723 Update of PW C-Bit Negotiation September 2012
+
+
+ | | 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
+
+
+
+
+
+
+
+
+
+Jin, et al. Standards Track [Page 9]
+