Network Working Group L. Martini
Request for Comments: 4863 G. Swallow
Category: Standards Track Cisco Systems, Inc.
May 2007
Network Working Group L. Martini
Request for Comments: 4863 G. Swallow
Category: Standards Track Cisco Systems, Inc.
May 2007
Wildcard Pseudowire Type
通配符伪线类型
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
Abstract
摘要
Pseudowire signaling requires that the Pseudowire Type (PW Type) be identical in both directions. For certain applications the configuration of the PW Type is most easily accomplished by configuring this information at just one PW endpoint. In any form of LDP-based signaling, each PW endpoint must initiate the creation of a unidirectional LSP. In order to allow the initiation of these two LSPs to remain independent, a means is needed for allowing the PW endpoint (lacking a priori knowledge of the PW Type) to initiate the creation of an LSP. This document defines a Wildcard PW Type to satisfy this need.
伪线信令要求伪线类型（PW类型）在两个方向上相同。对于某些应用程序，PW类型的配置最容易通过在一个PW端点配置此信息来完成。在任何形式的基于LDP的信令中，每个PW端点必须发起单向LSP的创建。为了允许这两个LSP的启动保持独立，需要一种方法来允许PW端点（缺乏PW类型的先验知识）启动LSP的创建。本文档定义了通配符PW类型以满足此需求。
Table of Contents
目录
1. Introduction ....................................................2
1.1. Conventions and Terminology ................................2
2. Wildcard PW Type ................................................3
3. Procedures ......................................................3
3.1. Procedures When Sending the Wildcard FEC ...................3
3.2. Procedures When Receiving the Wildcard FEC .................3
4. Security Considerations .........................................4
5. IANA Considerations .............................................4
6. References ......................................................4
6.1. Normative References .......................................4
6.2. Informative References .....................................4
1. Introduction ....................................................2
1.1. Conventions and Terminology ................................2
2. Wildcard PW Type ................................................3
3. Procedures ......................................................3
3.1. Procedures When Sending the Wildcard FEC ...................3
3.2. Procedures When Receiving the Wildcard FEC .................3
4. Security Considerations .........................................4
5. IANA Considerations .............................................4
6. References ......................................................4
6.1. Normative References .......................................4
6.2. Informative References .....................................4
Pseudowire signaling requires that the Pseudowire Type (PW Type) be identical in both directions. For certain applications the configuration of the PW Type is most easily accomplished by configuring this information at just one PW endpoint. In any form of LDP-based signaling, each PW endpoint must initiate the creation of a unidirectional LSP.
伪线信令要求伪线类型（PW类型）在两个方向上相同。对于某些应用程序，PW类型的配置最容易通过在一个PW端点配置此信息来完成。在任何形式的基于LDP的信令中，每个PW端点必须发起单向LSP的创建。
By the procedures of [CONTROL], both Label Mapping messages must carry the PW type, and the two unidirectional mapping messages must be in agreement. Thus within the current procedures, the PW endpoint that lacks configuration must wait to receive a Label Mapping message in order to learn the PW Type, prior to signaling its unidirectional LSP.
根据[CONTROL]的过程，两个标签映射消息必须携带PW类型，并且两个单向映射消息必须一致。因此，在当前过程中，缺少配置的PW端点必须等待接收标签映射消息，以便在向其单向LSP发送信号之前了解PW类型。
For certain applications this can become particularly onerous. For example, suppose that an ingress Provider Edge (PE) is serving as part of a gateway function between a layer 2 network and layer 2 attachment circuits on remote PEs. Suppose further that the initial setup needs to be initiated from the layer 2 network, but the layer 2 signaling does not contain sufficient information to determine the PW Type. However, this information is known at the PE supporting the targeted attachment circuit.
对于某些应用程序，这可能变得特别繁重。例如，假设入口提供商边缘（PE）作为网关功能的一部分在第2层网络和远程PE上的第2层连接电路之间使用。进一步假设初始设置需要从第2层网络发起，但是第2层信令不包含足够的信息来确定PW类型。然而，该信息在支持目标连接电路的PE处是已知的。
In this situation, it is often desirable to allow the initiation of the two LSPs that compose a pseudowire to remain independent. A means is needed for allowing a PW endpoint (lacking a priori knowledge of the PW Type) to initiate the creation of an LSP. This document defines a wildcard PW Type to satisfy this need.
在这种情况下，通常需要允许组成伪线的两个LSP的启动保持独立。需要一种方法来允许PW端点（缺乏PW类型的先验知识）启动LSP的创建。本文档定义了通配符PW类型以满足此需求。
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 RFC 2119 [KEYWORDS].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[关键词]中所述进行解释。
This document introduces no new terminology. However, it assumes that the reader is familiar with the terminology contained in [CONTROL] and RFC 3985, "Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture" [ARCH].
本文件未引入新术语。但是，假设读者熟悉[CONTROL]和RFC 3985“伪线仿真边到边（PWE3）架构”[ARCH]中包含的术语。
In order to allow a PE to initiate the signaling exchange for a pseudowire without knowing the pseudowire type, a new PW Type is defined. The codepoint is 0x7FFF. The semantics are the following:
为了允许PE在不知道伪线类型的情况下发起伪线的信令交换，定义了一种新的PW类型。代码点是0x7FFF。语义如下所示：
1. To the targeted PE, this value indicates that it is to determine the PW Type (for both directions) and signal that in a Label Mapping message back to the initiating PE.
1. 对于目标PE，该值表示要确定PW类型（用于两个方向），并在标签映射消息中将其发送回发起PE。
2. For the procedures of [CONTROL], this PW Type is interpreted to match any PW Type other than itself. That is, the targeted PE may respond with any valid PW Type other than the wildcard PW Type.
2. 对于[控制]程序，该PW类型被解释为与除自身以外的任何PW类型相匹配。也就是说，目标PE可以使用除通配符PW类型之外的任何有效PW类型进行响应。
When a PE that is not configured to use a specific PW Type for a particular pseudowire wishes to signal an LSP for that pseudowire, it sets the PW Type to "wildcard". This indicates that the target PE should determine the PW Type for this pseudowire.
当未配置为对特定伪线使用特定PW类型的PE希望为该伪线发送LSP信号时，它会将PW类型设置为“通配符”。这表明目标PE应确定此伪导线的PW类型。
When a Label Mapping message is received for the pseudowire, the PE checks the PW Type.
当收到伪导线的标签映射消息时，PE检查PW类型。
If the PW Type can be supported, the PE uses this as the PW Type for both directions.
如果可以支持PW类型，PE将其用作两个方向的PW类型。
If the PW Type cannot be supported or is "wildcard", it MUST respond to this message with a Label Release message with an LDP Status Code of "Generic Misconfiguration Error". Further actions are beyond the scope of this document, but could include notifying the associated application (if any) or notifying network management.
如果PW类型不受支持或为“通配符”，则必须使用LDP状态码为“通用错误配置错误”的标签释放消息响应此消息。进一步的操作超出了本文档的范围，但可能包括通知相关应用程序（如果有）或通知网络管理。
When a targeted PE receives a Label Mapping message indicating the wildcard PW Type, it follows the normal procedures for checking the Attachment Group Identifier (AGI) and Target Attachment Individual Identifier (TAII) values. If the targeted PE is not configured to use a specific, non-wildcard PW Type, it MUST respond to this message with a Label Release message with an LDP Status Code of "Generic Misconfiguration Error".
当目标PE收到指示通配符PW类型的标签映射消息时，它遵循检查附件组标识符（AGI）和目标附件个人标识符（TAII）值的正常过程。如果目标PE未配置为使用特定的非通配符PW类型，则必须使用LDP状态码为“通用错误配置错误”的标签释放消息响应此消息。
Otherwise, it treats the Label Mapping message as if it had indicated the PW Type it is configured to use.
否则，它将标签映射消息视为已指示其配置为使用的PW类型。
This document has little impact on the security aspects of [CONTROL]. The message exchanges remain the same. However, a malicious agent attempting to connect to an access circuit would require one less piece of information. To mitigate against this, a pseudowire control entity receiving a request containing the wildcard FEC type SHOULD only proceed with setup if explicitly configured to do so for the particular AI in the TAI. Further, the reader should note the security considerations of [CONTROL], in general, and those pertaining to the Generalized PWid FEC Element, in particular.
本文件对[控制]的安全方面几乎没有影响。信息交换保持不变。然而，恶意代理试图连接到访问电路将需要更少的一条信息。为了缓解这种情况，接收到包含通配符FEC类型的请求的伪线控制实体只有在明确配置为针对TAI中的特定AI进行设置时才应继续进行设置。此外，读者一般应注意[控制]的安全注意事项，特别是与广义PWid FEC元素有关的安全注意事项。
IANA has made the following allocation from the IETF consensus range of the "Pseudowire Type" registry as defined in [IANA].
IANA根据[IANA]中定义的“伪线类型”注册表的IETF共识范围进行了以下分配。
PW Type Description
PW类型说明
0x7FFF Wildcard
0x7FFF通配符
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[关键词]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[CONTROL] Martini, L., Ed., Rosen, E., El-Aawar, N., Smith, T., and G. Heron, "Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)", RFC 4447, April 2006.
[对照]Martini，L.，Ed.，Rosen，E.，El Aawar，N.，Smith，T.，和G.Heron，“使用标签分发协议（LDP）的伪线设置和维护”，RFC 4447，2006年4月。
[IANA] Martini, L., "IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3)", BCP 116, RFC 4446, April 2006.
[IANA]Martini，L.，“伪线边到边仿真（PWE3）的IANA分配”，BCP 116，RFC 4446，2006年4月。
[ARCH] Bryant, S., Ed., and P. Pate, Ed., "Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture", RFC 3985, March 2005.
[ARCH]Bryant，S.，Ed.，和P.Pate，Ed.，“伪线仿真边到边（PWE3）架构”，RFC 39852005年3月。
Authors' Addresses
作者地址
Luca Martini Cisco Systems 9155 East Nichols Avenue, Suite 400 Englewood, CO, 80112
卢卡·马蒂尼思科系统公司，地址：科罗拉多州恩格尔伍德东尼科尔斯大道9155号400室，邮编：80112
EMail: lmartini@cisco.com
EMail: lmartini@cisco.com
George Swallow Cisco Systems 1414 Massachusetts Ave, Boxborough, MA 01719
马萨诸塞州伯斯堡马萨诸塞大道1414号George Swallow思科系统公司，邮编01719
EMail: swallow@cisco.com
EMail: swallow@cisco.com
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。