Internet Engineering Task Force (IETF) D. Fedyk
Request for Comments: 6060 Alcatel-Lucent
Category: Standards Track H. Shah
ISSN: 2070-1721 Ciena
N. Bitar
Verizon
A. Takacs
Ericsson
March 2011
Internet Engineering Task Force (IETF) D. Fedyk
Request for Comments: 6060 Alcatel-Lucent
Category: Standards Track H. Shah
ISSN: 2070-1721 Ciena
N. Bitar
Verizon
A. Takacs
Ericsson
March 2011
Generalized Multiprotocol Label Switching (GMPLS) Control of Ethernet Provider Backbone Traffic Engineering (PBB-TE)
以太网提供商骨干通信工程（PBB-TE）的通用多协议标签交换（GMPLS）控制
Abstract
摘要
This specification is complementary to the GMPLS Ethernet Label Switching Architecture and Framework and describes the technology-specific aspects of GMPLS control for Provider Backbone Bridge Traffic Engineering (PBB-TE). The necessary GMPLS extensions and mechanisms are described to establish Ethernet PBB-TE point-to-point (P2P) and point-to-multipoint (P2MP) connections. This document supports, but does not modify, the standard IEEE data plane.
本规范是对GMPLS以太网标签交换体系结构和框架的补充，描述了供应商主干网桥流量工程（PBB-TE）GMPLS控制的技术特定方面。描述了建立以太网PBB-TE点对点（P2P）和点对多点（P2MP）连接所需的GMPLS扩展和机制。本文档支持但不修改标准IEEE数据平面。
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/rfc6060.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6060.
Copyright Notice
版权公告
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2011 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
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您在以下方面的权利和限制：
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.
请参阅本文件。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Co-Authors .................................................3
2. Terminology .....................................................4
2.1. PBB-TE and GMPLS Terminology ...............................5
2.2. Conventions Used in This Document ..........................6
3. Creation and Maintenance of PBB-TE Paths Using GMPLS ............6
3.1. Shared Forwarding ..........................................9
3.2. P2P Connections Procedures for Shared Forwarding ..........10
4. Specific Procedures ............................................10
4.1. P2P Ethernet LSPs .........................................10
4.1.1. P2P Path Maintenance ...............................11
4.2. P2MP Ethernet-LSPs ........................................12
4.3. PBB-TE Ethernet Label .....................................12
4.4. Protection Paths ..........................................13
4.5. Service Instance Identification ...........................13
5. Error Conditions ...............................................15
5.1. ESP-VID-Related Errors ....................................15
5.1.1. Invalid ESP-VID Value in the PBB-TE
Ethernet Label .....................................15
5.1.2. Allocated ESP-VID Range is Exhausted ...............16
5.2. Invalid MAC Address .......................................16
6. Security Considerations ........................................16
7. IANA Considerations ............................................17
8. References .....................................................17
8.1. Normative References ......................................17
8.2. Informative References ....................................19
9. Acknowledgments ................................................19
1. Introduction ....................................................3
1.1. Co-Authors .................................................3
2. Terminology .....................................................4
2.1. PBB-TE and GMPLS Terminology ...............................5
2.2. Conventions Used in This Document ..........................6
3. Creation and Maintenance of PBB-TE Paths Using GMPLS ............6
3.1. Shared Forwarding ..........................................9
3.2. P2P Connections Procedures for Shared Forwarding ..........10
4. Specific Procedures ............................................10
4.1. P2P Ethernet LSPs .........................................10
4.1.1. P2P Path Maintenance ...............................11
4.2. P2MP Ethernet-LSPs ........................................12
4.3. PBB-TE Ethernet Label .....................................12
4.4. Protection Paths ..........................................13
4.5. Service Instance Identification ...........................13
5. Error Conditions ...............................................15
5.1. ESP-VID-Related Errors ....................................15
5.1.1. Invalid ESP-VID Value in the PBB-TE
Ethernet Label .....................................15
5.1.2. Allocated ESP-VID Range is Exhausted ...............16
5.2. Invalid MAC Address .......................................16
6. Security Considerations ........................................16
7. IANA Considerations ............................................17
8. References .....................................................17
8.1. Normative References ......................................17
8.2. Informative References ....................................19
9. Acknowledgments ................................................19
The IEEE 802.1 Provider Backbone Bridge Traffic Engineering (PBB-TE) [IEEE802.1Qay] standard supports the establishment of explicitly routed traffic engineered paths within Provider Backbone Bridged (PBB) networks. PBB-TE allows the disabling of:
IEEE 802.1提供商主干网桥流量工程（PBB-TE）[IEEE802.1Qay]标准支持在提供商主干网桥（PBB）网络内建立明确路由的流量工程路径。PBB-TE允许禁用：
- the Spanning Tree Protocol - unknown destination address forwarding - source address learning
- 生成树协议-未知目的地址转发-源地址学习
for administratively selected VLAN Identifiers. With PBB-TE an external provisioning system or control plane can be used to configure static entries in the managed objects of bridges and so establish traffic engineered paths in the network.
用于管理选择的VLAN标识符。通过PBB-TE，外部供应系统或控制平面可用于在网桥的受管对象中配置静态条目，从而在网络中建立流量工程路径。
Generalized MPLS (GMPLS) [RFC3945] is a family of control plane protocols designed to operate in connection oriented and traffic engineering transport networks. GMPLS is applicable to a range of network technologies including L2SC networks (Layer 2 Switching Capable). The purpose of this document is to specify extensions for a GMPLS-based control plane to manage PBB-TE explicitly routed traffic engineered paths. This specification is complementary to the GMPLS Ethernet Label Switching Architecture and Framework document [RFC5828].
广义MPLS（GMPLS）[RFC3945]是一系列控制平面协议，设计用于面向连接和流量工程的传输网络。GMPLS适用于一系列网络技术，包括L2SC网络（支持第2层交换）。本文档旨在为基于GMPLS的控制平面指定扩展，以管理PBB-TE明确路由的流量工程路径。本规范是对GMPLS以太网标签交换体系结构和框架文件[RFC5828]的补充。
This document is the result of a large team of authors and contributors. The following is a list of the co-authors:
本文档是一个由作者和贡献者组成的大型团队的成果。以下是合著者名单：
David Allan Ericsson EMail: david.i.allan@ericsson.com
David Allan Ericsson电子邮件：David.i。allan@ericsson.com
Diego Caviglia Ericsson Via Negrone 1/A Genoa, Italy 16153 EMail: diego.caviglia@ericsson.com
Diego Caviglia Ericsson Via Negrone 1/A意大利热那亚16153电子邮件：Diego。caviglia@ericsson.com
Alan McGuire BT Group PLC OP6 Polaris House, Adastral Park, Martlesham Heath, Ipswich, Suffolk, IP5 3RE, UK EMail: alan.mcguire@bt.com
Alan McGuire英国电信集团有限公司OP6 Polaris House，Adastral公园，Martlesham Heath，伊普斯维奇，萨福克，IP5 3RE，英国电子邮件：Alan。mcguire@bt.com
Nurit Sprecher Nokia Siemens Networks, GmbH & Co. KG COO RTP IE Fixed 3 Hanagar St. Neve Ne'eman B, 45241 Hod Hasharon, Israel EMail: nurit.sprecher@nsn.com
Nurit Sprecher诺基亚西门子网络股份有限公司KG COO RTP IE Fixed 3 Hanagar St.Neve'eman B，45241 Hod Hasharon，Israel电子邮件：Nurit。sprecher@nsn.com
Lou Berger LabN Consulting, L.L.C. Phone: +1-301-468-9228 EMail: lberger@labn.net
Lou Berger LabN Consulting，L.L.C.电话：+1-301-468-9228电子邮件：lberger@labn.net
In addition to well-understood GMPLS terms, this memo uses the following terminology from IEEE 802.1 [IEEE802.1ah] [IEEE802.1Qay]:
除了广为人知的GMPLS术语外，本备忘录还使用了IEEE 802.1[IEEE802.1ah][IEEE802.1Qay]中的以下术语：
- BCB Backbone Core Bridge - BEB Backbone Edge Bridge - B-MAC Backbone MAC - B-VID Backbone VLAN ID - B-VLAN Backbone VLAN - CBP Customer Backbone Port - CCM Continuity Check Message - CNP Customer Network Port - C-MAC Customer MAC - C-VID Customer VLAN ID - C-VLAN Customer VLAN - ESP Ethernet Switched Path - ESP-MAC SA ESP Source MAC Address - ESP-MAC DA ESP Destination MAC Address - ESP-VID ESP VLAN ID - Eth-LSP Ethernet Label Switched Path - IB-BEB A BEB comprised of both I- and B-components - I-SID Ethernet Service Instance Identifier - TAG An Ethernet Header Field with Type and Values - MAC Media Access Control - PBB Provider Backbone Bridges - PBB-TE Provider Backbone Bridges Traffic Engineering - PIP Provider Instance Port - PNP Provider Network Port - PS Protection Switching - P2P Point-to-Point - P2MP Point-to-Multipoint - SVL Shared VLAN Learning
- BCB主干核心网桥-BEB主干边缘网桥-B-MAC主干MAC-B-VID主干VLAN ID-B-VLAN主干VLAN-CBP客户主干端口-CCM连续性检查消息-CNP客户网络端口-C-MAC客户MAC-C-VID客户VLAN ID-C-VLAN客户VLAN-ESP以太网交换路径-ESP-MAC SA ESP源MAC地址-ESP-MAC DA ESP目标MAC地址-ESP-VID ESP VLAN ID-Eth LSP以太网标签交换路径-IB-BEB A BEB由I组件和B组件组成-I-SID以太网服务实例标识符-使用类型和值标记以太网报头字段-MAC媒体访问控制-PBB提供商主干网桥-PBB-TE提供商主干网桥流量工程-PIP提供商实例端口-PNP提供商网络端口-PS保护交换-P2P点对点-P2MP点对多点-SVL共享VLAN学习
- TESI Traffic Engineering Service Instance - VID VLAN ID - VIP Virtual Instance Port - VLAN Virtual LAN
- TESI流量工程服务实例-VID VLAN ID-VIP虚拟实例端口-VLAN虚拟LAN
The PBB-TE specification [IEEE802.1Qay] defines some additional terminology to clarify the PBB-TE functions. We repeat these here in expanded context to translate from IEEE to GMPLS terminology. The terms "bridge" and "switch" are used interchangeably in this document. The signaling extensions described here apply equally well to a PBB-TE-capable bridge supporting GMPLS signaling or to a GMPLS-capable switch supporting Ethernet PBB-TE forwarding.
PBB-TE规范[IEEE802.1Qay]定义了一些附加术语，以澄清PBB-TE功能。我们在这里的扩展上下文中重复这些，以将IEEE术语翻译成GMPLS术语。术语“桥接器”和“开关”在本文件中互换使用。这里描述的信令扩展同样适用于支持GMPLS信令的支持PBB TE的网桥或支持以太网PBB-TE转发的支持GMPLS的交换机。
- Ethernet Switched Path (ESP):
- 以太网交换路径（ESP）：
A provisioned traffic engineered unidirectional connectivity path between two or more Customer Backbone Ports (CBPs) that extends over a Provider Backbone Bridge Network (PBBN). The path is identified by the 3-tuple <ESP-MAC DA, ESP-MAC SA, ESP-VID>. An ESP is point-to-point (P2P) or point-to-multipoint (P2MP). An ESP is analogous to a (unidirectional) point-to-point or point-to-multipoint LSP. We use the term Ethernet-LSP (Eth-LSP) for GMPLS established ESPs.
在两个或多个客户主干网端口（CBP）之间的一种供应流量工程单向连接路径，扩展到提供商主干网桥网络（PBBN）。路径由三元组<ESP-MAC DA、ESP-MAC SA、ESP-VID>标识。ESP是点对点（P2P）或点对多点（P2MP）。ESP类似于（单向）点对点或点对多点LSP。我们将术语以太网LSP（Eth LSP）用于GMPLS建立的ESP。
- Point-to-Point ESP:
- 点对点ESP：
An ESP between two CBPs. The ESP-DA and the ESP-SA in the ESP's 3-tuple identifier are the individual MAC addresses of the two CBPs.
两个CBP之间的ESP。ESP的三元组标识符中的ESP-DA和ESP-SA是两个CBP的单独MAC地址。
- Point-to-Multipoint ESP:
- 点对多点ESP：
An ESP among one root CBP and n leaf CBPs. The ESP-DA in the ESP's 3-tuple identifier is a group MAC address identifying the n leaf CBPs, and the ESP-SA is the individual MAC address of the root.
单根CBP和n叶CBP之间的ESP。ESP的三元组标识符中的ESP-DA是标识n叶CBP的组MAC地址，ESP-SA是根的单个MAC地址。
- Point-to-Point PBB-TE Service Instance (P2P TESI):
- 点对点PBB-TE服务实例（P2P TESI）：
A service instance supported by two point-to-point ESPs where the ESPs' endpoints have the same CBP MAC addresses. The two unidirectional ESPs are forming a bidirectional service. The PBB-TE standard [IEEE802.1Qay] notes the following: for reasons relating to TE service monitoring diagnostics, operational simplicity, etc., the IEEE PBB-TE standard assumes that the point-to-point ESPs associated with a point-to-point TESI are
由两个点对点ESP支持的服务实例，其中ESP的端点具有相同的CBP MAC地址。两个单向ESP正在形成双向服务。PBB-TE标准[IEEE802.1Qay]注意到以下几点：出于与TE服务监控诊断、操作简单性等相关的原因，IEEE PBB-TE标准假设与点对点TESI相关的点对点ESP是
co-routed. Support for a point-to-point TE services that comprises non-co-routed ESPs is problematic, and is not defined in this standard. Hence, a GMPLS bidirectional LSP is analogous to a P2P TE Service Instance. We use the term "bidirectional Ethernet-LSP" for GMPLS-established P2P PBB-TE Service Instances.
共同路由。对包含非共路由ESP的点对点TE服务的支持存在问题，本标准中未定义。因此，GMPLS双向LSP类似于P2P TE服务实例。对于GMPLS建立的P2P PBB-TE服务实例，我们使用术语“双向以太网LSP”。
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]中所述进行解释。
IEEE PBB-TE is a connection-oriented Ethernet technology. PBB-TE ESPs are created bridge by bridge (or switch by switch) by simple configuration of Ethernet forwarding entries. This document describes the use of GMPLS as a valid control plane for the setup, teardown, protection, and recovery of ESPs and TESIs and specifies the required RSVP-TE extensions for the control of PBB-TE Service Instances.
IEEE PBB-TE是一种面向连接的以太网技术。PBB-TE ESP是通过简单配置以太网转发条目逐桥（或逐交换机）创建的。本文件描述了将GMPLS用作ESP和TESI设置、拆卸、保护和恢复的有效控制平面，并规定了控制PBB-TE服务实例所需的RSVP-TE扩展。
PBB-TE ESP and services are always originated and terminated on IB-Backbone Edge Bridges (IB-BEBs). IB-BEBs are constituted of I and B components, this is illustrated in Figure 1. A B-component refers to the structure and mechanisms that support the relaying of frames identified by Backbone VLANs in a Provider Backbone Bridge. An I-component refers to the structure and mechanisms that support the relaying of frames identified by service instances (I-SIDs) in a Provider Backbone Bridge. PBB and PBB-TE relay frames with added I-Component TAGs in the I-component and VLAN TAGs in the B-component. PBB and PBB-TE forward frames based on VLAN ID in the VLAN TAG (in the PBB case a B-VID) until the destination MAC address is supported locally by a B-component on this bridge indicating the destination has been reached. At that point, the B-VLAN tag is removed and processing or forwarding on the next TAG begins (in the PBB case an I-Component TAG) until the I-component identified by the I-SID is reached. At the I-component, the I-Component TAG is removed and the next Ethernet type identifies the TAG, etc.
PBB-TE ESP和服务始终在IB主干边缘网桥（IB BEB）上发起和终止。IB BEB由I和B组件组成，如图1所示。B组件是指支持在提供商主干网桥中中继由主干VLAN标识的帧的结构和机制。I组件是指在提供者主干网桥中支持由服务实例（I-SID）标识的帧中继的结构和机制。PBB和PBB-TE中继帧，在I组件中添加I组件标签，在B组件中添加VLAN标签。PBB和PBB-TE根据VLAN标签中的VLAN ID转发帧（在PBB情况下为B-VID），直到该网桥上的B组件本地支持目标MAC地址，表明已到达目标。此时，删除B-VLAN标记，并开始处理或转发下一个标记（在PBB情况下为I-Component标记），直到到达I-SID标识的I-Component。在I-component，I-component标签被移除，下一个以太网类型识别标签，等等。
An Ethernet service supported by a PBB-TE TESI is always attached to a Customer Network Port (CNP) of the I-component. A Service Instance Identifier (I-SID) is assigned for the service. I-SIDs are only looked at by source and destination (edge) bridges, so I-SIDs are transparent to path operations and MAY be signaled. The I- and B-components have internal ports that are connected via an internal LAN. These internal ports are the Provider Instance Ports (PIPs) and
PBB-TE TESI支持的以太网服务始终连接到I组件的客户网络端口（CNP）。为服务分配了服务实例标识符（I-SID）。I-SID仅由源和目标（边缘）网桥查看，因此I-SID对路径操作是透明的，并且可以用信号通知。I组件和B组件具有通过内部LAN连接的内部端口。这些内部端口是提供程序实例端口（PIP）和
Customer Backbone Ports (CBPs). PIPs and CBPs are not visible outside the IB-BEB. ESPs are always originated and terminated on CBP ports and use the MAC address of that port. The I-component encapsulates the service frames arriving from the CNP by adding an I-SID and a complete Ethernet MAC header with an ESP-MAC DA and ESP-MAC SA. The B-component adds the ESP-VID.
客户主干端口（CBP）。IB-BEB外不可见PIP和CBP。ESP始终在CBP端口上发起和终止，并使用该端口的MAC地址。I组件通过添加I-SID和带有ESP-MAC DA和ESP-MAC SA的完整以太网MAC报头来封装来自CNP的服务帧。B组件添加ESP-VID。
This document defines extensions to GMPLS to establish ESPs and TESIs. As can be seen from the above, this requires configuration of both the I- and B-components of the IB-BEBs connected by the ESPs.
本文件定义了GMPLS的扩展，以建立ESP和TESI。从上面可以看出，这需要配置ESP连接的IB BEB的I组件和B组件。
In the GMPLS control plane, TE Router IDs are used to identify the IB-BEBs and Backbone Core Bridges (BCBs), and TE Links describe links connected to PNPs and CNPs. TE Links are not associated with CBPs or PIPs.
在GMPLS控制平面中，TE路由器ID用于识别IB BEB和主干核心网桥（BCB），TE链路描述连接到PNP和CNP的链路。TE链路与CBP或PIP不关联。
Note that since multiple internal CBPs may exist, an IB-BEB receiving a PATH message MUST be able to determine the appropriate CBP that is the termination point of the Eth-LSP. To this end, IB-BEBs SHOULD advertise the CNP TE Links in the GMPLS control plane and RSVP-TE signaling SHOULD use the CNP TE Links to identify the termination point of Eth-LSPs. An IB-BEB receiving a PATH message specifying one of its CNPs can locally determine which CBPs have internal connectivity to the I-component supporting the given CNP. In the case that there is more than one suitable CBP, and no I-SID information is provided in the PATH message or previously in the associated Call setup, then the IB-BEB can decide freely which CBP to assign to the requested connection. On the other hand, if there is information on the service (I-SID) that the given ESP will support, then the IB-BEB MUST first determine which PIP and associated CBP is configured with the I-SID and MUST assign that CBP to the ESP.
注意，由于可能存在多个内部CBP，因此接收PATH消息的IB-BEB必须能够确定作为Eth LSP终止点的适当CBP。为此，IB BEBs应在GMPLS控制平面上公布CNP TE链路，RSVP-TE信令应使用CNP TE链路识别Eth LSP的终止点。IB-BEB接收到指定其一个CNP的路径消息后，可以在本地确定哪些CBP具有与支持给定CNP的I组件的内部连接。如果有多个合适的CBP，并且PATH消息或之前的相关呼叫设置中没有提供I-SID信息，则IB-BEB可以自由决定将哪个CBP分配给请求的连接。另一方面，如果存在关于给定ESP将支持的服务（I-SID）的信息，则IB-BEB必须首先确定哪个PIP和相关CBP配置了I-SID，并且必须将该CBP分配给ESP。
Backbone Edge Bridge (BEB)
+------------------------------------------------------+
| <TE - Router ID > |
| |
| I-Component Relay B-Component Relay |
| +-----------------------+ +---------------------+ |
| | +---+ | | B-VID | |
| | |VIP| | | +---+ +---+ | | <TE Link>
| | +---+ | +---|CBP| |PNP|------
| | | | | +---+ +---+ | |
| | +---+ +---+ | | | | |
------|CNP| |PIP|----+ | | |
| | +---+ +---+ | | | |
| +-----------------------+ +---------------------+ |
| |
| PBB Edge Bridge |
+------------------------------------------------------+
Backbone Edge Bridge (BEB)
+------------------------------------------------------+
| <TE - Router ID > |
| |
| I-Component Relay B-Component Relay |
| +-----------------------+ +---------------------+ |
| | +---+ | | B-VID | |
| | |VIP| | | +---+ +---+ | | <TE Link>
| | +---+ | +---|CBP| |PNP|------
| | | | | +---+ +---+ | |
| | +---+ +---+ | | | | |
------|CNP| |PIP|----+ | | |
| | +---+ +---+ | | | |
| +-----------------------+ +---------------------+ |
| |
| PBB Edge Bridge |
+------------------------------------------------------+
^--------Configured--------------^
^-----------GMPLS or Configured------^
^--------Configured--------------^
^-----------GMPLS or Configured------^
Figure 1: IB-BEBs and GMPLS Identifiers
图1:IB BEBs和GMPLS标识符
Control TE Router ID TE Router ID
Plane | (TE Link) |
V | V
+----+ | +-----+
Data | | | | |
Plane | | V label=ESP:VID/MAC DA | |
-----N N----------------------------N N----------
| | PBB-TE | | \ Network
| | / | Or
+----+ /+-----+ Customer
BCB ESP:MAC IB-BEB Facing
Ethernet
Ports
Control TE Router ID TE Router ID
Plane | (TE Link) |
V | V
+----+ | +-----+
Data | | | | |
Plane | | V label=ESP:VID/MAC DA | |
-----N N----------------------------N N----------
| | PBB-TE | | \ Network
| | / | Or
+----+ /+-----+ Customer
BCB ESP:MAC IB-BEB Facing
Ethernet
Ports
Figure 2: Ethernet/GMPLS Addressing and Label Space
图2：以太网/GMPLS寻址和标签空间
PBB-TE defines the tuple of <ESP-MAC DA, ESP-MAC SA, ESP-VID> as a unique connection identifier in the data plane, but the forwarding operation only uses the ESP-MAC DA and the ESP-VID in each direction. The ESP-VID typically comes from a small number of VIDs dedicated to PBB-TE. ESP-VIDs can be reused across ESPs. There is no requirement that ESP-VIDs for two ESPs that form a P2P TESI be the same.
PBB-TE将<ESP-MAC DA、ESP-MAC SA、ESP-VID>的元组定义为数据平面中的唯一连接标识符，但转发操作仅在每个方向使用ESP-MAC DA和ESP-VID。ESP-VID通常来自专用于PBB-TE的少量VID。ESP视频可以跨ESP重复使用。不要求构成P2P TESI的两个ESP的ESP视频相同。
When configuring an ESP with GMPLS, the ESP-MAC DA and ESP-VID are carried in a generalized label object and are assigned hop by hop, but are invariant within a domain. This invariance is similar to GMPLS operation in transparent optical networks. As is typical with other technologies controlled by GMPLS, the data plane receiver MUST accept, and usually assigns, labels from its available label pool. This, together with the label invariance requirement mentioned above, result in each PBB-TE Ethernet Label being a domain-wide unique label, with a unique ESP-VID + ESP-MAC DA, for each direction.
使用GMPLS配置ESP时，ESP-MAC DA和ESP-VID携带在通用标签对象中，并逐跳分配，但在域内不变。这种不变性类似于透明光网络中的GMPLS操作。与GMPLS控制的其他技术一样，数据平面接收器必须接受并通常分配其可用标签池中的标签。这与上述标签不变性要求一起，导致每个PBB-TE以太网标签都是一个域范围内的唯一标签，每个方向都有一个唯一的ESP-VID+ESP-MAC DA。
The following illustrates PBB-TE Ethernet Labels and ESPs for a P2P TESI.
以下说明了P2P TESI的PBB-TE以太网标签和ESP。
GMPLS Upstream Label <ESP:MAC1(DA), VID1> (60 bits)
GMPLS Downstream Label <ESP:MAC2(DA), VID2> (60 bits)
Upstream PBB-TE ESP 3-tuple <ESP:MAC1, MAC2, VID1> (108 bits)
Downstream PBB-TE ESP 3-tuple <ESP:MAC2, MAC1, VID2> (108 bits)
GMPLS Upstream Label <ESP:MAC1(DA), VID1> (60 bits)
GMPLS Downstream Label <ESP:MAC2(DA), VID2> (60 bits)
Upstream PBB-TE ESP 3-tuple <ESP:MAC1, MAC2, VID1> (108 bits)
Downstream PBB-TE ESP 3-tuple <ESP:MAC2, MAC1, VID2> (108 bits)
Table 1: Labels and ESPs
表1：标签和ESP
One capability of a connectionless Ethernet data plane is to reuse destination forwarding entries for packets from any source within a VLAN to a destination. When setting up P2P PBB-TE connections for multiple sources sharing a common destination, this capability MAY be preserved provided certain requirements are met. We refer to this capability as "shared forwarding". Shared forwarding is invoked based on policy when conditions are met. It is a local decision by label allocation at each end plus the path constraints. Shared forwarding has no impact on the actual paths that are set up, but it allows the reduction of forwarding entries. Shared forwarding paths are identical in function to independently routed paths that share a path from an intersecting bridge or link except they share a single forwarding entry.
无连接以太网数据平面的一个功能是重用从VLAN内任何源到目的地的数据包的目的地转发条目。为共享同一目的地的多个源建立P2P PBB-TE连接时，如果满足某些要求，则可以保留此功能。我们将此功能称为“共享转发”。当满足条件时，根据策略调用共享转发。这是一个局部决策，由每一端的标签分配加上路径约束。共享转发对设置的实际路径没有影响，但它允许减少转发条目。共享转发路径在功能上与共享交叉网桥或链路路径的独立路由路径相同，但它们共享单个转发条目。
The forwarding memory savings from shared forwarding can be quite dramatic in some topologies where a high degree of meshing is required; however, it is typically easier to achieve when the connectivity is known in advance. Normally, the originating GMPLS switch will not have knowledge of the set of shared forwarding paths rooted on the source or destination switch.
共享转发节省的转发内存在某些需要高度网格化的拓扑中非常显著；然而，当预先知道连通性时，通常更容易实现。通常，发起的GMPLS交换机不知道源交换机或目标交换机上的共享转发路径集。
Use of a Path Computation Element [RFC4655] or other planning style of tool with more complete knowledge of the network configuration is a way to impose pre-selection of shared forwarding with multiple paths using a single forwarding entry and optimizing for both
使用路径计算元素[RFC4655]或具有更完整网络配置知识的其他规划方式的工具是一种使用单个转发条目对多条路径的共享转发进行预选并对两者进行优化的方法
directions. In this scenario, the originating bridge uses the LABEL_SET and UPSTREAM_LABEL objects to indicate the selection of the shared forwarding labels at both ends.
方向。在这种情况下，发起网桥使用LABEL_SET和UPSTREAM_LABEL对象来指示两端共享转发标签的选择。
The ESP-VID/ESP-MAC DA can be considered to be a shared forwarding identifier or label consisting of some number of P2P connections distinctly identified by the <ESP-MAC DA, ESP-MAC SA, ESP-VID> tuple. This is analogous to an LDP label merge, but in the shared forwarding case, the ESP header contains sufficient information to identify the flow to which a packet belongs. Resources can continue to be allocated per LSP with shared forwarding.
ESP-VID/ESP-MAC DA可被视为共享转发标识符或标签，由<ESP-MAC DA、ESP-MAC SA、ESP-VID>元组明确标识的一些P2P连接组成。这类似于LDP标签合并，但在共享转发情况下，ESP报头包含足够的信息来标识数据包所属的流。通过共享转发，可以继续为每个LSP分配资源。
VLAN-tagged Ethernet packets include priority marking. Priority bits MAY be used to indicate Class of Service (COS) and drop priority. Thus, traffic from multiple COSs could be multiplexed on the same Eth-LSP (i.e., similar to E-LSPs) and queuing and drop decisions are made based on the p-bits. This means that the queue selection can be done based on a per-flow basis (i.e., Eth-LSP + priority) and is decoupled from the actual steering of the packet at any given bridge.
VLAN标记的以太网数据包包括优先级标记。优先级位可用于指示服务类别（COS）和丢弃优先级。因此，来自多个cos的业务可以在同一Eth-LSP（即，类似于e-LSP）上复用，并且基于p比特做出排队和丢弃决策。这意味着队列选择可以基于每个流（即Eth LSP+优先级）来完成，并且与任何给定网桥上的数据包的实际转向分离。
A bridge terminating an Eth-LSP will frequently have more than one suitable candidate for sharing a forwarding entry (common ESP-VID/ESP-MAC DA, unique ESP-MAC SA). It is a local decision of how this is performed but a good choice is a path that reduces the requirement for new forwarding entries by reusing common existing paths.
终止Eth LSP的网桥通常会有多个合适的候选共享转发条目（通用ESP-VID/ESP-MAC DA、唯一ESP-MAC SA）。这是如何执行的本地决定，但一个好的选择是通过重用常见的现有路径来减少对新转发条目的需求。
The concept of bandwidth management still applies equally well with shared forwarding.
带宽管理的概念同样适用于共享转发。
PBB-TE is designed to be bidirectional and symmetrically routed just like Ethernet. That is, complete and proper functionality of Ethernet protocols is only guaranteed for bidirectional Eth-LSPs. In this section, we discuss the establishment of bidirectional Eth-LSPs.
PBB-TE设计为双向对称路由，就像以太网一样。也就是说，只有双向Eth LSP才能保证以太网协议的完整和正确功能。在本节中，我们将讨论双向Eth LSP的建立。
Note, however, that it is also possible to use RSVP-TE to configure unidirectional ESPs, if the UPSTREAM_LABEL is not included in the PATH message.
但是，请注意，如果路径消息中不包括上游_标签，也可以使用RSVP-TE配置单向ESP。
To initiate a bidirectional Eth-LSP, the initiator of the PATH message MUST use the procedures outlined in [RFC3473] with the following specifics:
要启动双向Eth LSP，路径消息的发起人必须使用[RFC3473]中概述的程序，并具有以下细节：
1) it MUST set the LSP encoding type to Ethernet (2) [RFC3471].
1) 它必须将LSP编码类型设置为以太网（2）[RFC3471]。
2) it MUST set the LSP switching type to "802_1 PBB-TE", value 40.
2) 它必须将LSP交换类型设置为“802_1 PBB-TE”，值为40。
3) it SHOULD set the Generalized Payload Identifier (G-PID) to Ethernet (33) [RFC3471].
3) 它应该将通用有效负载标识符（G-PID）设置为以太网（33）[RFC3471]。
4) it MUST set the UPSTREAM_LABEL to the ESP-VID1/ESP-MAC1 tuple where the ESP-VID1 is administered locally for the local MAC address: MAC1.
4) 它必须将上游_标签设置为ESP-VID1/ESP-MAC1元组，其中ESP-VID1针对本地MAC地址MAC1进行本地管理。
5) it SHOULD set the LABEL_SET or SUGGESTED_LABEL if it chooses to influence the choice of ESP-VID/ESP-MAC DA.
5) 如果选择影响ESP-VID/ESP-MAC DA的选择，则应设置标签集或建议标签。
6) it MAY carry an I-SID via Call/Connection ID [RFC4974].
6) 它可以通过呼叫/连接ID[RFC4974]携带I-SID。
Intermediate and egress bridge processing is not modified by this document, i.e., is per [RFC3473]. However, as previously stated, intermediate bridges supporting the 802_1 PBB-TE switching type MUST NOT modify LABEL values.
本文件未对中间和出口桥处理进行修改，即按照[RFC3473]进行修改。但是，如前所述，支持802_1 PBB-TE交换类型的中间网桥不得修改标签值。
The ESP-VID1/ESP-MAC1 tuple contained in the UPSTREAM_LABEL is used to create a static forwarding entry in the Filtering Database of bridges at each hop for the upstream direction. This behavior is inferred from the switching type, which is 802_1 PBB-TE. The port derived from the RSVP_HOP object and the ESP-VID1 and ESP-MAC1 included in the PBB-TE Ethernet Label constitute the static entry.
上游_标签中包含的ESP-VID1/ESP-MAC1元组用于在上游方向每个跃点的网桥过滤数据库中创建静态转发条目。此行为是从切换类型（即802_1 PBB-TE）推断出来的。从RSVP_HOP对象派生的端口以及PBB-TE以太网标签中包含的ESP-VID1和ESP-MAC1构成静态条目。
At the destination, an ESP-VID (ESP-VID2) is allocated for the local MAC address: MAC2, the ESP-VID2/ESP-MAC2 tuple is passed in the LABEL object in the RESV message. As with the PATH message, intermediate bridge processing is per [RFC3473], and the LABEL object MUST be passed on unchanged, upstream. The ESP-VID2/ESP-MAC2 tuple contained in the LABEL object is installed in the forwarding table as a static forwarding entry at each hop. This creates a bidirectional Eth-LSP as the PATH and RESV messages follow the same path.
在目的地，为本地MAC地址分配ESP-VID（ESP-VID2）：MAC2，ESP-VID2/ESP-MAC2元组在RESV消息的标签对象中传递。与PATH消息一样，中间网桥处理是按照[RFC3473]进行的，并且标签对象必须在上游进行未更改的传递。标签对象中包含的ESP-VID2/ESP-MAC2元组作为每个跃点的静态转发条目安装在转发表中。这将创建一个双向Eth LSP，因为路径和RESV消息遵循相同的路径。
Make-before-break procedures can be employed to modify the characteristics of a P2P Eth-LSP. As described in [RFC3209], the LSP ID in the sender template is updated as the new path is signaled. The procedures (including those for shared forwarding) are identical to those employed in establishing a new LSP, with the extended tunnel
先通后断过程可用于修改P2P Eth LSP的特征。如[RFC3209]中所述，发送方模板中的LSP ID随着新路径的信号发送而更新。程序（包括共享转发的程序）与使用扩展隧道建立新LSP时使用的程序相同
ID in the signaling exchange ensuring that double booking of an associated resource does not occur.
信令交换中的ID，确保不会发生相关资源的双重预订。
Where individual paths in a protection group are modified, signaling procedures MAY be combined with Protection Switching (PS) coordination to administratively force PS operations such that modification is only ever performed on the protection path. PS is a native capability of PBB-TE [IEEE802.1Qay] that can operate when two paths are set up between two common endpoints.
在修改保护组中的各个路径的情况下，信令过程可与保护切换（PS）协调相结合，以管理性地强制PS操作，从而仅在保护路径上执行修改。PS是PBB-TE[IEEE802.1Qay]的本机功能，在两个公共端点之间设置两条路径时可以运行。
PBB-TE supports P2MP VID/Multicast MAC (MMAC) forwarding. In this case, the PBB-TE Ethernet Label consists of a VID and a Group MAC address. The procedures outlined in [RFC3473] and [RFC4875] could be adapted to signal P2MP LSPs for the source (point) to destination (multipoint) direction. Each one of the branches of the P2MP Eth-LSP would be associated with a reverse-path symmetric and congruent P2P Eth-LSP.
PBB-TE支持P2MP视频/多播MAC（MMAC）转发。在这种情况下，PBB-TE以太网标签由VID和组MAC地址组成。[RFC3473]和[RFC4875]中概述的程序可适用于向源（点）到目标（多点）方向的P2MP LSP发送信号。P2MP Eth LSP的每一个分支将与反向路径对称且全等的P2P Eth LSP相关联。
Complete procedures for signaling bidirectional P2MP E-LSPs are out of scope for this document.
发送双向P2MP E-LSP信号的完整程序不在本文件范围内。
The PBB-TE Ethernet Label is a new generalized label with the following format:
PBB-TE以太网标签是一种新的通用标签，其格式如下：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0| ESP VID | ESP MAC (highest 2 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ESP MAC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0| ESP VID | ESP MAC (highest 2 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ESP MAC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: PBB-TE Ethernet Label
图3:PBB-TE以太网标签
This format MUST be used for both P2P and P2MP Eth-LSPs. For P2P Eth-LSPs, the fields specify a VID and a unicast MAC address; whereas, for P2MP Eth-LSPs, a VID and a group MAC address is carried in the label. The PBB-TE Ethernet Label is a domain-wide unique label and MUST be passed unchanged at each hop. This has similarity to the way in which a wavelength label is handled at an intermediate bridge that cannot perform wavelength conversion, and is described in [RFC3473].
此格式必须同时用于P2P和P2MP Eth LSP。对于P2P Eth lsp，字段指定VID和单播MAC地址；然而，对于P2MP Eth LSP，标签中带有VID和组MAC地址。PBB-TE以太网标签是一个域范围的唯一标签，必须在每个跃点不变地传递。这类似于在无法执行波长转换的中间桥处处理波长标签的方式，如[RFC3473]所述。
When protection is used for path recovery, it is required to associate the working and protection paths into a protection group. This is achieved as defined in [RFC4872] and [RFC4873] using the ASSOCIATION and PROTECTION objects.
当保护用于路径恢复时，需要将工作路径和保护路径关联到一个保护组中。这是按照[RFC4872]和[RFC4873]中的定义，使用关联和保护对象实现的。
The I-SID is used to uniquely identify services within the network. Unambiguous identification is achieved by ensuring global uniqueness of the I-SIDs within the network or at least between any pair of edge bridges. On IB-BEBs, the Backbone Service Instance Table is used to configure the mapping between I-SIDs and ESPs. This configuration can be either manual or semi-automated by signaling described here.
I-SID用于唯一标识网络中的服务。通过确保网络内或至少任何一对边缘网桥之间的I-SID的全局唯一性，可以实现明确的识别。在IB BEBs上，主干服务实例表用于配置I-SID和ESP之间的映射。此配置可以是手动的，也可以是通过此处所述的信令实现的半自动的。
RSVP-TE Signaling MAY be used to automate I-SID to ESP mapping. By relying on signaling, it is ensured that the same I-SID is assigned to the service and mapped to the same ESP. Note, by signaling the I-SID associated to the ESP, one can ensure that IB-BEBs select the appropriate CBP port.
RSVP-TE信令可用于自动化I-SID到ESP的映射。通过依赖信令，可以确保将相同的I-SID分配给服务并映射到相同的ESP。注意，通过向ESP关联的I-SID发送信令，可以确保IB BEBs选择适当的CBP端口。
CALL signaling [RFC4974] MAY be used to create an association between the Eth-LSP endpoints prior to establishment of the LSP. The CALL_ATTRIBUTES object can be used during CALL signaling, as described in [RFC4974], to indicate properties of the CALL. The Service ID TLV, defined below, can be carried in the CALL_ATTRIBUTES object to indicate the I-SID to ESP mapping for the Eth-LSP that will be set up in association with the CALL.
呼叫信令[RFC4974]可用于在建立LSP之前在Eth LSP端点之间创建关联。CALL_ATTRIBUTES对象可在呼叫信令期间使用，如[RFC4974]中所述，以指示呼叫的属性。下面定义的服务ID TLV可以携带在CALL_ATTRIBUTES对象中，以指示将与调用关联设置的Eth LSP的I-SID到ESP映射。
Alternatively, the GMPLS RSVP-TE PATH message can carry the I-SID association using the Service ID TLV in the LSP_ATTRIBUTES object [RFC5420] at the time of Eth-LSP signaling. Using this mechanism, it is possible to create the I-SID association, either when the path is set up or at a later time using a PATH refresh.
或者，GMPLS RSVP-TE PATH消息可以在Eth LSP信令时使用LSP_属性对象[RFC5420]中的服务ID TLV携带I-SID关联。使用此机制，可以在设置路径时或稍后使用路径刷新创建I-SID关联。
A new Service ID TLV is defined for the CALL_ATTRIBUTES and LSP_ATTRIBUTES objects. The type value is 3 when carried in the CALL_ATTRIBUTES object and the type value is 2 when carried in the LSP_ATTRIBUTES object. The format is depicted below.
为CALL_属性和LSP_属性对象定义了一个新的服务ID TLV。在CALL_ATTRIBUTES对象中携带时，类型值为3，在LSP_ATTRIBUTES对象中携带时，类型值为2。格式如下所示。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| I-SID Set Object 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: : :
: : :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| I-SID Set Object n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| I-SID Set Object 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: : :
: : :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| I-SID Set Object n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Service ID TLV
图4：服务ID TLV
- I-SID Set Object: is used to define a list or range of I-SIDs. Multiple I-SID Set Objects can be present. At least one I-SID Set Object MUST be present. In most of the cases, a single I-SID Set Object with a single I-SID value is used. The I-SID Set Object is used to define a list or range of I-SIDs. The format of the I-SID Set Object is based on the LABEL_SET Object:
- I-SID集合对象：用于定义I-SID的列表或范围。可以存在多个I-SID集对象。必须至少存在一个I-SID集对象。在大多数情况下，使用具有单个I-SID值的单个I-SID集合对象。I-SID集合对象用于定义I-SID的列表或范围。I-SID集合对象的格式基于标签\集合对象：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Action | Reserved | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | I-SID 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: : :
: : :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | I-SID n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Action | Reserved | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | I-SID 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: : :
: : :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | I-SID n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: I-SID Set Object
图5:I-SID集合对象
- Action: 8 bits
- 动作：8位
The following actions are defined: list (0), range (1). When a range is defined, there are only two I-SIDs that follow the beginning I-SID and the end of the range I-SID. When list is defined, a number of I-SIDs may be defined.
定义了以下操作：列表（0）、范围（1）。定义范围时，只有两个I-SID位于范围I-SID的开始和结束之后。定义列表时，可以定义多个I-SID。
- Length: 16 bits
- 长度：16位
This indicates the length of the I-SID Set object.
这表示I-SID集合对象的长度。
- I-SID: 24 bits
- I-SID:24位
The I-SID value identifies a particular backbone service instance.
I-SID值标识特定的主干网服务实例。
The following errors identify Eth-LSP-specific problems.
以下错误识别Eth LSP特定的问题。
In PBB-TE, a set of ESP-VIDs allocated to PBB-TE must be configured. Therefore, it is possible in some situations that the configuration of a bridge is not the same as other bridges. If the ESP-VIDs of various bridges have some ESP-VIDs in common, it is possible some paths may be set up before encountering issues. This is a management issue since all bridges should have the same ESP-VID range. Configuration should be consistent.
在PBB-TE中，必须配置一组分配给PBB-TE的ESP视频。因此，在某些情况下，网桥的配置可能与其他网桥不同。如果各种网桥的ESP VID有一些共同的ESP VID，则可能会在遇到问题之前设置一些路径。这是一个管理问题，因为所有网桥应具有相同的ESP-VID范围。配置应该是一致的。
The network operator administratively selects a set of VLAN Identifiers that can be used to set up ESPs. Consequently, any VID outside the allocated range is invalid, and an error MUST be generated where the mismatch is discovered. The Error indication is carried in the PathErr message from any intermediate bridge that does not support the signaled source VID or optionally the destination VID. The Error MAY be indicated in the ResvErr if the allocation error happens on the RESV message. In this case, a bridge that does not support the signaled destination VID MUST signal the error.
网络运营商以管理方式选择一组可用于设置ESP的VLAN标识符。因此，任何超出分配范围的VID都是无效的，如果发现不匹配，则必须生成错误。错误指示在PathErr消息中携带，该消息来自不支持信号源VID或（可选）目标VID的任何中间网桥。如果RESV消息上发生分配错误，则该错误可能会在ResvErr中指示。在这种情况下，不支持发信号的目的地VID的网桥必须发出错误信号。
If a bridge is not configured to use the ESP-VID value, carried in the Label object, for PBB-TE ESPs, it MUST immediately generate an error: Routing problem (24) / Unacceptable label value (6). Handling of this error is according to [RFC3209].
如果网桥未配置为使用PBB-TE ESP标签对象中携带的ESP-VID值，则必须立即生成错误：路由问题（24）/不可接受的标签值（6）。根据[RFC3209]处理此错误。
Note that an originating bridge can reuse an ESP-VID with a different source or destination B-MAC address. By allocating a number of B-MACs and a number of ESP-VIDs, a large number of PBB-TE connections may be supported.
请注意，发起网桥可以使用不同的源或目标B-MAC地址重用ESP-VID。通过分配大量的B-MAC和ESP视频，可以支持大量的PBB-TE连接。
Note, this error may be originated by any bridge along the path.
注意，此错误可能由路径上的任何桥引起。
The destination bridge, after receiving the PATH message, has to assign a VID, which, together with its MAC address, will constitute the PBB-TE Ethernet Label. An existing VID may be reused when shared forwarding is used or when there are no path conflicts; otherwise, the bridge has to allocate a VID.
目标网桥在接收到PATH消息后，必须分配一个VID，该VID与其MAC地址一起构成PBB-TE以太网标签。当使用共享转发或不存在路径冲突时，可以重用现有VID；否则，网桥必须分配一个VID。
Depending on the size of the allocated VLAN range and the number of Eth-LSPs terminated on a particular bridge, it is possible that the available VIDs are exhausted; hence, no PBB-TE Ethernet Label can be allocated. In this case, the destination bridge SHOULD generate a PathErr message with error code: Routing problem (24) and error value: MPLS Label allocation failure (9).
根据所分配的VLAN范围的大小和在特定网桥上终止的Eth LSP的数量，可用VID可能耗尽；因此，无法分配PBB-TE以太网标签。在这种情况下，目标网桥应生成一条PathErr消息，错误代码为：路由问题（24），错误值为：MPLS标签分配失败（9）。
IEEE defines a set of reserved MAC addresses from 01-80-C2-00-00-00 to 01-80-C2-00-00-0F as explained in [IEEE802.1Q] that have special meaning, processing, and follow specific forwarding rules. These addresses cannot be used for PBB-TE ESPs. In the case the PBB-TE Ethernet Label refers to such a MAC address, a bridge encountering the mismatch MUST immediately generate an error: Routing problem (24) / Unacceptable label value (6). Handling of this error is according to [RFC3209].
IEEE定义了一组从01-80-C2-00-00-00到01-80-C2-00-00-0F的保留MAC地址，如[IEEE802.1Q]中所述，这些地址具有特殊含义、处理和遵循特定的转发规则。这些地址不能用于PBB-TE ESP。在PBB-TE以太网标签引用这种MAC地址的情况下，遇到不匹配的网桥必须立即生成错误：路由问题（24）/不可接受的标签值（6）。根据[RFC3209]处理此错误。
This document does not introduce new security issues; the considerations in [RFC4872] and [RFC4873] apply.
本文件未引入新的安全问题；[RFC4872]和[RFC4873]中的注意事项适用。
A GMPLS-controlled Ethernet PBB-TE system assumes that users and devices attached to User-to-Network Interfaces (UNIs) may behave maliciously, negligently, or incorrectly. Intra-provider control traffic is trusted not to be malicious. In general, these requirements are no different from the security requirements for operating any GMPLS network. Access to the trusted network will only occur through the protocols defined for the UNI or Network-to-Network Interface (NNI) or through protected management interfaces.
GMPLS控制的以太网PBB-TE系统假设连接到用户到网络接口（UNIs）的用户和设备可能有恶意、疏忽或错误行为。提供程序内控制通信被认为不是恶意的。一般来说，这些要求与运行任何GMPLS网络的安全要求没有区别。只有通过为UNI或网络到网络接口（NNI）定义的协议或通过受保护的管理接口才能访问受信任的网络。
When in-band GMPLS signaling is used for the control plane, the security of the control plane and the data plane may affect each other. When out-of-band GMPLS signaling is used for the control plane, the data-plane security is decoupled from the control plane; therefore, the security of the data plane has less impact on overall security.
当控制平面使用带内GMPLS信令时，控制平面和数据平面的安全性可能会相互影响。当控制平面使用带外GMPLS信令时，数据平面安全性与控制平面解耦；因此，数据平面的安全性对整体安全性的影响较小。
Where GMPLS is applied to the control of VLAN only, the commonly known techniques for mitigation of Ethernet denial-of-service (DoS) attacks may be required on UNI ports. PBB-TE has been designed to interwork with legacy VLANs and the VLANs provide isolation from Ethernet legacy control planes.
如果GMPLS仅应用于VLAN的控制，则可能需要在UNI端口上使用常见的减轻以太网拒绝服务（DoS）攻击的技术。PBB-TE设计用于与传统VLAN互通，VLAN提供与以太网传统控制平面的隔离。
Where control-plane communications are point-to-point over links that employ 802.1AE Media Access Control Security [MACSEC], it may reasonably be determined that no further security measures are used. In other cases, it is appropriate to use control-plane security where it is deemed necessary to secure the signaling messages. GMPLS signaling security measures are described in [RFC3471] and [RFC3473], and they inherit security techniques applicable to RSVP-TE, as described in [RFC3209] and [RFC2205]. For a fuller overview of GMPLS security techniques, see [RFC5920].
如果控制平面通信是通过采用802.1AE媒体访问控制安全[MACSEC]的链路进行的点对点通信，则可以合理地确定不使用进一步的安全措施。在其他情况下，如果认为有必要保护信令消息，则宜使用控制平面安全性。[RFC3471]和[RFC3473]中描述了GMPLS信令安全措施，它们继承了适用于RSVP-TE的安全技术，如[RFC3209]和[RFC2205]中所述。有关GMPLS安全技术的更全面概述，请参阅[RFC5920]。
A new Switching Type, "802_1 PBB-TE" (40), has been assigned in the Switching Types registry of the GMPLS Signaling Parameters registry.
在GMPLS信令参数注册表的交换类型注册表中分配了一种新的交换类型“802_1 PBB-TE”（40）。
The Service ID TLV has been assigned in the Attributes TLV Space in the RSVP-TE Parameters registry. It is carried in the LSP_ATTRIBUTES object (class = 197, C-Type = 1) [RFC5420]. This new type has been registered as follows:
已在RSVP-TE参数注册表的属性TLV空间中分配了服务ID TLV。它携带在LSP_属性对象中（类=197，C类型=1）[RFC5420]。此新类型已注册如下：
Type: 2 Name: Service ID TLV Allowed on LSP_ATTRIBUTES: Yes Allowed on LSP_REQUIRED_ATTRIBUTES: No
类型：2名称：LSP_属性上允许的服务ID TLV：LSP_必需_属性上允许的是：否
The Service ID TLV has been assigned value 3 in the Call Attributes TLV registry in the RSVP Parameters registry. It is carried in the CALL_ATTRIBUTES object (class = 202, C-Type = 1) defined by [RFC6001].
服务ID TLV已在RSVP参数注册表中的调用属性TLV注册表中分配了值3。它在[RFC6001]定义的CALL_ATTRIBUTES对象（class=202，C-Type=1）中携带。
[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月。
[RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[RFC2205]Braden，R.，Ed.，Zhang，L.，Berson，S.，Herzog，S.，和S.Jamin，“资源预留协议（RSVP）——版本1功能规范”，RFC 22052997年9月。
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.
[RFC3209]Awduche，D.，Berger，L.，Gan，D.，Li，T.，Srinivasan，V.，和G.Swallow，“RSVP-TE：LSP隧道RSVP的扩展”，RFC 3209，2001年12月。
[RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label Swicthing (GMPLS) Signaling Functional Description", RFC 3471, January 2003.
[RFC3471]Berger，L.，Ed.“通用多协议标签交换（GMPLS）信令功能描述”，RFC 3471，2003年1月。
[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC3473]Berger，L.，Ed.“通用多协议标签交换（GMPLS）信令资源预留协议流量工程（RSVP-TE）扩展”，RFC 3473，2003年1月。
[RFC3945] Mannie, E., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", RFC 3945, October 2004.
[RFC3945]Mannie，E.，Ed.“通用多协议标签交换（GMPLS）体系结构”，RFC 39452004年10月。
[RFC4872] Lang, J., Ed., Rekhter, Y., Ed., and D. Papadimitriou, Ed., "RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery", RFC 4872, May 2007.
[RFC4872]Lang，J.，Ed.，Rekhter，Y.，Ed.，和D.Papadimitriou，Ed.，“支持端到端通用多协议标签交换（GMPLS）恢复的RSVP-TE扩展”，RFC 4872，2007年5月。
[RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel, "GMPLS Segment Recovery", RFC 4873, May 2007.
[RFC4873]Berger，L.，Bryskin，I.，Papadimitriou，D.，和A.Farrel，“GMPLS段恢复”，RFC 4873，2007年5月。
[RFC4974] Papadimitriou, D. and A. Farrel, "Generalized MPLS (GMPLS) RSVP-TE Signaling Extensions in Support of Calls", RFC 4974, August 2007.
[RFC4974]Papadimitriou，D.和A.Farrel，“支持呼叫的通用MPLS（GMPLS）RSVP-TE信令扩展”，RFC 4974，2007年8月。
[RFC5420] Farrel, A., Ed., Papadimitriou, D., Vasseur, JP., and A. Ayyangarps, "Encoding of Attributes for MPLS LSP Establishment Using Resource Reservation Protocol Traffic Engineering (RSVP-TE)", RFC 5420, February 2009.
[RFC5420]Farrel，A.，Ed.，Papadimitriou，D.，Vasseur，JP.，和A.Ayyangarps，“使用资源预留协议流量工程（RSVP-TE）建立MPLS LSP的属性编码”，RFC 5420，2009年2月。
[RFC6001] Papadimitriou, D., Vigoureux, M., Shiomoto, K., Brungard, D., and JL. Le Roux, "Generalized MPLS (GMPLS) Protocol Extensions for Multi-Layer and Multi-Region Networks (MLN/MRN)", RFC 6001, October 2010.
[RFC6001]Papadimitriou，D.，Vigoureux，M.，Shiomoto，K.，Brungard，D.，和JL。Le Roux，“多层和多区域网络（MLN/MRN）的通用MPLS（GMPLS）协议扩展”，RFC 60012010年。
[IEEE802.1ah] "IEEE Standard for Local and Metropolitan Area Networks - Virtual Bridged Local Area Networks - Amendment 6: Provider Backbone Bridges", (2008)
[IEEE802.1ah]“局域网和城域网IEEE标准-虚拟桥接局域网-修改件6：提供商主干网桥”，（2008年）
[IEEE802.1Q] "IEEE Standard for Local and Metropolitan Area Networks - Virtual Bridged Local Area Networks", IEEE Std 802.1Q-2005, May 19, 2006.
[IEEE802.1Q]“局域网和城域网的IEEE标准-虚拟桥接局域网”，IEEE标准802.1Q-2005，2006年5月19日。
[IEEE802.1Qay] "IEEE Standard for Local and Metropolitan Area Networks - Virtual Bridged Local Area Networks - Amendment : Provider Backbone Bridges Traffic Engineering", 2009.
[IEEE802.1Qay]“局域网和城域网IEEE标准-虚拟桥接局域网-修订：提供商主干桥流量工程”，2009年。
[MACSEC] "IEEE Standard for Local and metropolitan area networks Media Access Control (MAC) Security", IEEE 802.1AE-2006, August 18, 2006.
[MACSEC]“局域网和城域网媒体访问控制（MAC）安全的IEEE标准”，IEEE 802.1AE-2006，2006年8月18日。
[RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S. Yasukawa, Ed., "Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs)", RFC 4875, May 2007.
[RFC4875]Aggarwal，R.，Ed.，Papadimitriou，D.，Ed.，和S.Yasukawa，Ed.，“资源预留协议的扩展-点对多点TE标签交换路径（LSP）的流量工程（RSVP-TE）”，RFC 48752007年5月。
[RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, August 2006.
[RFC4655]Farrel，A.，Vasseur，J.-P.，和J.Ash，“基于路径计算元素（PCE）的体系结构”，RFC 46552006年8月。
[RFC5828] Fedyk, D., Berger, L., and L. Andersson, "Generalized Multiprotocol Label Switching (GMPLS) Ethernet Label Switching Architecture and Framework", RFC 5828, March 2010.
[RFC5828]Fedyk，D.，Berger，L.，和L.Andersson，“通用多协议标签交换（GMPLS）以太网标签交换体系结构和框架”，RFC 58282010年3月。
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", RFC 5920, July 2010.
[RFC5920]方，L.，编辑，“MPLS和GMPLS网络的安全框架”，RFC 5920，2010年7月。
The authors would like to thank Dinesh Mohan, Nigel Bragg, Stephen Shew, Dave Martin and Sandra Ballarte for their contributions to this document. The authors thank Deborah Brungard and Adrian Farrel for their review and suggestions to this document.
作者要感谢Dinesh Mohan、Nigel Bragg、Stephen Shew、Dave Martin和Sandra Ballarte对本文件的贡献。作者感谢Deborah Brungard和Adrian Farrel对本文件的评论和建议。
Authors' Addresses
作者地址
Don Fedyk Alcatel-Lucent Groton, MA 01450 Phone: +1-978-467-5645 EMail: donald.fedyk@alcatel-lucent.com
唐·费迪克·阿尔卡特·朗讯·格罗顿，马萨诸塞州01450电话：+1-978-467-5645电子邮件：唐纳德。fedyk@alcatel-朗讯网
Himanshu Shah Ciena 1741 Technology Dr, #400 San Jose, CA 95110 Phone: 508-435-0448 EMail: hshah@ciena.com
Himanshu Shah Ciena 1741技术博士，加利福尼亚州圣何塞400号，邮编95110电话：508-435-0448电子邮件：hshah@ciena.com
Nabil Bitar Verizon 40 Sylvan Rd. Waltham, MA 02451 EMail: nabil.n.bitar@verizon.com
Nabil Bitar Verizon马萨诸塞州沃尔瑟姆Sylvan路40号02451电子邮件：Nabil.n。bitar@verizon.com
Attila Takacs Ericsson 1. Laborc u. Budapest, HUNGARY 1037 EMail: attila.takacs@ericsson.com
阿提拉·塔卡茨·爱立信1号。劳工大学。匈牙利布达佩斯1037电子邮件：attila。takacs@ericsson.com