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
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.
当PE（提供者边缘）将控制字的使用偏好从非优选更改为优选时，RFC 4447中指定的控制字协商机制存在问题。本文档通过添加标签请求消息来更新RFC 4447和RFC 6073，以解决单段和多段伪导线的控制字协商问题。
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.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
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.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问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.
版权所有（c）2012 IETF信托基金和确定为文件作者的人员。版权所有。
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.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
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 . . . . . . . . . . . . . . . . . . . . . . . . . 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
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
[RFC4447]第6.2节中规定的控制字协商机制在PE将控制字的使用偏好从非首选更改为首选时遇到问题。[RFC4447]指定如果两个端点都喜欢使用控制字，则应使用伪线控制字。然而，在PE将其偏好从非优选更改为优选并且PW（伪线）PE的两端将控制字的使用设置为优选的情况下，将控制字的协商结果错误地设置为“未使用”。本文档通过添加标签请求消息来更新[RFC4447]中的控制字协商机制，以解决单段PW的协商问题。[RFC6073]中的多段PW继承了[RFC4447]中的控制字协商机制，本文档通过在
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.
S-PE（交换提供程序边缘）。当PE将控制字的使用偏好从首选更改为非首选时，它应该遵循[RFC4447]，并且没有问题。
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].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
[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".
[RFC4447]第6节描述了控制字协商机制。每个PW端点都有一个可配置的参数，用于指定是否首选使用控制字。在控制字协商期间，如果一个PE在标签映射消息中播发设置为0的C位，并将其本地配置的控制字的使用作为首选，并且相应的对等PE将其控制字的使用从非首选更改为首选，这将导致“未使用”的协商控制字结果不正确。
The following case will describe the negotiation problem in detail:
以下案例将详细描述协商问题：
+-------+ +-------+
| | PW | |
| PE1 |====================| PE2 |
| | | |
+-------+ +-------+
+-------+ +-------+
| | PW | |
| PE1 |====================| PE2 |
| | | |
+-------+ +-------+
Figure 1
图1
1. Initially, the use of control word on PE1 is configured as PREFERRED, and on PE2 as NOT PREFERRED.
1. 最初，PE1上控制字的使用配置为首选，PE2上控制字的使用配置为非首选。
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.
2. 未使用该PW控制字的协商结果，最终PE1发送标签映射消息，根据[RFC4447]第6.2节，C位设置为0。
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.
3. 然后，PE2将其控制字配置的使用从非首选更改为首选，方法是删除控制字非首选使用的PW配置，并再次配置控制字首选使用的PW。
4. PE2 will then send the Label Withdraw message to PE1, and correspondingly will receive the Label Release message from PE1.
4. 然后，PE2将向PE1发送标签撤回消息，并相应地从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.
5. 根据控制字协商机制，先前从PE1在PE2上接收到的标签映射消息携带设置为0的C位；因此，PE2仍将发送C位设置为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.
尽管在PE1和PE2上都首选使用控制字配置，但仍不使用控制字的协商结果。
The control-word negotiation mechanism in [RFC4447], Section 6, is updated to add the Label Request message described in this section.
[RFC4447]第6节中的控制字协商机制已更新，以添加本节中描述的标签请求消息。
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:
当本地PE收到C位设置为0的远程标签映射消息时，重新协商过程开始，此时其控制字的使用从非首选更改为首选。将执行以下附加程序：
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.
i. 本地PE必须向远程PE发送标签释放消息。如果本地PE以前发送过标签映射消息，则必须向远程PE发送标签撤销消息，并等待收到来自远程PE的标签释放消息。注：上述标签释放信息和标签撤回信息的发送不需要特定的顺序。
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.
二,。本地PE必须向对等PE发送标签请求消息，然后必须等待，直到收到包含对等PE当前配置的使用控制字首选项的标签映射消息。
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.
iii.在接收到带有C位的远程对等PE标签映射消息后，本地PE在发送其标签映射消息时，必须遵循[RFC4447]第6节中定义的程序。
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].
远程PE将遵循[RFC4447]，一旦远程PE成功处理标签撤销消息和标签释放消息，它将使用本地配置的首选项重置其对控制字的使用。然后，远程PE将发送带有本地配置的首选项的标签映射消息，以使用控制字作为对[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
注意：对于本地PE，在处理更改配置的新请求之前，应完成上述消息交换过程。标签请求消息中的FEC（转发等价类）元素应该是PE的本地PW FEC元素。作为对标签请求消息的响应，对等PE应发送
Label Mapping message with its own local PW FEC element. The Label Request message format and procedure is described in [RFC5036].
使用自己的本地PW FEC元素标记映射消息。[RFC5036]中描述了标签请求消息格式和过程。
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.
T-PE（端接提供商边缘）的多段PW情况与上节中所述的单段PW中的PE操作类似。[RFC6073]中为处理标签映射消息时的S-PE定义了初始被动角色。[RFC6073]通过将此被动角色应用于标签请求消息的处理来更新。当S-PE从其一个相邻PE（可能是S-PE或另一个T-PE）接收到标签请求消息时，它必须向其他相邻PE（也可能是S-PE或T-PE）发送匹配的标签请求消息。这是必要的，因为S-PE没有FEC广告中接口参数字段的完整信息。当S-PE收到来自远程PE的标签释放消息时，当S-PE持有来自远程PE的PW标签时，它必须向另一个远程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.
注意：由于本地T-PE将在向远程对等方发送标签请求消息之前发送标签撤回消息，因此S-PE必须在标签请求消息之前处理标签撤回消息。当S-PE收到标签撤销消息时，应处理该消息，以向上游S-PE/T-PE发送标签释放消息作为响应和标签撤销消息。然后，S-PE将处理下一个LDP消息，例如标签请求消息。
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.
当本地PE将控制字的使用从首选更改为非首选时，本地PE随后将通过删除首选控制字的PW配置并再次配置非首选控制字来重新协商控制字，以使其不被使用。所有这些程序已在[RFC4447]第5.4.1节中定义。
The diagram in Appendix A of this document updates the control-word negotiation diagram in [RFC4447] Appendix A.
本文件附录A中的图表更新了[RFC4447]附录A中的控制字协商图。
The procedure of PE1 and PE2 for the use case in Figure 1 will become as follows:
图1中用例的PE1和PE2程序如下：
1. PE2 changes locally configured preference for use of control word to PREFERRED.
1. PE2将使用控制字的本地配置首选项更改为首选项。
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.
2. 然后，PE2将向PE1发送释放消息。PE2还将发送标签撤回消息，并等待收到来自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.
3. PE1将发送标签释放消息，以响应PE2的标签撤回消息。在处理PE2的标签释放后，PE1会将控制字的使用重置为本地配置的首选项。
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.
4. 收到来自PE1的标签释放消息后，PE2将向PE1发送标签请求消息，并继续等待，直到收到标签映射消息。
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.
5. PE1将向PE2发送一条C位设置为1的标签映射消息，以响应标签请求消息。
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.
6. PE2从PE1接收标签映射消息并获取远程标签绑定信息。PE2将等待PE1标签映射消息，然后再发送其设置了C位的标签映射消息。
7. PE2 will send the Label Mapping to PE1 with C bit set to 1, and follow procedures defined in [RFC4447], Section 6.
7. PE2将向PE1发送标签映射，C位设置为1，并遵循[RFC4447]第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.
虽然假定PE1被配置为更喜欢使用控制字，但在步骤5中，如果PE1不喜欢或不支持控制字，PE1将发送标签映射消息，其中C位设置为0。因此，步骤7中的PE2将根据[RFC4447]第6节发送C位设置为0的标签映射消息。
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.
通过发送标签请求消息，PE2将获得本地配置的首选项，以便在收到的标签映射消息中使用对等PE1的控制字。通过使用从对等PE1接收的标签映射消息中的新C位和本地配置的控制字使用偏好，PE2应根据[RFC4447]第6节确定PW控制字的使用。
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
由于控制字协商机制通过添加标签请求消息进行更新，并且仍然遵循[RFC4447]第6节中描述的基本过程，因此本文档与现有实现完全兼容。对于单段伪线，已经实现[RFC4447]的远程PE（图1中的PE1）和[RFC5036]中定义的标签请求消息可以按照此机制与PE（图1中的PE2）兼容
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.
文件对于多段假丝，T-PE与单段假丝中的PE相同；应使用本文件中定义的机制升级S-PE。
The security considerations specified in [RFC4447] and [RFC6073] also apply to this document, and this document does not introduce any additional security constraints.
[RFC4447]和[RFC6073]中规定的安全注意事项也适用于本文件，本文件不引入任何其他安全约束。
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.
作者要感谢Stewart Bryant、Andrew Malis、Nick Del Regno、Luca Martini、Venkatesan Mahalingam、Alexander Vainstein、Adrian Farrel和Spike Curtis的讨论和评论。
Vishwas Manral Hewlett-Packard Co. 19111 Pruneridge Ave., Bldg. 44 Cupertino, CA 95014-0691 US EMail: vishwas.manral@hp.com
Vishwas Manral Hewlett-Packard Co.19111 Pruneridge Ave.，Bldg.44 Cupertino，CA 95014-0691美国电子邮件：Vishwas。manral@hp.com
Reshad Rahman Cisco Systems, Inc. 2000 Innovation Drive Ottawa, Ontario K2K 3E8 CANADA EMail: rrahman@cisco.com
Reshad Rahman Cisco Systems，Inc.2000加拿大安大略省渥太华创新大道K2K 3E8电子邮件：rrahman@cisco.com
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[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.
[RFC4447]Martini，L.，Rosen，E.，El Aawar，N.，Smith，T.，和G.Heron，“使用标签分发协议（LDP）的伪线设置和维护”，RFC 4447，2006年4月。
[RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP Specification", RFC 5036, October 2007.
[RFC5036]Andersson，L.，Minei，I.，和B.Thomas，“LDP规范”，RFC 5036，2007年10月。
[RFC6073] Martini, L., Metz, C., Nadeau, T., Bocci, M., and M. Aissaoui, "Segmented Pseudowire", RFC 6073, January 2011.
[RFC6073]Martini，L.，Metz，C.，Nadeau，T.，Bocci，M.和M.Aissaoui，“分段伪线”，RFC 60732011年1月。
-----------------------------------
| |
| ------------------
| 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 | ------------------- -----------
| ------------------- | |
-----------------------------------
| |
| ------------------
| 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
| |
-------------
| | 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
金立中（编辑）中国上海碧波路889号中兴通讯股份有限公司，邮编：201203
EMail: lizhong.jin@zte.com.cn
EMail: lizhong.jin@zte.com.cn
Raymond Key (editor) Huawei
雷蒙德·基（编辑）华为
EMail: raymond.key@ieee.org
EMail: raymond.key@ieee.org
Simon Delord Alcatel-Lucent
西蒙·德洛德·阿尔卡特·朗讯
EMail: simon.delord@gmail.com
EMail: simon.delord@gmail.com
Thomas Nadeau Juniper
托马斯·纳多·朱尼珀
EMail: tnadeau@juniper.net
EMail: tnadeau@juniper.net
Sami Boutros Cisco Systems, Inc. 3750 Cisco Way San Jose, California 95134, USA
Sami Boutros Cisco Systems，Inc.美国加利福尼亚州圣何塞市思科大道3750号，邮编95134
EMail: sboutros@cisco.com
EMail: sboutros@cisco.com