Internet Engineering Task Force (IETF) A. Farrel, Ed.
Request for Comments: 7926 J. Drake
BCP: 206 Juniper Networks
Category: Best Current Practice N. Bitar
ISSN: 2070-1721 Nokia
G. Swallow
Cisco Systems, Inc.
D. Ceccarelli
Ericsson
X. Zhang
Huawei
July 2016
Internet Engineering Task Force (IETF) A. Farrel, Ed.
Request for Comments: 7926 J. Drake
BCP: 206 Juniper Networks
Category: Best Current Practice N. Bitar
ISSN: 2070-1721 Nokia
G. Swallow
Cisco Systems, Inc.
D. Ceccarelli
Ericsson
X. Zhang
Huawei
July 2016
Problem Statement and Architecture for Information Exchange between Interconnected Traffic-Engineered Networks
互联交通工程网络间信息交换的问题陈述和体系结构
Abstract
摘要
In Traffic-Engineered (TE) systems, it is sometimes desirable to establish an end-to-end TE path with a set of constraints (such as bandwidth) across one or more networks from a source to a destination. TE information is the data relating to nodes and TE links that is used in the process of selecting a TE path. TE information is usually only available within a network. We call such a zone of visibility of TE information a domain. An example of a domain may be an IGP area or an Autonomous System.
在流量工程（TE）系统中，有时需要在一个或多个网络上从源到目的地建立具有一组约束（例如带宽）的端到端TE路径。TE信息是与选择TE路径过程中使用的节点和TE链路相关的数据。TE信息通常仅在网络中可用。我们把这种信息的可视区域称为域。域的示例可以是IGP区域或自治系统。
In order to determine the potential to establish a TE path through a series of connected networks, it is necessary to have available a certain amount of TE information about each network. This need not be the full set of TE information available within each network but does need to express the potential of providing TE connectivity. This subset of TE information is called TE reachability information.
为了确定通过一系列连接网络建立TE路径的可能性，有必要获得关于每个网络的一定数量的TE信息。这不需要是每个网络中可用的完整TE信息集，但需要表达提供TE连接的潜力。TE信息的子集称为TE可达性信息。
This document sets out the problem statement for the exchange of TE information between interconnected TE networks in support of end-to-end TE path establishment and describes the best current practice architecture to meet this problem statement. For reasons that are explained in this document, this work is limited to simple TE constraints and information that determine TE reachability.
本文件阐述了支持端到端TE路径建立的互连TE网络之间TE信息交换的问题陈述，并描述了满足该问题陈述的最佳实践体系结构。出于本文档中解释的原因，本工作仅限于确定TE可达性的简单TE约束和信息。
Status of This Memo
关于下段备忘
This memo documents an Internet Best Current Practice.
本备忘录记录了互联网最佳实践。
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 BCPs is available in Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关BCP的更多信息，请参见RFC 7841第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/rfc7926.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7926.
Copyright Notice
版权公告
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2016 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 ....................................................5
1.1. Terminology ................................................6
1.1.1. TE Paths and TE Connections .........................6
1.1.2. TE Metrics and TE Attributes ........................6
1.1.3. TE Reachability .....................................7
1.1.4. Domain ..............................................7
1.1.5. Server Network ......................................7
1.1.6. Client Network ......................................7
1.1.7. Aggregation .........................................7
1.1.8. Abstraction .........................................8
1.1.9. Abstract Link .......................................8
1.1.10. Abstract Node or Virtual Node ......................8
1.1.11. Abstraction Layer Network ..........................9
2. Overview of Use Cases ...........................................9
2.1. Peer Networks ..............................................9
2.2. Client-Server Networks ....................................11
2.3. Dual-Homing ...............................................15
2.4. Requesting Connectivity ...................................15
2.4.1. Discovering Server Network Information .............17
3. Problem Statement ..............................................18
3.1. Policy and Filters ........................................18
3.2. Confidentiality ...........................................19
3.3. Information Overload ......................................19
3.4. Issues of Information Churn ...............................20
3.5. Issues of Aggregation .....................................21
4. Architecture ...................................................22
4.1. TE Reachability ...........................................22
4.2. Abstraction, Not Aggregation ..............................22
4.2.1. Abstract Links .....................................23
4.2.2. The Abstraction Layer Network ......................23
4.2.3. Abstraction in Client-Server Networks ..............26
4.2.4. Abstraction in Peer Networks .......................32
4.3. Considerations for Dynamic Abstraction ....................34
4.4. Requirements for Advertising Links and Nodes ..............35
4.5. Addressing Considerations .................................36
5. Building on Existing Protocols .................................36
5.1. BGP-LS ....................................................37
5.2. IGPs ......................................................37
5.3. RSVP-TE ...................................................37
5.4. Notes on a Solution .......................................37
6. Application of the Architecture to Optical Domains and
Networks .......................................................39
1. Introduction ....................................................5
1.1. Terminology ................................................6
1.1.1. TE Paths and TE Connections .........................6
1.1.2. TE Metrics and TE Attributes ........................6
1.1.3. TE Reachability .....................................7
1.1.4. Domain ..............................................7
1.1.5. Server Network ......................................7
1.1.6. Client Network ......................................7
1.1.7. Aggregation .........................................7
1.1.8. Abstraction .........................................8
1.1.9. Abstract Link .......................................8
1.1.10. Abstract Node or Virtual Node ......................8
1.1.11. Abstraction Layer Network ..........................9
2. Overview of Use Cases ...........................................9
2.1. Peer Networks ..............................................9
2.2. Client-Server Networks ....................................11
2.3. Dual-Homing ...............................................15
2.4. Requesting Connectivity ...................................15
2.4.1. Discovering Server Network Information .............17
3. Problem Statement ..............................................18
3.1. Policy and Filters ........................................18
3.2. Confidentiality ...........................................19
3.3. Information Overload ......................................19
3.4. Issues of Information Churn ...............................20
3.5. Issues of Aggregation .....................................21
4. Architecture ...................................................22
4.1. TE Reachability ...........................................22
4.2. Abstraction, Not Aggregation ..............................22
4.2.1. Abstract Links .....................................23
4.2.2. The Abstraction Layer Network ......................23
4.2.3. Abstraction in Client-Server Networks ..............26
4.2.4. Abstraction in Peer Networks .......................32
4.3. Considerations for Dynamic Abstraction ....................34
4.4. Requirements for Advertising Links and Nodes ..............35
4.5. Addressing Considerations .................................36
5. Building on Existing Protocols .................................36
5.1. BGP-LS ....................................................37
5.2. IGPs ......................................................37
5.3. RSVP-TE ...................................................37
5.4. Notes on a Solution .......................................37
6. Application of the Architecture to Optical Domains and
Networks .......................................................39
7. Application of the Architecture to the User-Network Interface ..44
8. Application of the Architecture to L3VPN Multi-AS Environments .46
9. Scoping Future Work ............................................47
9.1. Limiting Scope to Only Part of the Internet ...............47
9.2. Working with "Related" Domains ............................47
9.3. Not Finding Optimal Paths in All Situations ...............48
9.4. Sanity and Scaling ........................................48
10. Manageability Considerations ..................................48
10.1. Managing the Abstraction Layer Network ...................49
10.2. Managing Interactions of Abstraction Layer and
Client Networks ..........................................49
10.3. Managing Interactions of Abstraction Layer and
Server Networks ..........................................50
11. Security Considerations .......................................51
12. Informative References ........................................52
Appendix A. Existing Work .........................................58
A.1. Per-Domain Path Computation ...............................58
A.2. Crankback .................................................59
A.3. Path Computation Element ..................................59
A.4. GMPLS UNI and Overlay Networks ............................61
A.5. Layer 1 VPN ...............................................62
A.6. Policy and Link Advertisement .............................62
Appendix B. Additional Features ...................................63
B.1. Macro Shared Risk Link Groups .............................63
B.2. Mutual Exclusivity ........................................64
Acknowledgements ..................................................65
Contributors ......................................................66
Authors' Addresses ................................................67
7. Application of the Architecture to the User-Network Interface ..44
8. Application of the Architecture to L3VPN Multi-AS Environments .46
9. Scoping Future Work ............................................47
9.1. Limiting Scope to Only Part of the Internet ...............47
9.2. Working with "Related" Domains ............................47
9.3. Not Finding Optimal Paths in All Situations ...............48
9.4. Sanity and Scaling ........................................48
10. Manageability Considerations ..................................48
10.1. Managing the Abstraction Layer Network ...................49
10.2. Managing Interactions of Abstraction Layer and
Client Networks ..........................................49
10.3. Managing Interactions of Abstraction Layer and
Server Networks ..........................................50
11. Security Considerations .......................................51
12. Informative References ........................................52
Appendix A. Existing Work .........................................58
A.1. Per-Domain Path Computation ...............................58
A.2. Crankback .................................................59
A.3. Path Computation Element ..................................59
A.4. GMPLS UNI and Overlay Networks ............................61
A.5. Layer 1 VPN ...............................................62
A.6. Policy and Link Advertisement .............................62
Appendix B. Additional Features ...................................63
B.1. Macro Shared Risk Link Groups .............................63
B.2. Mutual Exclusivity ........................................64
Acknowledgements ..................................................65
Contributors ......................................................66
Authors' Addresses ................................................67
Traffic-Engineered (TE) systems such as MPLS-TE [RFC2702] and GMPLS [RFC3945] offer a way to establish paths through a network in a controlled way that reserves network resources on specified links. TE paths are computed by examining the Traffic Engineering Database (TED) and selecting a sequence of links and nodes that are capable of meeting the requirements of the path to be established. The TED is constructed from information distributed by the Interior Gateway Protocol (IGP) running in the network -- for example, OSPF-TE [RFC3630] or ISIS-TE [RFC5305].
诸如MPLS-TE[RFC2702]和GMPLS[RFC3945]等流量工程（TE）系统提供了一种以受控方式建立网络路径的方法，该方法在指定链路上保留网络资源。TE路径通过检查交通工程数据库（TED）并选择能够满足待建立路径要求的链路和节点序列来计算。TED由网络中运行的内部网关协议（IGP）分发的信息构成，例如OSPF-TE[RFC3630]或ISIS-TE[RFC5305]。
It is sometimes desirable to establish an end-to-end TE path that crosses more than one network or administrative domain as described in [RFC4105] and [RFC4216]. In these cases, the availability of TE information is usually limited to within each network. Such networks are often referred to as domains [RFC4726], and we adopt that definition in this document; viz.,
如[RFC4105]和[RFC4216]中所述，有时需要建立跨越多个网络或管理域的端到端TE路径。在这些情况下，TE信息的可用性通常限于每个网络内。此类网络通常称为域[RFC4726]，我们在本文件中采用该定义；即。，
For the purposes of this document, a domain is considered to be any collection of network elements within a common sphere of address management or path computational responsibility. Examples of such domains include IGP areas and Autonomous Systems (ASes).
在本文档中，域被视为地址管理或路径计算责任的公共范围内的任何网络元素集合。此类域的示例包括IGP区域和自治系统（ASE）。
In order to determine the potential to establish a TE path through a series of connected domains and to choose the appropriate domain connection points through which to route a path, it is necessary to have available a certain amount of TE information about each domain. This need not be the full set of TE information available within each domain but does need to express the potential of providing TE connectivity. This subset of TE information is called TE reachability information. The TE reachability information can be exchanged between domains based on the information gathered from the local routing protocol, filtered by configured policy, or statically configured.
为了确定通过一系列连接域建立TE路径的可能性，并选择适当的域连接点来路由路径，有必要提供关于每个域的一定数量的TE信息。这不需要是每个域中可用的完整TE信息集，但需要表达提供TE连接的潜力。TE信息的子集称为TE可达性信息。TE可达性信息可以基于从本地路由协议收集的信息在域之间交换，通过配置的策略进行过滤，或者静态配置。
This document sets out the problem statement for the exchange of TE information between interconnected TE networks in support of end-to-end TE path establishment and describes the best current practice architecture to meet this problem statement. The scope of this document is limited to the simple TE constraints and information (such as TE metrics, hop count, bandwidth, delay, shared risk) necessary to determine TE reachability: discussion of multiple additional constraints that might qualify the reachability can significantly complicate aggregation of information and the stability of the mechanism used to present potential connectivity, as is explained in the body of this document.
本文件阐述了支持端到端TE路径建立的互连TE网络之间TE信息交换的问题陈述，并描述了满足该问题陈述的最佳实践体系结构。本文档的范围仅限于简单的TE约束和信息（如TE指标、跳数、带宽、延迟、共享风险）确定TE可达性的必要条件：讨论可能限定可达性的多个附加约束可能会使信息聚合和用于呈现潜在连接的机制的稳定性显著复杂化，如本文件正文所述。
Appendix A summarizes relevant existing work that is used to route TE paths across multiple domains.
附录A总结了用于跨多个域路由TE路径的相关现有工作。
This section introduces some key terms that need to be understood to arrive at a common understanding of the problem space. Some of the terms are defined in more detail in the sections that follow (in which case forward pointers are provided), and some terms are taken from definitions that already exist in other RFCs (in which case references are given, but no apology is made for repeating or summarizing the definitions here).
本节介绍一些需要理解的关键术语，以便对问题空间达成共识。一些术语在后面的章节中有更详细的定义（在这种情况下，提供了前进指针），一些术语取自其他RFC中已经存在的定义（在这种情况下，给出了参考文献，但没有为重复或总结此处的定义而道歉）。
A TE connection is a Label Switched Path (LSP) through an MPLS-TE or GMPLS network that directs traffic along a particular path (the TE path) in order to provide a specific service such as bandwidth guarantee, separation of traffic, or resilience between a well-known pair of end points.
TE连接是通过MPLS-TE或GMPLS网络的标签交换路径（LSP），该网络沿着特定路径（TE路径）引导流量，以便提供特定服务，例如带宽保证、流量分离或已知端点对之间的弹性。
"TE metrics" and "TE attributes" are terms applied to parameters of links (and possibly nodes) in a network that is traversed by TE connections. The TE metrics and TE attributes are used by path computation algorithms to select the TE paths that the TE connections traverse. A TE metric is a quantifiable value (including measured characteristics) describing some property of a link or node that can be used as part of TE routing or planning, while a TE attribute is a wider term (i.e., including the concept of a TE metric) that refers to any property or characteristic of a link or node that can be used as part of TE routing or planning. Thus, the delay introduced by transmission of a packet on a link is an example of a TE metric, while the geographic location of a router is an example of a more general attribute.
“TE度量”和“TE属性”是应用于TE连接所穿越的网络中的链路（可能还有节点）参数的术语。路径计算算法使用TE度量和TE属性来选择TE连接遍历的TE路径。TE度量是一个可量化的值（包括测量的特征），描述链路或节点的某些属性，可作为TE路由或规划的一部分，而TE属性是一个更广泛的术语（即，包括TE度量的概念）指链路或节点的任何属性或特征，可作为TE路由或规划的一部分。因此，由链路上的分组的传输引入的延迟是TE度量的示例，而路由器的地理位置是更一般属性的示例。
Provisioning a TE connection through a network may result in dynamic changes to the TE metrics and TE attributes of the links and nodes in the network.
通过网络提供TE连接可能导致网络中链路和节点的TE度量和TE属性的动态变化。
These terms are also sometimes used to describe the end-to-end characteristics of a TE connection and can be derived according to a formula from the TE metrics and TE attributes of the links and nodes that the TE connection traverses. Thus, for example, the end-to-end delay for a TE connection is usually considered to be the sum of the delay on each link that the connection traverses.
这些术语有时也用于描述TE连接的端到端特性，并且可以根据公式从TE连接穿过的链路和节点的TE度量和TE属性中导出。因此，例如，TE连接的端到端延迟通常被认为是连接所经过的每个链路上的延迟之和。
In an IP network, reachability is the ability to deliver a packet to a specific address or prefix, i.e., the existence of an IP path to that address or prefix. TE reachability is the ability to reach a specific address along a TE path. More specifically, it is the ability to establish a TE connection in an MPLS-TE or GMPLS sense. Thus, we talk about TE reachability as the potential of providing TE connectivity.
在IP网络中，可达性是指将数据包传送到特定地址或前缀的能力，即该地址或前缀的IP路径的存在。TE可达性是指沿着TE路径到达特定地址的能力。更具体地说，它是在MPLS-TE或GMPLS意义上建立TE连接的能力。因此，我们将TE可达性视为提供TE连通性的潜力。
TE reachability may be unqualified (there is a TE path, but no information about available resources or other constraints is supplied); this is helpful especially in determining a path to a destination that lies in an unknown domain or that may be qualified by TE attributes and TE metrics such as hop count, available bandwidth, delay, and shared risk.
TE可达性可能不合格（存在TE路径，但未提供有关可用资源或其他约束的信息）；这尤其有助于确定位于未知域中或可能由TE属性和TE度量（如跳数、可用带宽、延迟和共享风险）限定的目的地的路径。
As defined in [RFC4726], a domain is any collection of network elements within a common sphere of address management or path computational responsibility. Examples of such domains include IGP areas and ASes.
如[RFC4726]中所定义，域是地址管理或路径计算责任的公共范围内的任何网络元素集合。此类域的示例包括IGP区域和ASE。
A Server Network is a network that provides connectivity for another network (the Client Network) in a client-server relationship. A Server Network is sometimes referred to as an underlay network.
服务器网络是为客户机-服务器关系中的另一个网络（客户机网络）提供连接的网络。服务器网络有时称为参考底图网络。
A Client Network is a network that uses the connectivity provided by a Server Network. A Client Network is sometimes referred to as an overlay network.
客户端网络是使用服务器网络提供的连接的网络。客户端网络有时称为覆盖网络。
The concept of aggregation is discussed in Section 3.5. In aggregation, multiple network resources from a domain are represented outside the domain as a single entity. Thus, multiple links and nodes forming a TE connection may be represented as a single link, or a collection of nodes and links (perhaps the whole domain) may be represented as a single node with its attachment links.
第3.5节讨论了聚合的概念。在聚合中，域中的多个网络资源在域外表示为单个实体。因此，形成TE连接的多个链路和节点可以表示为单个链路，或者节点和链路的集合（可能是整个域）可以表示为具有其连接链路的单个节点。
Section 4.2 introduces the concept of abstraction and distinguishes it from aggregation. Abstraction may be viewed as "policy-based aggregation" where the policies are applied to overcome the issues with aggregation as identified in Section 3 of this document.
第4.2节介绍了抽象的概念，并将其与聚合区分开来。抽象可被视为“基于策略的聚合”，其中应用策略以克服本文档第3节中确定的聚合问题。
Abstraction is the process of applying policy to the available TE information within a domain, to produce selective information that represents the potential ability to connect across the domain. Thus, abstraction does not necessarily offer all possible connectivity options, but it presents a general view of potential connectivity according to the policies that determine how the domain's administrator wants to allow the domain resources to be used.
抽象是将策略应用于域内可用的TE信息的过程，以生成表示跨域连接的潜在能力的选择性信息。因此，抽象不一定提供所有可能的连接选项，但它根据确定域管理员希望如何使用域资源的策略提供了潜在连接的一般视图。
An abstract link is the representation of the characteristics of a path between two nodes in a domain produced by abstraction. The abstract link is advertised outside that domain as a TE link for use in signaling in other domains. Thus, an abstract link represents the potential to connect between a pair of nodes.
抽象链接是由抽象产生的域中两个节点之间的路径特征的表示。抽象链路作为TE链路在该域之外进行广告，以用于其他域中的信令。因此，抽象链接表示一对节点之间连接的可能性。
More details regarding abstract links are provided in Section 4.2.1.
第4.2.1节提供了有关抽象链接的更多详细信息。
An abstract node was defined in [RFC3209] as a group of nodes whose internal topology is opaque to an ingress node of the LSP. More generally, an abstract node is the representation as a single node in a TE topology of some or all of the resources of one or more nodes and the links that connect them. An abstract node may be advertised outside the domain as a TE node for use in path computation and signaling in other domains.
[RFC3209]中将抽象节点定义为一组节点，其内部拓扑对LSP的入口节点不透明。更一般地说，抽象节点是一个或多个节点的部分或全部资源以及连接它们的链接在TE拓扑中作为单个节点的表示。抽象节点可以在域外作为TE节点进行广告，以用于其他域中的路径计算和信令。
The term "virtual node" has typically been applied to the aggregation of a domain (that is, a collection of nodes and links that operate as a single administrative entity for TE purposes) into a single entity that is treated as a node for the purposes of end-to-end traffic engineering. Virtual nodes are often considered a way to present islands of single-vendor equipment in an optical network.
术语“虚拟节点”通常用于将域（即，为TE目的作为单个管理实体运行的节点和链路的集合）聚合为单个实体，该实体被视为端到端流量工程的节点。虚拟节点通常被认为是在光网络中呈现单个供应商设备孤岛的一种方式。
Sections 3.5 and 4.2.2.1 provide more information about the uses and issues of abstract nodes and virtual nodes.
第3.5节和第4.2.2.1节提供了有关抽象节点和虚拟节点的使用和问题的更多信息。
The abstraction layer network is introduced in Section 4.2.2. It may be seen as a brokerage-layer network between one or more server networks and one or more client networks. The abstraction layer network is the collection of abstract links that provide potential connectivity across the server networks and on which path computation can be performed to determine edge-to-edge paths that provide connectivity as links in the client network.
第4.2.2节介绍了抽象层网络。它可以被看作是一个或多个服务器网络和一个或多个客户端网络之间的中间层网络。抽象层网络是提供跨服务器网络的潜在连接性的抽象链路的集合，可在其上执行路径计算以确定作为客户端网络中的链路提供连接性的边到边路径。
In the simplest case, the abstraction layer network is just a set of edge-to-edge connections (i.e., abstract links), but to make the use of server network resources more flexible, the abstract links might not all extend from edge to edge but might offer connectivity between server network nodes to form a more complex network.
在最简单的情况下，抽象层网络只是一组边缘到边缘的连接（即，抽象链接），但为了使服务器网络资源的使用更加灵活，抽象链接可能并非全部从边缘延伸到边缘，而是可能提供服务器网络节点之间的连接，以形成更复杂的网络。
The peer network use case can be most simply illustrated by the example in Figure 1. A TE path is required between the source (Src) and destination (Dst), which are located in different domains. There are two points of interconnection between the domains, and selecting the wrong point of interconnection can lead to a suboptimal path or even fail to make a path available. Note that peer networks are assumed to have the same technology type -- that is, the same "switching capability", to use the term from GMPLS [RFC3945].
对等网络用例可以通过图1中的示例进行最简单的说明。在位于不同域中的源（Src）和目标（Dst）之间需要TE路径。域之间有两个互连点，选择错误的互连点可能导致次优路径，甚至无法使路径可用。请注意，对等网络假定具有相同的技术类型——即相同的“交换能力”，使用GMPLS[RFC3945]中的术语。
-------------- --------------
| Domain A | x1 | Domain Z |
| ----- +----+ ----- |
| | Src | +----+ | Dst | |
| ----- | x2 | ----- |
-------------- --------------
-------------- --------------
| Domain A | x1 | Domain Z |
| ----- +----+ ----- |
| | Src | +----+ | Dst | |
| ----- | x2 | ----- |
-------------- --------------
Figure 1: Peer Networks
图1：对等网络
For example, when Domain A attempts to select a path, it may determine that adequate bandwidth is available from Src through both interconnection points x1 and x2. It may pick the path through x1 for local policy reasons: perhaps the TE metric is smaller. However, if there is no connectivity in Domain Z from x1 to Dst, the path cannot be established. Techniques such as crankback may be used to alleviate this situation, but such techniques do not lead to rapid setup or guaranteed optimality. Furthermore, RSVP signaling creates state in the network that is immediately removed by the crankback
例如，当域A尝试选择路径时，它可以确定通过互连点x1和x2从Src获得足够的带宽。出于本地策略的原因，它可能选择通过x1的路径：TE度量可能更小。但是，如果域Z中没有从x1到Dst的连接，则无法建立路径。可使用诸如回退等技术来缓解这种情况，但此类技术不会导致快速设置或保证最佳性。此外，RSVP信令在网络中创建状态，该状态立即被回退删除
procedure. Frequent events of this kind will impact scalability in a non-deterministic manner. More details regarding crankback can be found in Appendix A.2.
程序此类频繁事件将以不确定的方式影响可伸缩性。有关回退的更多详细信息，请参见附录A.2。
There are countless more complicated examples of the problem of peer networks. Figure 2 shows the case where there is a simple mesh of domains. Clearly, to find a TE path from Src to Dst, Domain A must not select a path leaving through interconnect x1, since Domain B has no connectivity to Domain Z. Furthermore, in deciding whether to select interconnection x2 (through Domain C) or interconnection x3 through Domain D, Domain A must be sensitive to the TE connectivity available through each of Domains C and D, as well as the TE connectivity from each of interconnections x4 and x5 to Dst within Domain Z. The problem may be further complicated when the source domain does not know in which domain the destination node is located, since the choice of a domain path clearly depends on the knowledge of the destination domain: this issue is obviously mitigated in IP networks by inter-domain routing [RFC4271].
对等网络问题有无数更复杂的例子。图2显示了存在域的简单网格的情况。显然，为了找到从Src到Dst的TE路径，域a不得选择通过互连x1离开的路径，因为域B与域Z没有连接。此外，在决定是选择互连x2（通过域C）还是选择互连x3通过域D时，域A必须对通过每个域C和D可用的TE连接以及从每个互连x4和x5到域Z内Dst的TE连接敏感。当源域不知道目标节点位于哪个域时，问题可能会更加复杂，由于域路径的选择显然取决于目标域的知识：在IP网络中，域间路由显然可以缓解这个问题[RFC4271]。
Of course, many network interconnection scenarios are going to be a combination of the situations expressed in these two examples. There may be a mesh of domains, and the domains may have multiple points of interconnection.
当然，许多网络互连场景将是这两个示例中表达的情况的组合。可能存在域的网格，并且域可能具有多个互连点。
--------------
| Domain B |
| |
| |
/--------------
/
/x1
--------------/ --------------
| Domain A | | Domain Z |
| | -------------- | |
| ----- | x2| Domain C | x4| ----- |
| | Src | +---+ +---+ | Dst | |
| ----- | | | | ----- |
| | -------------- | |
--------------\ /--------------
\x3 /
\ /
\ /x5
\--------------/
| Domain D |
| |
| |
--------------
--------------
| Domain B |
| |
| |
/--------------
/
/x1
--------------/ --------------
| Domain A | | Domain Z |
| | -------------- | |
| ----- | x2| Domain C | x4| ----- |
| | Src | +---+ +---+ | Dst | |
| ----- | | | | ----- |
| | -------------- | |
--------------\ /--------------
\x3 /
\ /
\ /x5
\--------------/
| Domain D |
| |
| |
--------------
Figure 2: Peer Networks in a Mesh
图2：网状网络中的对等网络
Two major classes of use case relate to the client-server relationship between networks. These use cases have sometimes been referred to as overlay networks. In both of these classes of use case, the client and server networks may have the same switching capability, or they may be built from nodes and links that have different technology types in the client and server networks.
用例的两大类与网络之间的客户机-服务器关系有关。这些用例有时被称为覆盖网络。在这两类用例中，客户机和服务器网络可以具有相同的交换能力，或者它们可以从客户机和服务器网络中具有不同技术类型的节点和链路构建。
The first group of use cases, shown in Figure 3, occurs when domains belonging to one network are connected by a domain belonging to another network. In this scenario, once connectivity is formed across the lower-layer network, the domains of the upper-layer network can be merged into a single domain by running IGP adjacencies and by treating the server-network-layer connectivity as links in the higher-layer network. The TE relationship between the domains (higher and lower layers) in this case is reduced to determining what server network connectivity to establish, how to trigger it, how to route it in the server network, and what resources and capacity to assign within the server network layer. As the demands in the
图3所示的第一组用例发生在属于一个网络的域被属于另一个网络的域连接时。在这种情况下，一旦在下层网络上形成连接，上层网络的域可以通过运行IGP邻接并将服务器网络层连接视为上层网络中的链路而合并到单个域中。在这种情况下，域（上层和下层）之间的TE关系简化为确定要建立的服务器网络连接、如何触发连接、如何在服务器网络中路由连接以及要在服务器网络层中分配的资源和容量。按照
higher-layer (client) network vary, the connectivity in the server network may need to be modified. Section 2.4 explains in a little more detail how connectivity may be requested.
更高层（客户端）网络不同，可能需要修改服务器网络中的连接。第2.4节更详细地解释了如何请求连接。
---------------- ----------------
| Client Network | | Client Network |
| Domain A | | Domain B |
| | | |
| ----- | | ----- |
| | Src | | | | Dst | |
| ----- | | ----- |
| | | |
----------------\ /----------------
\x1 x2/
\ /
\ /
\----------------/
| Server Network |
| Domain |
| |
----------------
---------------- ----------------
| Client Network | | Client Network |
| Domain A | | Domain B |
| | | |
| ----- | | ----- |
| | Src | | | | Dst | |
| ----- | | ----- |
| | | |
----------------\ /----------------
\x1 x2/
\ /
\ /
\----------------/
| Server Network |
| Domain |
| |
----------------
Figure 3: Client-Server Networks
图3：客户机-服务器网络
The second class of use case relating to client-server networking is for Virtual Private Networks (VPNs). In this case, as opposed to the former one, it is assumed that the client network has a different address space than that of the server network, where non-overlapping IP addresses between the client and the server networks cannot be guaranteed. A simple example is shown in Figure 4. The VPN sites comprise a set of domains that are interconnected over a core domain (i.e., the provider network) that is the server network in our model.
与客户机-服务器联网相关的第二类用例用于虚拟专用网络（VPN）。在这种情况下，与前一种情况相反，假设客户机网络具有与服务器网络不同的地址空间，其中无法保证客户机网络和服务器网络之间的IP地址不重叠。图4显示了一个简单的示例。VPN站点由一组通过核心域（即提供商网络）互连的域组成，核心域是我们模型中的服务器网络。
Note that in the use cases shown in Figures 3 and 4 the client network domains may (and, in fact, probably do) operate as a single connected network.
请注意，在图3和图4所示的用例中，客户机网络域可以（事实上，可能确实）作为单个连接的网络运行。
-------------- --------------
| Domain A | | Domain Z |
| (VPN site) | | (VPN site) |
| | | |
| ----- | | ----- |
| | Src | | | | Dst | |
| ----- | | ----- |
| | | |
--------------\ /--------------
\x1 x2/
\ /
\ /
\---------------/
| Core Domain |
| |
| |
/---------------\
/ \
/ \
/x3 x4\
--------------/ \--------------
| Domain B | | Domain C |
| (VPN site) | | (VPN site) |
| | | |
| | | |
-------------- --------------
-------------- --------------
| Domain A | | Domain Z |
| (VPN site) | | (VPN site) |
| | | |
| ----- | | ----- |
| | Src | | | | Dst | |
| ----- | | ----- |
| | | |
--------------\ /--------------
\x1 x2/
\ /
\ /
\---------------/
| Core Domain |
| |
| |
/---------------\
/ \
/ \
/x3 x4\
--------------/ \--------------
| Domain B | | Domain C |
| (VPN site) | | (VPN site) |
| | | |
| | | |
-------------- --------------
Figure 4: A Virtual Private Network
图4：虚拟专用网络
Both use cases in this section become "more interesting" when combined with the use case in Section 2.1 -- that is, when the connectivity between higher-layer domains or VPN sites is provided by a sequence or mesh of lower-layer domains. Figure 5 shows how this might look in the case of a VPN.
当与第2.1节中的用例结合时，本节中的两个用例都变得“更有趣”——也就是说，当高层域或VPN站点之间的连接由底层域的序列或网格提供时。图5显示了在VPN的情况下可能出现的情况。
------------ ------------
| Domain A | | Domain Z |
| (VPN site) | | (VPN site) |
| ----- | | ----- |
| | Src | | | | Dst | |
| ----- | | ----- |
| | | |
------------\ /------------
\x1 x2/
\ /
\ /
\---------- ----------/
| Domain X |x5 | Domain Y |
| (core) +---+ (core) |
| | | |
| +---+ |
| |x6 | |
/---------- ----------\
/ \
/ \
/x3 x4\
------------/ \------------
| Domain B | | Domain C |
| (VPN site) | | (VPN site) |
| | | |
------------ ------------
------------ ------------
| Domain A | | Domain Z |
| (VPN site) | | (VPN site) |
| ----- | | ----- |
| | Src | | | | Dst | |
| ----- | | ----- |
| | | |
------------\ /------------
\x1 x2/
\ /
\ /
\---------- ----------/
| Domain X |x5 | Domain Y |
| (core) +---+ (core) |
| | | |
| +---+ |
| |x6 | |
/---------- ----------\
/ \
/ \
/x3 x4\
------------/ \------------
| Domain B | | Domain C |
| (VPN site) | | (VPN site) |
| | | |
------------ ------------
Figure 5: A VPN Supported over Multiple Server Domains
图5：支持多个服务器域的VPN
A further complication may be added to the client-server relationship described in Section 2.2 by considering what happens when a client network domain is attached to more than one domain in the server network or has two points of attachment to a server network domain. Figure 6 shows an example of this for a VPN.
第2.2节中描述的客户机-服务器关系可能会增加另一个复杂因素，即考虑当一个客户机网络域连接到服务器网络中的多个域或有两个连接点连接到服务器网络域时会发生什么情况。图6显示了VPN的一个示例。
------------
| Domain B |
| (VPN site) |
------------ | ----- |
| Domain A | | | Src | |
| (VPN site) | | ----- |
| | | |
------------\ -+--------+-
\x1 | |
\ x2| |x3
\ | | ------------
\--------+- -+-------- | Domain C |
| Domain X | x8 | Domain Y | x4 | (VPN site) |
| (core) +----+ (core) +----+ ----- |
| | | | | | Dst | |
| +----+ +----+ ----- |
| | x9 | | x5 | |
/---------- ----------\ ------------
/ \
/ \
/x6 x7\
------------/ \------------
| Domain D | | Domain E |
| (VPN site) | | (VPN site) |
| | | |
------------ ------------
------------
| Domain B |
| (VPN site) |
------------ | ----- |
| Domain A | | | Src | |
| (VPN site) | | ----- |
| | | |
------------\ -+--------+-
\x1 | |
\ x2| |x3
\ | | ------------
\--------+- -+-------- | Domain C |
| Domain X | x8 | Domain Y | x4 | (VPN site) |
| (core) +----+ (core) +----+ ----- |
| | | | | | Dst | |
| +----+ +----+ ----- |
| | x9 | | x5 | |
/---------- ----------\ ------------
/ \
/ \
/x6 x7\
------------/ \------------
| Domain D | | Domain E |
| (VPN site) | | (VPN site) |
| | | |
------------ ------------
Figure 6: Dual-Homing in a Virtual Private Network
图6：虚拟专用网络中的双归属
The relationship between domains can be entirely under the control of management processes, dynamically triggered by the client network, or some hybrid of these cases. In the management case, the server network may be asked to establish a set of LSPs to provide client network connectivity. In the dynamic case, the client network may make a request to the server network exerting a range of controls over the paths selected in the server network. This range extends from no control (i.e., a simple request for connectivity), through a
域之间的关系可以完全在管理过程的控制下，由客户端网络动态触发，也可以是这些情况的混合。在管理情况下，可以要求服务器网络建立一组lsp以提供客户端网络连接。在动态情况下，客户端网络可以向服务器网络发出请求，对服务器网络中选择的路径施加一系列控制。该范围从无控制（即简单的连接请求）扩展到
set of constraints (latency, path protection, etc.), up to and including full control of the path and resources used in the server network (i.e., the use of explicit paths with label subobjects).
一组约束（延迟、路径保护等），包括对服务器网络中使用的路径和资源的完全控制（即使用带有标签子对象的显式路径）。
There are various models by which a server network can be asked to set up the connections that support a service provided to the client network. These requests may come from management systems, directly from the client network control plane, or through an intermediary broker such as the Virtual Network Topology Manager (VNTM) [RFC5623].
有各种模型，通过这些模型可以要求服务器网络设置支持向客户机网络提供的服务的连接。这些请求可能来自管理系统，直接来自客户机网络控制平面，或通过中介代理，如虚拟网络拓扑管理器（VNTM）[RFC5623]。
The trigger that causes the request to the server network is also flexible. It could be that the client network discovers a pressing need for server network resources (such as the desire to provision an end-to-end connection in the client network or severe congestion on a specific path), or it might be that a planning application has considered how best to optimize traffic in the client network or how to handle a predicted traffic demand.
向服务器网络发出请求的触发器也是灵活的。可能是客户机网络发现对服务器网络资源的迫切需求（例如希望在客户机网络中提供端到端连接或特定路径上的严重拥塞），或者，规划应用程序可能考虑了如何最好地优化客户端网络中的流量，或者如何处理预测的流量需求。
In all cases, the relationship between client and server networks is subject to policy so that server network resources are under the administrative control of the operator or the server network and are only used to support a client network in ways that the server network operator approves.
在所有情况下，客户机和服务器网络之间的关系都受政策约束，因此服务器网络资源受运营商或服务器网络的管理控制，并且仅用于以服务器网络运营商批准的方式支持客户机网络。
As just noted, connectivity requests issued to a server network may include varying degrees of constraint upon the choice of path that the server network can implement.
正如刚刚指出的，发送到服务器网络的连接性请求可以包括对服务器网络可以实现的路径选择的不同程度的约束。
o "Basic provisioning" is a simple request for connectivity. The only constraints are the end points of the connection and the capacity (bandwidth) that the connection will support for the client network. In the case of some server networks, even the bandwidth component of a basic provisioning request is superfluous because the server network has no facility to vary bandwidth and can offer connectivity only at a default capacity.
o “基本资源调配”是一个简单的连接性请求。唯一的限制是连接的端点以及连接将支持客户端网络的容量（带宽）。在某些服务器网络的情况下，即使是基本配置请求的带宽组件也是多余的，因为服务器网络没有改变带宽的设施，只能以默认容量提供连接。
o "Basic provisioning with optimization" is a service request that indicates one or more metrics that the server network must optimize in its selection of a path. Metrics may be hop count, path length, summed TE metric, jitter, delay, or any number of technology-specific constraints.
o “带优化的基本资源调配”是一个服务请求，指示服务器网络在选择路径时必须优化的一个或多个指标。度量可以是跳数、路径长度、总TE度量、抖动、延迟或任何数量的技术特定约束。
o "Basic provisioning with optimization and constraints" enhances the optimization process to apply absolute constraints to functions of the path metrics. For example, a connection may be requested that optimizes for the shortest path but in any case requests that the end-to-end delay be less than a certain value.
o “带优化和约束的基本资源调配”增强了优化过程，将绝对约束应用于路径度量的功能。例如，可以请求优化最短路径的连接，但在任何情况下都请求端到端延迟小于某个值。
Equally, optimization may be expressed in terms of the impact on the network. For example, a service may be requested in order to leave maximal flexibility to satisfy future service requests.
同样，优化可以用对网络的影响来表示。例如，可以请求服务以留下最大的灵活性来满足未来的服务请求。
o "Fate diversity requests" ask the server network to provide a path that does not use any network resources (usually links and nodes) that share fate (i.e., can fail as the result of a single event) as the resources used by another connection. This allows the client network to construct protection services over the server network -- for example, by establishing links that are known to be fate diverse. The connections that have diverse paths need not share end points.
o “命运多样性请求”要求服务器网络提供一条不使用任何网络资源（通常是链路和节点）的路径，该网络资源共享命运（即，可能因单个事件而失败）作为另一个连接使用的资源。这允许客户端网络在服务器网络上构建保护服务——例如，通过建立已知不同的链路。具有不同路径的连接不需要共享端点。
o "Provisioning with fate sharing" is the exact opposite of fate diversity. In this case, two or more connections are requested to follow the same path in the server network. This may be requested, for example, to create a bundled or aggregated link in the client network where each component of the client-layer composite link is required to have the same server network properties (metrics, delay, etc.) and the same failure characteristics.
o “命运共享供应”与命运多样性正好相反。在这种情况下，请求两个或多个连接在服务器网络中遵循相同的路径。这可以被请求，例如，在客户端网络中创建捆绑或聚合链路，其中客户端层复合链路的每个组件需要具有相同的服务器网络属性（度量、延迟等）和相同的故障特征。
o "Concurrent provisioning" enables the interrelated connection requests described in the previous two bullets to be enacted through a single, compound service request.
o “并发资源调配”使前两个项目中描述的相互关联的连接请求能够通过单个复合服务请求来执行。
o "Service resilience" requests that the server network provide connectivity for which the server network takes responsibility to recover from faults. The resilience may be achieved through the use of link-level protection, segment protection, end-to-end protection, or recovery mechanisms.
o “服务弹性”要求服务器网络提供连接，服务器网络负责从故障中恢复。可通过使用链路级保护、段保护、端到端保护或恢复机制来实现恢复能力。
Although the topology and resource availability information of a server network may be hidden from the client network, the service request interface may support features that report details about the services and potential services that the server network supports.
尽管服务器网络的拓扑和资源可用性信息可能对客户端网络隐藏，但服务请求接口可能支持报告有关服务器网络支持的服务和潜在服务的详细信息的功能。
o Reporting of path details, service parameters, and issues such as path diversity of LSPs that support deployed services allows the client network to understand to what extent its requests were satisfied. This is particularly important when the requests were made as "best effort".
o 报告支持已部署服务的LSP的路径详细信息、服务参数和问题（如路径多样性），使客户端网络能够了解其请求的满足程度。当请求被视为“尽最大努力”时，这一点尤为重要。
o A server network may support requests of the form "If I were to ask you for this service, would you be able to provide it?" -- that is, a service request that does everything except actually provision the service.
o 服务器网络可能支持以下形式的请求：“如果我向您请求此服务，您是否能够提供？”——也就是说，除了实际提供服务之外，服务请求可以执行所有操作。
The problem statement presented in this section is as much about the issues that may arise in any solution (and so have to be avoided) and the features that are desirable within a solution, as it is about the actual problem to be solved.
本节中提出的问题陈述涉及任何解决方案中可能出现的问题（因此必须避免）以及解决方案中所需的功能，正如它涉及要解决的实际问题一样。
The problem can be stated very simply and with reference to the use cases presented in the previous section.
这个问题可以非常简单地描述，并参考上一节中介绍的用例。
A mechanism is required that allows TE path computation in one domain to make informed choices about the TE capabilities and exit points from the domain when signaling an end-to-end TE path that will extend across multiple domains.
需要一种机制，该机制允许一个域中的TE路径计算在发送跨多个域的端到端TE路径信号时，对域中的TE能力和出口点做出明智的选择。
Thus, the problem is one of information collection and presentation, not about signaling. Indeed, the existing signaling mechanisms for TE LSP establishment are likely to prove adequate [RFC4726] with the possibility of minor extensions. Similarly, TE information may currently be distributed in a domain by TE extensions to one of the two IGPs as described in OSPF-TE [RFC3630] and ISIS-TE [RFC5305], and TE information may be exported from a domain (for example, northbound) using link-state extensions to BGP [RFC7752].
因此，问题在于信息的收集和呈现，而不是信号。事实上，用于TE LSP建立的现有信令机制可能证明是足够的[RFC4726]，并且有可能进行较小的扩展。类似地，TE信息当前可通过对OSPF-TE[RFC3630]和ISIS-TE[RFC5305]中所述的两个IGP之一的TE扩展在域中分布，并且TE信息可使用对BGP[RFC7752]的链路状态扩展从域（例如，北行）导出。
An interesting annex to the problem is how the path is made available for use. For example, in the case of a client-server network, the path established in the server network needs to be made available as a TE link to provide connectivity in the client network.
这个问题的一个有趣的附件是如何使路径可用。例如，在客户机-服务器网络的情况下，服务器网络中建立的路径需要作为TE链路提供，以在客户机网络中提供连接性。
A solution must be amenable to the application of policy and filters. That is, the operator of a domain that is sharing information with another domain must be able to apply controls to what information is shared. Furthermore, the operator of a domain that has information shared with it must be able to apply policies and filters to the received information.
解决方案必须适用于策略和过滤器的应用。也就是说，与另一个域共享信息的域的操作员必须能够对共享的信息应用控制。此外，拥有与其共享信息的域的操作员必须能够对接收到的信息应用策略和过滤器。
Additionally, the path computation within a domain must be able to weight the information received from other domains according to local policy such that the resultant computed path meets the local operator's needs and policies rather than those of the operators of other domains.
此外，域内的路径计算必须能够根据本地策略对从其他域接收到的信息进行加权，以便生成的计算路径满足本地操作员的需求和策略，而不是其他域的操作员的需求和策略。
A feature of the policy described in Section 3.1 is that an operator of a domain may desire to keep confidential the details about its internal network topology and loading. This information could be construed as commercially sensitive.
第3.1节所述政策的一个特点是，域的运营商可能希望对其内部网络拓扑和负载的详细信息保密。该信息可能被解释为商业敏感信息。
Although it is possible that TE information exchange will take place only between parties that have significant trust, there are also use cases (such as the VPN supported over multiple server network domains described in Section 2.2) where information will be shared between domains that have a commercial relationship but a low level of trust.
尽管TE信息交换可能仅在具有重要信任的各方之间进行，但也存在一些用例（如第2.2节所述的通过多个服务器网络域支持的VPN），其中信息将在具有商业关系但信任级别较低的域之间共享。
Thus, it must be possible for a domain to limit the shared information to only that which the computing domain needs to know, with the understanding that the less information that is made available the more likely it is that the result will be a less optimal path and/or more crankback events.
因此，域必须能够将共享信息限制为仅计算域需要知道的信息，并且理解，可用信息越少，结果越有可能是不太理想的路径和/或更多的回退事件。
One reason that networks are partitioned into separate domains is to reduce the set of information that any one router has to handle. This also applies to the volume of information that routing protocols have to distribute.
将网络划分为不同域的一个原因是为了减少任何一个路由器必须处理的信息集。这也适用于路由协议必须分发的信息量。
Over the years, routers have become more sophisticated, with greater processing capabilities and more storage; the control channels on which routing messages are exchanged have become higher capacity; and the routing protocols (and their implementations) have become more robust. Thus, some of the arguments in favor of dividing a network into domains may have been reduced. Conversely, however, the size of networks continues to grow dramatically with a consequent increase in the total amount of routing-related information available. Additionally, in this case, the problem space spans two or more networks.
多年来，路由器变得更加复杂，具有更大的处理能力和更多的存储空间；交换路由消息的控制信道的容量变得更大；路由协议（及其实现）变得更加健壮。因此，支持将网络划分为域的一些论点可能已经减少。然而，与此相反，网络的规模继续急剧增长，从而导致可用的路由相关信息总量的增加。此外，在这种情况下，问题空间跨越两个或多个网络。
Any solution to the problems voiced in this document must be aware of the issues of information overload. If the solution was to simply share all TE information between all domains in the network, the effect from the point of view of the information load would be to create one single flat network domain. Thus, the solution must deliver enough information to make the computation practical (i.e., to solve the problem) but not so much as to overload the receiving domain. Furthermore, the solution cannot simply rely on the policies and filters described in Section 3.1 because such filters might not always be enabled.
本文件中提出的任何问题的解决方案都必须意识到信息过载的问题。如果解决方案只是在网络中的所有域之间共享所有TE信息，那么从信息负载的角度来看，效果将是创建一个单一的平面网络域。因此，解决方案必须提供足够的信息使计算实用（即，解决问题），但不至于使接收域过载。此外，解决方案不能简单地依赖于第3.1节中描述的策略和过滤器，因为这些过滤器可能并不总是启用的。
As LSPs are set up and torn down, the available TE resources on links in the network change. In order to reliably compute a TE path through a network, the computation point must have an up-to-date view of the available TE resources. However, collecting this information may result in considerable load on the distribution protocol and churn in the stored information. In order to deal with this problem even in a single domain, updates are sent at periodic intervals or whenever there is a significant change in resources, whichever happens first.
随着LSP的设置和拆除，网络中链路上的可用TE资源将发生变化。为了可靠地计算通过网络的TE路径，计算点必须具有可用TE资源的最新视图。但是，收集这些信息可能会对分发协议造成相当大的负载，并会对存储的信息造成混乱。为了解决这个问题，即使在单个域中，更新也会定期发送，或者在资源发生重大变化时发送，以先发生的为准。
Consider, for example, that a TE LSP may traverse ten links in a network. When the LSP is set up or torn down, the resources available on each link will change, resulting in a new advertisement of the link's capabilities and capacity. If the arrival rate of new LSPs is relatively fast, and the hold times relatively short, the network may be in a constant state of flux. Note that the problem here is not limited to churn within a single domain, since the information shared between domains will also be changing. Furthermore, the information that one domain needs to share with another may change as the result of LSPs that are contained within or cross the first domain but that are of no direct relevance to the domain receiving the TE information.
例如，考虑TE LSP可以遍历网络中的十个链路。当LSP被设置或拆除时，每条链路上的可用资源将发生变化，从而产生链路能力和容量的新广告。如果新LSP的到达率相对较快，且保持时间相对较短，则网络可能处于恒定的流量状态。请注意，这里的问题不仅限于单个域内的搅动，因为域之间共享的信息也将发生变化。此外，一个域需要与另一个域共享的信息可能由于包含在第一域内或跨第一域但与接收TE信息的域没有直接相关性的lsp而改变。
In packet networks, where the capacity of an LSP is often a small fraction of the resources available on any link, this issue is partially addressed by the advertising routers. They can apply a threshold so that they do not bother to update the advertisement of available resources on a link if the change is less than a configured percentage of the total (or, alternatively, the remaining) resources. The updated information in that case will be disseminated based on an update interval rather than a resource change event.
在分组网络中，LSP的容量通常是任何链路上可用资源的一小部分，这个问题部分由广告路由器解决。他们可以应用一个阈值，这样，如果更改小于总资源（或者，剩余资源）的配置百分比，他们就不用费心更新链接上可用资源的公布。在这种情况下，更新的信息将根据更新间隔而不是资源更改事件进行传播。
In non-packet networks, where link resources are physical switching resources (such as timeslots or wavelengths), the capacity of an LSP may more frequently be a significant percentage of the available link resources. Furthermore, in some switching environments, it is necessary to achieve end-to-end resource continuity (such as using the same wavelength on the whole length of an LSP), so it is far more desirable to keep the TE information held at the computation points up to date. Fortunately, non-packet networks tend to be quite a bit smaller than packet networks, the arrival rates of non-packet LSPs are much lower, and the hold times are considerably longer. Thus, the information churn may be sustainable.
在非分组网络中，链路资源是物理交换资源（例如时隙或波长），LSP的容量可能更频繁地是可用链路资源的重要百分比。此外，在一些交换环境中，有必要实现端到端资源连续性（例如在LSP的整个长度上使用相同的波长），因此更希望保持计算点处保持的TE信息是最新的。幸运的是，非分组网络往往比分组网络小得多，非分组LSP的到达率要低得多，保持时间要长得多。因此，信息流失可能是可持续的。
One possible solution to the issues raised in other subsections of this section is to aggregate the TE information shared between domains. Two aggregation mechanisms are often considered:
本节其他小节中提出的问题的一个可能解决方案是聚合域之间共享的TE信息。通常考虑两种聚合机制：
- Virtual node model. In this view, the domain is aggregated as if it was a single node (or router/switch). Its links to other domains are presented as real TE links, but the model assumes that any LSP entering the virtual node through a link can be routed to leave the virtual node through any other link (although recent work on "limited cross-connect switches" may help with this problem [RFC7579]).
- 虚拟节点模型。在此视图中，域被聚合，就像它是单个节点（或路由器/交换机）一样。它与其他域的链接显示为真实的TE链接，但该模型假设通过链接进入虚拟节点的任何LSP都可以路由到通过任何其他链接离开虚拟节点（尽管最近关于“有限交叉连接交换机”的工作可能有助于解决此问题[RFC7579]）。
- Virtual link model. In this model, the domain is reduced to a set of edge-to-edge TE links. Thus, when computing a path for an LSP that crosses the domain, a computation point can see which domain entry points can be connected to which others, and with what TE attributes.
- 虚拟链路模型。在该模型中，域被简化为一组边到边的TE链接。因此，当计算跨越域的LSP的路径时，计算点可以看到哪些域入口点可以连接到哪些其他入口点，以及具有哪些TE属性。
Part of the nature of aggregation is that information is removed from the system. This can cause inaccuracies and failed path computation. For example, in the virtual node model there might not actually be a TE path available between a pair of domain entry points, but the model lacks the sophistication to represent this "limited cross-connect capability" within the virtual node. On the other hand, in the virtual link model it may prove very hard to aggregate multiple link characteristics: for example, there may be one path available with high bandwidth, and another with low delay, but this does not mean that the connectivity should be assumed or advertised as having both high bandwidth and low delay.
聚合的部分性质是从系统中删除信息。这可能会导致不准确和路径计算失败。例如，在虚拟节点模型中，一对域入口点之间实际上可能没有可用的TE路径，但该模型缺乏在虚拟节点内表示这种“有限的交叉连接能力”的复杂性。另一方面，在虚拟链路模型中，可能很难聚合多个链路特性：例如，可能有一条路径具有高带宽，另一条路径具有低延迟，但这并不意味着应假设或宣传连接同时具有高带宽和低延迟。
The trick to this multidimensional problem, therefore, is to aggregate in a way that retains as much useful information as possible while removing the data that is not needed. An important part of this trick is a clear understanding of what information is actually needed.
因此，这个多维问题的诀窍是以一种方式进行聚合，即在删除不需要的数据的同时保留尽可能多的有用信息。这个技巧的一个重要部分是清楚地了解实际需要的信息。
It should also be noted in the context of Section 3.4 that changes in the information within a domain may have a bearing on what aggregated data is shared with another domain. Thus, while the data shared is reduced, the aggregation algorithm (operating on the routers responsible for sharing information) may be heavily exercised.
在第3.4节中还应注意，域内信息的变化可能会影响到与另一个域共享的聚合数据。因此，在减少共享数据的同时，可以大量使用聚合算法（在负责共享信息的路由器上操作）。
As described in Section 1.1, TE reachability is the ability to reach a specific address along a TE path. The knowledge of TE reachability enables an end-to-end TE path to be computed.
如第1.1节所述，TE可达性是指沿着TE路径到达特定地址的能力。TE可达性的知识使得能够计算端到端TE路径。
In a single network, TE reachability is derived from the Traffic Engineering Database (TED), which is the collection of all TE information about all TE links in the network. The TED is usually built from the data exchanged by the IGP, although it can be supplemented by configuration and inventory details, especially in transport networks.
在单个网络中，TE可达性来自交通工程数据库（TED），它是关于网络中所有TE链路的所有TE信息的集合。TED通常是根据IGP交换的数据构建的，尽管它可以通过配置和库存细节进行补充，尤其是在运输网络中。
In multi-network scenarios, TE reachability information can be described as "You can get from node X to node Y with the following TE attributes." For transit cases, nodes X and Y will be edge nodes of the transit network, but it is also important to consider the information about the TE connectivity between an edge node and a specific destination node. TE reachability may be qualified by TE attributes such as TE metrics, hop count, available bandwidth, delay, and shared risk.
在多网络场景中，TE可达性信息可以描述为“您可以通过以下TE属性从节点X到节点Y”。对于公交案例，节点X和Y将是公交网络的边缘节点，但是重要的是考虑关于边缘节点和特定目的节点之间的TE连通性的信息。TE可达性可以通过TE属性进行限定，如TE度量、跳数、可用带宽、延迟和共享风险。
TE reachability information can be exchanged between networks so that nodes in one network can determine whether they can establish TE paths across or into another network. Such exchanges are subject to a range of policies imposed by the advertiser (for security and administrative control) and by the receiver (for scalability and stability).
TE可达性信息可以在网络之间交换，以便一个网络中的节点可以确定它们是否可以跨另一个网络或进入另一个网络建立TE路径。此类交换受广告商（出于安全和管理控制）和接收方（出于可扩展性和稳定性）实施的一系列政策的约束。
Aggregation is the process of synthesizing from available information. Thus, the virtual node and virtual link models described in Section 3.5 rely on processing the information available within a network to produce the aggregate representations of links and nodes that are presented to the consumer. As described in Section 3, dynamic aggregation is subject to a number of pitfalls.
聚合是根据可用信息进行合成的过程。因此，第3.5节中描述的虚拟节点和虚拟链路模型依赖于处理网络中可用的信息，以产生呈现给消费者的链路和节点的聚合表示。如第3节所述，动态聚合存在许多缺陷。
In order to distinguish the architecture described in this document from the previous work on aggregation, we use the term "abstraction" in this document. The process of abstraction is one of applying policy to the available TE information within a domain, to produce selective information that represents the potential ability to connect across the domain.
为了将本文档中描述的体系结构与以前关于聚合的工作区分开来，我们在本文档中使用术语“抽象”。抽象的过程是将策略应用于域内的可用TE信息，以生成表示跨域连接的潜在能力的选择性信息。
Abstraction does not offer all possible connectivity options (refer to Section 3.5) but does present a general view of potential connectivity. Abstraction may have a dynamic element but is not intended to keep pace with the changes in TE attribute availability within the network.
抽象并没有提供所有可能的连接选项（参考第3.5节），但提供了潜在连接的一般视图。抽象可能有一个动态元素，但并不打算跟上网络中TE属性可用性的变化。
Thus, when relying on an abstraction to compute an end-to-end path, the process might not deliver a usable path. That is, there is no actual guarantee that the abstractions are current or feasible.
因此，当依赖抽象来计算端到端路径时，流程可能无法提供可用路径。也就是说，没有实际保证抽象是当前的或可行的。
Although abstraction uses available TE information, it is subject to policy and management choices. Thus, not all potential connectivity will be advertised to each client network. The filters may depend on commercial relationships, the risk of disclosing confidential information, and concerns about what use is made of the connectivity that is offered.
虽然抽象使用可用的TE信息，但它受制于策略和管理选择。因此，并非所有潜在的连接都将公布到每个客户端网络。过滤器可能取决于商业关系、泄露机密信息的风险以及对所提供连接的用途的担忧。
An abstract link is a measure of the potential to connect a pair of points with certain TE parameters. That is, it is a path and its characteristics in the server network. An abstract link represents the possibility of setting up an LSP, and LSPs may be set up over the abstract link.
抽象链接是对连接具有特定TE参数的一对点的电位的度量。也就是说，它是服务器网络中的一条路径及其特征。抽象链接表示建立LSP的可能性，LSP可以通过抽象链接建立。
When looking at a network such as the network shown in Figure 7, the link from CN1 to CN4 may be an abstract link. It is easy to advertise it as a link by abstracting the TE information in the server network, subject to policy.
当查看如图7所示的网络时，从CN1到CN4的链路可能是抽象链路。根据策略，通过抽象服务器网络中的TE信息，很容易将其作为链接进行宣传。
The path (i.e., the abstract link) represents the possibility of establishing an LSP from client network edge to client network edge across the server network. There is not necessarily a one-to-one relationship between the abstract link and the LSP, because more than one LSP could be set up over the path.
路径（即，抽象链接）表示在服务器网络上从客户端网络边缘到客户端网络边缘建立LSP的可能性。抽象链接和LSP之间不一定存在一对一的关系，因为可以在路径上设置多个LSP。
Since the client network nodes do not have visibility into the server network, they must rely on abstraction information delivered to them by the server network. That is, the server network will report on the potential for connectivity.
由于客户机网络节点对服务器网络没有可见性，因此它们必须依赖于服务器网络提供给它们的抽象信息。也就是说，服务器网络将报告连接的可能性。
Figure 7 introduces the abstraction layer network. This construct separates the client network resources (nodes C1, C2, C3, and C4, and the corresponding links) and the server network resources (nodes CN1, CN2, CN3, and CN4, and the corresponding links). Additionally, the architecture introduces an intermediary network layer called the
图7介绍了抽象层网络。此构造将客户端网络资源（节点C1、C2、C3和C4，以及相应的链路）和服务器网络资源（节点CN1、CN2、CN3和CN4，以及相应的链路）分开。此外，该体系结构还引入了一个称为
abstraction layer. The abstraction layer contains the client network edge nodes (C2 and C3), the server network edge nodes (CN1 and CN4), the client-server links (C2-CN1 and CN4-C3), and the abstract link (CN1-CN4).
抽象层。抽象层包含客户端网络边缘节点（C2和C3）、服务器网络边缘节点（CN1和CN4）、客户端-服务器链路（C2-CN1和CN4-C3）和抽象链路（CN1-CN4）。
The client network is able to operate as normal. Connectivity across the network can be either found or not found, based on links that appear in the client network TED. If connectivity cannot be found, end-to-end LSPs cannot be set up. This failure may be reported, but no dynamic action is taken by the client network.
客户端网络能够正常运行。根据客户端网络中出现的链接，可以找到网络连接，也可以找不到网络连接。如果找不到连接，则无法设置端到端LSP。可能会报告此故障，但客户端网络不会采取动态操作。
The server network also operates as normal. LSPs across the server network between client network edges are set up in response to management commands or in response to signaling requests.
服务器网络也正常运行。通过服务器网络在客户端网络边缘之间建立LSP，以响应管理命令或信令请求。
The abstraction layer consists of the physical links between the two networks, and also the abstract links. The abstract links are created by the server network according to local policy and represent the potential connectivity that could be created across the server network and that the server network is willing to make available for use by the client network. Thus, in this example, the diameter of the abstraction layer network is only three hops, but an instance of an IGP could easily be run so that all nodes participating in the abstraction layer (and, in particular, the client network edge nodes) can see the TE connectivity in the layer.
抽象层由两个网络之间的物理链路以及抽象链路组成。抽象链接由服务器网络根据本地策略创建，表示可以在服务器网络上创建的潜在连接，以及服务器网络愿意提供给客户端网络使用的连接。因此，在此示例中，抽象层网络的直径仅为三个跃点，但IGP的实例可以容易地运行，以便参与抽象层的所有节点（尤其是客户端网络边缘节点）都可以看到该层中的TE连接性。
-- -- -- --
|C1|--|C2| |C3|--|C4| Client Network
-- | | | | --
| | | | . . . . . . . . . . .
| | | |
| | | |
| | --- --- | | Abstraction
| |---|CN1|================|CN4|---| | Layer Network
-- | | | | --
| | | | . . . . . . . . . . . . . .
| | | |
| | | |
| | --- --- | | Server Network
| |--|CN2|--|CN3|--| |
--- --- --- ---
-- -- -- --
|C1|--|C2| |C3|--|C4| Client Network
-- | | | | --
| | | | . . . . . . . . . . .
| | | |
| | | |
| | --- --- | | Abstraction
| |---|CN1|================|CN4|---| | Layer Network
-- | | | | --
| | | | . . . . . . . . . . . . . .
| | | |
| | | |
| | --- --- | | Server Network
| |--|CN2|--|CN3|--| |
--- --- --- ---
Key
--- Direct connection between two nodes
=== Abstract link
Key
--- Direct connection between two nodes
=== Abstract link
Figure 7: Architecture for Abstraction Layer Network
图7：抽象层网络的体系结构
When the client network needs additional connectivity, it can make a request to the abstraction layer network. For example, the operator of the client network may want to create a link from C2 to C3. The abstraction layer can see the potential path C2-CN1-CN4-C3 and can set up an LSP C2-CN1-CN4-C3 across the server network and make the LSP available as a link in the client network.
当客户端网络需要额外的连接时，它可以向抽象层网络发出请求。例如，客户端网络的运营商可能希望创建从C2到C3的链路。抽象层可以看到潜在路径C2-CN1-CN4-C3，并且可以在服务器网络上建立LSP C2-CN1-CN4-C3，并使LSP作为客户端网络中的链路可用。
Sections 4.2.3 and 4.2.4 show how this model is used to satisfy the requirements for connectivity in client-server networks and in peer networks.
第4.2.3节和第4.2.4节说明了如何使用该模型来满足客户机-服务器网络和对等网络中的连接性要求。
Figure 7 shows a very simplified network diagram, and the reader would be forgiven for thinking that only client network edge nodes and server network edge nodes may appear in the abstraction layer network. But this is not the case: other nodes from the server network may be present. This allows the abstraction layer network to be more complex than a full mesh with access spokes.
图7显示了一个非常简化的网络图，如果读者认为抽象层网络中只会出现客户机网络边缘节点和服务器网络边缘节点，那是情有可原的。但事实并非如此：可能存在来自服务器网络的其他节点。这使得抽象层网络比具有访问辐条的完整网格更复杂。
Thus, as shown in Figure 8, a transit node in the server network (here, the node is CN3) can be exposed as a node in the abstraction layer network with abstract links connecting it to other nodes in the abstraction layer network. Of course, in the network shown in Figure 8, there is little if any value in exposing CN3, but if it had other abstract links to other nodes in the abstraction layer network and/or direct connections to client network nodes, then the resulting network would be richer.
因此，如图8所示，服务器网络中的传输节点（这里，节点是CN3）可以公开为抽象层网络中的节点，抽象链路将其连接到抽象层网络中的其他节点。当然，在图8所示的网络中，公开CN3几乎没有任何价值，但是如果它具有到抽象层网络中其他节点的其他抽象链接和/或到客户机网络节点的直接连接，那么生成的网络将更加丰富。
-- -- -- -- Client
|C1|--|C2| |C3|--|C4| Network
-- | | | | --
| | | | . . . . . . . . .
| | | |
| | | |
| | --- --- --- | | Abstraction
| |--|CN1|========|CN3|========|CN5|--| | Layer Network
-- | | | | | | --
| | | | | | . . . . . . . . . . . .
| | | | | |
| | | | | | Server
| | --- | | --- | | Network
| |--|CN2|-| |-|CN4|--| |
--- --- --- --- ---
-- -- -- -- Client
|C1|--|C2| |C3|--|C4| Network
-- | | | | --
| | | | . . . . . . . . .
| | | |
| | | |
| | --- --- --- | | Abstraction
| |--|CN1|========|CN3|========|CN5|--| | Layer Network
-- | | | | | | --
| | | | | | . . . . . . . . . . . .
| | | | | |
| | | | | | Server
| | --- | | --- | | Network
| |--|CN2|-| |-|CN4|--| |
--- --- --- --- ---
Figure 8: Abstraction Layer Network with Additional Node
图8：具有附加节点的抽象层网络
It should be noted that the nodes included in the abstraction layer network in this way are not "abstract nodes" in the sense of a virtual node described in Section 3.5. Although it is the case that the policy point responsible for advertising server network resources into the abstraction layer network could choose to advertise abstract nodes in place of real physical nodes, it is believed that doing so would introduce significant complexity in terms of:
应注意，以这种方式包含在抽象层网络中的节点不是第3.5节中描述的虚拟节点意义上的“抽象节点”。尽管在这种情况下，负责向抽象层网络中发布服务器网络资源的策略点可以选择发布抽象节点来代替真实的物理节点，但相信这样做将在以下方面引入显著的复杂性：
- Coordination between all of the external interfaces of the abstract node.
- 抽象节点的所有外部接口之间的协调。
- Management of changes in the server network that lead to limited capabilities to reach (cross-connect) across the abstract node. There has been recent work on control-plane extensions to describe and operate devices (such as asymmetrical switches) that have limited cross-connect capabilities [RFC7579] [RFC7580]. These or similar extensions could be used to represent the same type of limitations, as they also apply in an abstract node.
- 管理服务器网络中导致跨抽象节点访问（交叉连接）能力有限的更改。最近有一项关于控制平面扩展的工作，用于描述和操作交叉连接能力有限的设备（如不对称开关）[RFC7579][RFC7580]。这些或类似的扩展可以用来表示相同类型的限制，因为它们也适用于抽象节点。
Figure 9 shows the basic architectural concepts for a client-server network. The nodes in the client network are C1, C2, CE1, CE2, C3, and C4, where the client edge (CE) nodes are CE1 and CE2. The core (server) network nodes are CN1, CN2, CN3, and CN4. The interfaces CE1-CN1 and CE2-CN4 are the interfaces between the client and server networks.
图9显示了客户机-服务器网络的基本架构概念。客户端网络中的节点是C1、C2、CE1、CE2、C3和C4，其中客户端边缘（CE）节点是CE1和CE2。核心（服务器）网络节点为CN1、CN2、CN3和CN4。接口CE1-CN1和CE2-CN4是客户端和服务器网络之间的接口。
The technologies (switching capabilities) of the client and server networks may be the same or different. If they are different, the client network traffic must be tunneled over a server network LSP. If they are the same, the client network LSP may be routed over the server network links, tunneled over a server network LSP, or constructed from the concatenation (stitching) of client network and server network LSP segments.
客户机和服务器网络的技术（交换能力）可能相同，也可能不同。如果它们不同，则客户端网络流量必须通过服务器网络LSP进行隧道传输。如果它们相同，则客户机网络LSP可以通过服务器网络链路路由，通过服务器网络LSP隧道，或者从客户机网络和服务器网络LSP段的串联（缝合）构造。
: :
Client Network : Server Network : Client Network
: :
-- -- --- --- -- --
|C1|--|C2|--|CE1|................................|CE2|--|C3|--|C4|
-- -- | | --- --- | | -- --
| |===|CN1|================|CN4|===| |
| |---| | | |---| |
--- | | --- --- | | ---
| |--|CN2|--|CN3|--| |
--- --- --- ---
: :
Client Network : Server Network : Client Network
: :
-- -- --- --- -- --
|C1|--|C2|--|CE1|................................|CE2|--|C3|--|C4|
-- -- | | --- --- | | -- --
| |===|CN1|================|CN4|===| |
| |---| | | |---| |
--- | | --- --- | | ---
| |--|CN2|--|CN3|--| |
--- --- --- ---
Key
--- Direct connection between two nodes
... CE-to-CE LSP tunnel
=== Potential path across the server network (abstract link)
Key
--- Direct connection between two nodes
... CE-to-CE LSP tunnel
=== Potential path across the server network (abstract link)
Figure 9: Architecture for Client-Server Network
图9：客户机-服务器网络的体系结构
The objective is to be able to support an end-to-end connection, C1-to-C4, in the client network. This connection may support TE or normal IP forwarding. To achieve this, CE1 is to be connected to CE2 by a link in the client network. This enables the client network to view itself as connected and to select an end-to-end path.
目标是能够支持客户端网络中的端到端连接（C1到C4）。此连接可能支持TE或正常IP转发。为此，CE1通过客户端网络中的链路连接到CE2。这使客户端网络能够将自身视为已连接，并选择端到端路径。
As shown in the figure, three abstraction layer links are formed: CE1-CN1, CN1-CN2, and CN4-CE2. A three-hop LSP is then established from CE1 to CE2 that can be presented as a link in the client network.
如图所示，形成了三个抽象层链接：CE1-CN1、CN1-CN2和CN4-CE2。然后建立从CE1到CE2的三跳LSP，该LSP可以在客户端网络中呈现为链路。
The practicalities of how the CE1-CE2 LSP is carried across the server network LSP may depend on the switching and signaling options available in the server network. The CE1-CE2 LSP may be tunneled down the server network LSP using the mechanisms of a hierarchical LSP [RFC4206], or the LSP segments CE1-CN1 and CN4-CE2 may be stitched to the server network LSP as described in [RFC5150].
CE1-CE2 LSP如何在服务器网络LSP上传送的实用性可能取决于服务器网络中可用的交换和信令选项。CE1-CE2 LSP可以使用分层LSP[RFC4206]的机制沿服务器网络LSP向下隧道传输，或者LSP段CE1-CN1和CN4-CE2可以按照[RFC5150]中的描述缝合到服务器网络LSP。
Section 4.2.2 has already introduced the concept of the abstraction layer network through an example of a simple layered network. But it may be helpful to expand on the example using a slightly more complex network.
第4.2.2节已经通过简单分层网络的示例介绍了抽象层网络的概念。但是，使用稍微复杂一点的网络来扩展示例可能会有所帮助。
Figure 10 shows a multi-layer network comprising client network nodes (labeled as Cn for n = 0 to 9) and server network nodes (labeled as Sn for n = 1 to 9).
图10显示了一个由客户端网络节点（标记为Cn表示n=0到9）和服务器网络节点（标记为Sn表示n=1到9）组成的多层网络。
-- --
|C3|---|C4|
/-- --\
-- -- -- -- --/ \--
|C1|---|C2|---|S1|---|S2|----|S3| |C5|
-- /-- --\ --\ --\ /--
/ \-- \-- \-- --/ --
/ |S4| |S5|----|S6|---|C6|---|C7|
/ /-- --\ /-- /-- --
--/ -- --/ -- \--/ --/
|C8|---|C9|---|S7|---|S8|----|S9|---|C0|
-- -- -- -- -- --
-- --
|C3|---|C4|
/-- --\
-- -- -- -- --/ \--
|C1|---|C2|---|S1|---|S2|----|S3| |C5|
-- /-- --\ --\ --\ /--
/ \-- \-- \-- --/ --
/ |S4| |S5|----|S6|---|C6|---|C7|
/ /-- --\ /-- /-- --
--/ -- --/ -- \--/ --/
|C8|---|C9|---|S7|---|S8|----|S9|---|C0|
-- -- -- -- -- --
Figure 10: An Example Multi-Layer Network
图10：多层网络示例
If the network in Figure 10 is operated as separate client and server networks, then the client network topology will appear as shown in Figure 11. As can be clearly seen, the network is partitioned, and there is no way to set up an LSP from a node on the left-hand side (say C1) to a node on the right-hand side (say C7).
如果图10中的网络作为独立的客户机和服务器网络运行，那么客户机网络拓扑将如图11所示。可以清楚地看到，网络是分区的，并且无法设置从左侧节点（比如C1）到右侧节点（比如C7）的LSP。
-- --
|C3|---|C4|
-- --\
-- -- \--
|C1|---|C2| |C5|
-- /-- /--
/ --/ --
/ |C6|---|C7|
/ /-- --
--/ -- --/
|C8|---|C9| |C0|
-- -- --
-- --
|C3|---|C4|
-- --\
-- -- \--
|C1|---|C2| |C5|
-- /-- /--
/ --/ --
/ |C6|---|C7|
/ /-- --
--/ -- --/
|C8|---|C9| |C0|
-- -- --
Figure 11: Client Network Topology Showing Partitioned Network
图11：显示分区网络的客户端网络拓扑
For reference, Figure 12 shows the corresponding server network topology.
为了便于参考，图12显示了相应的服务器网络拓扑。
-- -- --
|S1|---|S2|----|S3|
--\ --\ --\
\-- \-- \--
|S4| |S5|----|S6|
/-- --\ /--
--/ -- \--/
|S7|---|S8|----|S9|
-- -- --
-- -- --
|S1|---|S2|----|S3|
--\ --\ --\
\-- \-- \--
|S4| |S5|----|S6|
/-- --\ /--
--/ -- \--/
|S7|---|S8|----|S9|
-- -- --
Figure 12: Server Network Topology
图12：服务器网络拓扑
Operating on the TED for the server network, a management entity or a software component may apply policy and consider what abstract links it might offer for use by the client network. To do this, it obviously needs to be aware of the connections between the layers (there is no point in offering an abstract link S2-S8, since this could not be of any use in this example).
在TED为服务器网络运行时，管理实体或软件组件可以应用策略，并考虑它可能提供什么抽象的链路供客户端网络使用。要做到这一点，它显然需要知道层之间的连接（提供抽象链接S2-S8没有意义，因为这在本示例中没有任何用处）。
In our example, after consideration of which LSPs could be set up in the server network, four abstract links are offered: S1-S3, S3-S6, S1-S9, and S7-S9. These abstract links are shown as double lines on the resulting topology of the abstraction layer network in Figure 13. As can be seen, two of the links must share part of a path (S1-S9 must share with either S1-S3 or S7-S9). This could be achieved using distinct resources (for example, separate lambdas) where the paths are common, but it could also be done using resource sharing.
在我们的示例中，在考虑了可以在服务器网络中设置哪些LSP之后，提供了四个抽象链接：S1-S3、S3-S6、S1-S9和S7-S9。这些抽象链接在图13中抽象层网络的最终拓扑上显示为双线。可以看出，两个链路必须共享路径的一部分（S1-S9必须与S1-S3或S7-S9共享）。这可以通过使用不同的资源（例如，单独的lambda）来实现，其中路径是公共的，但也可以通过资源共享来实现。
--
|C3|
/--
-- -- --/
|C2|---|S1|==========|S3|
-- --\\ --\\
\\ \\
\\ \\-- --
\\ |S6|---|C6|
\\ -- --
-- -- \\-- --
|C9|---|S7|=====|S9|---|C0|
-- -- -- --
--
|C3|
/--
-- -- --/
|C2|---|S1|==========|S3|
-- --\\ --\\
\\ \\
\\ \\-- --
\\ |S6|---|C6|
\\ -- --
-- -- \\-- --
|C9|---|S7|=====|S9|---|C0|
-- -- -- --
Figure 13: Abstraction Layer Network with Abstract Links
图13：具有抽象链接的抽象层网络
That would mean that when both paths S1-S3 and S7-S9 carry client-edge-to-client-edge LSPs, the resources on path S1-S9 are used and might be depleted to the point that the path is resource constrained and cannot be used.
这将意味着，当路径S1-S3和S7-S9都携带客户端边缘到客户端边缘lsp时，使用路径S1-S9上的资源，并且可能耗尽到该路径资源受限且无法使用的程度。
The separate IGP instance running in the abstraction layer network means that this topology is visible at the edge nodes (C2, C3, C6, C9, and C0) as well as at a Path Computation Element (PCE) if one is present.
在抽象层网络中运行的独立IGP实例意味着该拓扑在边缘节点（C2、C3、C6、C9和C0）以及路径计算元素（PCE）（如果存在）处可见。
Now the client network is able to make requests to the abstraction layer network to provide connectivity. In our example, it requests that C2 be connected to C3 and that C2 be connected to C0. This results in several actions:
现在，客户机网络能够向抽象层网络发出请求以提供连接。在我们的示例中，它要求C2连接到C3，C2连接到C0。这导致了几个行动：
1. The management component for the abstraction layer network asks its PCE to compute the paths necessary to make the connections. This yields C2-S1-S3-C3 and C2-S1-S9-C0.
1. 抽象层网络的管理组件要求其PCE计算建立连接所需的路径。这将产生C2-S1-S3-C3和C2-S1-S9-C0。
2. The management component for the abstraction layer network instructs C2 to start the signaling process for the new LSPs in the abstraction layer.
2. 抽象层网络的管理组件指示C2启动抽象层中新LSP的信令过程。
3. C2 signals the LSPs for setup using the explicit routes C2-S1-S3-C3 and C2-S1-S9-C0.
3. C2使用显式路由C2-S1-S3-C3和C2-S1-S9-C0向LSP发送设置信号。
4. When the signaling messages reach S1 (in our example, both LSPs traverse S1), the server network may support them by a number of means, including establishing server network LSPs as tunnels, depending on the mismatch of technologies between the client and server networks. For example, S1-S2-S3 and S1-S2-S5-S9 might be traversed via an LSP tunnel, using LSPs stitched together, or simply by routing the client network LSP through the server network. If server network LSPs are needed, they can be signaled at this point.
4. 当信令消息到达S1（在我们的示例中，两个lsp都穿过S1）时，服务器网络可以通过多种方式支持它们，包括将服务器网络lsp建立为隧道，这取决于客户端和服务器网络之间的技术不匹配。例如，S1-S2-S3和S1-S2-S5-S9可以使用缝合在一起的LSP经由LSP隧道穿越，或者简单地通过服务器网络路由客户端网络LSP。如果需要服务器网络LSP，可以在此时发出信号。
5. Once any server network LSPs that are needed have been established, S1 can continue to signal the client-edge-to-client-edge LSP across the abstraction layer, using the server network LSPs as either tunnels or stitching segments, or simply routing through the server network.
5. 一旦建立了所需的任何服务器网络LSP，S1就可以继续通过抽象层向客户机边缘到客户机边缘LSP发送信号，使用服务器网络LSP作为隧道或缝合段，或者简单地通过服务器网络路由。
6. Finally, once the client-edge-to-client-edge LSPs have been set up, the client network can be informed and can start to advertise the new TE links C2-C3 and C2-C0. The resulting client network topology is shown in Figure 14.
6. 最后，一旦建立了客户机边缘到客户机边缘lsp，就可以通知客户机网络并开始公布新的TE链路C2-C3和C2-C0。产生的客户端网络拓扑如图14所示。
-- --
|C3|-|C4|
/-- --\
/ \--
-- --/ |C5|
|C1|---|C2| /--
-- /--\ --/ --
/ \ |C6|---|C7|
/ \ /-- --
/ \--/
--/ -- |C0|
|C8|---|C9| --
-- --
-- --
|C3|-|C4|
/-- --\
/ \--
-- --/ |C5|
|C1|---|C2| /--
-- /--\ --/ --
/ \ |C6|---|C7|
/ \ /-- --
/ \--/
--/ -- |C0|
|C8|---|C9| --
-- --
Figure 14: Connected Client Network with Additional Links
图14：具有附加链接的已连接客户端网络
7. Now the client network can compute an end-to-end path from C1 to C7.
7. 现在，客户端网络可以计算从C1到C7的端到端路径。
A single server network may support multiple client networks. This is not an uncommon state of affairs -- for example, when the server network provides connectivity for multiple customers.
单个服务器网络可以支持多个客户端网络。这种情况并不少见——例如，当服务器网络为多个客户提供连接时。
In this case, the abstraction provided by the server network may vary considerably according to the policies and commercial relationships with each customer. This variance would lead to a separate abstraction layer network maintained to support each client network.
在这种情况下，服务器网络提供的抽象可能会根据策略和与每个客户的商业关系而有很大的不同。这种差异将导致维护一个独立的抽象层网络来支持每个客户机网络。
On the other hand, it may be that multiple client networks are subject to the same policies and the abstraction can be identical. In this case, a single abstraction layer network can support more than one client.
另一方面，可能是多个客户端网络受相同策略的约束，并且抽象可以是相同的。在这种情况下，单个抽象层网络可以支持多个客户机。
The choices here are made as an operational issue by the server network.
此处的选择由服务器网络作为操作问题进行。
A single client network may be supported by multiple server networks. The server networks may provide connectivity between different parts of the client network or may provide parallel (redundant) connectivity for the client network.
多个服务器网络可能支持单个客户端网络。服务器网络可以提供客户端网络的不同部分之间的连接，或者可以为客户端网络提供并行（冗余）连接。
In this case, the abstraction layer network should contain the abstract links from all server networks so that it can make suitable computations and create the correct TE links in the client network.
在这种情况下，抽象层网络应该包含来自所有服务器网络的抽象链路，以便能够进行适当的计算并在客户端网络中创建正确的TE链路。
That is, the relationship between the client network and the abstraction layer network should be one to one.
也就是说，客户机网络和抽象层网络之间的关系应该是一对一的。
Figure 15 shows the basic architectural concepts for connecting across peer networks. Nodes from four networks are shown: A1 and A2 come from one network; B1, B2, and B3 from another network; etc. The interfaces between the networks (sometimes known as External Network Network Interfaces - ENNIs) are A2-B1, B3-C1, and C3-D1.
图15显示了跨对等网络连接的基本架构概念。四个网络的节点如图所示：A1和A2来自一个网络；来自另一个网络的B1、B2和B3；网络之间的接口（有时称为外部网络接口-ENNIs）为A2-B1、B3-C1和C3-D1。
The objective is to be able to support an end-to-end connection, A1-to-D2. This connection is for TE connectivity.
目标是能够支持端到端连接，A1到D2。此连接用于TE连接。
As shown in the figure, abstract links that span the transit networks are used to achieve the required connectivity. These links form the key building blocks of the end-to-end connectivity. An end-to-end LSP uses these links as part of its path. If the stitching capabilities of the networks are homogeneous, then the end-to-end LSP may simply traverse the path defined by the abstract links across the various peer networks or may utilize stitching of LSP segments that each traverse a network along the path of an abstract link. If the network switching technologies support or necessitate the use of LSP hierarchies, the end-to-end LSP may be tunneled across each network using hierarchical LSPs that each traverse a network along the path of an abstract link.
如图所示，跨越公交网络的抽象链路用于实现所需的连接。这些链接构成了端到端连接的关键构建块。端到端LSP使用这些链接作为其路径的一部分。如果网络的缝合能力是同质的，则端到端LSP可以简单地穿过由各种对等网络的抽象链路定义的路径，或者可以利用LSP段的缝合，每个LSP段沿着抽象链路的路径穿过网络。如果网络交换技术支持或需要使用LSP层次结构，则可以使用层次LSP在每个网络上隧道化端到端LSP，每个层次LSP沿着抽象链路的路径穿越网络。
: : :
Network A : Network B : Network C : Network D
: : :
-- -- -- -- -- -- -- -- -- --
|A1|--|A2|---|B1|--|B2|--|B3|---|C1|--|C2|--|C3|---|D1|--|D2|
-- -- | | -- | | | | -- | | -- --
| |========| | | |========| |
-- -- -- --
: : :
Network A : Network B : Network C : Network D
: : :
-- -- -- -- -- -- -- -- -- --
|A1|--|A2|---|B1|--|B2|--|B3|---|C1|--|C2|--|C3|---|D1|--|D2|
-- -- | | -- | | | | -- | | -- --
| |========| | | |========| |
-- -- -- --
Key
--- Direct connection between two nodes
=== Abstract link across transit network
Key
--- Direct connection between two nodes
=== Abstract link across transit network
Figure 15: Architecture for Peering
图15：对等的体系结构
Peer networks exist in many situations in the Internet. Packet networks may peer as IGP areas (levels) or as ASes. Transport networks (such as optical networks) may peer to provide concatenations of optical paths through single-vendor environments (see Section 6). Figure 16 shows a simple example of three peer networks (A, B, and C) each comprising a few nodes.
对等网络在互联网的许多情况下都存在。分组网络可以作为IGP区域（级别）或as对等。传输网络（如光网络）可以对等地通过单个供应商环境提供光路径的连接（见第6节）。图16显示了三个对等网络（a、B和C）的简单示例，每个对等网络包含几个节点。
Network A : Network B : Network C
: :
-- -- -- : -- -- -- : -- --
|A1|---|A2|----|A3|---|B1|---|B2|---|B3|---|C1|---|C2|
-- --\ /-- : -- /--\ -- : -- --
\--/ : / \ :
|A4| : / \ :
--\ : / \ :
-- \-- : --/ \-- : -- --
|A5|---|A6|---|B4|----------|B6|---|C3|---|C4|
-- -- : -- -- : -- --
: :
: :
Network A : Network B : Network C
: :
-- -- -- : -- -- -- : -- --
|A1|---|A2|----|A3|---|B1|---|B2|---|B3|---|C1|---|C2|
-- --\ /-- : -- /--\ -- : -- --
\--/ : / \ :
|A4| : / \ :
--\ : / \ :
-- \-- : --/ \-- : -- --
|A5|---|A6|---|B4|----------|B6|---|C3|---|C4|
-- -- : -- -- : -- --
: :
: :
Figure 16: A Network Comprising Three Peer Networks
图16：由三个对等网络组成的网络
As discussed in Section 2, peered networks do not share visibility of their topologies or TE capabilities for scaling and confidentiality reasons. That means, in our example, that computing a path from A1 to C4 can be impossible without the aid of cooperating PCEs or some form of crankback.
如第2节所述，对等网络由于可扩展性和保密性的原因，不共享其拓扑或TE功能的可见性。这意味着，在我们的示例中，如果没有协作PCE或某种形式的回退的帮助，计算从A1到C4的路径是不可能的。
But it is possible to produce abstract links for reachability across transit peer networks and to create an abstraction layer network. That network can be enhanced with specific reachability information if a destination network is partitioned, as is the case with Network C in Figure 16.
但是，有可能生成抽象链路，以实现跨传输对等网络的可达性，并创建一个抽象层网络。如果对目标网络进行分区，则可以使用特定的可达性信息增强该网络，如图16中的网络C所示。
Suppose that Network B decides to offer three abstract links B1-B3, B4-B3, and B4-B6. The abstraction layer network could then be constructed to look like the network in Figure 17.
假设网络B决定提供三个抽象链路B1-B3、B4-B3和B4-B6。然后可以将抽象层网络构造成图17中的网络。
-- -- -- --
|A3|---|B1|====|B3|----|C1|
-- -- //-- --
//
//
//
-- --// -- --
|A6|---|B4|=====|B6|---|C3|
-- -- -- --
-- -- -- --
|A3|---|B1|====|B3|----|C1|
-- -- //-- --
//
//
//
-- --// -- --
|A6|---|B4|=====|B6|---|C3|
-- -- -- --
Figure 17: Abstraction Layer Network for the Peer Network Example
图17：对等网络示例的抽象层网络
Using a process similar to that described in Section 4.2.3, Network A can request connectivity to Network C, and abstract links can be advertised that connect the edges of the two networks and that can be used to carry LSPs that traverse both networks. Furthermore, if
使用类似于第4.2.3节所述的过程，网络a可以请求连接到网络C，并且可以公布连接两个网络边缘的抽象链路，该抽象链路可用于承载穿越两个网络的LSP。此外，如果
Network C is partitioned, reachability information can be exchanged to allow Network A to select the correct abstract link, as shown in Figure 18.
网络C是分区的，可以交换可达性信息以允许网络A选择正确的抽象链路，如图18所示。
Network A : Network C
:
-- -- -- : -- --
|A1|---|A2|----|A3|=========|C1|.....|C2|
-- --\ /-- : -- --
\--/ :
|A4| :
--\ :
-- \-- : -- --
|A5|---|A6|=========|C3|.....|C4|
-- -- : -- --
Network A : Network C
:
-- -- -- : -- --
|A1|---|A2|----|A3|=========|C1|.....|C2|
-- --\ /-- : -- --
\--/ :
|A4| :
--\ :
-- \-- : -- --
|A5|---|A6|=========|C3|.....|C4|
-- -- : -- --
Figure 18: Tunnel Connections to Network C with TE Reachability
图18：具有TE可达性的网络C的隧道连接
Peer networking cases can be made far more complex by dual-homing between network peering nodes (for example, A3 might connect to B1 and B4 in Figure 17) and by the networks themselves being arranged in a mesh (for example, A6 might connect to B4 and C1 in Figure 17).
通过网络对等节点之间的双归宿（例如，A3可能连接到图17中的B1和B4）和网络本身被布置在网格中（例如，A6可能连接到图17中的B4和C1），对等网络情况可能变得更加复杂。
These additional complexities can be handled gracefully by the abstraction layer network model.
抽象层网络模型可以优雅地处理这些额外的复杂性。
Further examples of abstraction in peer networks can be found in Sections 6 and 8.
在第6节和第8节中可以找到对等网络中抽象的更多示例。
It is possible to consider a highly dynamic system where the server network adaptively suggests new abstract links into the abstraction layer, and where the abstraction layer proactively deploys new client-edge-to-client-edge LSPs to provide new links in the client network. Such fluidity is, however, to be treated with caution. In particular, in the case of client-server networks of differing technologies where hierarchical server network LSPs are used, this caution is needed for three reasons: there may be longer turn-up times for connections in some server networks; the server networks are likely to be sparsely connected; and expensive physical resources will only be deployed where there is believed to be a need for them. More significantly, the complex commercial, policy, and administrative relationships that may exist between client and server network operators mean that stability is more likely to be the desired operational practice.
可以考虑一种高度动态的系统，其中服务器网络自适应地向抽象层提出新的抽象链接，并且抽象层主动地将新的客户端边缘部署到客户端边缘LSP以在客户端网络中提供新的链路。然而，应谨慎处理此类流动性。特别是，在使用分层服务器网络LSP的不同技术的客户机-服务器网络的情况下，出于三个原因需要注意：某些服务器网络中的连接可能需要更长的启动时间；服务器网络可能连接稀疏；而且昂贵的物质资源只会部署在人们认为需要的地方。更重要的是，客户机和服务器网络运营商之间可能存在复杂的商业、政策和管理关系，这意味着稳定性更有可能成为理想的运营实践。
Thus, proposals for fully automated multi-layer networks based on this architecture may be regarded as forward-looking topics for research both in terms of network stability and with regard to economic impact.
因此，基于该体系结构的全自动多层网络的建议可被视为网络稳定性和经济影响方面的前瞻性研究课题。
However, some elements of automation should not be discarded. A server network may automatically apply policy to determine the best set of abstract links to offer and the most suitable way for the server network to support them. And a client network may dynamically observe congestion, lack of connectivity, or predicted changes in traffic demand and may use this information to request additional links from the abstraction layer. And, once policies have been configured, the whole system should be able to operate independently of operator control (which is not to say that the operator will not have the option of exerting control at every step in the process).
但是，不应放弃自动化的某些要素。服务器网络可以自动应用策略来确定要提供的最佳抽象链接集以及服务器网络支持它们的最合适方式。并且客户端网络可以动态地观察拥塞、缺乏连接或者预测流量需求的变化，并且可以使用该信息从抽象层请求额外的链路。而且，一旦配置了策略，整个系统应该能够独立于操作员控制运行（这并不是说操作员将无法选择在流程的每一步实施控制）。
The abstraction layer network is "just another network layer". The links and nodes in the network need to be advertised along with their associated TE information (metrics, bandwidth, etc.) so that the topology is disseminated and so that routing decisions can be made.
抽象层网络是“另一个网络层”。网络中的链路和节点需要与其相关的TE信息（度量、带宽等）一起进行广告，以便传播拓扑，并做出路由决策。
This requires a routing protocol running between the nodes in the abstraction layer network. Note that this routing information exchange could be piggybacked on an existing routing protocol instance (subject to different switching capabilities applying to the links in the different networks, or to adequate address space separation) or use a new instance (or even a new protocol). Clearly, the information exchanged is only information that has been created as part of the abstraction function according to policy.
这需要在抽象层网络中的节点之间运行路由协议。请注意，此路由信息交换可以在现有路由协议实例上进行（取决于应用于不同网络中的链路的不同交换能力，或者充分的地址空间分离），或者使用新实例（甚至新协议）。显然，交换的信息只是根据策略作为抽象功能的一部分创建的信息。
It should be noted that in many cases the abstract link represents the potential for connectivity across the server network but that no such connectivity exists. In this case, we may ponder how the routing protocol in the abstraction layer will advertise topology information for, and over, a link that has no underlying connectivity. In other words, there must be a communication channel between the abstraction layer nodes so that the routing protocol messages can flow. The answer is that control-plane connectivity already exists in the server network and on the client-server edge links, and this can be used to carry the routing protocol messages for the abstraction layer network. The same consideration applies to the advertisement, in the client network, of the potential connectivity that the abstraction layer network can provide, although it may be more normal to establish that connectivity before advertising a link in the client network.
应该注意的是，在许多情况下，抽象链接表示跨服务器网络的连接潜力，但不存在这种连接。在这种情况下，我们可以考虑抽象层中的路由协议如何为没有底层连接的链路宣传拓扑信息。换句话说，抽象层节点之间必须有一个通信通道，这样路由协议消息才能流动。答案是，服务器网络和客户机-服务器边缘链路中已经存在控制平面连接，这可以用于承载抽象层网络的路由协议消息。同样的考虑也适用于在客户端网络中公布抽象层网络可以提供的潜在连接性，尽管在公布客户端网络中的链路之前建立该连接性可能更正常。
The network layers in this architecture should be able to operate with separate address spaces, and these may overlap without any technical issues. That is, one address may mean one thing in the client network, yet the same address may have a different meaning in the abstraction layer network or the server network. In other words, there is complete address separation between networks.
该体系结构中的网络层应该能够使用单独的地址空间进行操作，并且这些地址空间可以重叠，而不会出现任何技术问题。也就是说，一个地址在客户机网络中可能意味着一件事，但是同一地址在抽象层网络或服务器网络中可能有不同的含义。换句话说，网络之间存在完全的地址分离。
However, this will require some care, both because human operators may well become confused, and because mapping between address spaces is needed at the interfaces between the network layers. That mapping requires configuration so that, for example, when the server network announces an abstract link from A to B, the abstraction layer network must recognize that A and B are server network addresses and must map them to abstraction layer addresses (say P and Q) before including the link in its own topology. And similarly, when the abstraction layer network informs the client network that a new link is available from S to T, it must map those addresses from its own address space to that of the client network.
然而，这需要一定的注意，因为操作人员可能会感到困惑，而且在网络层之间的接口处需要地址空间之间的映射。该映射需要配置，例如，当服务器网络宣布从A到B的抽象链路时，抽象层网络必须识别A和B是服务器网络地址，并且必须将它们映射到抽象层地址（例如P和Q），然后再将链路包括在其自己的拓扑中。同样，当抽象层网络通知客户机网络从S到T有一个新的链路可用时，它必须将这些地址从它自己的地址空间映射到客户机网络的地址空间。
This form of address mapping will become particularly important in cases where one abstraction layer network is constructed from connectivity in multiple server networks, or where one abstraction layer network provides connectivity for multiple client networks.
当一个抽象层网络由多个服务器网络中的连接构成，或者一个抽象层网络为多个客户端网络提供连接时，这种形式的地址映射将变得特别重要。
This section is non-normative and is not intended to prejudge a solutions framework or any applicability work. It does, however, very briefly serve to note the existence of protocols that could be examined for applicability to serve in realizing the model described in this document.
本节是非规范性的，不打算预先判断解决方案框架或任何适用性工作。然而，它确实非常简要地说明了协议的存在，这些协议可以被检查是否适用于实现本文档中描述的模型。
The general principle of protocol reuse is preferred over the invention of new protocols or additional protocol extensions, and it would be advantageous to make use of an existing protocol that is commonly implemented on network nodes and is currently deployed, or to use existing computational elements such as PCEs. This has many benefits in network stability, time to deployment, and operator training.
协议重用的一般原则优于新协议或附加协议扩展的发明，并且利用通常在网络节点上实现且当前部署的现有协议或使用现有计算元件（例如pce）将是有利的。这在网络稳定性、部署时间和操作员培训方面有很多好处。
It is recognized, however, that existing protocols are unlikely to be immediately suitable to this problem space without some protocol extensions. Extending protocols must be done with care and with consideration for the stability of existing deployments. In extreme cases, a new protocol can be preferable to a messy hack of an existing protocol.
然而，人们认识到，如果没有一些协议扩展，现有协议不可能立即适用于这个问题空间。扩展协议时必须小心，并考虑现有部署的稳定性。在极端情况下，新协议可能比现有协议的混乱攻击更可取。
BGP - Link State (BGP-LS) is a set of extensions to BGP, as described in [RFC7752]. Its purpose is to announce topology information from one network to a "northbound" consumer. Application of BGP-LS to date has focused on a mechanism to build a TED for a PCE. However, BGP's mechanisms would also serve well to advertise abstract links from a server network into the abstraction layer network or to advertise potential connectivity from the abstraction layer network to the client network.
BGP-链路状态（BGP-LS）是BGP的一组扩展，如[RFC7752]所述。其目的是将拓扑信息从一个网络发布给“北行”用户。迄今为止，BGP-LS的应用主要集中在为PCE构建TED的机制上。然而，BGP的机制也可以很好地用于宣传从服务器网络到抽象层网络的抽象链接，或者宣传从抽象层网络到客户机网络的潜在连接。
Both OSPF and IS-IS have been extended through a number of RFCs to advertise TE information. Additionally, both protocols are capable of running in a multi-instance mode either as ships that pass in the night (i.e., completely separate instances using different address spaces) or as dual instances on the same address space. This means that either OSPF or IS-IS could probably be used as the routing protocol in the abstraction layer network.
OSPF和IS-IS都通过许多RFC进行了扩展，以公布TE信息。此外，这两种协议都能够以多实例模式运行，既可以作为夜间通过的船只（即使用不同地址空间的完全独立实例），也可以作为同一地址空间上的双实例。这意味着OSPF或IS-IS可能被用作抽象层网络中的路由协议。
RSVP-TE signaling can be used to set up all TE LSPs demanded by this model, without the need for any protocol extensions.
RSVP-TE信令可用于建立该模型所需的所有TE LSP，无需任何协议扩展。
If necessary, LSP hierarchy [RFC4206] or LSP stitching [RFC5150] can be used to carry LSPs over the server network, again without needing any protocol extensions.
如有必要，LSP层次结构[RFC4206]或LSP缝合[RFC5150]可用于在服务器网络上传输LSP，同样不需要任何协议扩展。
Furthermore, the procedures in [RFC6107] allow the dynamic signaling of the purpose of any LSP that is established. This means that when an LSP tunnel is set up, the two ends can coordinate into which routing protocol instance it should be advertised and can also agree on the addressing to be said to identify the link that will be created.
此外，[RFC6107]中的程序允许动态发送所建立的任何LSP目的的信号。这意味着，当建立LSP隧道时，两端可以协调它应该发布到哪个路由协议实例中，并且还可以商定所说的地址，以识别将创建的链路。
This section is not intended to be prescriptive or dictate the protocol solutions that may be used to satisfy the architecture described in this document, but it does show how the existing protocols listed in the previous sections can be combined, with only minor modifications, to provide a solution.
本节不打算规定或规定可用于满足本文件所述体系结构的协议解决方案，但它确实说明了如何将前几节中列出的现有协议结合起来，只需稍作修改，即可提供解决方案。
A server network can be operated using GMPLS routing and signaling protocols. Using information gathered from the routing protocol, a TED can be constructed containing resource availability information and Shared Risk Link Group (SRLG) details. A policy-based process can then determine which nodes and abstract links it wishes to advertise to form the abstraction layer network.
服务器网络可以使用GMPLS路由和信令协议进行操作。使用从路由协议收集的信息，可以构建包含资源可用性信息和共享风险链路组（SRLG）详细信息的TED。然后，基于策略的流程可以确定它希望公布哪些节点和抽象链接以形成抽象层网络。
The server network can now use BGP-LS to advertise a topology of links and nodes to form the abstraction layer network. This information would most likely be advertised from a single point of control that made all of the abstraction decisions, but the function could be distributed to multiple server network edge nodes. The information can be advertised by BGP-LS to multiple points within the abstraction layer (such as all client network edge nodes) or to a single controller.
服务器网络现在可以使用BGP-LS公布链路和节点的拓扑，以形成抽象层网络。这些信息很可能是从做出所有抽象决策的单个控制点发布的，但该功能可以分布到多个服务器网络边缘节点。BGP-LS可以将信息通告到抽象层内的多个点（例如所有客户端网络边缘节点）或单个控制器。
Multiple server networks may advertise information that is used to construct an abstraction layer network, and one server network may advertise different information in different instances of BGP-LS to form different abstraction layer networks. Furthermore, in the case of one controller constructing multiple abstraction layer networks, BGP-LS uses the route target mechanism defined in [RFC4364] to distinguish the different applications (effectively abstraction layer network VPNs) of the exported information.
多个服务器网络可以公布用于构建抽象层网络的信息，一个服务器网络可以公布BGP-LS的不同实例中的不同信息，以形成不同的抽象层网络。此外，在一个控制器构建多个抽象层网络的情况下，BGP-LS使用[RFC4364]中定义的路由目标机制来区分导出信息的不同应用（有效的抽象层网络VPN）。
Extensions may be made to BGP-LS to allow advertisement of Macro Shared Risk Link Groups (MSRLGs) (Appendix B.1) and the identification of mutually exclusive links (Appendix B.2), and to indicate whether the abstract link has been pre-established or not. Such extensions are valid options but do not form a core component of this architecture.
可对BGP-LS进行扩展，以允许公布宏观共享风险链接组（MSRLG）（附录B.1）和识别互斥链接（附录B.2），并表明是否预先建立了抽象链接。这些扩展是有效的选项，但不构成此体系结构的核心组件。
The abstraction layer network may operate under central control or use a distributed control plane. Since the links and nodes may be a mix of physical and abstract links, and since the nodes may have diverse cross-connect capabilities, it is most likely that a GMPLS routing protocol will be beneficial for collecting and correlating the routing information and for distributing updates. No special additional features are needed beyond adding those extra parameters just described for BGP-LS, but it should be noted that the control plane of the abstraction layer network must run in an out-of-band control network because the data-bearing links might not yet have been established via connections in the server network.
抽象层网络可以在中央控制下运行，也可以使用分布式控制平面。由于链路和节点可以是物理链路和抽象链路的混合，并且由于节点可以具有不同的交叉连接能力，因此GMPLS路由协议很可能有利于收集和关联路由信息以及分发更新。除了添加刚才为BGP-LS描述的那些额外参数外，不需要其他特殊功能，但应注意，抽象层网络的控制平面必须在带外控制网络中运行，因为数据承载链路可能尚未通过服务器网络中的连接建立。
The abstraction layer network is also able to determine potential connectivity from client network edge to client network edge. It will determine which client network links to create according to policy and subject to requests from the client network, and will take four steps:
抽象层网络还能够确定从客户端网络边缘到客户端网络边缘的潜在连接性。它将根据策略和客户端网络的请求确定要创建的客户端网络链接，并将采取四个步骤：
- First, it will compute a path across the abstraction layer network.
- 首先，它将计算跨越抽象层网络的路径。
- Then, if support of the abstract links requires the use of server network LSPs for tunneling or stitching and if those LSPs are not already established, it will ask the server layer to set them up.
- 然后，如果对抽象链接的支持需要使用服务器网络LSP进行隧道或缝合，并且如果这些LSP尚未建立，它将要求服务器层进行设置。
- Then, it will signal the client-edge-to-client-edge LSP.
- 然后，它将向客户机边缘LSP发送客户机边缘信号。
- Finally, the abstraction layer network will inform the client network of the existence of the new client network link.
- 最后，抽象层网络将通知客户机网络新客户机网络链路的存在。
This last step can be achieved by either (1) coordination of the end points of the LSPs that span the abstraction layer (these points are client network edge nodes) using mechanisms such as those described in [RFC6107] or (2) using BGP-LS from a central controller.
最后一步可以通过（1）使用[RFC6107]中描述的机制协调跨越抽象层的LSP端点（这些端点是客户端网络边缘节点）或（2）使用来自中央控制器的BGP-LS来实现。
Once the client network edge nodes are aware of a new link, they will automatically advertise it using their routing protocol and it will become available for use by traffic in the client network.
一旦客户机网络边缘节点意识到新链路，它们将使用其路由协议自动公布该链路，并且该链路将可供客户机网络中的流量使用。
Sections 6, 7, and 8 discuss the applicability of this architecture to different network types and problem spaces, while Section 9 gives some advice about scoping future work. Section 10 ("Manageability Considerations") is particularly relevant in the context of this section because it contains a discussion of the policies and mechanisms for indicating connectivity and link availability between network layers in this architecture.
第6、7和8节讨论了该体系结构对不同网络类型和问题空间的适用性，而第9节给出了一些关于确定未来工作范围的建议。第10节（“可管理性注意事项”）与本节特别相关，因为它包含了用于指示此体系结构中网络层之间的连接和链路可用性的策略和机制的讨论。
Many optical networks are arranged as a set of small domains. Each domain is a cluster of nodes, usually from the same equipment vendor and with the same properties. The domain may be constructed as a mesh or a ring, or maybe as an interconnected set of rings.
许多光网络被安排为一组小域。每个域都是一组节点，通常来自同一设备供应商，具有相同的属性。域可以构造为网格或环，也可以构造为一组相互连接的环。
The network operator seeks to provide end-to-end connectivity across a network constructed from multiple domains, and so (of course) the domains are interconnected. In a network under management control, such as through an Operations Support System (OSS), each domain is under the operational control of a Network Management System (NMS).
网络运营商寻求在由多个域构成的网络上提供端到端连接，因此（当然）这些域是相互连接的。在管理控制下的网络中，例如通过操作支持系统（OSS），每个域都在网络管理系统（NMS）的操作控制下。
In this way, an end-to-end path may be commissioned by the OSS instructing each NMS, and the NMSes setting up the path fragments across the domains.
通过这种方式，OSS可以委托端到端路径来指示每个NMS，NMSE可以跨域设置路径片段。
However, in a system that uses a control plane, there is a need for integration between the domains.
然而，在使用控制平面的系统中，需要在域之间进行集成。
Consider a simple domain, D1, as shown in Figure 19. In this case, nodes A through F are arranged in a topological ring. Suppose that there is a control plane in use in this domain and that OSPF is used as the TE routing protocol.
考虑一个简单的域D1，如图19所示。在这种情况下，节点A到F排列在拓扑环中。假设此域中使用了一个控制平面，并且OSPF用作TE路由协议。
-----------------
| D1 |
| B---C |
| / \ |
| / \ |
| A D |
| \ / |
| \ / |
| F---E |
| |
-----------------
-----------------
| D1 |
| B---C |
| / \ |
| / \ |
| A D |
| \ / |
| \ / |
| F---E |
| |
-----------------
Figure 19: A Simple Optical Domain
图19：一个简单的光学域
Now consider that the operator's network is built from a mesh of such domains, D1 through D7, as shown in Figure 20. It is possible that these domains share a single, common instance of OSPF, in which case there is nothing further to say because that OSPF instance will distribute sufficient information to build a single TED spanning the whole network, and an end-to-end path can be computed. A more likely scenario is that each domain is running its own OSPF instance. In this case, each is able to handle the peculiarities (or, rather, advanced functions) of each vendor's equipment capabilities.
现在考虑操作员的网络是由这样的域的网格构建的，D1到D7，如图20所示。这些域有可能共享一个OSPF的公共实例，在这种情况下，没有什么要说的了，因为OSPF实例将分发足够的信息来构建一个跨越整个网络的TED，并且可以计算端到端路径。更可能的情况是，每个域都运行自己的OSPF实例。在这种情况下，每个供应商都能够处理每个供应商设备能力的特性（或者更确切地说，高级功能）。
------ ------ ------ ------
| | | | | | | |
| D1 |---| D2 |---| D3 |---| D4 |
| | | | | | | |
------\ ------\ ------\ ------
\ | \ | \ |
\------ \------ \------
| | | | | |
| D5 |---| D6 |---| D7 |
| | | | | |
------ ------ ------
------ ------ ------ ------
| | | | | | | |
| D1 |---| D2 |---| D3 |---| D4 |
| | | | | | | |
------\ ------\ ------\ ------
\ | \ | \ |
\------ \------ \------
| | | | | |
| D5 |---| D6 |---| D7 |
| | | | | |
------ ------ ------
Figure 20: A Mesh of Simple Optical Domains
图20：简单光学域的网格
The question now is how to combine the multiple sets of information distributed by the different OSPF instances. Three possible models suggest themselves, based on pre-existing routing practices.
现在的问题是如何组合由不同OSPF实例分发的多组信息。根据预先存在的路由实践，提出了三种可能的模型。
o In the first model (the area-based model), each domain is treated as a separate OSPF area. The end-to-end path will be specified to traverse multiple areas, and each area will be left to determine the path across the nodes in the area. The feasibility of an end-to-end path (and, thus, the selection of the sequence of areas and their interconnections) can be derived using hierarchical PCEs.
o 在第一个模型（基于区域的模型）中，每个域都被视为一个单独的OSPF区域。将指定端到端路径以遍历多个区域，每个区域将留待确定跨区域中节点的路径。端到端路径的可行性（因此，区域序列及其互连的选择）可以使用分层PCE导出。
This approach, however, fits poorly with established use of the OSPF area: in this form of optical network, the interconnection points between domains are likely to be links, and the mesh of domains is far more interconnected and unstructured than we are used to seeing in the normal area-based routing paradigm.
然而，这种方法很不适合OSPF区域的既定用途：在这种形式的光网络中，域之间的互连点很可能是链路，并且域的网格比我们在常规的基于区域的路由范例中看到的更加互连和非结构化。
Furthermore, while hierarchical PCEs may be able to resolve this type of network, the effort involved may be considerable for more than a small collection of domains.
此外，虽然分层PCE可能能够解析这种类型的网络，但所涉及的工作对于一小部分域来说可能是相当大的。
o Another approach (the AS-based model) treats each domain as a separate Autonomous System (AS). The end-to-end path will be specified to traverse multiple ASes, and each AS will be left to determine the path across the nodes in that AS.
o 另一种方法（基于AS的模型）将每个域视为一个独立的自治系统（AS）。端到端路径将被指定为遍历多个AS，而每个AS将被保留以确定该AS中节点之间的路径。
This model sits more comfortably with the established routing paradigm but causes a massive escalation of ASes in the global Internet. It would, in practice, require that the operator use private AS numbers [RFC6996], of which there are plenty.
该模型与已建立的路由范式更为吻合，但会导致全球互联网上ASE的大规模升级。在实践中，它将要求运营商使用私有AS号码[RFC6996]，其中有很多。
Then, as suggested in the area-based model, hierarchical PCEs could be used to determine the feasibility of an end-to-end path and to derive the sequence of domains and the points of interconnection to use. But just as in the area-based model, the scalability of this model using a hierarchical PCE must be questioned, given the sheer number of ASes and their interconnectivity.
然后，如基于区域的模型中所建议的，分层PCE可用于确定端到端路径的可行性，并导出要使用的域序列和互连点。但正如在基于区域的模型中一样，考虑到ASE的绝对数量及其相互关联性，使用分层PCE的该模型的可伸缩性必须受到质疑。
Furthermore, determining the mesh of domains (i.e., the inter-AS connections) conventionally requires the use of BGP as an inter-domain routing protocol. However, not only is BGP not normally available on optical equipment, but this approach indicates that the TE properties of the inter-domain links would need to be distributed and updated using BGP -- something for which it is not well suited.
此外，确定域的网格（即，AS间连接）通常需要使用BGP作为域间路由协议。然而，不仅BGP通常在光学设备上不可用，而且这种方法表明域间链路的TE属性需要使用BGP进行分发和更新——这是它不太适合的。
o The third approach (the Automatically Switched Optical Network (ASON) model) follows the architectural model set out by the ITU-T [G.8080] and uses the routing protocol extensions described in [RFC6827]. In this model, the concept of "levels" is introduced to OSPF. Referring back to Figure 20, each OSPF instance running in a domain would be construed as a "lower-level" OSPF instance and would leak routes into a "higher-level" instance of the protocol that runs across the whole network.
o 第三种方法（自动交换光网络（ASON）模型）遵循ITU-T[G.8080]提出的架构模型，并使用[RFC6827]中描述的路由协议扩展。在这个模型中，OSPF引入了“级别”的概念。回到图20，在域中运行的每个OSPF实例将被解释为“较低级别”的OSPF实例，并将路由泄漏到在整个网络中运行的协议的“较高级别”实例中。
This approach handles the awkwardness of representing the domains as areas or ASes by simply considering them as domains running distinct instances of OSPF. Routing advertisements flow "upward" from the domains to the high-level OSPF instance, giving it a full view of the whole network and allowing end-to-end paths to be computed. Routing advertisements may also flow "downward" from the network-wide OSPF instance to any one domain so that it can see the connectivity of the whole network.
这种方法通过简单地将域视为运行不同OSPF实例的域来处理将域表示为区域或ASE的尴尬。路由广告从域“向上”流向高级OSPF实例，使其能够全面查看整个网络，并允许计算端到端路径。路由广告也可以从网络范围的OSPF实例“向下”流到任何一个域，以便它可以看到整个网络的连通性。
Although architecturally satisfying, this model suffers from having to handle the different characteristics of different equipment vendors. The advertisements coming from each low-level domain would be meaningless when distributed into the other domains, and the high-level domain would need to be kept up to date with the semantics of each new release of each vendor's equipment. Additionally, the scaling issues associated with a well-meshed network of domains, each with many entry and exit points and each with network resources that are continually being updated, reduces to the same problem, as noted in the virtual link model. Furthermore, in the event that the domains are under the control of different administrations, the domains would not want to distribute the details of their topologies and TE resources.
尽管在架构上令人满意，但该模型必须处理不同设备供应商的不同特征。来自每个低级域的广告在分发到其他域时将毫无意义，高级域需要与每个供应商设备的每个新版本的语义保持最新。此外，如虚拟链路模型中所述，与网孔良好的域网络（每个域都有许多入口和出口点，并且每个域都有不断更新的网络资源）相关联的缩放问题会减少为相同的问题。此外，如果域由不同的管理机构控制，则域不希望分发其拓扑和TE资源的详细信息。
Practically, this third model turns out to be very close to the methodology described in this document. As noted in Section 6.1 of [RFC6827], there are policy rules that can be applied to define exactly what information is exported from or imported to a low-level OSPF instance. [RFC6827] even notes that some forms of aggregation may be appropriate. Thus, we can apply the following simplifications to the mechanisms defined in [RFC6827]:
实际上，第三个模型与本文中描述的方法非常接近。如[RFC6827]第6.1节所述，有一些策略规则可用于精确定义从低级OSPF实例导出或导入哪些信息。[RFC6827]甚至注意到某些形式的聚合可能是合适的。因此，我们可以对[RFC6827]中定义的机制进行以下简化：
- Zero information is imported to low-level domains.
- 零信息导入到低级域。
- Low-level domains export only abstracted links as defined in this document and according to local abstraction policy, and with appropriate removal of vendor-specific information.
- 低级域仅导出本文档中定义的抽象链接，并根据本地抽象策略，适当删除特定于供应商的信息。
- There is no need to formally define routing levels within OSPF.
- 没有必要在OSPF中正式定义路由级别。
- Export of abstracted links from the domains to the network-wide routing instance (the abstraction routing layer) can take place through any mechanism, including BGP-LS or direct interaction between OSPF implementations.
- 将抽象链路从域导出到网络范围的路由实例（抽象路由层）可以通过任何机制进行，包括BGP-LS或OSPF实现之间的直接交互。
With these simplifications, it can be seen that the framework defined in this document can be constructed from the architecture discussed in [RFC6827], but without needing any of the protocol extensions defined in that document. Thus, using the terminology and concepts already established, the problem may be solved as shown in Figure 21. The abstraction layer network is constructed from the inter-domain links, the domain border nodes, and the abstracted (cross-domain) links.
通过这些简化，可以看出本文档中定义的框架可以根据[RFC6827]中讨论的体系结构构建，但不需要该文档中定义的任何协议扩展。因此，使用已经建立的术语和概念，可以解决问题，如图21所示。抽象层网络由域间链路、域边界节点和抽象（跨域）链路构成。
Abstraction Layer
-- -- -- -- -- --
| |===========| |--| |===========| |--| |===========| |
| | | | | | | | | | | |
..| |...........| |..| |...........| |..| |...........| |......
| | | | | | | | | | | |
| | -- -- | | | | -- -- | | | | -- -- | |
| |_| |_| |_| | | |_| |_| |_| | | |_| |_| |_| |
| | | | | | | | | | | | | | | | | | | | | | | |
-- -- -- -- -- -- -- -- -- -- -- --
Domain 1 Domain 2 Domain 3
Key Optical Layer
... Layer separation
--- Physical link
=== Abstract link
Abstraction Layer
-- -- -- -- -- --
| |===========| |--| |===========| |--| |===========| |
| | | | | | | | | | | |
..| |...........| |..| |...........| |..| |...........| |......
| | | | | | | | | | | |
| | -- -- | | | | -- -- | | | | -- -- | |
| |_| |_| |_| | | |_| |_| |_| | | |_| |_| |_| |
| | | | | | | | | | | | | | | | | | | | | | | |
-- -- -- -- -- -- -- -- -- -- -- --
Domain 1 Domain 2 Domain 3
Key Optical Layer
... Layer separation
--- Physical link
=== Abstract link
Figure 21: The Optical Network Implemented through the Abstraction Layer Network
图21：通过抽象层网络实现的光网络
The User-Network Interface (UNI) is an important architectural concept in many implementations and deployments of client-server networks, especially those where the client and server network have different technologies. The UNI is described in [G.8080], and the GMPLS approach to the UNI is documented in [RFC4208]. Other GMPLS-related documents describe the application of GMPLS to specific UNI scenarios: for example, [RFC6005] describes how GMPLS can support a UNI that provides access to Ethernet services.
在客户机-服务器网络的许多实现和部署中，用户网络接口（UNI）是一个重要的体系结构概念，特别是在客户机和服务器网络具有不同技术的情况下。[G.8080]中描述了UNI，而[RFC4208]中记录了UNI的GMPLS方法。其他GMPLS相关文档描述了GMPLS在特定UNI场景中的应用：例如，[RFC6005]描述了GMPLS如何支持提供以太网服务访问的UNI。
Figure 1 of [RFC6005] is reproduced here as Figure 22. It shows the Ethernet UNI reference model, and that figure can serve as an example for all similar UNIs. In this case, the UNI is an interface between client network edge nodes and the server network. It should be noted that neither the client network nor the server network need be an Ethernet switching network.
[RFC6005]的图1在此处复制为图22。它显示了以太网UNI参考模型，该图可作为所有类似UNI的示例。在这种情况下，UNI是客户端网络边缘节点和服务器网络之间的接口。应该注意，客户机网络和服务器网络都不需要是以太网交换网络。
There are three network layers in this model: the client network, the "Ethernet service network", and the server network. The so-called Ethernet service network consists of links comprising the UNI links and the tunnels across the server network, and nodes comprising the client network edge nodes and various server network nodes. That is, the Ethernet service network is equivalent to the abstraction layer network, with the UNI links being the physical links between the client and server networks, the client edge nodes taking the role of UNI Client-side (UNI-C) nodes, and the server edge nodes acting as the UNI Network-side (UNI-N) nodes.
该模型有三个网络层：客户端网络、“以太网服务网络”和服务器网络。所谓的以太网服务网络包括包括跨服务器网络的UNI链路和隧道的链路，以及包括客户端网络边缘节点和各种服务器网络节点的节点。也就是说，以太网服务网络等效于抽象层网络，其中UNI链路是客户端和服务器网络之间的物理链路，客户端边缘节点充当UNI客户端（UNI-C）节点，服务器边缘节点充当UNI网络侧（UNI-N）节点。
Client Client
Network +----------+ +-----------+ Network
-------------+ | | | | +-------------
+----+ | | +-----+ | | +-----+ | | +----+
------+ | | | | | | | | | | | | +------
------+ EN +-+-----+--+ CN +-+----+--+ CN +--+-----+-+ EN +------
| | | +--+--| +-+-+ | | +--+-----+-+ |
+----+ | | | +--+--+ | | | +--+--+ | | +----+
| | | | | | | | | |
-------------+ | | | | | | | | +-------------
| | | | | | | |
-------------+ | | | | | | | | +-------------
| | | +--+--+ | | | +--+--+ | |
+----+ | | | | | | +--+--+ | | | +----+
------+ +-+--+ | | CN +-+----+--+ CN | | | | +------
------+ EN +-+-----+--+ | | | | +--+-----+-+ EN +------
| | | | +-----+ | | +-----+ | | | |
+----+ | | | | | | +----+
| +----------+ |-----------+ |
-------------+ Server Networks +-------------
Client UNI UNI Client
Network <-----> <-----> Network
Scope of This Document
Client Client
Network +----------+ +-----------+ Network
-------------+ | | | | +-------------
+----+ | | +-----+ | | +-----+ | | +----+
------+ | | | | | | | | | | | | +------
------+ EN +-+-----+--+ CN +-+----+--+ CN +--+-----+-+ EN +------
| | | +--+--| +-+-+ | | +--+-----+-+ |
+----+ | | | +--+--+ | | | +--+--+ | | +----+
| | | | | | | | | |
-------------+ | | | | | | | | +-------------
| | | | | | | |
-------------+ | | | | | | | | +-------------
| | | +--+--+ | | | +--+--+ | |
+----+ | | | | | | +--+--+ | | | +----+
------+ +-+--+ | | CN +-+----+--+ CN | | | | +------
------+ EN +-+-----+--+ | | | | +--+-----+-+ EN +------
| | | | +-----+ | | +-----+ | | | |
+----+ | | | | | | +----+
| +----------+ |-----------+ |
-------------+ Server Networks +-------------
Client UNI UNI Client
Network <-----> <-----> Network
Scope of This Document
Legend: EN - Client Network Edge Node CN - Server Network (Core) Node
图例：EN-客户端网络边缘节点CN-服务器网络（核心）节点
Figure 22: Ethernet UNI Reference Model
图22：以太网UNI参考模型
An issue that is often raised relates to how a dual-homed client network edge node (such as that shown at the bottom left-hand corner of Figure 22) can make determinations about how they connect across the UNI. This can be particularly important when reachability across the server network is limited or when two diverse paths are desired (for example, to provide protection). However, in the model described in this network, the edge node (the UNI-C node) is part of the abstraction layer network and can see sufficient topology information to make these decisions. If the approach introduced in this document is used to model the UNI as described in this section, there is no need to enhance the signaling protocols at the GMPLS UNI nor to add routing exchanges at the UNI.
经常提出的一个问题涉及双宿客户端网络边缘节点（如图22左下角所示）如何确定它们如何跨UNI连接。当服务器网络的可达性受到限制或需要两条不同的路径（例如，提供保护）时，这一点尤为重要。然而，在该网络中描述的模型中，边缘节点（UNI-C节点）是抽象层网络的一部分，可以看到足够的拓扑信息来做出这些决策。如果本文件中介绍的方法用于按照本节所述对UNI进行建模，则无需增强GMPLS UNI处的信令协议，也无需在UNI处添加路由交换。
Serving Layer 3 VPNs (L3VPNs) across a multi-AS or multi-operator environment currently provides a significant planning challenge. Figure 6 shows the general case of the problem that needs to be solved. This section shows how the abstraction layer network can address this problem.
跨多AS或多运营商环境提供第3层VPN（L3VPN）目前是一个重大的规划挑战。图6显示了需要解决的问题的一般情况。本节展示了抽象层网络如何解决这个问题。
In the VPN architecture, the CE nodes are the client network edge nodes, and the PE nodes are the server network edge nodes. The abstraction layer network is made up of the CE nodes, the CE-PE links, the PE nodes, and PE-PE tunnels that are the abstract links.
在VPN体系结构中，CE节点是客户端网络边缘节点，PE节点是服务器网络边缘节点。抽象层网络由抽象链路的CE节点、CE-PE链路、PE节点和PE-PE隧道组成。
In the multi-AS or multi-operator case, the abstraction layer network also includes the PEs (maybe Autonomous System Border Routers (ASBRs)) at the edges of the multiple server networks, and the PE-PE (maybe inter-AS) links. This gives rise to the architecture shown in Figure 23.
在多AS或多运营商情况下，抽象层网络还包括位于多个服务器网络边缘的PE（可能是自治系统边界路由器（ASBR））和PE-PE（可能是AS间）链路。这就产生了图23所示的体系结构。
The policy for adding abstract links to the abstraction layer network will be driven substantially by the needs of the VPN. Thus, when a new VPN site is added and the existing abstraction layer network cannot support the required connectivity, a new abstract link will be created out of the underlying network.
将抽象链路添加到抽象层网络的策略将主要由VPN的需求驱动。因此，当添加一个新的VPN站点并且现有的抽象层网络无法支持所需的连接时，将从底层网络创建一个新的抽象链路。
........... .............
VPN Site : : VPN Site
-- -- : : -- --
|C1|-|CE| : : |CE|-|C2|
-- | | : : | | --
| | : : | |
| | : : | |
| | : : | |
| | : -- -- -- -- : | |
| |----|PE|=========|PE|---|PE|=====|PE|----| |
-- : | | | | | | | | : --
........... | | | | | | | | ............
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | - - | | | | - | |
| |-|P|-|P|-| | | |-|P|-| |
-- - - -- -- - --
........... .............
VPN Site : : VPN Site
-- -- : : -- --
|C1|-|CE| : : |CE|-|C2|
-- | | : : | | --
| | : : | |
| | : : | |
| | : : | |
| | : -- -- -- -- : | |
| |----|PE|=========|PE|---|PE|=====|PE|----| |
-- : | | | | | | | | : --
........... | | | | | | | | ............
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | - - | | | | - | |
| |-|P|-|P|-| | | |-|P|-| |
-- - - -- -- - --
Figure 23: The Abstraction Layer Network for a Multi-AS VPN
图23：多AS VPN的抽象层网络
It is important to note that each VPN instance can have a separate abstraction layer network. This means that the server network resources can be partitioned and that traffic can be kept separate.
需要注意的是，每个VPN实例都可以有一个单独的抽象层网络。这意味着可以对服务器网络资源进行分区，并且可以将通信量分开。
This can be achieved even when VPN sites from different VPNs connect at the same PE. Alternatively, multiple VPNs can share the same abstraction layer network if that is operationally preferable.
即使来自不同VPN的VPN站点在同一个PE上连接，也可以实现这一点。或者，多个VPN可以共享同一抽象层网络（如果在操作上更可取）。
Lastly, just as for the UNI discussed in Section 7, the issue of dual-homing of VPN sites is a function of the abstraction layer network and so is just a normal routing problem in that network.
最后，正如第7节中讨论的UNI一样，VPN站点的双重归属问题是抽象层网络的一个功能，因此只是该网络中的一个正常路由问题。
This section is provided to help guide the work on this problem. The overarching view is that it is important to limit and focus the work on those things that are core and necessary to achieve the main function, and to not attempt to add unnecessary features or to over-complicate the architecture or the solution by attempting to address marginal use cases or corner cases. This guidance is non-normative for this architecture description.
本节旨在帮助指导有关此问题的工作。总体观点是，重要的是要将工作限制在实现主要功能所必需的核心内容上，而不是试图添加不必要的特性，或试图通过解决边缘用例或角落案例来过度复杂化架构或解决方案。本指南不适用于本体系结构描述。
The scope of the use cases and problem statement in this document is limited to "some small set of interconnected domains." In particular, it is not the objective of this work to turn the whole Internet into one large, interconnected TE network.
本文档中用例和问题陈述的范围仅限于“一些小范围的互联域”。特别是，本工作的目标不是将整个互联网变成一个大型互联网络。
Starting with this subsection, the intention of this work is to solve the TE interconnectivity for only "related" domains. Such domains may be under common administrative operation (such as IGP areas within a single AS, or ASes belonging to a single operator) or may have a direct commercial arrangement for the sharing of TE information to provide specific services. Thus, in both cases, there is a strong opportunity for the application of policy.
从本小节开始，这项工作的目的是仅解决“相关”域的TE互连。这些域可能处于公共管理操作之下（例如单个as内的IGP区域，或属于单个运营商的ASE），或者可能具有共享TE信息以提供特定服务的直接商业安排。因此，在这两种情况下，都有实施政策的巨大机会。
As has been well described in this document, abstraction necessarily involves compromises and removal of information. That means that it is not possible to guarantee that an end-to-end path over interconnected TE domains follows the absolute optimal (by any measure of optimality) path. This is taken as understood, and future work should not attempt to achieve such paths, which can only be found by a full examination of all network information across all connected networks.
正如本文档中所描述的，抽象必然涉及信息的妥协和删除。这意味着不可能保证互连TE域上的端到端路径遵循绝对最优（通过任何最优度量）路径。这是可以理解的，未来的工作不应该试图实现这样的路径，这只能通过全面检查所有连接网络中的所有网络信息来找到。
All of the above points play into a final observation. This work is intended to "bite off" a small problem for some relatively simple use cases as described in Section 2. It is not intended that this work will be immediately (or even soon) extended to cover many large interconnected domains. Obviously, the solution should, as far as possible, be designed to be extensible and scalable; however, it is also reasonable to make trade-offs in favor of utility and simplicity.
以上所有几点构成了最后的观察结果。这项工作旨在为第2节中描述的一些相对简单的用例“解决”一个小问题。这项工作不打算立即（甚至很快）扩展到许多大型互联领域。显然，解决方案应尽可能设计为可扩展和可伸缩的；然而，为了实用性和简单性进行权衡也是合理的。
Manageability should not be a significant additional burden. Each layer in the network model can, and should, be managed independently.
可管理性不应该是一个重大的额外负担。网络模型中的每一层都可以而且应该独立管理。
That is, each client network will run its own management systems and tools to manage the nodes and links in the client network: each client network link that uses an abstract link will still be available for management in the client network as any other link.
也就是说，每个客户机网络将运行其自己的管理系统和工具来管理客户机网络中的节点和链接：使用抽象链接的每个客户机网络链接仍将与任何其他链接一样可用于客户机网络中的管理。
Similarly, each server network will run its own management systems and tools to manage the nodes and links in that network just as normal.
类似地，每个服务器网络将运行其自己的管理系统和工具，以正常方式管理该网络中的节点和链接。
Three issues remain for consideration:
还有三个问题有待审议：
- How is the abstraction layer network managed?
- 抽象层网络是如何管理的？
- How is the interface between the client network and the abstraction layer network managed?
- 客户机网络和抽象层网络之间的接口是如何管理的？
- How is the interface between the abstraction layer network and the server network managed?
- 抽象层网络和服务器网络之间的接口是如何管理的？
Management of the abstraction layer network differs from the client and server networks because not all of the links that are visible in the TED are real links. That is, it is not possible to run Operations, Administration, and Maintenance (OAM) on the links that constitute the potential of a link.
抽象层网络的管理不同于客户端和服务器网络，因为TED中可见的链接并非都是真实的链接。也就是说，不可能在构成链路潜力的链路上运行操作、管理和维护（OAM）。
Other than that, however, the management of the abstraction layer network should be essentially the same. Routing and signaling protocols can be run in the abstraction layer (using out-of-band channels for links that have not yet been established), and a centralized TED can be constructed and used to examine the availability and status of the links and nodes in the network.
然而，除此之外，抽象层网络的管理本质上应该是相同的。路由和信令协议可以在抽象层中运行（对尚未建立的链路使用带外信道），并且可以构造集中式TED并用于检查网络中链路和节点的可用性和状态。
Note that different deployment models will place the "ownership" of the abstraction layer network differently. In some cases, the abstraction layer network will be constructed by the operator of the server network and run by that operator as a service for one or more client networks. In other cases, one or more server networks will present the potential of links to an abstraction layer network run by the operator of the client network. And it is feasible that a business model could be built where a third-party operator manages the abstraction layer network, constructing it from the connectivity available in multiple server networks and facilitating connectivity for multiple client networks.
注意，不同的部署模型将不同地放置抽象层网络的“所有权”。在某些情况下，抽象层网络将由服务器网络的运营商构建，并由该运营商作为一个或多个客户端网络的服务运行。在其他情况下，一个或多个服务器网络将呈现到由客户机网络的运营商运行的抽象层网络的链路的潜力。而且，可以建立一个业务模型，由第三方运营商管理抽象层网络，从多个服务器网络中可用的连接性构建抽象层网络，并促进多个客户端网络的连接性。
The interaction between the client network and the abstraction layer network is a management task. It might be automated (software driven), or it might require manual intervention.
客户机网络和抽象层网络之间的交互是一项管理任务。它可能是自动化的（软件驱动的），也可能需要手动干预。
This is a two-way interaction:
这是一种双向互动：
- The client network can express the need for additional connectivity. For example, the client network may try, and fail, to find a path across the client network and may request additional, specific connectivity (this is similar to the situation with the Virtual Network Topology Manager (VNTM) [RFC5623]). Alternatively, a more proactive client network management system may monitor traffic demands (current and predicted), network usage, and network "hot spots" and may request changes in connectivity by both releasing unused links and requesting new links.
- 客户端网络可以表达对额外连接的需求。例如，客户端网络可能尝试在客户端网络上查找路径，但失败，并且可能请求额外的特定连接（这与虚拟网络拓扑管理器（VNTM）[RFC5623]的情况类似）。或者，更主动的客户端网络管理系统可以监控流量需求（当前和预测）、网络使用情况和网络“热点”，并可以通过释放未使用的链路和请求新链路来请求连接更改。
- The abstraction layer network can make links available to the client network or can withdraw them. These actions can be in response to requests from the client network or can be driven by processes within the abstraction layer (perhaps reorganizing the use of server network resources). In any case, the presentation of new links to the client network is heavily subject to policy, since this is both operationally key to the success of this architecture and the central plank of the commercial model described in this document. Such policies belong to the operator of the abstraction layer network and are expected to be fully configurable.
- 抽象层网络可以使链接对客户端网络可用，也可以将它们撤回。这些操作可以响应来自客户端网络的请求，也可以由抽象层中的进程驱动（可能是重新组织服务器网络资源的使用）。在任何情况下，向客户网络提供新链接都要严格遵守政策，因为这既是该体系结构成功的操作关键，也是本文件中所述商业模式的核心。这些策略属于抽象层网络的运营商，并且应该是完全可配置的。
Once the abstraction layer network has decided to make a link available to the client network, it will install it at the link end points (which are nodes in the client network) such that it appears and can be advertised as a link in the client network.
一旦抽象层网络决定将链路提供给客户机网络，它将在链路端点（即客户机网络中的节点）处安装该链路，以使其出现并可以作为客户机网络中的链路进行广告。
In all cases, it is important that the operators of both networks are able to track the requests and responses, and the operator of the client network should be able to see which links in that network are "real" physical links and which links are presented by the abstraction layer network.
在所有情况下，重要的是两个网络的运营商都能够跟踪请求和响应，并且客户端网络的运营商应该能够看到该网络中的哪些链路是“真实”物理链路，哪些链路由抽象层网络呈现。
The interactions between the abstraction layer network and the server network are similar to those described in Section 10.2, but there is a difference in that the server network is more likely to offer up connectivity and the abstraction layer network is less likely to ask for it.
抽象层网络和服务器网络之间的交互类似于第10.2节中所述的交互，但区别在于服务器网络更可能提供连接，而抽象层网络不太可能要求连接。
That is, the server network will, according to policy that may include commercial relationships, offer the abstraction layer network a "set" of potential connectivity that the abstraction layer network can treat as links. This server network policy will include:
也就是说，根据可能包括商业关系的策略，服务器网络将向抽象层网络提供一组潜在连接，抽象层网络可以将其视为链路。此服务器网络策略将包括：
- how much connectivity to offer
- 提供多少连接
- what level of server network redundancy to include
- 要包括的服务器网络冗余级别是多少
- how to support the use of the abstract links
- 如何支持抽象链接的使用
This process of offering links from the server network may include a mechanism to indicate which links have been pre-established in the server network and can include other properties, such as:
提供来自服务器网络的链接的过程可以包括一种机制，用于指示哪些链接已经在服务器网络中预先建立，并且可以包括其他属性，例如：
- link-level protection [RFC4202]
- 链路级保护[RFC4202]
- SRLGs and MSRLGs (see Appendix B.1)
- SRLGs和MSRLG（见附录B.1）
- mutual exclusivity (see Appendix B.2)
- 相互排他性（见附录B.2）
The abstraction layer network needs a mechanism to tell the server network which links it is using. This mechanism could also include the ability to request additional connectivity from the server network, although it seems most likely that the server network will already have presented as much connectivity as it is physically capable of, subject to the constraints of policy.
抽象层网络需要一种机制来告诉服务器网络它正在使用哪个链接。该机制还可以包括从服务器网络请求额外连接的能力，尽管受策略约束，服务器网络很可能已经提供了尽可能多的物理连接。
Finally, the server network will need to confirm the establishment of connectivity, withdraw links if they are no longer feasible, and report failures.
最后，服务器网络需要确认连接的建立，如果链路不再可行，则撤回链路，并报告故障。
Again, it is important that the operators of both networks are able to track the requests and responses, and the operator of the server network should be able to see which links are in use.
同样重要的是，两个网络的运营商都能够跟踪请求和响应，服务器网络的运营商应该能够看到正在使用的链路。
Security of signaling and routing protocols is usually administered and achieved within the boundaries of a domain. Thus, and for example, a domain with a GMPLS control plane [RFC3945] would apply the security mechanisms and considerations that are appropriate to GMPLS [RFC5920]. Furthermore, domain-based security relies strongly on ensuring that control-plane messages are not allowed to enter the domain from outside.
信令和路由协议的安全性通常在域的边界内管理和实现。因此，例如，具有GMPLS控制平面[RFC3945]的域将应用适用于GMPLS[RFC5920]的安全机制和注意事项。此外，基于域的安全性在很大程度上依赖于确保控制平面消息不允许从外部进入域。
In this context, additional security considerations arising from this document relate to the exchange of control-plane information between domains. Messages are passed between domains using control-plane protocols operating between peers that have predictable relationships (for example, UNI-C to UNI-N, between BGP-LS speakers, or between peer domains). Thus, the security that needs to be given additional attention for inter-domain TE concentrates on authentication of peers; assertion that messages have not been tampered with; and, to a lesser extent, protecting the content of the messages from inspection, since that might give away sensitive information about the networks. The protocols described in Appendix A, which are likely to provide the foundation for solutions to this architecture,
在这种情况下，本文件中产生的其他安全注意事项涉及域之间控制平面信息的交换。使用控制平面协议在具有可预测关系的对等方之间（例如，UNI-C到UNI-N、BGP-LS扬声器之间或对等域之间）操作，在域之间传递消息。因此，需要对域间TE给予额外关注的安全性集中于对等方的认证；断言消息未被篡改；而且，在较小程度上，保护消息内容不受检查，因为这可能泄露有关网络的敏感信息。附录A中描述的协议，很可能为该体系结构的解决方案提供基础，
already include such protection and also can be run over protected transports such as IPsec [RFC6071], Transport Layer Security (TLS) [RFC5246], and the TCP Authentication Option (TCP-AO) [RFC5925].
已经包括此类保护，并且还可以在受保护的传输上运行，例如IPsec[RFC6071]、传输层安全性（TLS）[RFC5246]和TCP身份验证选项（TCP-AO）[RFC5925]。
It is worth noting that the control plane of the abstraction layer network is likely to be out of band. That is, control-plane messages will be exchanged over network links that are not the links to which they apply. This models the facilities of GMPLS (but not of MPLS-TE), and the security mechanisms can be applied to the protocols operating in the out-of-band network.
值得注意的是，抽象层网络的控制平面可能是带外的。也就是说，控制平面消息将通过非其应用的链路的网络链路进行交换。该模型模拟了GMPLS（但不是MPLS-TE）的设施，安全机制可应用于带外网络中运行的协议。
[G.8080] International Telecommunication Union, "Architecture for the automatically switched optical network", ITU-T Recommendation G.8080/Y.1304, February 2012, <https://www.itu.int/rec/T-REC-G.8080-201202-I/en>.
[G.8080]国际电信联盟，“自动交换光网络的体系结构”，ITU-T建议G.8080/Y.1304，2012年2月<https://www.itu.int/rec/T-REC-G.8080-201202-I/en>.
[GMPLS-ENNI] Bryskin, I., Ed., Doonan, W., Beeram, V., Ed., Drake, J., Ed., Grammel, G., Paul, M., Kunze, R., Armbruster, F., Margaria, C., Gonzalez de Dios, O., and D. Ceccarelli, "Generalized Multiprotocol Label Switching (GMPLS) External Network Network Interface (E-NNI): Virtual Link Enhancements for the Overlay Model", Work in Progress, draft-beeram-ccamp-gmpls-enni-03, September 2013.
[GMPLS-ENNI]Bryskin，I.，Ed.，Doonan，W.，Beeram，V.，Ed.，Drake，J.，Ed.，Grammel，G.，Paul，M.，Kunze，R.，Armburster，F.，Margaria，C.，Gonzalez de Dios，O.，and D.Ceccarelli，“通用多协议标签交换（GMPLS）外部网络接口（E-NNI）：覆盖模型的虚拟链路增强”，正在进行中，草案-beeram-ccamp-gmpls-enni-032013年9月。
[RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J. McManus, "Requirements for Traffic Engineering Over MPLS", RFC 2702, DOI 10.17487/RFC2702, September 1999, <http://www.rfc-editor.org/info/rfc2702>.
[RFC2702]Awduche，D.，Malcolm，J.，Agogbua，J.，O'Dell，M.，和J.McManus，“MPLS上的流量工程要求”，RFC 2702，DOI 10.17487/RFC2702，1999年9月<http://www.rfc-editor.org/info/rfc2702>.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, <http://www.rfc-editor.org/info/rfc3209>.
[RFC3209]Awduche，D.，Berger，L.，Gan，D.，Li，T.，Srinivasan，V.，和G.Swallow，“RSVP-TE：LSP隧道RSVP的扩展”，RFC 3209，DOI 10.17487/RFC3209，2001年12月<http://www.rfc-editor.org/info/rfc3209>.
[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, DOI 10.17487/RFC3473, January 2003, <http://www.rfc-editor.org/info/rfc3473>.
[RFC3473]Berger，L.，Ed.“通用多协议标签交换（GMPLS）信令资源预留协议流量工程（RSVP-TE）扩展”，RFC 3473，DOI 10.17487/RFC3473，2003年1月<http://www.rfc-editor.org/info/rfc3473>.
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, DOI 10.17487/RFC3630, September 2003, <http://www.rfc-editor.org/info/rfc3630>.
[RFC3630]Katz，D.，Kompella，K.，和D.Yeung，“OSPF版本2的交通工程（TE）扩展”，RFC 3630，DOI 10.17487/RFC3630，2003年9月<http://www.rfc-editor.org/info/rfc3630>.
[RFC3945] Mannie, E., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", RFC 3945, DOI 10.17487/RFC3945, October 2004, <http://www.rfc-editor.org/info/rfc3945>.
[RFC3945]Mannie，E.，Ed.“通用多协议标签交换（GMPLS）体系结构”，RFC 3945，DOI 10.17487/RFC3945，2004年10月<http://www.rfc-editor.org/info/rfc3945>.
[RFC4105] Le Roux, J.-L., Ed., Vasseur, J.-P., Ed., and J. Boyle, Ed., "Requirements for Inter-Area MPLS Traffic Engineering", RFC 4105, DOI 10.17487/RFC4105, June 2005, <http://www.rfc-editor.org/info/rfc4105>.
[RFC4105]Le Roux，J.-L.，Ed.，Vasseur，J.-P.，Ed.，和J.Boyle，Ed.，“区域间MPLS流量工程的要求”，RFC 4105，DOI 10.17487/RFC4105，2005年6月<http://www.rfc-editor.org/info/rfc4105>.
[RFC4202] Kompella, K., Ed., and Y. Rekhter, Ed., "Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4202, DOI 10.17487/RFC4202, October 2005, <http://www.rfc-editor.org/info/rfc4202>.
[RFC4202]Kompella，K.，Ed.，和Y.Rekhter，Ed.，“支持通用多协议标签交换（GMPLS）的路由扩展”，RFC 4202，DOI 10.17487/RFC4202，2005年10月<http://www.rfc-editor.org/info/rfc4202>.
[RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE)", RFC 4206, DOI 10.17487/RFC4206, October 2005, <http://www.rfc-editor.org/info/rfc4206>.
[RFC4206]Kompella，K.和Y.Rekhter，“具有通用多协议标签交换（GMPLS）流量工程（TE）的标签交换路径（LSP）层次结构”，RFC 4206，DOI 10.17487/RFC4206，2005年10月<http://www.rfc-editor.org/info/rfc4206>.
[RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter, "Generalized Multiprotocol Label Switching (GMPLS) User-Network Interface (UNI): Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Support for the Overlay Model", RFC 4208, DOI 10.17487/RFC4208, October 2005, <http://www.rfc-editor.org/info/rfc4208>.
[RFC4208]Swallow，G.，Drake，J.，Ishimatsu，H.，和Y.Rekhter，“通用多协议标签交换（GMPLS）用户网络接口（UNI）：覆盖模型的资源预留协议流量工程（RSVP-TE）支持”，RFC 4208，DOI 10.17487/RFC4208，2005年10月<http://www.rfc-editor.org/info/rfc4208>.
[RFC4216] Zhang, R., Ed., and J.-P. Vasseur, Ed., "MPLS Inter-Autonomous System (AS) Traffic Engineering (TE) Requirements", RFC 4216, DOI 10.17487/RFC4216, November 2005, <http://www.rfc-editor.org/info/rfc4216>.
[RFC4216]Zhang，R.，Ed.，和J.-P.Vasseur，Ed.“MPLS自治系统间（AS）流量工程（TE）要求”，RFC 4216，DOI 10.17487/RFC4216，2005年11月<http://www.rfc-editor.org/info/rfc4216>.
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, January 2006, <http://www.rfc-editor.org/info/rfc4271>.
[RFC4271]Rekhter，Y.，Ed.，Li，T.，Ed.，和S.Hares，Ed.，“边境网关协议4（BGP-4）”，RFC 4271，DOI 10.17487/RFC4271，2006年1月<http://www.rfc-editor.org/info/rfc4271>.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 2006, <http://www.rfc-editor.org/info/rfc4364>.
[RFC4364]Rosen，E.和Y.Rekhter，“BGP/MPLS IP虚拟专用网络（VPN）”，RFC 4364，DOI 10.17487/RFC4364，2006年2月<http://www.rfc-editor.org/info/rfc4364>.
[RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, DOI 10.17487/RFC4655, August 2006, <http://www.rfc-editor.org/info/rfc4655>.
[RFC4655]Farrel，A.，Vasseur，J.-P.，和J.Ash，“基于路径计算元素（PCE）的体系结构”，RFC 4655，DOI 10.17487/RFC4655，2006年8月<http://www.rfc-editor.org/info/rfc4655>.
[RFC4726] Farrel, A., Vasseur, J.-P., and A. Ayyangar, "A Framework for Inter-Domain Multiprotocol Label Switching Traffic Engineering", RFC 4726, DOI 10.17487/RFC4726, November 2006, <http://www.rfc-editor.org/info/rfc4726>.
[RFC4726]Farrel，A.，Vasseur，J.-P.，和A.Ayyangar，“域间多协议标签交换流量工程框架”，RFC 4726，DOI 10.17487/RFC4726，2006年11月<http://www.rfc-editor.org/info/rfc4726>.
[RFC4847] Takeda, T., Ed., "Framework and Requirements for Layer 1 Virtual Private Networks", RFC 4847, DOI 10.17487/RFC4847, April 2007, <http://www.rfc-editor.org/info/rfc4847>.
[RFC4847]武田，T.，编辑，“第1层虚拟专用网络的框架和要求”，RFC 4847，DOI 10.17487/RFC4847，2007年4月<http://www.rfc-editor.org/info/rfc4847>.
[RFC4874] Lee, CY., Farrel, A., and S. De Cnodder, "Exclude Routes - Extension to Resource ReserVation Protocol-Traffic Engineering (RSVP-TE)", RFC 4874, DOI 10.17487/RFC4874, April 2007, <http://www.rfc-editor.org/info/rfc4874>.
[RFC4874]Lee，CY.，Farrel，A.和S.De Cnodder，“排除路由-资源预留协议流量工程（RSVP-TE）的扩展”，RFC 4874，DOI 10.17487/RFC4874，2007年4月<http://www.rfc-editor.org/info/rfc4874>.
[RFC4920] Farrel, A., Ed., Satyanarayana, A., Iwata, A., Fujita, N., and G. Ash, "Crankback Signaling Extensions for MPLS and GMPLS RSVP-TE", RFC 4920, DOI 10.17487/RFC4920, July 2007, <http://www.rfc-editor.org/info/rfc4920>.
[RFC4920]Farrel，A.，Ed.，Satyanarayana，A.，Iwata，A.，Fujita，N.，和G.Ash，“MPLS和GMPLS RSVP-TE的回退信令扩展”，RFC 4920，DOI 10.17487/RFC4920，2007年7月<http://www.rfc-editor.org/info/rfc4920>.
[RFC5150] Ayyangar, A., Kompella, K., Vasseur, JP., and A. Farrel, "Label Switched Path Stitching with Generalized Multiprotocol Label Switching Traffic Engineering (GMPLS TE)", RFC 5150, DOI 10.17487/RFC5150, February 2008, <http://www.rfc-editor.org/info/rfc5150>.
[RFC5150]Ayyangar，A.，Kompella，K.，Vasseur，JP.，和A.Farrel，“使用通用多协议标签交换流量工程（GMPLS TE）的标签交换路径缝合”，RFC 5150，DOI 10.17487/RFC5150，2008年2月<http://www.rfc-editor.org/info/rfc5150>.
[RFC5152] Vasseur, JP., Ed., Ayyangar, A., Ed., and R. Zhang, "A Per-Domain Path Computation Method for Establishing Inter-Domain Traffic Engineering (TE) Label Switched Paths (LSPs)", RFC 5152, DOI 10.17487/RFC5152, February 2008, <http://www.rfc-editor.org/info/rfc5152>.
[RFC5152]Vasseur，JP.，Ed.，Ayyangar，A.，Ed.，和R.Zhang，“建立域间流量工程（TE）标签交换路径（LSP）的每域路径计算方法”，RFC 5152，DOI 10.17487/RFC5152，2008年2月<http://www.rfc-editor.org/info/rfc5152>.
[RFC5195] Ould-Brahim, H., Fedyk, D., and Y. Rekhter, "BGP-Based Auto-Discovery for Layer-1 VPNs", RFC 5195, DOI 10.17487/RFC5195, June 2008, <http://www.rfc-editor.org/info/rfc5195>.
[RFC5195]Ould Brahim，H.，Fedyk，D.，和Y.Rekhter，“基于BGP的第一层VPN自动发现”，RFC 5195，DOI 10.17487/RFC5195，2008年6月<http://www.rfc-editor.org/info/rfc5195>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, <http://www.rfc-editor.org/info/rfc5246>.
[RFC5246]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，DOI 10.17487/RFC5246，2008年8月<http://www.rfc-editor.org/info/rfc5246>.
[RFC5251] Fedyk, D., Ed., Rekhter, Y., Ed., Papadimitriou, D., Rabbat, R., and L. Berger, "Layer 1 VPN Basic Mode", RFC 5251, DOI 10.17487/RFC5251, July 2008, <http://www.rfc-editor.org/info/rfc5251>.
[RFC5251]Fedyk，D.，Ed.，Rekhter，Y.，Ed.，Papadimitriou，D.，Rabbat，R.，和L.Berger，“第1层VPN基本模式”，RFC 5251，DOI 10.17487/RFC5251，2008年7月<http://www.rfc-editor.org/info/rfc5251>.
[RFC5252] Bryskin, I. and L. Berger, "OSPF-Based Layer 1 VPN Auto-Discovery", RFC 5252, DOI 10.17487/RFC5252, July 2008, <http://www.rfc-editor.org/info/rfc5252>.
[RFC5252]Bryskin，I.和L.Berger，“基于OSPF的第1层VPN自动发现”，RFC 5252，DOI 10.17487/RFC5252，2008年7月<http://www.rfc-editor.org/info/rfc5252>.
[RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic Engineering", RFC 5305, DOI 10.17487/RFC5305, October 2008, <http://www.rfc-editor.org/info/rfc5305>.
[RFC5305]Li，T.和H.Smit，“交通工程的IS-IS扩展”，RFC 5305，DOI 10.17487/RFC5305，2008年10月<http://www.rfc-editor.org/info/rfc5305>.
[RFC5440] Vasseur, JP., Ed., and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, DOI 10.17487/RFC5440, March 2009, <http://www.rfc-editor.org/info/rfc5440>.
[RFC5440]Vasseur，JP.，Ed.，和JL。Le Roux主编，“路径计算元件（PCE）通信协议（PCEP）”，RFC 5440，DOI 10.17487/RFC5440，2009年3月<http://www.rfc-editor.org/info/rfc5440>.
[RFC5441] Vasseur, JP., Ed., Zhang, R., Bitar, N., and JL. Le Roux, "A Backward-Recursive PCE-Based Computation (BRPC) Procedure to Compute Shortest Constrained Inter-Domain Traffic Engineering Label Switched Paths", RFC 5441, DOI 10.17487/RFC5441, April 2009, <http://www.rfc-editor.org/info/rfc5441>.
[RFC5441]Vasseur，JP.，Ed.，Zhang，R.，Bitar，N.，和JL。Le Roux，“计算最短约束域间流量工程标签交换路径的基于PCE的反向递归计算（BRPC）程序”，RFC 5441，DOI 10.17487/RFC5441，2009年4月<http://www.rfc-editor.org/info/rfc5441>.
[RFC5523] Berger, L., "OSPFv3-Based Layer 1 VPN Auto-Discovery", RFC 5523, DOI 10.17487/RFC5523, April 2009, <http://www.rfc-editor.org/info/rfc5523>.
[RFC5523]Berger，L.，“基于OSPFv3的第1层VPN自动发现”，RFC 5523，DOI 10.17487/RFC5523，2009年4月<http://www.rfc-editor.org/info/rfc5523>.
[RFC5553] Farrel, A., Ed., Bradford, R., and JP. Vasseur, "Resource Reservation Protocol (RSVP) Extensions for Path Key Support", RFC 5553, DOI 10.17487/RFC5553, May 2009, <http://www.rfc-editor.org/info/rfc5553>.
[RFC5553]Farrel，A.，Ed.，Bradford，R.，和JP。Vasseur，“路径密钥支持的资源预留协议（RSVP）扩展”，RFC 5553，DOI 10.17487/RFC5553，2009年5月<http://www.rfc-editor.org/info/rfc5553>.
[RFC5623] Oki, E., Takeda, T., Le Roux, JL., and A. Farrel, "Framework for PCE-Based Inter-Layer MPLS and GMPLS Traffic Engineering", RFC 5623, DOI 10.17487/RFC5623, September 2009, <http://www.rfc-editor.org/info/rfc5623>.
[RFC5623]Oki，E.，Takeda，T.，Le Roux，JL.，和A.Farrel，“基于PCE的层间MPLS和GMPLS流量工程框架”，RFC 5623，DOI 10.17487/RFC5623，2009年9月<http://www.rfc-editor.org/info/rfc5623>.
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010, <http://www.rfc-editor.org/info/rfc5920>.
[RFC5920]方，L.，编辑，“MPLS和GMPLS网络的安全框架”，RFC 5920，DOI 10.17487/RFC5920，2010年7月<http://www.rfc-editor.org/info/rfc5920>.
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP Authentication Option", RFC 5925, DOI 10.17487/RFC5925, June 2010, <http://www.rfc-editor.org/info/rfc5925>.
[RFC5925]Touch，J.，Mankin，A.，和R.Bonica，“TCP认证选项”，RFC 5925，DOI 10.17487/RFC5925，2010年6月<http://www.rfc-editor.org/info/rfc5925>.
[RFC6005] Berger, L. and D. Fedyk, "Generalized MPLS (GMPLS) Support for Metro Ethernet Forum and G.8011 User Network Interface (UNI)", RFC 6005, DOI 10.17487/RFC6005, October 2010, <http://www.rfc-editor.org/info/rfc6005>.
[RFC6005]Berger，L.和D.Fedyk，“对城域以太网论坛和G.8011用户网络接口（UNI）的通用MPLS（GMPLS）支持”，RFC 6005，DOI 10.17487/RFC6005，2010年10月<http://www.rfc-editor.org/info/rfc6005>.
[RFC6071] Frankel, S. and S. Krishnan, "IP Security (IPsec) and Internet Key Exchange (IKE) Document Roadmap", RFC 6071, DOI 10.17487/RFC6071, February 2011, <http://www.rfc-editor.org/info/rfc6071>.
[RFC6071]Frankel，S.和S.Krishnan，“IP安全（IPsec）和互联网密钥交换（IKE）文档路线图”，RFC 6071，DOI 10.17487/RFC6071，2011年2月<http://www.rfc-editor.org/info/rfc6071>.
[RFC6107] Shiomoto, K., Ed., and A. Farrel, Ed., "Procedures for Dynamically Signaled Hierarchical Label Switched Paths", RFC 6107, DOI 10.17487/RFC6107, February 2011, <http://www.rfc-editor.org/info/rfc6107>.
[RFC6107]Shiomoto，K.，Ed.，和A.Farrel，Ed.“动态信号分层标签交换路径的程序”，RFC 6107，DOI 10.17487/RFC6107，2011年2月<http://www.rfc-editor.org/info/rfc6107>.
[RFC6805] King, D., Ed., and A. Farrel, Ed., "The Application of the Path Computation Element Architecture to the Determination of a Sequence of Domains in MPLS and GMPLS", RFC 6805, DOI 10.17487/RFC6805, November 2012, <http://www.rfc-editor.org/info/rfc6805>.
[RFC6805]King，D.，Ed.，和A.Farrel，Ed.，“路径计算元素架构在MPLS和GMPLS域序列确定中的应用”，RFC 6805，DOI 10.17487/RFC6805，2012年11月<http://www.rfc-editor.org/info/rfc6805>.
[RFC6827] Malis, A., Ed., Lindem, A., Ed., and D. Papadimitriou, Ed., "Automatically Switched Optical Network (ASON) Routing for OSPFv2 Protocols", RFC 6827, DOI 10.17487/RFC6827, January 2013, <http://www.rfc-editor.org/info/rfc6827>.
[RFC6827]Malis，A.，Ed.，Lindem，A.，Ed.，和D.Papadimitriou，Ed.，“OSPFv2协议的自动交换光网络（ASON）路由”，RFC 6827，DOI 10.17487/RFC6827，2013年1月<http://www.rfc-editor.org/info/rfc6827>.
[RFC6996] Mitchell, J., "Autonomous System (AS) Reservation for Private Use", BCP 6, RFC 6996, DOI 10.17487/RFC6996, July 2013, <http://www.rfc-editor.org/info/rfc6996>.
[RFC6996]Mitchell，J.，“供私人使用的自主系统（AS）预订”，BCP 6，RFC 6996，DOI 10.17487/RFC6996，2013年7月<http://www.rfc-editor.org/info/rfc6996>.
[RFC7399] Farrel, A. and D. King, "Unanswered Questions in the Path Computation Element Architecture", RFC 7399, DOI 10.17487/RFC7399, October 2014, <http://www.rfc-editor.org/info/rfc7399>.
[RFC7399]Farrel，A.和D.King，“路径计算元素架构中未回答的问题”，RFC 7399，DOI 10.17487/RFC7399，2014年10月<http://www.rfc-editor.org/info/rfc7399>.
[RFC7579] Bernstein, G., Ed., Lee, Y., Ed., Li, D., Imajuku, W., and J. Han, "General Network Element Constraint Encoding for GMPLS-Controlled Networks", RFC 7579, DOI 10.17487/RFC7579, June 2015, <http://www.rfc-editor.org/info/rfc7579>.
[RFC7579]Bernstein，G.，Ed.，Lee，Y.，Ed.，Li，D.，Imajuku，W.，和J.Han，“GMPLS控制网络的一般网元约束编码”，RFC 7579，DOI 10.17487/RFC7579，2015年6月<http://www.rfc-editor.org/info/rfc7579>.
[RFC7580] Zhang, F., Lee, Y., Han, J., Bernstein, G., and Y. Xu, "OSPF-TE Extensions for General Network Element Constraints", RFC 7580, DOI 10.17487/RFC7580, June 2015, <http://www.rfc-editor.org/info/rfc7580>.
[RFC7580]Zhang，F.，Lee，Y.，Han，J.，Bernstein，G.，和Y.Xu，“一般网元约束的OSPF-TE扩展”，RFC 7580，DOI 10.17487/RFC75802015年6月<http://www.rfc-editor.org/info/rfc7580>.
[RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and S. Ray, "North-Bound Distribution of Link-State and Traffic Engineering (TE) Information Using BGP", RFC 7752, DOI 10.17487/RFC7752, March 2016, <http://www.rfc-editor.org/info/rfc7752>.
[RFC7752]Gredler，H.，Ed.，Medved，J.，Previdi，S.，Farrel，A.，和S.Ray，“使用BGP的链路状态和流量工程（TE）信息的北向分布”，RFC 7752，DOI 10.17487/RFC7752，2016年3月<http://www.rfc-editor.org/info/rfc7752>.
[RSVP-TE-EXCL] Ali, Z., Ed., Swallow, G., Ed., Zhang, F., Ed., and D. Beller, Ed., "Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Path Diversity using Exclude Route", Work in Progress, draft-ietf-teas-lsp-diversity-05, June 2016.
[RSVP-TE-EXCL]Ali，Z.，Ed.，Swallow，G.，Ed.，Zhang，F.，Ed.，和D.Beller，Ed.，“使用排除路由的资源预留协议流量工程（RSVP-TE）路径分集”，正在进行的工作，草案-ietf-teas-lsp-Diversity-05，2016年6月。
[RSVP-TE-EXT] Zhang, F., Ed., Gonzalez de Dios, O., Ed., Hartley, M., Ali, Z., and C. Margaria, "RSVP-TE Extensions for Collecting SRLG Information", Work in Progress, draft-ietf-teas-rsvp-te-srlg-collect-06, May 2016.
[RSVP-TE-EXT]Zhang，F.，Ed.，Gonzalez de Dios，O.，Ed.，Hartley，M.，Ali，Z.，和C.Margaria，“用于收集SRLG信息的RSVP-TE扩展”，正在进行的工作，草稿-ietf-teas-RSVP-TE-SRLG-collect-062016年5月。
[RSVP-TE-METRIC] Ali, Z., Swallow, G., Filsfils, C., Hartley, M., Kumaki, K., and R. Kunze, "Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) extension for recording TE Metric of a Label Switched Path", Work in Progress, draft-ietf-teas-te-metric-recording-04, March 2016.
[RSVP-TE-METRIC]Ali，Z.，Swallow，G.，Filsfils，C.，Hartley，M.，Kumaki，K.，和R.Kunze，“记录标签交换路径TE度量的资源预留协议流量工程（RSVP-TE）扩展”，正在进行中的工作，草稿-ietf-teas-TE-METRIC-recording-042016年3月。
This appendix briefly summarizes relevant existing work that is used to route TE paths across multiple domains. It is non-normative.
本附录简要总结了用于跨多个域路由TE路径的相关现有工作。这是不规范的。
The mechanism for per-domain path establishment is described in [RFC5152], and its applicability is discussed in [RFC4726]. In summary, this mechanism assumes that each domain entry point is responsible for computing the path across the domain but that details regarding the path in the next domain are left to the next domain entry point. The computation may be performed directly by the entry point or may be delegated to a computation server.
[RFC5152]中描述了每域路径建立的机制，并在[RFC4726]中讨论了其适用性。总之，此机制假设每个域入口点负责计算跨域的路径，但有关下一个域中路径的详细信息将留给下一个域入口点。计算可以由入口点直接执行，也可以委托给计算服务器。
This basic mode of operation can run into many of the issues described alongside the use cases in Section 2. However, in practice it can be used effectively, with a little operational guidance.
这种基本的操作模式可能会遇到许多与第2节中的用例一起描述的问题。然而，在实践中，它可以有效地使用，只需一点操作指导。
For example, RSVP-TE [RFC3209] includes the concept of a "loose hop" in the explicit path that is signaled. This allows the original request for an LSP to list the domains or even domain entry points to include on the path. Thus, in the example in Figure 1, the source can be told to use interconnection x2. Then, the source computes the path from itself to x2 and initiates the signaling. When the signaling message reaches Domain Z, the entry point to the domain computes the remaining path to the destination and continues the signaling.
例如，RSVP-TE[RFC3209]在信号发送的显式路径中包括“松散跳跃”的概念。这允许LSP的原始请求列出要包含在路径上的域或域入口点。因此，在图1中的示例中，可以告诉源使用互连x2。然后，源计算从自身到x2的路径并启动信令。当信令消息到达域Z时，域的入口点计算到目的地的剩余路径并继续信令。
Another alternative suggested in [RFC5152] is to make TE routing attempt to follow inter-domain IP routing. Thus, in the example shown in Figure 2, the source would examine the BGP routing information to determine the correct interconnection point for forwarding IP packets and would use that to compute and then signal a path for Domain A. Each domain in turn would apply the same approach so that the path is progressively computed and signaled domain by domain.
[RFC5152]中建议的另一种选择是使TE路由尝试遵循域间IP路由。因此，在图2所示的示例中，源将检查BGP路由信息，以确定转发IP数据包的正确互连点，并使用该互连点计算域a的路径，然后向其发送信号。每个域依次应用相同的方法，以便逐步计算路径，并向每个域发送信号。
Although the per-domain approach has many issues and drawbacks in terms of achieving optimal (or, indeed, any) paths, it has been the mainstay of inter-domain LSP setup to date.
尽管每个域的方法在实现最佳（或任何）路径方面存在许多问题和缺点，但迄今为止，它一直是域间LSP设置的主流。
Crankback addresses one of the main issues with per-domain path computation: What happens when an initial path is selected that cannot be completed toward the destination? For example, what happens if, in Figure 2, the source attempts to route the path through interconnection x2 but Domain C does not have the right TE resources or connectivity to route the path further?
回溯解决了每个域路径计算的一个主要问题：当选择了无法向目标完成的初始路径时会发生什么？例如，在图2中，如果源尝试通过互连x2路由路径，但域C没有正确的TE资源或连接来进一步路由路径，会发生什么？
Crankback for MPLS-TE and GMPLS networks is described in [RFC4920] and is based on a concept similar to the Acceptable Label Set mechanism described for GMPLS signaling in [RFC3473]. When a node (i.e., a domain entry point) is unable to compute a path further across the domain, it returns an error message in the signaling protocol that states where the blockage occurred (link identifier, node identifier, domain identifier, etc.) and gives some clues about what caused the blockage (bad choice of label, insufficient bandwidth available, etc.). This information allows a previous computation point to select an alternative path, or to aggregate crankback information and return it upstream to a previous computation point.
[RFC4920]中描述了MPLS-TE和GMPLS网络的回退，回退基于与[RFC3473]中描述的GMPLS信令可接受标签集机制类似的概念。当节点（即，域入口点）无法进一步计算跨域的路径时，它会在信令协议中返回一条错误消息，说明阻塞发生的位置（链路标识符、节点标识符、域标识符等），并给出导致阻塞的一些线索（标签选择不当、可用带宽不足等）。此信息允许上一个计算点选择替代路径，或聚合回退信息并将其返回到上一个计算点的上游。
Crankback is a very powerful mechanism and can be used to find an end-to-end path in a multi-domain network if one exists.
回溯是一种非常强大的机制，可用于在多域网络中查找端到端路径（如果存在）。
On the other hand, crankback can be quite resource-intensive, as signaling messages and path setup attempts may "wander around" in the network, attempting to find the correct path for a long time. Since (1) RSVP-TE signaling ties up network resources for partially established LSPs, (2) network conditions may be in flux, and (3) most particularly, LSP setup within well-known time limits is highly desirable, crankback is not a popular mechanism.
另一方面，回退可能会占用大量资源，因为信令消息和路径设置尝试可能会在网络中“徘徊”，试图长时间找到正确的路径。由于（1）RSVP-TE信令为部分建立的LSP连接网络资源，（2）网络条件可能在变化，以及（3）最特别的是，在众所周知的时间限制内设置LSP是非常理想的，回退不是一种流行的机制。
Furthermore, even if crankback can always find an end-to-end path, it does not guarantee that the optimal path will be found. (Note that there have been some academic proposals to use signaling-like techniques to explore the whole network in order to find optimal paths, but these tend to place even greater burdens on network processing.)
此外，即使回退始终可以找到端到端路径，也不能保证找到最佳路径。（注意，有一些学术建议使用类似信令的技术来探索整个网络，以找到最佳路径，但这些建议往往会给网络处理带来更大的负担。）
The Path Computation Element (PCE) is introduced in [RFC4655]. It is an abstract functional entity that computes paths. Thus, in the example of per-domain path computation (see Appendix A.1), both the source node and each domain entry point are PCEs. On the other hand, the PCE can also be realized as a separate network element (a server) to which computation requests can be sent using the Path Computation Element Communication Protocol (PCEP) [RFC5440].
[RFC4655]中介绍了路径计算元素（PCE）。它是计算路径的抽象功能实体。因此，在每个域路径计算的示例中（参见附录A.1），源节点和每个域入口点都是PCE。另一方面，PCE还可以实现为单独的网络元件（服务器），可以使用路径计算元件通信协议（PCEP）[RFC5440]向其发送计算请求。
Each PCE is responsible for computations within a domain and has visibility of the attributes within that domain. This immediately enables per-domain path computation with the opportunity to offload complex, CPU-intensive, or memory-intensive computation functions from routers in the network. But the use of PCEs in this way does not solve any of the problems articulated in Appendices A.1 and A.2.
每个PCE负责域内的计算，并具有该域内属性的可见性。这将立即启用每域路径计算，并有机会从网络中的路由器卸载复杂、CPU密集或内存密集的计算功能。但以这种方式使用PCE并不能解决附录A.1和A.2中阐述的任何问题。
Two significant mechanisms for cooperation between PCEs have been described. These mechanisms are intended to specifically address the problems of computing optimal end-to-end paths in multi-domain environments.
已经描述了PCE之间合作的两个重要机制。这些机制旨在专门解决多域环境中计算最佳端到端路径的问题。
- The Backward-Recursive PCE-Based Computation (BRPC) mechanism [RFC5441] involves cooperation between the set of PCEs along the inter-domain path. Each one computes the possible paths from the domain entry point (or source node) to the domain exit point (or destination node) and shares the information with its upstream neighbor PCE, which is able to build a tree of possible paths rooted at the destination. The PCE in the source domain can select the optimal path.
- 基于PCE的反向递归计算（BRPC）机制[RFC5441]涉及沿域间路径的一组PCE之间的协作。每个节点计算从域入口点（或源节点）到域出口点（或目标节点）的可能路径，并与其上游邻居PCE共享信息，后者能够构建以目标为根的可能路径树。源域中的PCE可以选择最佳路径。
BRPC is sometimes described as "crankback at computation time". It is capable of determining the optimal path in a multi-domain network but depends on knowing the domain that contains the destination node. Furthermore, the mechanism can become quite complicated and can involve a lot of data in a mesh of interconnected domains. Thus, BRPC is most often proposed for a simple mesh of domains and specifically for a path that will cross a known sequence of domains, but where there may be a choice of domain interconnections. In this way, BRPC would only be applied to Figure 2 if a decision had been made (externally) to traverse Domain C rather than Domain D (notwithstanding that it could functionally be used to make that choice itself), but BRPC could be used very effectively to select between interconnections x1 and x2 in Figure 1.
BRPC有时被描述为“计算时的回退”。它能够确定多域网络中的最佳路径，但取决于知道包含目标节点的域。此外，该机制可能会变得相当复杂，并且可能会在相互连接的域的网格中涉及大量数据。因此，BRPC通常用于简单的域网，特别是用于穿过已知域序列的路径，但可能存在域互连选择。通过这种方式，只有在（外部）决定遍历域C而不是域D时，BRPC才会应用于图2（尽管它在功能上可用于做出选择本身），但BRPC可以非常有效地用于在图1中的互连x1和x2之间进行选择。
- The Hierarchical PCE (H-PCE) [RFC6805] mechanism offers a parent PCE that is responsible for navigating a path across the domain mesh and for coordinating intra-domain computations by the child PCEs responsible for each domain. This approach makes computing an end-to-end path across a mesh of domains far more tractable. However, it still leaves unanswered the issue of determining the location of the destination (i.e., discovering the destination domain) as described in Section 2.1. Furthermore, it raises the question of who operates the parent PCE, especially in networks where the domains are under different administrative and commercial control.
- 分层PCE（H-PCE）[RFC6805]机制提供一个父PCE，负责在域网格上导航路径，并协调负责每个域的子PCE的域内计算。这种方法使得计算跨域网格的端到端路径变得更加容易处理。然而，如第2.1节所述，确定目的地位置（即发现目的地域）的问题仍然没有得到回答。此外，它还提出了谁运营父PCE的问题，特别是在域处于不同行政和商业控制下的网络中。
It should also be noted that [RFC5623] discusses how PCEs are used in a multi-layer network with coordination between PCEs operating at each network layer. Further issues and considerations regarding the use of PCEs can be found in [RFC7399].
还应注意的是，[RFC5623]讨论了如何在多层网络中使用PCE，以及在每个网络层上运行的PCE之间的协调。有关PCE使用的更多问题和注意事项，请参见[RFC7399]。
[RFC4208] defines the GMPLS User-Network Interface (UNI) to present a routing boundary between an overlay (client) network and the server network, i.e., the client-server interface. In the client network, the nodes connected directly to the server network are known as edge nodes, while the nodes in the server network are called core nodes.
[RFC4208]定义GMPLS用户网络接口（UNI），以表示覆盖（客户机）网络和服务器网络之间的路由边界，即客户机-服务器接口。在客户端网络中，直接连接到服务器网络的节点称为边缘节点，而服务器网络中的节点称为核心节点。
In the overlay model defined by [RFC4208], the core nodes act as a closed system and the edge nodes do not participate in the routing protocol instance that runs among the core nodes. Thus, the UNI allows access to, and limited control of, the core nodes by edge nodes that are unaware of the topology of the core nodes. This respects the operational and layer boundaries while scaling the network.
在[RFC4208]定义的覆盖模型中，核心节点充当封闭系统，边缘节点不参与在核心节点之间运行的路由协议实例。因此，UNI允许不知道核心节点的拓扑的边缘节点访问核心节点并限制对核心节点的控制。这在缩放网络时尊重操作和层边界。
[RFC4208] does not define any routing protocol extension for the interaction between core and edge nodes but allows for the exchange of reachability information between them. In terms of a VPN, the client network can be considered as the customer network comprised of a number of disjoint sites, and the edge nodes match the VPN CE nodes. Similarly, the provider network in the VPN model is equivalent to the server network.
[RFC4208]没有为核心节点和边缘节点之间的交互定义任何路由协议扩展，但允许在它们之间交换可达性信息。就VPN而言，客户端网络可以被视为由多个不相交的站点组成的客户网络，并且边缘节点与VPN CE节点匹配。类似地，VPN模型中的提供商网络相当于服务器网络。
[RFC4208] is, therefore, a signaling-only solution that allows edge nodes to request connectivity across the server network and leaves the server network to select the paths for the LSPs as they traverse the core nodes (setting up hierarchical LSPs if necessitated by the technology). This solution is supplemented by a number of signaling extensions, such as [RFC4874], [RFC5553], [RSVP-TE-EXCL], [RSVP-TE-EXT], and [RSVP-TE-METRIC], to give the edge node more control over the path within the server network and by allowing the edge nodes to supply additional constraints on the path used in the server network. Nevertheless, in this UNI/overlay model, the edge node has limited information regarding precisely what LSPs could be set up across the server network and what TE services (diverse routes for end-to-end protection, end-to-end bandwidth, etc.) can be supported.
因此，[RFC4208]是一种仅发信号的解决方案，允许边缘节点请求跨服务器网络的连接，并让服务器网络在LSP穿过核心节点时为其选择路径（如果技术需要，设置分层LSP）。该解决方案由许多信令扩展来补充，例如[RFC4874]、[RFC5553]、[RSVP-TE-EXC]、[RSVP-TE-EXT]和[RSVP-TE-METRIC]，以使边缘节点对服务器网络内的路径有更多的控制，并允许边缘节点对服务器网络中使用的路径提供附加约束。然而，在该UNI/覆盖模型中，边缘节点具有关于可以在服务器网络上设置哪些LSP以及可以支持哪些TE服务（端到端保护的不同路由、端到端带宽等）的有限信息。
A Layer 1 VPN (L1VPN) is a service offered by a Layer 1 server network to provide Layer 1 connectivity (Time-Division Multiplexing (TDM), Lambda Switch Capable (LSC)) between two or more customer networks in an overlay service model [RFC4847].
第1层VPN（L1VPN）是由第1层服务器网络提供的服务，用于在覆盖服务模型[RFC4847]中的两个或多个客户网络之间提供第1层连接（时分多路复用（TDM）、支持Lambda交换机（LSC））。
As in the UNI case, the customer edge has some control over the establishment and type of connectivity. In the L1VPN context, three different service models have been defined, classified by the semantics of information exchanged over the customer interface: the management-based model, the signaling-based (a.k.a. basic) service model, and the signaling and routing (a.k.a. enhanced) service model.
与UNI案例一样，客户边缘对连接的建立和类型具有一定的控制权。在L1VPN上下文中，定义了三种不同的服务模型，根据通过客户接口交换的信息语义进行分类：基于管理的模型、基于信令（也称为基本）的服务模型以及信令和路由（也称为增强）的服务模型。
In the management-based model, all edge-to-edge connections are set up using configuration and management tools. This is not a dynamic control-plane solution and need not concern us here.
在基于管理的模型中，所有边到边连接都是使用配置和管理工具设置的。这不是一个动态控制平面解决方案，在这里我们不必担心。
In the signaling-based (basic) service model [RFC5251], the CE-PE interface allows only for signaling message exchange, and the provider network does not export any routing information about the server network. VPN membership is known a priori (presumably through configuration) or is discovered using a routing protocol [RFC5195] [RFC5252] [RFC5523], as is the relationship between CE nodes and ports on the PE. This service model is much in line with GMPLS UNI as defined in [RFC4208].
在基于信令的（基本）服务模型[RFC5251]中，CE-PE接口仅允许信令消息交换，提供商网络不导出关于服务器网络的任何路由信息。VPN成员身份是先验的（可能通过配置），或者使用路由协议[RFC5195][RFC5252][RFC5523]发现，CE节点和PE上端口之间的关系也是如此。此服务模型与[RFC4208]中定义的GMPLS UNI非常一致。
In the signaling and routing (enhanced) service model, there is an additional limited exchange of routing information over the CE-PE interface between the provider network and the customer network. The enhanced model considers four different types of service models, namely the overlay extension, virtual node, virtual link, and per-VPN service models. All of these represent particular cases of the TE information aggregation and representation.
在信令和路由（增强）服务模型中，提供商网络和客户网络之间通过CE-PE接口进行额外的有限路由信息交换。增强模型考虑了四种不同类型的服务模型，即覆盖扩展、虚拟节点、虚拟链路和每VPN服务模型。所有这些都代表了TE信息聚合和表示的特殊情况。
Inter-domain networking relies on policy and management input to coordinate the allocation of resources under different administrative control. [RFC5623] introduces a functional component called the VNTM for this purpose.
域间联网依赖于策略和管理输入来协调不同管理控制下的资源分配。[RFC5623]为此引入了一个称为VNTM的功能组件。
An important companion to this function is determining how connectivity across the abstraction layer network is made available as a TE link in the client network. Obviously, if the connectivity is established using management intervention, the consequent client network TE link can also be configured manually. However, if connectivity from client edge to client edge is achieved using
此功能的一个重要附带功能是确定如何将抽象层网络上的连接作为客户端网络中的TE链路提供。显然，如果使用管理干预建立连接，那么也可以手动配置随后的客户端网络TE链路。但是，如果使用
dynamic signaling, then there is need for the end points to exchange the link properties that they should advertise within the client network, and in the case of support for more than one client network, it will be necessary to indicate which client network or networks can use the link. This capability it provided in [RFC6107].
动态信令，则需要端点交换其应在客户端网络内公布的链路属性，并且在支持多个客户端网络的情况下，将需要指示哪个客户端网络或多个网络可以使用链路。该功能在[RFC6107]中提供。
This appendix describes additional features that may be desirable and that can be achieved within this architecture. It is non-normative.
本附录描述了可能需要的以及在此体系结构中可以实现的其他功能。这是不规范的。
Network links often share fate with one or more other links. That is, a scenario that may cause a link to fail could cause one or more other links to fail. This may occur, for example, if the links are supported by the same fiber bundle, or if some links are routed down the same duct or in a common piece of infrastructure such as a bridge. A common way to identify the links that may share fate is to label them as belonging to a Shared Risk Link Group (SRLG) [RFC4202].
网络链接通常与一个或多个其他链接共享命运。也就是说，可能导致链接失败的场景可能会导致一个或多个其他链接失败。例如，如果链路由同一光纤束支撑，或者某些链路沿同一管道或在桥梁等公共基础设施中布线，则可能会发生这种情况。识别可能共享命运的链接的常用方法是将其标记为属于共享风险链接组（SRLG）[RFC4202]。
TE links created from LSPs in lower layers may also share fate, and it can be hard for a client network to know about this problem because it does not know the topology of the server network or the path of the server network LSPs that are used to create the links in the client network.
从较低层中的LSP创建的TE链路也可能有相同的命运，客户端网络可能很难了解此问题，因为它不知道服务器网络的拓扑或用于在客户端网络中创建链路的服务器网络LSP的路径。
For example, looking at the example used in Section 4.2.3 and considering the two abstract links S1-S3 and S1-S9, there is no way for the client network to know whether links C2-C0 and C2-C3 share fate. Clearly, if the client layer uses these links to provide a link-diverse end-to-end protection scheme, it needs to know that the links actually share a piece of network infrastructure (the server network link S1-S2).
例如，查看第4.2.3节中使用的示例，并考虑两个抽象链路S1-S3和S1-S9，客户端网络无法知道链路C2-C0和C2-C3是否共享命运。显然，如果客户端层使用这些链路提供链路多样性端到端保护方案，则需要知道链路实际上共享一个网络基础设施（服务器网络链路S1-S2）。
Per [RFC4202], an SRLG represents a shared physical network resource upon which the normal functioning of a link depends. Multiple SRLGs can be identified and advertised for every TE link in a network. However, this can produce a scalability problem in a multi-layer network that equates to advertising in the client network the server network route of each TE link.
根据[RFC4202]，SRLG表示链路正常运行所依赖的共享物理网络资源。可以为网络中的每个TE链路识别和公布多个SRLGs。然而，这可能在多层网络中产生可伸缩性问题，这相当于在客户端网络中公布每个TE链路的服务器网络路由。
Macro SRLGs (MSRLGs) address this scaling problem and are a form of abstraction performed at the same time that the abstract links are derived. In this way, links that actually share resources in the server network are advertised as having the same MSRLG, rather than advertising each SRLG for each resource on each path in the server
宏SRLGs（MSRLG）解决了这个缩放问题，是在派生抽象链接的同时执行的一种抽象形式。这样，在服务器网络中实际共享资源的链路被通告为具有相同的MSRLG，而不是通告服务器中每个路径上每个资源的每个SRLG
network. This saving is possible because the abstract links are formulated on behalf of the server network by a central management agency that is aware of all of the link abstractions being offered.
网络这种节省是可能的，因为抽象链接是由一个中央管理机构代表服务器网络制定的，该机构知道所提供的所有链接抽象。
It may be noted that a less optimal alternative path for the abstract link S1-S9 exists in the server network (S1-S4-S7-S8-S9). It would be possible for the client network request for C2-C0 connectivity to also ask that the path be maximally disjoint from path C2-C3. Although nothing can be done about the shared link C2-S1, the abstraction layer could make a request to use link S1-S9 in a way that is diverse from the use of link S1-S3, and this request could be honored if the server network policy allows it.
可以注意到，在服务器网络（S1-S4-S7-S8-S9）中存在抽象链路S1-S9的较不理想的备选路径。对于C2-C0连接的客户端网络请求，也可能要求路径与路径C2-C3最大程度地不相交。尽管无法对共享链路C2-S1采取任何措施，但抽象层可以请求以不同于链路S1-S3的方式使用链路S1-S9，并且如果服务器网络策略允许，可以满足该请求。
Note that SRLGs and MSRLGs may be very hard to describe in the case of multiple server networks because the abstraction points will not know whether the resources in the various server layers share physical locations.
注意，在多服务器网络的情况下，SRLGs和MSRLG可能很难描述，因为抽象点不知道各个服务器层中的资源是否共享物理位置。
As noted in the discussion of Figure 13, it is possible that some abstraction layer links cannot be used at the same time. This arises when the potentiality of the links is indicated by the server network, but the use of the links would actually compete for server network resources. Referring to Figure 13, this situation would arise when both link S1-S3 and link S7-S9 are used to carry LSPs: in that case, link S1-S9 could no longer be used.
如图13讨论中所述，可能无法同时使用某些抽象层链接。当服务器网络显示链路的潜力时，就会出现这种情况，但链路的使用实际上会争夺服务器网络资源。参考图13，当链路S1-S3和链路S7-S9都用于承载LSP时，会出现这种情况：在这种情况下，链路S1-S9将无法再使用。
Such a situation need not be an issue when client-edge-to-client-edge LSPs are set up one by one, because the use of one abstraction layer link and the corresponding use of server network resources will cause the server network to withdraw the availability of the other abstraction layer links, and these will become unavailable for further abstraction layer path computations.
当一个接一个地建立客户机边缘到客户机边缘LSP时，这种情况不一定是问题，因为使用一个抽象层链路和相应地使用服务器网络资源将导致服务器网络取消其他抽象层链路的可用性，这些将无法用于进一步的抽象层路径计算。
Furthermore, in deployments where abstraction layer links are only presented as available after server network LSPs have been established to support them, the problem is unlikely to exist.
此外，在部署中，抽象层链接仅在建立服务器网络LSP以支持它们之后才显示为可用，因此问题不太可能存在。
However, when the server network is constrained but chooses to advertise the potential of multiple abstraction layer links even though they compete for resources, and when multiple client-edge-to-client-edge LSPs are computed simultaneously (perhaps to provide protection services), there may be contention for server network resources. In the case where protected abstraction layer LSPs are being established, this situation would be avoided through the use of SRLGs and/or MSRLGs, since the two abstraction layer links that compete for server network resources must also fate-share across
然而，当服务器网络受到约束，但选择宣传多个抽象层链路的潜力，即使它们竞争资源，并且当同时计算多个客户端边缘到客户端边缘lsp（可能是为了提供保护服务）时，可能存在对服务器网络资源的竞争。在建立受保护的抽象层LSP的情况下，可以通过使用SRLGs和/或MSRLG来避免这种情况，因为争夺服务器网络资源的两个抽象层链路也必须共享命运
those resources. But in the case where the multiple client-edge-to-client-edge LSPs do not care about fate sharing, it may be necessary to flag the mutually exclusive links in the abstraction layer TED so that path computation can avoid accidentally attempting to utilize two of a set of such links at the same time.
这些资源。但是，在多个客户机边缘到客户机边缘lsp不关心命运共享的情况下，可能需要在抽象层TED中标记互斥链路，以便路径计算可以避免意外地试图同时利用一组这样的链路中的两个。
Acknowledgements
致谢
Thanks to Igor Bryskin for useful discussions in the early stages of this work and to Gert Grammel for discussions on the extent of aggregation in abstract nodes and links.
感谢Igor Bryskin在这项工作的早期阶段进行了有益的讨论，感谢Gert Grammel对抽象节点和链接中聚合程度的讨论。
Thanks to Deborah Brungard, Dieter Beller, Dhruv Dhody, Vallinayakam Somasundaram, Hannes Gredler, Stewart Bryant, Brian Carpenter, and Hilarie Orman for review and input.
感谢Deborah Brungard、Dieter Beller、Dhruv Dhody、Vallinayakam Somasundaram、Hannes Gredler、Stewart Bryant、Brian Carpenter和Hilarie Orman的审查和意见。
Particular thanks to Vishnu Pavan Beeram for detailed discussions and white-board scribbling that made many of the ideas in this document come to life.
特别感谢毗瑟奴·帕万·比拉姆的详细讨论和白板涂鸦，使本文件中的许多想法变得栩栩如生。
Text in Section 4.2.3 is freely adapted from the work of Igor Bryskin, Wes Doonan, Vishnu Pavan Beeram, John Drake, Gert Grammel, Manuel Paul, Ruediger Kunze, Friedrich Armbruster, Cyril Margaria, Oscar Gonzalez de Dios, and Daniele Ceccarelli in [GMPLS-ENNI], for which the authors of this document express their thanks.
第4.2.3节中的文本自由改编自[GMPLS-ENNI]中Igor Bryskin、Wes Doonan、Vishnu Pavan Beeram、John Drake、Gert Grammel、Manuel Paul、Ruediger Kunze、Friedrich Armburster、Cyril Margaria、Oscar Gonzalez de Dios和Daniele Ceccarelli的作品，本文件的作者对此表示感谢。
Contributors
贡献者
Gert Grammel Juniper Networks Email: ggrammel@juniper.net
Gert Grammel Juniper Networks电子邮件：ggrammel@juniper.net
Vishnu Pavan Beeram Juniper Networks Email: vbeeram@juniper.net
Vishnu Pavan Beeram Juniper Networks电子邮件：vbeeram@juniper.net
Oscar Gonzalez de Dios Email: ogondio@tid.es
Oscar Gonzalez de Dios电子邮件：ogondio@tid.es
Fatai Zhang Email: zhangfatai@huawei.com
张法泰电邮：zhangfatai@huawei.com
Zafar Ali Email: zali@cisco.com
扎法尔·阿里电子邮件：zali@cisco.com
Rajan Rao Email: rrao@infinera.com
Rajan Rao电子邮件：rrao@infinera.com
Sergio Belotti Email: sergio.belotti@alcatel-lucent.com
塞尔吉奥·贝洛蒂电子邮件：塞尔吉奥。belotti@alcatel-朗讯网
Diego Caviglia Email: diego.caviglia@ericsson.com
Diego Caviglia电子邮件：Diego。caviglia@ericsson.com
Jeff Tantsura Email: jeff.tantsura@ericsson.com
Jeff Tantsura电子邮件：Jeff。tantsura@ericsson.com
Khuzema Pithewan Email: kpithewan@infinera.com
Khuzema Pithewan电子邮件：kpithewan@infinera.com
Cyril Margaria Email: cyril.margaria@googlemail.com
西里尔·玛格丽亚电子邮件：西里尔。margaria@googlemail.com
Victor Lopez Email: vlopez@tid.es
Victor Lopez电子邮件：vlopez@tid.es
Authors' Addresses
作者地址
Adrian Farrel (editor) Juniper Networks
Adrian Farrel（编辑）Juniper Networks
Email: adrian@olddog.co.uk
Email: adrian@olddog.co.uk
John Drake Juniper Networks
约翰·德雷克·杜松网络公司
Email: jdrake@juniper.net
Email: jdrake@juniper.net
Nabil Bitar Nokia
诺基亚比塔
Email: nbitar40@gmail.com
Email: nbitar40@gmail.com
George Swallow Cisco Systems, Inc. 1414 Massachusetts Ave. Boxborough, MA 01719
乔治·斯沃诺思科系统公司，地址：马萨诸塞州伯斯堡马萨诸塞大道1414号，邮编01719
Email: swallow@cisco.com
Email: swallow@cisco.com
Daniele Ceccarelli Ericsson Via A. Negrone 1/A Genova - Sestri Ponente Italy
Daniele Ceccarelli Ericsson通过A.Negrone 1/A Genova-意大利塞斯特里·波南特
Email: daniele.ceccarelli@ericsson.com
Email: daniele.ceccarelli@ericsson.com
Xian Zhang Huawei Technologies
张贤华为技术有限公司
Email: zhang.xian@huawei.com
Email: zhang.xian@huawei.com