Network Working Group A. Farrel
Request for Comments: 4726 Old Dog Consulting
Category: Informational J.-P. Vasseur
Cisco Systems, Inc.
A. Ayyangar
Nuova Systems
November 2006
Network Working Group A. Farrel
Request for Comments: 4726 Old Dog Consulting
Category: Informational J.-P. Vasseur
Cisco Systems, Inc.
A. Ayyangar
Nuova Systems
November 2006
A Framework for Inter-Domain Multiprotocol Label Switching Traffic Engineering
域间多协议标签交换流量工程框架
Status of This Memo
关于下段备忘
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The IETF Trust (2006).
版权所有（C）IETF信托基金（2006年）。
Abstract
摘要
This document provides a framework for establishing and controlling Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineered (TE) Label Switched Paths (LSPs) in multi-domain networks.
本文档提供了在多域网络中建立和控制多协议标签交换（MPLS）和通用MPLS（GMPLS）流量工程（TE）标签交换路径（LSP）的框架。
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 Interior Gateway Protocol (IGP) areas and Autonomous Systems (ASes).
在本文档中，域被视为地址管理或路径计算责任的公共范围内的任何网络元素集合。此类域的示例包括内部网关协议（IGP）区域和自治系统（ASE）。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Nested Domains .............................................3
2. Signaling Options ...............................................4
2.1. LSP Nesting ................................................4
2.2. Contiguous LSP .............................................5
2.3. LSP Stitching ..............................................5
2.4. Hybrid Methods .............................................6
2.5. Control of Downstream Choice of Signaling Method ...........6
3. Path Computation Techniques .....................................6
3.1. Management Configuration ...................................7
3.2. Head-End Computation .......................................7
3.2.1. Multi-Domain Visibility Computation .................7
3.2.2. Partial Visibility Computation ......................7
3.2.3. Local Domain Visibility Computation .................8
3.3. Domain Boundary Computation ................................8
3.4. Path Computation Element ...................................9
3.4.1. Multi-Domain Visibility Computation ................10
3.4.2. Path Computation Use of PCE When Preserving
Confidentiality ....................................10
3.4.3. Per-Domain Computation Elements ....................10
3.5. Optimal Path Computation ..................................11
4. Distributing Reachability and TE Information ...................11
5. Comments on Advanced Functions .................................12
5.1. LSP Re-Optimization .......................................12
5.2. LSP Setup Failure .........................................13
5.3. LSP Repair ................................................14
5.4. Fast Reroute ..............................................14
5.5. Comments on Path Diversity ................................15
5.6. Domain-Specific Constraints ...............................16
5.7. Policy Control ............................................17
5.8. Inter-Domain Operations and Management (OAM) ..............17
5.9. Point-to-Multipoint .......................................17
5.10. Applicability to Non-Packet Technologies .................17
6. Security Considerations ........................................18
7. Acknowledgements ...............................................19
8. Normative References ...........................................19
9. Informative References .........................................20
1. Introduction ....................................................3
1.1. Nested Domains .............................................3
2. Signaling Options ...............................................4
2.1. LSP Nesting ................................................4
2.2. Contiguous LSP .............................................5
2.3. LSP Stitching ..............................................5
2.4. Hybrid Methods .............................................6
2.5. Control of Downstream Choice of Signaling Method ...........6
3. Path Computation Techniques .....................................6
3.1. Management Configuration ...................................7
3.2. Head-End Computation .......................................7
3.2.1. Multi-Domain Visibility Computation .................7
3.2.2. Partial Visibility Computation ......................7
3.2.3. Local Domain Visibility Computation .................8
3.3. Domain Boundary Computation ................................8
3.4. Path Computation Element ...................................9
3.4.1. Multi-Domain Visibility Computation ................10
3.4.2. Path Computation Use of PCE When Preserving
Confidentiality ....................................10
3.4.3. Per-Domain Computation Elements ....................10
3.5. Optimal Path Computation ..................................11
4. Distributing Reachability and TE Information ...................11
5. Comments on Advanced Functions .................................12
5.1. LSP Re-Optimization .......................................12
5.2. LSP Setup Failure .........................................13
5.3. LSP Repair ................................................14
5.4. Fast Reroute ..............................................14
5.5. Comments on Path Diversity ................................15
5.6. Domain-Specific Constraints ...............................16
5.7. Policy Control ............................................17
5.8. Inter-Domain Operations and Management (OAM) ..............17
5.9. Point-to-Multipoint .......................................17
5.10. Applicability to Non-Packet Technologies .................17
6. Security Considerations ........................................18
7. Acknowledgements ...............................................19
8. Normative References ...........................................19
9. Informative References .........................................20
The Traffic Engineering Working Group has developed requirements for inter-area and inter-AS Multiprotocol Label Switching (MPLS) Traffic Engineering in [RFC4105] and [RFC4216].
流量工程工作组在[RFC4105]和[RFC4216]中制定了区域间和AS间多协议标签交换（MPLS）流量工程的要求。
Various proposals have subsequently been made to address some or all of these requirements through extensions to the Resource Reservation Protocol Traffic Engineering extensions (RSVP-TE) and to the Interior Gateway Protocols (IGPs) (i.e., Intermediate System to Intermediate System (IS-IS) and OSPF).
随后提出了各种建议，通过扩展资源预留协议流量工程扩展（RSVP-TE）和内部网关协议（IGPs）（即中间系统到中间系统（IS-IS）和OSPF）来满足部分或所有这些要求。
This document introduces the techniques for establishing Traffic Engineered (TE) Label Switched Paths (LSPs) across multiple domains. In this context and within the remainder of this document, we consider all source-based and constraint-based routed LSPs and refer to them interchangeably as "TE LSPs" or "LSPs".
本文档介绍跨多个域建立流量工程（TE）标签交换路径（LSP）的技术。在此上下文中，在本文档的其余部分中，我们考虑所有基于源的和基于约束的路由LSP，并将它们交替地称为“TE LSPs”或“LSP”。
The functional components of these techniques are separated into the mechanisms for discovering reachability and TE information, for computing the paths of LSPs, and for signaling the LSPs. Note that the aim of this document is not to detail each of those techniques, which are covered in separate documents referenced from the sections of this document that introduce the techniques, but rather to propose a framework for inter-domain MPLS Traffic Engineering.
这些技术的功能组件分为用于发现可达性和TE信息、用于计算LSP路径和用于向LSP发送信号的机制。请注意，本文档的目的不是详细说明这些技术中的每一项，这些技术将在本文档介绍这些技术的章节中引用的单独文档中介绍，而是提出域间MPLS流量工程的框架。
Note that in the remainder of this document, the term "MPLS Traffic Engineering" is used equally to apply to MPLS and Generalized MPLS (GMPLS) traffic. Specific issues pertaining to the use of GMPLS in inter-domain environments (for example, policy implications of the use of the Link Management Protocol [RFC4204] on inter-domain links) are covered in separate documents such as [GMPLS-AS].
请注意，在本文档的其余部分中，术语“MPLS流量工程”同样适用于MPLS和通用MPLS（GMPLS）流量。与在域间环境中使用GMPLS相关的具体问题（例如，在域间链路上使用链路管理协议[RFC4204]的政策含义）在单独的文档中进行了说明，如[GMPLS-as]。
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. Wholly or partially overlapping domains (e.g., path computation sub-domains of areas or ASes) are not within the scope of this document.
在本文档中，域被视为地址管理或路径计算责任的公共范围内的任何网络元素集合。此类域的示例包括IGP区域和自治系统。完全或部分重叠的域（例如，区域或ASE的路径计算子域）不在本文件的范围内。
Nested domains are outside the scope of this document. It may be that some domains that are nested administratively or for the purposes of address space management can be considered as adjacent domains for the purposes of this document; however, the fact that the domains are nested is then immaterial. In the context of MPLS TE, domain A is considered to be nested within domain B if domain A is
嵌套域不在此文档范围内。就本文档而言，可能是一些以管理方式嵌套或出于地址空间管理目的的域被视为相邻域；然而，域嵌套的事实是无关紧要的。在MPLS TE的上下文中，如果域A是嵌套的，则认为域A嵌套在域B中
wholly contained in domain B, and domain B is fully or partially aware of the TE characteristics and topology of domain A.
完全包含在域B中，且域B完全或部分了解域A的TE特征和拓扑结构。
Three distinct options for signaling TE LSPs across multiple domains are identified. The choice of which options to use may be influenced by the path computation technique used (see section 3), although some path computation techniques may apply to multiple signaling options. The choice may further depend on the application to which the TE LSPs are put and the nature, topology, and switching capabilities of the network.
确定了跨多个域发送TE-lsp信号的三种不同选择。使用哪些选项的选择可能会受到所用路径计算技术的影响（参见第3节），尽管一些路径计算技术可能适用于多个信令选项。选择可能进一步取决于TE lsp被放置到的应用以及网络的性质、拓扑和交换能力。
A comparison of the usages of the different signaling options is beyond the scope of this document and should be the subject of a separate applicability statement.
不同信令选项的使用比较超出了本文件的范围，应作为单独适用性声明的主题。
Hierarchical LSPs form a fundamental part of MPLS [RFC3031] and are discussed in further detail in [RFC4206]. Hierarchical LSPs may optionally be advertised as TE links. Note that a hierarchical LSP that spans multiple domains cannot be advertised in this way because there is no concept of TE information that spans domains.
分层LSP构成MPLS[RFC3031]的基本部分，并在[RFC4206]中进一步详细讨论。分层lsp可以可选地作为TE链路进行广告。请注意，跨多个域的分层LSP不能以这种方式发布，因为没有跨域的TE信息的概念。
Hierarchical LSPs can be used in support of inter-domain TE LSPs. In particular, a hierarchical LSP may be used to achieve connectivity between any pair of Label Switching Routers (LSRs) within a domain. The ingress and egress of the hierarchical LSP could be the edge nodes of the domain in which case connectivity is achieved across the entire domain, or they could be any other pair of LSRs in the domain.
分层LSP可用于支持域间TE LSP。具体地，分层LSP可用于实现域内任何一对标签交换路由器（lsr）之间的连接。分层LSP的入口和出口可以是域的边缘节点，在这种情况下跨整个域实现连接，或者它们可以是域中的任何其他lsr对。
The technique of carrying one TE LSP within another is termed LSP nesting. A hierarchical LSP may provide a TE LSP tunnel to transport (i.e., nest) multiple TE LSPs along a common part of their paths. Alternatively, a TE LSP may carry (i.e., nest) a single LSP in a one-to-one mapping.
将一个TE-LSP装入另一个TE-LSP的技术称为LSP嵌套。分层LSP可以提供TE-LSP隧道，以沿着其路径的公共部分传输（即，嵌套）多个TE-LSP。或者，TE LSP可以在一对一映射中携带（即，嵌套）单个LSP。
The signaling trigger for the establishment of a hierarchical LSP may be the receipt of a signaling request for the TE LSP that it will carry, or may be a management action to "pre-engineer" a domain to be crossed by TE LSPs that would be used as hierarchical LSPs by the traffic that has to traverse the domain. Furthermore, the mapping (inheritance rules) between attributes of the nested and the hierarchical LSPs (including bandwidth) may be statically pre-configured or, for on-demand hierarchical LSPs, may be dynamic
用于建立分层LSP的信令触发器可以是接收到其将承载的TE LSP的信令请求，或者可以是“预先设计”TE LSP将要跨越的域的管理动作，TE LSP将被必须穿越该域的业务用作分层LSP。此外，嵌套和分层lsp（包括带宽）的属性之间的映射（继承规则）可以是静态预配置的，或者对于按需分层lsp，可以是动态的
according to the properties of the nested LSPs. Even in the dynamic case, inheritance from the properties of the nested LSP(s) can be complemented by local or domain-wide policy rules.
根据嵌套LSP的属性。即使在动态情况下，从嵌套LSP的属性继承也可以由本地或域范围的策略规则来补充。
Note that a hierarchical LSP may be constructed to span multiple domains or parts of domains. However, such an LSP cannot be advertised as a TE link that spans domains. The end points of a hierarchical LSP are not necessarily on domain boundaries, so nesting is not limited to domain boundaries.
注意，分层LSP可以被构造成跨越多个域或域的一部分。但是，这样的LSP不能作为跨域的TE链路进行广告。分层LSP的端点不一定在域边界上，因此嵌套不限于域边界。
Note also that the Interior/Exterior Gateway Protocol (IGP/EGP) routing topology is maintained unaffected by the LSP connectivity and TE links introduced by hierarchical LSPs even if they are advertised as TE links. That is, the routing protocols do not exchange messages over the hierarchical LSPs, and LSPs are not used to create routing adjacencies between routers.
还要注意，内部/外部网关协议（IGP/EGP）路由拓扑不受LSP连接和分层LSP引入的TE链路的影响，即使它们被宣传为TE链路。也就是说，路由协议不通过分层LSP交换消息，并且LSP不用于在路由器之间创建路由邻接。
During the operation of establishing a nested LSP that uses a hierarchical LSP, the SENDER_TEMPLATE and SESSION objects remain unchanged along the entire length of the nested LSP, as do all other objects that have end-to-end significance.
在建立使用分层LSP的嵌套LSP的操作过程中，发送者_模板和会话对象在嵌套LSP的整个长度上保持不变，具有端到端重要性的所有其他对象也是如此。
A single contiguous LSP is established from ingress to egress in a single signaling exchange. No further LSPs are required to be established to support this LSP so that hierarchical or stitched LSPs are not needed.
在单个信令交换中从入口到出口建立单个连续LSP。不需要建立进一步的LSP来支持此LSP，因此不需要分层或缝合LSP。
A contiguous LSP uses the same Session/LSP ID along the whole of its path (that is, at each LSR). The notions of "splicing" together different LSPs or of "shuffling" Session or LSP identifiers are not considered.
连续LSP在其整个路径上（即在每个LSR上）使用相同的会话/LSP ID。不考虑将不同LSP“拼接”在一起或“洗牌”会话或LSP标识符的概念。
LSP Stitching is described in [STITCH]. In the LSP stitching model, separate LSPs (referred to as a TE LSP segments) are established and are "stitched" together in the data plane so that a single end-to-end Label Switched Path is achieved. The distinction is that the component LSP segments are signaled as distinct TE LSPs in the control plane. Each signaled TE LSP segment has a different source and destination.
LSP缝合在[STITCH]中介绍。在LSP缝合模型中，建立单独的LSP（称为TE LSP段）并在数据平面中“缝合”在一起，从而实现单个端到端标签交换路径。区别在于，组件LSP段在控制平面中作为不同的TE LSP发送信号。每个有信号的TE LSP段具有不同的源和目的地。
LSP stitching can be used in support of inter-domain TE LSPs. In particular, an LSP segment may be used to achieve connectivity between any pair of LSRs within a domain. The ingress and egress of the LSP segment could be the edge nodes of the domain in which case
LSP缝合可用于支持域间TE LSP。具体地，LSP段可用于实现域内任何lsr对之间的连接。LSP段的入口和出口可以是域的边缘节点，在这种情况下
connectivity is achieved across the entire domain, or they could be any other pair of LSRs in the domain.
连接在整个域中实现，也可以是域中的任何其他LSR对。
The signaling trigger for the establishment of a TE LSP segment may be the establishment of the previous TE LSP segment, the receipt of a setup request for TE LSP that it plans to stitch to a local TE LSP segment, or a management action.
用于建立TE-LSP段的信令触发可以是建立先前的TE-LSP段、接收到其计划缝合到本地TE-LSP段的TE-LSP的设置请求或管理动作。
LSP segments may be managed and advertised as TE links.
LSP段可以作为TE链路来管理和公布。
There is nothing to prevent the mixture of signaling methods described above when establishing a single, end-to-end, inter-domain TE LSP. It may be desirable in this case for the choice of the various methods to be reported along the path, perhaps through the Record Route Object (RRO).
当建立单个端到端域间TE LSP时，没有任何东西可以防止上述信令方法的混合。在这种情况下，可能希望选择沿路径（可能通过记录路由对象（RRO））报告的各种方法。
If there is a desire to restrict which methods are used, this must be signaled as described in the next section.
如果希望限制所使用的方法，则必须按照下一节中的说明发出信号。
Notwithstanding the previous section, an ingress LSR may wish to restrict the signaling methods applied to a particular LSP at domain boundaries across the network. Such control, where it is required, may be achieved by the definition of appropriate new flags in the SESSION-ATTRIBUTE object or the Attributes Flags TLV of the LSP_ATTRIBUTES object [RFC4420]. Before defining a mechanism to provide this level of control, the functional requirement to control the way in which the network delivers a service must be established. Also, due consideration must be given to the impact on interoperability since new mechanisms must be backwards compatible, and care must be taken to avoid allowing standards-conformant implementations that each supports a different functional subset in such a way that they are not capable of establishing LSPs.
尽管有前面的部分，入口LSR可能希望限制应用于跨网络的域边界处的特定LSP的信令方法。如果需要，可以通过在会话属性对象中定义适当的新标志或LSP_属性对象的属性标志TLV[RFC4420]来实现这种控制。在定义提供这种控制级别的机制之前，必须确定控制网络提供服务的方式的功能需求。此外，必须适当考虑对互操作性的影响，因为新机制必须向后兼容，并且必须注意避免允许符合标准的实现，每个实现都支持不同的功能子集，从而无法建立LSP。
The discussion of path computation techniques within this document is limited significantly to the determination of where computation may take place and what components of the full path may be determined.
本文件中对路径计算技术的讨论主要限于确定在何处进行计算以及确定完整路径的哪些部分。
The techniques used are closely tied to the signaling methodologies described in the previous section in that certain computation techniques may require the use of particular signaling approaches and vice versa.
所使用的技术与前一节中描述的信令方法密切相关，因为某些计算技术可能需要使用特定的信令方法，反之亦然。
Any discussion of the appropriateness of a particular path computation technique in any given circumstance is beyond the scope of this document and should be described in a separate applicability statement.
关于特定路径计算技术在任何给定情况下的适用性的任何讨论超出了本文件的范围，应在单独的适用性声明中进行说明。
Path computation algorithms are firmly out of the scope of this document.
路径计算算法完全不在本文档的范围内。
Path computation may be performed by offline tools or by a network planner. The resultant path may be supplied to the ingress LSR as part of the TE LSP or service request, and encoded by the ingress LSR as an Explicit Route Object (ERO) on the Path message that is sent out.
路径计算可由离线工具或网络规划器执行。结果路径可作为TE LSP或服务请求的一部分提供给入口LSR，并由入口LSR编码为发送的路径消息上的显式路由对象（ERO）。
There is no reason why the path provided by the operator should not span multiple domains if the relevant information is available to the planner or the offline tool. The definition of what information is needed to perform this operation and how that information is gathered, is outside the scope of this document.
如果计划者或脱机工具可以使用相关信息，则操作员提供的路径没有理由不跨越多个域。执行此操作需要哪些信息以及如何收集这些信息的定义超出了本文档的范围。
The head-end, or ingress, LSR may assume responsibility for path computation when the operator supplies part or none of the explicit path. The operator must, in any case, supply at least the destination address (egress) of the LSP.
当操作员提供部分或全部显式路径时，前端或入口LSR可能负责路径计算。在任何情况下，操作员必须至少提供LSP的目标地址（出口）。
If the ingress has sufficient visibility of the topology and TE information for all of the domains across which it will route the LSP to its destination, then it may compute and provide the entire path. The quality of this path (that is, its optimality as discussed in section 3.5) can be better if the ingress has full visibility into all relevant domains rather than just sufficient visibility to provide some path to the destination.
如果入口对其将LSP路由到其目的地的所有域的拓扑和TE信息具有足够的可见性，则入口可以计算并提供整个路径。如果入口对所有相关域具有完全可视性，而不仅仅是提供通往目的地的路径的足够可视性，则该路径的质量（即第3.5节中讨论的最佳性）可能会更好。
Extreme caution must be exercised in consideration of the distribution of the requisite TE information. See section 4.
考虑到所需TE信息的分发，必须格外小心。见第4节。
It may be that the ingress does not have full visibility of the topology of all domains, but does have information about the connectedness of the domains and the TE resource availability across the domains. In this case, the ingress is not able to provide a
入口可能不具备所有域拓扑的完全可视性，但具有关于域的连接性和跨域的TE资源可用性的信息。在这种情况下，入口无法提供
fully specified strict explicit path from ingress to egress. However, for example, the ingress might supply an explicit path that comprises:
从入口到出口的完全指定的严格显式路径。然而，例如，入口可以提供包括以下内容的显式路径：
- explicit hops from ingress to the local domain boundary - loose hops representing the domain entry points across the network - a loose hop identifying the egress.
- 从入口到本地域边界的显式跃点-表示网络中域入口点的松散跃点-标识出口的松散跃点。
Alternatively, the explicit path might be expressed as:
或者，显式路径可以表示为：
- explicit hops from ingress to the local domain boundary - strict hops giving abstract nodes representing each domain in turn - a loose hop identifying the egress.
- 从入口到本地域边界的显式跳数-严格跳数依次给出表示每个域的抽象节点-标识出口的松散跳数。
These two explicit path formats could be mixed according to the information available resulting in different combinations of loose hops and abstract nodes.
这两种显式路径格式可以根据可用信息进行混合，从而产生松散跳数和抽象节点的不同组合。
This form of explicit path relies on some further computation technique being applied at the domain boundaries. See section 3.3.
这种形式的显式路径依赖于在域边界处应用的某些进一步的计算技术。见第3.3节。
As with the multi-domain visibility option, extreme caution must be exercised in consideration of the distribution of the requisite TE information. See section 4.
与多域可见性选项一样，考虑到所需TE信息的分布，必须格外小心。见第4节。
A final possibility for ingress-based computation is that the ingress LSR has visibility only within its own domain, and connectivity information only as far as determining one or more domain exit points that may be suitable for carrying the LSP to its egress.
基于入口的计算的最后一种可能性是入口LSR仅在其自己的域内具有可见性，并且连接信息仅在确定可能适合将LSP携带到其出口的一个或多个域出口点时具有可见性。
In this case, the ingress builds an explicit path that comprises just:
在这种情况下，入口构建的显式路径仅包括：
- explicit hops from ingress to the local domain boundary - a loose hop identifying the egress.
- 从入口到本地域边界的显式跳数-标识出口的松散跳数。
If the partial explicit path methods described in sections 3.2.2 or 3.2.3 are applied, then the LSR at each domain boundary is responsible for ensuring that there is sufficient path information added to the Path message to carry it at least to the next domain boundary (that is, out of the new domain).
如果应用了第3.2.2节或第3.2.3节中描述的部分显式路径方法，则每个域边界处的LSR负责确保路径消息中添加了足够的路径信息，以将其至少传送到下一个域边界（即新域之外）。
If the LSR at the domain boundary has full visibility to the egress then it can supply the entire explicit path. Note, however, that the ERO processing rules of [RFC3209] state that it should only update the ERO as far as the next specified hop (that is, the next domain boundary if one was supplied in the original ERO) and, of course, must not insert ERO subobjects immediately before a strict hop.
如果域边界处的LSR对出口具有完全可见性，则它可以提供整个显式路径。但是，请注意，[RFC3209]的ERO处理规则规定，它只应在下一个指定跃点（即，如果原始ERO中提供了下一个域边界）更新ERO，当然，不能在严格跃点之前插入ERO子对象。
If the LSR at the domain boundary has only partial visibility (using the definitions of section 3.2.2), it will fill in the path as far as the next domain boundary, and will supply further domain/domain boundary information if not already present in the ERO.
如果域边界处的LSR仅具有部分可见性（使用第3.2.2节的定义），则它将填充到下一个域边界的路径，并将提供更多域/域边界信息（如果ERO中尚未提供）。
If the LSR at the domain boundary has only local visibility into the immediate domain, it will simply add information to the ERO to carry the Path message as far as the next domain boundary.
如果域边界处的LSR仅对直接域具有局部可见性，则它将简单地向ERO添加信息，以将路径消息传送到下一个域边界。
Domain boundary path computations are performed independently from each other. Domain boundary LSRs may have different computation capabilities, run different path computation algorithms, apply different sets of constraints and optimization criteria, and so forth, which might result in path segment quality that is unpredictable to and out of the control of the ingress LSR. A solution to this issue lies in enhancing the information signaled during LSP setup to include a larger set of constraints and to include the paths of related LSPs (such as diverse protected LSPs) as described in [GMPLS-E2E].
域边界路径计算彼此独立执行。域边界LSR可以具有不同的计算能力、运行不同的路径计算算法、应用不同的约束集和优化标准等，这可能导致入口LSR无法预测和控制的路径段质量。该问题的解决方案在于增强LSP设置期间发出信号的信息，以包括更大的约束集，并包括[GMPLS-E2E]中所述的相关LSP（如各种受保护LSP）的路径。
It is also the case that paths generated on domain boundaries may produce loops. Specifically, the paths computed may loop back into a domain that has already been crossed by the LSP. This may or may not be a problem, and might even be desirable, but could also give rise to real loops. This can be avoided by using the recorded route (RRO) to provide exclusions within the path computation algorithm, but in the case of lack of trust between domains it may be necessary for the RRO to indicate the previously visited domains. Even this solution is not available where the RRO is not available on a Path message. Note that when an RRO is used to provide exclusions, and a loop-free path is found to be not available by the computation at a downstream border node, crankback [CRANKBACK] may enable an upstream border node to select an alternate path.
域边界上生成的路径也可能产生循环。具体地说，所计算的路径可以循环回到LSP已经穿过的域中。这可能是问题，也可能不是问题，甚至可能是可取的，但也可能导致真正的循环。这可以通过使用记录路由（RRO）在路径计算算法中提供排除来避免，但是在域之间缺乏信任的情况下，RRO可能需要指示先前访问的域。即使在路径消息上没有RRO的情况下，此解决方案也不可用。请注意，当使用RRO提供排除时，并且通过下游边界节点处的计算发现无循环路径不可用，回退[回退]可使上游边界节点选择备用路径。
The computation techniques in sections 3.2 and 3.3 rely on topology and TE information being distributed to the ingress LSR and those LSRs at domain boundaries. These LSRs are responsible for computing paths. Note that there may be scaling concerns with distributing the required information; see section 4.
第3.2节和第3.3节中的计算技术依赖于分布到入口LSR和域边界处的LSR的拓扑和TE信息。这些LSR负责计算路径。注意，分发所需信息时可能存在缩放问题；见第4节。
An alternative technique places the responsibility for path computation with a Path Computation Element (PCE) [RFC4655]. There may be either a centralized PCE, or multiple PCEs (each having local visibility and collaborating in a distributed fashion to compute an end-to-end path) across the entire network and even within any one domain. The PCE may collect topology and TE information from the same sources as would be used by LSRs in the previous paragraph, or though other means.
另一种技术将路径计算的责任放在路径计算元素（PCE）[RFC4655]上。在整个网络中，甚至在任何一个域中，可能存在一个集中式PCE，也可能存在多个PCE（每个PCE都具有本地可见性，并以分布式方式协作以计算端到端路径）。PCE可以从上一段中LSR使用的相同来源收集拓扑和TE信息，或者通过其他方式收集。
Each LSR called upon to perform path computation (and even the offline management tools described in section 3.1) may abdicate the task to a PCE of its choice. The selection of PCE(s) may be driven by static configuration or the dynamic discovery.
被要求执行路径计算的每个LSR（甚至第3.1节中描述的离线管理工具）都可以将任务让给其选择的PCE。PCE的选择可以由静态配置或动态发现驱动。
A PCE may have full visibility, perhaps through connectivity to multiple domains. In this case, it is able to supply a full explicit path as in section 3.2.1.
PCE可能通过连接到多个域而具有完全可见性。在这种情况下，它能够提供第3.2.1节所述的完整显式路径。
Note that although a centralized PCE or multiple collaborative PCEs may have full visibility into one or more domains, it may be desirable (e.g., to preserve topology confidentiality) that the full path not be provided to the ingress LSR. Instead, a partial path is supplied (as in section 3.2.2 or 3.2.3), and the LSRs at each domain boundary are required to make further requests for each successive segment of the path.
注意，尽管集中式PCE或多个协作PCE可以对一个或多个域具有完全可见性，但是不向入口LSR提供完整路径可能是可取的（例如，为了保持拓扑机密性）。相反，提供部分路径（如第3.2.2节或第3.2.3节所述），每个域边界处的LSR需要对路径的每个连续段发出进一步的请求。
In this way, an end-to-end path may be computed using the full network capabilities, but confidentiality between domains may be preserved. Optionally, the PCE(s) may compute the entire path at the first request and hold it in storage for subsequent requests, or it may recompute each leg of the path on each request or at regular intervals until requested by the LSRs establishing the LSP.
这样，可以使用完整的网络功能来计算端到端路径，但是可以保持域之间的机密性。可选地，PCE可以在第一个请求时计算整个路径并将其保存在存储器中以供后续请求，或者可以在每个请求时或以固定间隔重新计算路径的每个分支，直到建立LSP的lsr请求为止。
It may be the case that the centralized PCE or the collaboration between PCEs may define a trust relationship greater than that normally operational between domains.
在这种情况下，集中式PCE或PCE之间的协作可能会定义一种信任关系，该信任关系大于域之间通常可操作的信任关系。
A third way that PCEs may be used is simply to have one (or more) per domain. Each LSR within a domain that wishes to derive a path across the domain may consult its local PCE.
第三种可能使用PCE的方法是简单地在每个域中使用一个（或多个）。域内希望在域上导出路径的每个LSR可以咨询其本地PCE。
This mechanism could be used for all path computations within the domain, or specifically limited to computations for LSPs that will leave the domain where external connectivity information can then be restricted to just the PCE.
该机制可用于域内的所有路径计算，或特别限于将离开域的lsp的计算，其中外部连接信息可仅限于PCE。
There are many definitions of an optimal path depending on the constraints applied to the path computation. In a multi-domain environment, the definitions are multiplied so that an optimal route might be defined as the route that would be computed in the absence of domain boundaries. Alternatively, another constraint might be applied to the path computation to reduce or limit the number of domains crossed by the LSP.
根据应用于路径计算的约束，有许多最优路径的定义。在多域环境中，会将定义相乘，以便将最佳路由定义为在没有域边界的情况下计算的路由。或者，可以将另一个约束应用于路径计算，以减少或限制LSP穿过的域的数量。
It is easy to construct examples that show that partitioning a network into domains, and the resulting loss or aggregation of routing information may lead to the computation of routes that are other than optimal. It is impossible to guarantee optimal routing in the presence of aggregation / abstraction / summarization of routing information.
很容易构造示例来说明将网络划分为多个域以及由此导致的路由信息丢失或聚合可能会导致计算非最优路由。在存在路由信息的聚合/抽象/汇总的情况下，不可能保证最佳路由。
It is beyond the scope of this document to define what is an optimum path for an inter-domain TE LSP. This debate is abdicated in favor of requirements documents and applicability statements for specific deployment scenarios. Note, however, that the meaning of certain computation metrics may differ between domains (see section 5.6).
定义域间TE LSP的最佳路径超出了本文档的范围。这场辩论被放弃，转而支持针对特定部署场景的需求文档和适用性声明。然而，请注意，某些计算指标的含义在不同领域可能有所不同（见第5.6节）。
Traffic Engineering information is collected into a TE Database (TED) on which path computation algorithms operate either directly or by first constructing a network graph.
交通工程信息被收集到一个TE数据库（TED）中，路径计算算法在该数据库上直接运行或首先构建一个网络图。
The path computation techniques described in the previous section make certain demands upon the distribution of reachability information and the TE capabilities of nodes and links within domains as well as the TE connectivity across domains.
前一节中描述的路径计算技术对可达性信息的分布、域内节点和链路的TE能力以及跨域的TE连接性提出了特定的要求。
Currently, TE information is distributed within domains by additions to IGPs [RFC3630], [RFC3784].
目前，TE信息通过添加到IGPs[RFC3630]、[RFC3784]而分布在域内。
In cases where two domains are interconnected by one or more links (that is, the domain boundary falls on a link rather than on a node), there should be a mechanism to distribute the TE information associated with the inter-domain links to the corresponding domains. This would facilitate better path computation and reduce TE-related crankbacks on these links.
在两个域通过一个或多个链路互连的情况下（即，域边界落在链路上而不是节点上），应该有一种机制将与域间链路相关联的TE信息分发到相应的域。这将促进更好的路径计算，并减少这些链路上与TE相关的回退。
Where a domain is a subset of an IGP area, filtering of TE information may be applied at the domain boundary. This filtering may be one way or two way.
在域是IGP区域的子集的情况下，可以在域边界处应用TE信息的过滤。这种过滤可以是单向的，也可以是双向的。
Where information needs to reach a PCE that spans multiple domains, the PCE may snoop on the IGP traffic in each domain, or play an active part as an IGP-capable node in each domain. The PCE might also receive TED updates from a proxy within the domain.
当信息需要到达跨越多个域的PCE时，PCE可以窥探每个域中的IGP流量，或者作为每个域中具有IGP能力的节点发挥活动部分。PCE还可能从域内的代理接收TED更新。
It is possible that an LSR that performs path computation (for example, an ingress LSR) obtains the topology and TE information of not just its own domain, but other domains as well. This information may be subject to filtering applied by the advertising domain (for example, the information may be limited to Forwarding Adjacencies (FAs) across other domains, or the information may be aggregated or abstracted).
执行路径计算的LSR（例如，入口LSR）可能不仅获得其自身域的拓扑和TE信息，还获得其他域的拓扑和TE信息。该信息可能受到广告域应用的过滤的影响（例如，该信息可能被限制为跨其他域转发邻接（FAs），或者该信息可能被聚合或抽象）。
Before starting work on any protocols or protocol extensions to enable cross-domain reachability and TE advertisement in support of inter-domain TE, the requirements and benefits must be clearly established. This has not been done to date. Where any cross-domain reachability and TE information needs to be advertised, consideration must be given to TE extensions to existing protocols such as BGP, and how the information advertised may be fed to the IGPs. It must be noted that any extensions that cause a significant increase in the amount of processing (such as aggregation computation) at domain boundaries, or a significant increase in the amount of information flooded (such as detailed TE information) need to be treated with extreme caution and compared carefully with the scaling requirements expressed in [RFC4105] and [RFC4216].
在开始任何协议或协议扩展工作以实现跨域可达性和TE广告以支持域间TE之前，必须明确确定要求和好处。到目前为止还没有这样做。如果需要公布任何跨域可达性和TE信息，则必须考虑对现有协议（如BGP）的TE扩展，以及如何将公布的信息提供给IGP。必须注意的是，任何扩展都会导致域边界处的处理量（如聚合计算）显著增加，或淹没的信息量（如详细的TE信息）显著增加需要极其谨慎地处理，并与[RFC4105]和[RFC4216]中表示的缩放要求进行仔细比较。
This section provides some non-definitive comments on the constraints placed on advanced MPLS TE functions by inter-domain MPLS. It does not attempt to state the implications of using one inter-domain technique or another. Such material is deferred to appropriate applicability statements where statements about the capabilities of existing or future signaling, routing, and computation techniques to deliver the functions listed should be made.
本节提供了一些关于域间MPLS对高级MPLS TE功能的限制的非确定性评论。它并不试图说明使用一种域间技术或另一种技术的含义。此类材料应遵循适当的适用性声明，其中应说明现有或未来信令、路由和计算技术的能力，以交付所列功能。
Re-optimization is the process of moving a TE LSP from one path to another, more preferable path (where no attempt is made in this document to define "preferable" as no attempt was made to define "optimal"). Make-before-break techniques are usually applied to ensure that traffic is disrupted as little as possible. The Shared
再优化是将TE LSP从一条路径移动到另一条更优选路径的过程（本文件中未尝试定义“优选”，因为未尝试定义“最优”）。通常采用先通后断技术，以确保交通尽可能少地中断。共享的
Explicit style is usually used to avoid double booking of network resources.
显式风格通常用于避免重复预订网络资源。
Re-optimization may be available within a single domain. Alternatively, re-optimization may involve a change in route across several domains or might involve a choice of different transit domains.
可以在单个域中进行重新优化。或者，重新优化可能涉及跨多个域的路线更改，或者可能涉及选择不同的中转域。
Re-optimization requires that all or part of the path of the LSP be re-computed. The techniques used may be selected as described in section 3, and this will influence whether the whole or part of the path is re-optimized.
重新优化要求重新计算LSP的全部或部分路径。可按照第3节所述选择所使用的技术，这将影响路径的全部或部分是否被重新优化。
The trigger for path computation and re-optimization may be an operator request, a timer, information about a change in availability of network resources, or a change in operational parameters (for example, bandwidth) of an LSP. This trigger must be applied to the point in the network that requests re-computation and controls re-optimization and may require additional signaling.
用于路径计算和重新优化的触发器可以是操作员请求、定时器、关于网络资源的可用性的变化的信息，或者LSP的操作参数（例如，带宽）的变化。此触发器必须应用于网络中请求重新计算和控制重新优化且可能需要额外信令的点。
Note also that where multiple mutually-diverse paths are applied end-to-end (i.e., not simply within protection domains; see section 5.5) the point of calculation for re-optimization (whether it is PCE, ingress, or domain entry point) needs to know all such paths before attempting re-optimization of any one path. Mutual diversity here means that a set of computed paths has no commonality. Such diversity might be link, node, Shared Risk Link Group (SRLG), or even domain disjointedness according to circumstances and the service being delivered.
还请注意，如果端到端应用了多个相互不同的路径（即，不只是在保护域内；参见第5.5节），则重新优化的计算点（无论是PCE、入口还是域入口点）需要在尝试重新优化任何一条路径之前了解所有此类路径。这里的相互分集意味着一组计算路径没有公共性。这种多样性可能是链接、节点、共享风险链接组（SRLG），甚至根据环境和所提供的服务的域分离。
It may be the case that re-optimization is best achieved by recomputing the paths of multiple LSPs at once. Indeed, this can be shown to be most efficient when the paths of all LSPs are known, not simply those LSPs that originate at a particular ingress. While this problem is inherited from single domain re-optimization and is out of scope within this document, it should be noted that the problem grows in complexity when LSPs wholly within one domain affect the re-optimization path calculations performed in another domain.
在这种情况下，最好通过一次重新计算多个LSP的路径来实现重新优化。事实上，当所有lsp的路径都已知时，这可以被证明是最有效的，而不仅仅是那些起源于特定入口的lsp。虽然该问题继承自单域重新优化，不在本文档范围内，但应注意，当一个域内的LSP完全影响另一个域中执行的重新优化路径计算时，该问题变得更加复杂。
When an inter-domain LSP setup fails in some domain other than the first, various options are available for reporting and retrying the LSP.
当域间LSP设置在第一个域以外的某些域中失败时，可以使用各种选项来报告和重试LSP。
In the first instance, a retry may be attempted within the domain that contains the failure. That retry may be attempted by nodes wholly within the domain, or the failure may be referred back to the LSR at the domain boundary.
在第一个实例中，可以在包含故障的域内尝试重试。该重试可由整个域内的节点尝试，或者故障可被引用回域边界处的LSR。
If the failure cannot be bypassed within the domain where the failure occurred (perhaps there is no suitable alternate route, perhaps rerouting is not allowed by domain policy, or perhaps the Path message specifically bans such action), the error must be reported back to the previous or head-end domain.
如果无法在发生故障的域内绕过故障（可能没有合适的备用路由，可能域策略不允许重新路由，或者路径消息明确禁止此类操作），则必须将错误报告回前一个域或前端域。
Subsequent repair attempts may be made by domains further upstream, but will only be properly effective if sufficient information about the failure and other failed repair attempts is also passed back upstream [CRANKBACK]. Note that there is a tension between this requirement and that of topology confidentiality although crankback aggregation may be applicable at domain boundaries.
后续修复尝试可由更上游的域进行，但只有在故障和其他失败的修复尝试的充分信息也传回上游[回退]的情况下，才会正确有效。请注意，尽管回退聚合可能适用于域边界，但这一要求与拓扑机密性之间存在紧张关系。
Further attempts to signal the failed LSP may apply the information about the failures as constraints to path computation, or may signal them as specific path exclusions [EXCLUDE].
向失败的LSP发送信号的进一步尝试可以将关于失败的信息作为约束应用于路径计算，或者可以将其作为特定路径排除[EXCLUDE]发送信号。
When requested by signaling, the failure may also be systematically reported to the head-end LSR.
当通过信令请求时，故障也可以系统地报告给前端LSR。
An LSP that fails after it has been established may be repaired dynamically by re-routing. The behavior in this case is either like that for re-optimization, or for handling setup failures (see previous two sections). Fast Reroute may also be used (see below).
建立后失败的LSP可以通过重新路由动态修复。这种情况下的行为要么类似于重新优化，要么类似于处理设置失败（请参见前两节）。也可使用快速重路由（见下文）。
MPLS Traffic Engineering Fast Reroute ([RFC4090]) defines local protection schemes intended to provide fast recovery (in 10s of msecs) of fast-reroutable packet-based TE LSPs upon link/SRLG/Node failure. A backup TE LSP is configured and signaled at each hop, and activated upon detecting or being informed of a network element failure. The node immediately upstream of the failure (called the PLR, or Point of Local Repair) reroutes the set of protected TE LSPs onto the appropriate backup tunnel(s) and around the failed resource.
MPLS流量工程快速重路由（[RFC4090]）定义了本地保护方案，旨在在链路/SRLG/节点发生故障时提供基于快速重路由分组的TE LSP的快速恢复（以10毫秒为单位）。备份TE LSP在每个跃点处被配置和发信号，并且在检测到或被告知网络元件故障时被激活。紧接故障上游的节点（称为PLR或本地修复点）将受保护的TE LSP集重新路由到相应的备份隧道上并围绕故障资源。
In the context of inter-domain TE, there are several different failure scenarios that must be analyzed. Provision of suitable solutions may be further complicated by the fact that [RFC4090] specifies two distinct modes of operation referred to as the "one to one mode" and the "facility back-up mode".
在域间TE的上下文中，必须分析几个不同的故障场景。由于[RFC4090]规定了两种不同的操作模式，即“一对一模式”和“设施备用模式”，因此提供合适的解决方案可能会更加复杂。
The failure scenarios specific to inter-domain TE are as follows:
特定于域间TE的故障场景如下：
- Failure of a domain edge node that is present in both domains. There are two sub-cases:
- 两个域中都存在的域边缘节点出现故障。有两个子案例：
- The Point of Local Repair (PLR) and the Merge Point (MP) are in the same domain.
- 本地修复点（PLR）和合并点（MP）位于同一域中。
- The PLR and the MP are in different domains.
- PLR和MP在不同的领域。
- Failure of a domain edge node that is only present in one of the domains.
- 仅在其中一个域中存在的域边缘节点出现故障。
- Failure of an inter-domain link.
- 域间链接失败。
Although it may be possible to apply the same techniques for Fast Reroute (FRR) to the different methods of signaling inter-domain LSPs described in section 2, the results of protection may be different when it is the boundary nodes that need to be protected, and when they are the ingress and egress of a hierarchical LSP or stitched LSP segment. In particular, the choice of PLR and MP may be different, and the length of the protection path may be greater. These uses of FRR techniques should be explained further in applicability statements or, in the case of a change in base behavior, in implementation guidelines specific to the signaling techniques.
尽管可以将用于快速重路由（FRR）的相同技术应用于第2节中描述的域间LSP的不同信令方法，但是当需要保护的是边界节点时，以及当它们是分层LSP或缝合LSP段的入口和出口时，保护的结果可能不同。具体地，PLR和MP的选择可能不同，并且保护路径的长度可能更大。FRR技术的这些使用应在适用性声明中进一步解释，或者在基本行为发生变化的情况下，在特定于信令技术的实施指南中进一步解释。
Note that after local repair has been performed, it may be desirable to re-optimize the LSP (see section 5.1). If the point of re-optimization (for example, the ingress LSR) lies in a different domain to the failure, it may rely on the delivery of a PathErr or Notify message to inform it of the local repair event.
注意，在进行局部维修后，可能需要重新优化LSP（见第5.1节）。如果重新优化点（例如，入口LSR）位于与故障不同的域中，它可能依赖于PathErr或Notify消息的传递来通知它本地修复事件。
It is important to note that Fast Reroute techniques are only applicable to packet switching networks because other network technologies cannot apply label stacking within the same switching type. Segment protection [GMPLS-SEG] provides a suitable alternative that is applicable to packet and non-packet networks.
需要注意的是，快速重路由技术仅适用于分组交换网络，因为其他网络技术无法在同一交换类型内应用标签堆叠。段保护[GMPLS-SEG]提供了适用于分组和非分组网络的合适替代方案。
Diverse paths may be required in support of load sharing and/or protection. Such diverse paths may be required to be node diverse, link diverse, fully path diverse (that is, link and node diverse), or SRLG diverse.
可能需要不同的路径来支持负载共享和/或保护。这种多样性路径可能需要节点多样性、链路多样性、完全路径多样性（即链路和节点多样性）或SRLG多样性。
Diverse path computation is a classic problem familiar to all graph theory majors. The problem is compounded when there are areas of "private knowledge" such as when domains do not share topology
多元路径计算是所有图论专业学生都熟悉的经典问题。当存在“私有知识”区域时，例如当域不共享拓扑时，问题就更加复杂了
information. The problem can be resolved more efficiently (e.g., avoiding the "trap problem") when mutually resource disjoint paths can be computed "simultaneously" on the fullest set of information.
信息当可以在最完整的信息集上“同时”计算相互资源不相交的路径时，可以更有效地解决问题（例如，避免“陷阱问题”）。
That being said, various techniques (out of the scope of this document) exist to ensure end-to-end path diversity across multiple domains.
也就是说，存在各种技术（不在本文档范围内）来确保跨多个域的端到端路径多样性。
Many network technologies utilize "protection domains" because they fit well with the capabilities of the technology. As a result, many domains are operated as protection domains. In this model, protection paths converge at domain boundaries.
许多网络技术利用“保护域”，因为它们与该技术的功能非常匹配。因此，许多域被用作保护域。在该模型中，保护路径收敛于域边界。
Note that the question of SRLG identification is not yet fully answered. There are two classes of SRLG:
请注意，SRLG标识问题尚未得到完全回答。SRLG分为两类：
- those that indicate resources that are all contained within one domain
- 那些表示所有资源都包含在一个域中的资源
- those that span domains.
- 那些跨域的。
The former might be identified using a combination of a globally scoped domain ID, and an SRLG ID that is administered by the domain. The latter requires a global scope to the SRLG ID. Both schemes, therefore, require external administration. The former is able to leverage existing domain ID administration (for example, area and AS numbers), but the latter would require a new administrative policy.
前者可以使用全局作用域ID和由域管理的SRLG ID的组合来识别。后者需要SRLG ID的全局范围。因此，两个方案都需要外部管理。前者能够利用现有的域ID管理（例如，区域和AS编号），但后者需要新的管理策略。
While the meaning of certain constraints, like bandwidth, can be assumed to be constant across different domains, other TE constraints (such as resource affinity, color, metric, priority, etc.) may have different meanings in different domains and this may impact the ability to support Diffserv-aware MPLS, or to manage preemption.
虽然某些约束（如带宽）的含义可以假定在不同的域中是恒定的，但其他TE约束（如资源亲和力、颜色、度量、优先级等）在不同的域中可能具有不同的含义，这可能会影响支持区分服务的MPLS或管理抢占的能力。
In order to achieve consistent meaning and LSP establishment, this fact must be considered when performing constraint-based path computation or when signaling across domain boundaries.
为了实现一致的含义和LSP建立，在执行基于约束的路径计算或跨域边界发送信号时，必须考虑这一事实。
A mapping function can be derived for most constraints based on policy agreements between the domain administrators. The details of such a mapping function are outside the scope of this document, but it is important to note that the default behavior must either be that a constant mapping is applied or that any requirement to apply these constraints across a domain boundary must fail in the absence of explicit mapping rules.
可以根据域管理员之间的策略协议为大多数约束派生映射函数。此类映射函数的详细信息不在本文档的范围内，但需要注意的是，默认行为必须是应用常量映射，或者在没有明确映射规则的情况下，跨域边界应用这些约束的任何要求都必须失败。
Domain boundaries are natural points for policy control. There is little to add on this subject except to note that a TE LSP that cannot be established on a path through one domain because of a policy applied at the domain boundary may be satisfactorily established using a path that avoids the demurring domain. In any case, when a TE LSP signaling attempt is rejected due to non-compliance with some policy constraint, this should be reflected to the ingress LSR.
域边界是策略控制的自然点。除了注意到由于在域边界处应用的策略而不能在通过一个域的路径上建立的TE LSP可以使用避免解扰域的路径令人满意地建立之外，在这个主题上没有什么可补充的。在任何情况下，当TE LSP信令尝试由于不符合某些策略约束而被拒绝时，这应反映到入口LSR。
Some elements of OAM may be intentionally confined within a domain. Others (such as end-to-end liveness and connectivity testing) clearly need to span the entire multi-domain TE LSP. Where issues of topology confidentiality are strong, collaboration between PCEs or domain boundary nodes might be required in order to provide end-to-end OAM, and a significant issue to be resolved is to ensure that the end-points support the various OAM capabilities.
OAM的某些元素可能被有意地限制在域内。其他测试（如端到端活性和连接性测试）显然需要跨越整个多域TE LSP。在拓扑机密性问题严重的情况下，可能需要PCE或域边界节点之间的协作以提供端到端OAM，需要解决的一个重要问题是确保端点支持各种OAM功能。
The different signaling mechanisms described above may need refinements to [RFC4379], [BFD-MPLS], etc., to gain full end-to-end visibility. These protocols should, however, be considered in the light of topology confidentiality requirements.
上述不同的信令机制可能需要对[RFC4379]、[BFD-MPLS]等进行改进，以获得完全的端到端可视性。但是，应根据拓扑保密性要求考虑这些协议。
Route recording is a commonly used feature of signaling that provides OAM information about the path of an established LSP. When an LSP traverses a domain boundary, the border node may remove or aggregate some of the recorded information for topology confidentiality or other policy reasons.
路由记录是信令的常用功能，它提供关于已建立LSP的路径的OAM信息。当LSP穿越域边界时，边界节点可以出于拓扑机密性或其他策略原因移除或聚合一些记录的信息。
Inter-domain point-to-multipoint (P2MP) requirements are explicitly out of the scope of this document. They may be covered by other documents dependent on the details of MPLS TE P2MP solutions.
域间点对多点（P2MP）要求明确不在本文件范围内。根据MPLS TE P2MP解决方案的详细信息，其他文档可能会涵盖这些内容。
Non-packet switching technologies may present particular issues for inter-domain LSPs. While packet switching networks may utilize control planes built on MPLS or GMPLS technology, non-packet networks are limited to GMPLS.
非分组交换技术可能为域间lsp带来特殊问题。虽然分组交换网络可以利用基于MPLS或GMPLS技术的控制平面，但非分组网络仅限于GMPLS。
On the other hand, some problems such as Fast Reroute on domain boundaries (see section 5.4) may be handled by the GMPLS technique of segment protection [GMPLS-SEG] that is applicable to both packet and non-packet switching technologies.
另一方面，一些问题，如域边界上的快速重路由（见第5.4节），可通过适用于分组和非分组交换技术的GMPLS段保护技术[GMPLS-SEG]来处理。
The specific architectural considerations and requirements for inter-domain LSP setup in non-packet networks are covered in a separate document [GMPLS-AS].
非分组网络中域间LSP设置的具体架构考虑和要求在单独的文件[GMPLS-AS]中介绍。
Requirements for security within domains are unchanged from [RFC3209] and [RFC3473], and from [RFC3630] and [RFC3784]. That is, all security procedures for existing protocols in the MPLS context continue to apply for the intra-domain cases.
[RFC3209]和[RFC3473]以及[RFC3630]和[RFC3784]对域内安全性的要求保持不变。也就是说，MPLS上下文中现有协议的所有安全过程继续适用于域内情况。
Inter-domain security may be considered as a more important and more sensitive issue than intra-domain security since in inter-domain traffic engineering control and information may be passed across administrative boundaries. The most obvious and most sensitive case is inter-AS TE.
域间安全可能被视为比域内安全更重要、更敏感的问题，因为域间流量工程控制和信息可能会跨越管理边界传递。最明显和最敏感的案例是inter AS TE。
All of the intra-domain security measures for the signaling and routing protocols are equally applicable in the inter-domain case. There is, however, a greater likelihood of them being applied in the inter-domain case.
信令和路由协议的所有域内安全措施都同样适用于域间情况。然而，在域间案例中应用这些规则的可能性更大。
Security for inter-domain MPLS TE is the subject of a separate document that analyzes the security deployment models and risks. This separate document must be completed before inter-domain MPLS TE solution documents can be advanced.
域间MPLS TE的安全性是分析安全部署模型和风险的单独文档的主题。在推进域间MPLS TE解决方案文档之前，必须完成此单独文档。
Similarly, the PCE procedures [RFC4655] are subject to security measures for the exchange computation information between PCEs and for LSRs that request path computations from a PCE. The requirements for this security (set out in [RFC4657]) apply whether the LSR and PCE (or the cooperating PCEs) are in the same domain or lie across domain boundaries.
类似地，PCE过程[RFC4655]受制于PCE之间的交换计算信息和从PCE请求路径计算的lsr的安全措施。无论LSR和PCE（或合作PCE）是否在同一个域中或跨越域边界，该安全性的要求（在[RFC4657]中规定）均适用。
It should be noted, however, that techniques used for (for example) authentication require coordination of secrets, keys, or passwords between sender and receiver. Where sender and receiver lie within a single administrative domain, this process may be simple. But where sender and receiver lie in different administrative domains, cross-domain coordination between network administrators will be required in order to provide adequate security. At this stage, it is not proposed that this coordination be provided through an automatic process or through the use of a protocol. Human-to-human
然而，应该注意的是，用于（例如）认证的技术需要在发送方和接收方之间协调机密、密钥或密码。当发送方和接收方位于单个管理域内时，此过程可能很简单。但是，如果发送方和接收方位于不同的管理域中，则需要网络管理员之间进行跨域协调，以提供足够的安全性。在这一阶段，不建议通过自动过程或通过使用协议来提供这种协调。人与人之间
coordination is more likely to provide the required level of confidence in the inter-domain security.
协调更有可能为域间安全提供所需的信任级别。
One new security concept is introduced by inter-domain MPLS TE. This is the preservation of confidentiality of topology information. That is, one domain may wish to keep secret the way that its network is constructed and the availability (or otherwise) of end-to-end network resources. This issue is discussed in sections 3.4.2, 5.2, and 5.8 of this document. When there is a requirement to preserve inter-domain topology confidentiality, policy filters must be applied at the domain boundaries to avoid distributing such information. This is the responsibility of the domain that distributes information, and it may be adequately addressed by aggregation of information as described in the referenced sections.
域间MPLS-TE引入了一种新的安全概念。这是保护拓扑信息的机密性。也就是说，一个域可能希望对其网络的构建方式和端到端网络资源的可用性（或其他）保密。本文件第3.4.2、5.2和5.8节讨论了该问题。当需要保持域间拓扑机密性时，必须在域边界应用策略筛选器，以避免分发此类信息。这是分发信息的领域的责任，可以通过参考章节中所述的信息聚合来充分解决。
Applicability statements for particular combinations of signaling, routing, and path computation techniques to provide inter-domain MPLS TE solutions are expected to contain detailed security sections.
用于提供域间MPLS-TE解决方案的信令、路由和路径计算技术的特定组合的适用性声明预计将包含详细的安全部分。
The authors would like to extend their warmest thanks to Kireeti Kompella for convincing them to expend effort on this document.
作者谨向Kireeti Kompella表示最热烈的感谢，感谢他说服他们在本文件上付出努力。
Grateful thanks to Dimitri Papadimitriou, Tomohiro Otani, and Igor Bryskin for their review and suggestions on the text.
感谢Dimitri Papadimitriou、Tomohiro Otani和Igor Bryskin对本文的评论和建议。
Thanks to Jari Arkko, Gonzalo Camarillo, Brian Carpenter, Lisa Dusseault, Sam Hartman, Russ Housley, and Dan Romascanu for final review of the text.
感谢贾里·阿尔科、冈萨洛·卡马里洛、布赖恩·卡彭特、丽莎·杜肖特、萨姆·哈特曼、罗斯·霍斯利和丹·罗马斯坎努对文本进行了最终审查。
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[RFC3031]Rosen，E.，Viswanathan，A.，和R.Callon，“多协议标签交换体系结构”，RFC 30312001年1月。
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.
[RFC3209]Awduche，D.，Berger，L.，Gan，D.，Li，T.，Srinivasan，V.，和G.Swallow，“RSVP-TE：LSP隧道RSVP的扩展”，RFC 3209，2001年12月。
[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC3473]Berger，L.，Ed.“通用多协议标签交换（GMPLS）信令资源预留协议流量工程（RSVP-TE）扩展”，RFC 3473，2003年1月。
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, September 2003.
[RFC3630]Katz，D.，Kompella，K.，和D.Yeung，“OSPF版本2的交通工程（TE）扩展”，RFC 3630，2003年9月。
[RFC3784] Smit, H. and T. Li, "Intermediate System to Intermediate System (IS-IS) Extensions for Traffic Engineering (TE)", RFC 3784, June 2004.
[RFC3784]Smit，H.和T.Li，“交通工程（TE）的中间系统到中间系统（IS-IS）扩展”，RFC 37842004年6月。
[BFD-MPLS] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, "BFD For MPLS LSPs", Work in Progress, June 2006.
[BFD-MPLS]Aggarwal，R.，Kompella，K.，Nadeau，T.，和G.Swallow，“MPLS LSP的BFD”，正在进行的工作，2006年6月。
[CRANKBACK] Farrel, A., et al., "Crankback Signaling Extensions for MPLS Signaling", Work in Progress, May 2005.
[CRANKBACK]Farrel，A.等人，“MPLS信令的回溯信令扩展”，正在进行的工作，2005年5月。
[EXCLUDE] Lee, CY., Farrel, A., and DeCnodder, "Exclude Routes - Extension to RSVP-TE", Work in Progress, August 2005.
[EXCLUDE]Lee，CY.，Farrel，A.和Decnoder，“不包括路线-延伸至RSVP-TE”，在建工程，2005年8月。
[RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May 2005.
[RFC4090]Pan，P.，Swallow，G.，和A.Atlas，“LSP隧道RSVP-TE快速重路由扩展”，RFC 40902005年5月。
[GMPLS-AS] Otani, T., Kumaki, K., Okamoto, S., and W. Imajuku, "GMPLS Inter-domain Traffic Engineering Requirements", Work in Progress, August 2006.
[GMPLS-AS]Otani，T.，Kumaki，K.，Okamoto，S.，和W.Imajuku，“GMPLS域间流量工程要求”，正在进行的工作，2006年8月。
[GMPLS-E2E] Lang, J.P., Rekhter, Y., and D. Papadimitriou, Editors, "RSVP-TE Extensions in support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS)- based Recovery", Work in Progress, April 2005.
[GMPLS-E2E]Lang，J.P.，Rekhter，Y.和D.Papadimitriou，编辑，“支持端到端通用多协议标签交换（GMPLS）恢复的RSVP-TE扩展”，正在进行的工作，2005年4月。
[GMPLS-SEG] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel, "GMPLS Based Segment Recovery", Work in Progress, May 2005.
[GMPLS-SEG]Berger，L.，Bryskin，I.，Papadimitriou，D.，和A.Farrel，“基于GMPLS的段恢复”，正在进行的工作，2005年5月。
[RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005.
[RFC4206]Kompella，K.和Y.Rekhter，“具有通用多协议标签交换（GMPLS）流量工程（TE）的标签交换路径（LSP）层次结构”，RFC 4206，2005年10月。
[RFC4105] Le Roux, J.-L., Vasseur, J.-P., and J. Boyle, "Requirements for Inter-Area MPLS Traffic Engineering", RFC 4105, June 2005.
[RFC4105]Le Roux，J.-L.，Vasseur，J.-P.，和J.Boyle，“区域间MPLS流量工程的要求”，RFC 4105，2005年6月。
[RFC4204] Lang, J., "Link Management Protocol (LMP)", RFC 4204, October 2005.
[RFC4204]Lang，J.，“链路管理协议（LMP）”，RFC4204，2005年10月。
[RFC4216] Zhang, R. and J.-P. Vasseur, "MPLS Inter-Autonomous System (AS) Traffic Engineering (TE) Requirements", RFC 4216, November 2005.
[RFC4216]Zhang，R.和J.-P.Vasseur，“MPLS自治系统间（AS）流量工程（TE）要求”，RFC 42162005年11月。
[RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", RFC 4379, February 2006.
[RFC4379]Kompella，K.和G.Swallow，“检测多协议标签交换（MPLS）数据平面故障”，RFC 4379，2006年2月。
[RFC4420] Farrel, A., Papadimitriou, D., Vasseur, J.-P., and A. Ayyangar, "Encoding of Attributes for Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) Establishment Using Resource ReserVation Protocol-Traffic Engineering (RSVP-TE)", RFC 4420, February 2006.
[RFC4420]Farrel，A.，Papadimitriou，D.，Vasseur，J.-P.，和A.Ayyangar，“使用资源预留协议流量工程（RSVP-TE）建立多协议标签交换（MPLS）标签交换路径（LSP）的属性编码”，RFC 4420，2006年2月。
[RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, August 2006.
[RFC4655]Farrel，A.，Vasseur，J.-P.，和J.Ash，“基于路径计算元素（PCE）的体系结构”，RFC 46552006年8月。
[RFC4657] Ash, J. and J. Le Roux, "Path Computation Element (PCE) Communication Protocol Generic Requirements", RFC 4657, September 2006.
[RFC4657]Ash，J.和J.Le Roux，“路径计算元件（PCE）通信协议通用要求”，RFC 4657，2006年9月。
[STITCH] Ayyangar, A. and J.-P. Vasseur, "LSP Stitching with Generalized MPLS TE", Work in Progress, September 2005.
[STITCH]Ayyangar，A.和J.-P.Vasseur，“使用广义MPLS TE的LSP缝合”，正在进行的工作，2005年9月。
Authors' Addresses
作者地址
Adrian Farrel Old Dog Consulting EMail: adrian@olddog.co.uk
Adrian Farrel老狗咨询电子邮件：adrian@olddog.co.uk
Jean-Philippe Vasseur Cisco Systems, Inc 1414 Massachusetts Avenue Boxborough, MA 01719 USA EMail: jpv@cisco.com
Jean-Philippe Vasseur Cisco Systems，Inc.美国马萨诸塞州伯斯堡马萨诸塞大道1414号电子邮件：01719jpv@cisco.com
Arthi Ayyangar Nuova Systems EMail: arthi@nuovasystems.com
Arthi Ayangar Nuova Systems电子邮件：arthi@nuovasystems.com
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2006).
版权所有（C）IETF信托基金（2006年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST, AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。