Network Working Group T. Takeda, Ed.
Request for Comments: 5298 NTT
Category: Informational A. Farrel, Ed.
Old Dog Consulting
Y. Ikejiri
NTT Communications
JP. Vasseur
Cisco Systems, Inc.
August 2008
Network Working Group T. Takeda, Ed.
Request for Comments: 5298 NTT
Category: Informational A. Farrel, Ed.
Old Dog Consulting
Y. Ikejiri
NTT Communications
JP. Vasseur
Cisco Systems, Inc.
August 2008
Analysis of Inter-Domain Label Switched Path (LSP) Recovery
域间标签交换路径（LSP）恢复分析
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.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Abstract
摘要
Protection and recovery are important features of service offerings in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. Increasingly, MPLS and GMPLS networks are being extended from single domain scope to multi-domain environments.
保护和恢复是多协议标签交换（MPLS）和通用MPLS（GMPLS）网络中服务产品的重要特征。MPLS和GMPLS网络正日益从单域范围扩展到多域环境。
Various schemes and processes have been developed to establish Label Switched Paths (LSPs) in multi-domain environments. These are discussed in RFC 4726: "A Framework for Inter-Domain Multiprotocol Label Switching Traffic Engineering".
为了在多域环境中建立标签交换路径（LSP），已经开发了各种方案和过程。RFC 4726：“域间多协议标签交换流量工程框架”中讨论了这些问题。
This document analyzes the application of these techniques to protection and recovery in multi-domain networks. The main focus for this document is on establishing end-to-end diverse Traffic Engineering (TE) LSPs in multi-domain networks.
本文分析了这些技术在多域网络保护和恢复中的应用。本文档的主要重点是在多域网络中建立端到端多样化流量工程（TE）LSP。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Terminology ................................................3
1.2. Domain .....................................................4
1.3. Document Scope .............................................5
1.4. Note on Other Recovery Techniques ..........................6
1.5. Signaling Options ..........................................6
2. Diversity in Multi-Domain Networks ..............................6
2.1. Multi-Domain Network Topology ..............................7
2.2. Note on Domain Diversity ...................................8
3. Factors to Consider .............................................9
3.1. Scalability versus Optimality ..............................9
3.2. Key Concepts ..............................................10
4. Diverse LSP Setup Schemes without Confidentiality ..............12
4.1. Management Configuration ..................................12
4.2. Head-End Path Computation (with Multi-Domain Visibility) ..12
4.3. Per-Domain Path Computation ...............................12
4.3.1. Sequential Path Computation ........................13
4.3.2. Simultaneous Path Computation ......................14
4.4. Inter-Domain Collaborative Path Computation ...............15
4.4.1. Sequential Path Computation ........................15
4.4.2. Simultaneous Path Computation ......................15
5. Diverse LSP Setup Schemes with Confidentiality .................16
5.1. Management Configuration ..................................17
5.2. Head-End Path Computation (with Multi-Domain Visibility) ..17
5.3. Per-Domain Path Computation ...............................17
5.3.1. Sequential Path Computation ........................18
5.3.2. Simultaneous Path Computation ......................19
5.4. Inter-Domain Collaborative Path Computation ...............20
5.4.1. Sequential Path Computation ........................20
5.4.2. Simultaneous Path Computation ......................20
6. Network Topology Specific Considerations .......................20
7. Addressing Considerations ......................................21
8. Note on SRLG Diversity .........................................21
9. Security Considerations ........................................21
10. References ....................................................22
10.1. Normative References .....................................22
10.2. Informative References ...................................22
11. Acknowledgements ..............................................25
1. Introduction ....................................................3
1.1. Terminology ................................................3
1.2. Domain .....................................................4
1.3. Document Scope .............................................5
1.4. Note on Other Recovery Techniques ..........................6
1.5. Signaling Options ..........................................6
2. Diversity in Multi-Domain Networks ..............................6
2.1. Multi-Domain Network Topology ..............................7
2.2. Note on Domain Diversity ...................................8
3. Factors to Consider .............................................9
3.1. Scalability versus Optimality ..............................9
3.2. Key Concepts ..............................................10
4. Diverse LSP Setup Schemes without Confidentiality ..............12
4.1. Management Configuration ..................................12
4.2. Head-End Path Computation (with Multi-Domain Visibility) ..12
4.3. Per-Domain Path Computation ...............................12
4.3.1. Sequential Path Computation ........................13
4.3.2. Simultaneous Path Computation ......................14
4.4. Inter-Domain Collaborative Path Computation ...............15
4.4.1. Sequential Path Computation ........................15
4.4.2. Simultaneous Path Computation ......................15
5. Diverse LSP Setup Schemes with Confidentiality .................16
5.1. Management Configuration ..................................17
5.2. Head-End Path Computation (with Multi-Domain Visibility) ..17
5.3. Per-Domain Path Computation ...............................17
5.3.1. Sequential Path Computation ........................18
5.3.2. Simultaneous Path Computation ......................19
5.4. Inter-Domain Collaborative Path Computation ...............20
5.4.1. Sequential Path Computation ........................20
5.4.2. Simultaneous Path Computation ......................20
6. Network Topology Specific Considerations .......................20
7. Addressing Considerations ......................................21
8. Note on SRLG Diversity .........................................21
9. Security Considerations ........................................21
10. References ....................................................22
10.1. Normative References .....................................22
10.2. Informative References ...................................22
11. Acknowledgements ..............................................25
Protection and recovery in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks are described in [RFC4428]. These are important features for service delivery in MPLS and GMPLS networks.
[RFC4428]中描述了多协议标签交换（MPLS）和通用MPLS（GMPLS）网络中的保护和恢复。这些是MPLS和GMPLS网络中服务交付的重要特性。
MPLS and GMPLS networks were originally limited to single domain environments. Increasingly, multi-domain MPLS and GMPLS networks are being considered, where 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).
MPLS和GMPLS网络最初仅限于单域环境。越来越多地考虑多域MPLS和GMPLS网络，其中域被认为是地址管理或路径计算责任的公共范围内的网络元素的任何集合。此类域的示例包括内部网关协议（IGP）区域和自治系统（ASE）。
[RFC4726] provides a framework for inter-domain MPLS and GMPLS traffic engineering. It introduces and discusses the various schemes and processes to establish Label Switched Paths (LSPs) in multi-domain environments.
[RFC4726]为域间MPLS和GMPLS流量工程提供了一个框架。介绍和讨论了在多域环境中建立标签交换路径（LSP）的各种方案和过程。
However, protection and recovery introduce additional complexities to LSP establishment. Protection LSPs are generally required to be path diverse from the working LSPs that they protect. Achieving this is particularly challenging in multi-domain environments because no single path computation or planning point is capable of determining path diversity for both paths from one end to the other.
然而，保护和恢复给LSP的建立带来了额外的复杂性。保护LSP通常需要与它们所保护的工作LSP的路径不同。在多域环境中实现这一点尤其具有挑战性，因为没有单个路径计算或规划点能够确定从一端到另一端的两条路径的路径多样性。
This document analyzes various schemes to realize MPLS and GMPLS LSP recovery in multi-domain networks. The main focus for this document is on establishing end-to-end diverse Traffic Engineering (TE) LSPs in multi-domain networks.
本文分析了在多域网络中实现MPLS和GMPLS LSP恢复的各种方案。本文档的主要重点是在多域网络中建立端到端多样化流量工程（TE）LSP。
The reader is assumed to be familiar with the terminology for LSP recovery set out in [RFC4427], and with the terms introduced in [RFC4726] that provides a framework for inter-domain Label Switched Path (LSP) setup. Key terminology may also be found in [RFC4216] that sets out requirements for inter-AS MPLS traffic engineering.
假定读者熟悉[RFC4427]中规定的LSP恢复术语，以及[RFC4726]中介绍的术语，该术语为域间标签交换路径（LSP）设置提供了框架。[RFC4216]中也可以找到关键术语，该术语规定了AS间MPLS流量工程的要求。
The following key terms from those sources are used within this document.
本文件中使用了来自这些来源的以下关键术语。
- Domain: See [RFC4726]. A domain is considered to be any collection of network elements within a common sphere of address management or path computational responsibility. Note that nested domains continue to be out of scope. Section 1.2 provides additional details.
- 域：请参阅[RFC4726]。域被认为是地址管理或路径计算责任的公共范围内的网络元素的任何集合。请注意，嵌套域继续超出范围。第1.2节提供了其他详细信息。
- Working LSP: See [RFC4427]. The working LSP transports normal user traffic. Note that the term LSP and TE LSP will be used interchangeably.
- 工作LSP：参见[RFC4427]。工作LSP传输正常的用户流量。请注意，术语LSP和TE LSP将互换使用。
- Recovery LSP: See [RFC4427]. The recovery LSP transports normal user traffic when the working LSP fails. The recovery LSP may also carry user traffic even when the working LSP is operating normally and transporting the user traffic (e.g., 1+1 protection). The recovery LSP is sometimes referred to as a protecting LSP.
- 恢复LSP：请参阅[RFC4427]。当工作LSP出现故障时，恢复LSP传输正常用户流量。即使在工作LSP正常工作并传输用户通信量（例如，1+1保护）时，恢复LSP也可以承载用户通信量。恢复LSP有时称为保护LSP。
- Diversity: See [RFC4726]. Diversity means the relationship of multiple LSPs, where those LSPs do not share some specific type of resource (e.g., link, node, or shared risk link group (SRLG)). Diversity is also referred to as disjointness.
- 多样性：参见[RFC4726]。多样性是指多个LSP之间的关系，其中这些LSP不共享某些特定类型的资源（例如，链路、节点或共享风险链路组（SRLG））。多样性也被称为不连续性。
Diverse LSPs may be used for various purposes, such as load-balancing and recovery. In this document, the recovery aspect of diversity, specifically the end-to-end diversity of two traffic engineering (TE) LSPs, is the focus. The two diverse LSPs are referred to as the working LSP and recovery LSP.
不同的LSP可用于各种目的，例如负载平衡和恢复。在本文件中，分集的恢复方面，特别是两个流量工程（TE）LSP的端到端分集是重点。这两种不同的LSP称为工作LSP和恢复LSP。
- Confidentiality: See [RFC4216]. Confidentiality refers to the protection of information about the topology and resources of one domain from visibility by people or applications outside that domain.
- 保密性：见[RFC4216]。机密性是指保护一个域的拓扑和资源的信息不被该域以外的人员或应用程序看到。
In order to fully understand the issues addressed in this document, it is necessary to carefully define and scope the term "domain".
为了充分理解本文件中涉及的问题，有必要仔细定义术语“域”的定义和范围。
As defined in [RFC4726], 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. Networks accessed over the GMPLS User-to-Network Interface (UNI) [RFC4208], and Layer One Virtual Private Networks (L1VPNs) [RFC4847] are special cases of multi-domain networks.
如[RFC4726]中所定义，域被认为是地址管理或路径计算责任的公共范围内的任何网络元素集合。此类域的示例包括IGP区域和自治系统。通过GMPLS用户到网络接口（UNI）[RFC4208]和第一层虚拟专用网络（L1VPN）[RFC4847]访问的网络是多域网络的特例。
Example motivations for using more than one domain include administrative separation, scalability, and the construction of domains for the purpose of providing protection. These latter "protection domains" offer edge-to-edge protection facilities for spans or segments of end-to-end LSPs.
使用多个域的示例动机包括管理分离、可伸缩性和为提供保护而构建域。后一类“保护域”为端到端LSP的跨度或段提供边到边保护设施。
As described in [RFC4726], there could be TE parameters (such as color and priority) whose meanings are specific to each domain. In such scenarios, in order to set up inter-domain LSPs, mapping functions may be needed to transform the TE parameters based on policy agreements between domain administrators.
如[RFC4726]所述，可能存在TE参数（如颜色和优先级），其含义特定于每个域。在这种情况下，为了建立域间LSP，可能需要映射函数来根据域管理员之间的策略协议转换TE参数。
This document analyzes various schemes to realize MPLS and GMPLS LSP recovery in multi-domain networks. It is based on the existing framework for multi-domain LSP setup [RFC4726]. Note that this document does not prevent the development of additional techniques where appropriate (i.e., additional to the ones described in this document). In other words, this document shows how the existing techniques can be applied.
本文分析了在多域网络中实现MPLS和GMPLS LSP恢复的各种方案。它基于现有的多域LSP设置框架[RFC4726]。请注意，本文件不妨碍在适当情况下开发附加技术（即，本文件所述技术的附加技术）。换句话说，本文档展示了如何应用现有技术。
There are various recovery techniques for LSPs. For TE LSPs, the major techniques are end-to-end recovery [RFC4872], local protection such as Fast Reroute (FRR) [RFC4090] (in packet switching environments), and segment recovery [RFC4873] (in GMPLS).
LSP有多种恢复技术。对于TE LSP，主要技术是端到端恢复[RFC4872]、本地保护，如快速重路由（FRR）[RFC4090]（在分组交换环境中）和段恢复[RFC4873]（在GMPLS中）。
The main focus of this document is the analysis of diverse TE LSP setup schemes that can be used in the context of end-to-end recovery. The methodology is to show different combinations of functional elements such as path computation and signaling techniques.
本文档的主要重点是分析可在端到端恢复环境中使用的各种TE LSP设置方案。该方法旨在展示功能元素的不同组合，如路径计算和信令技术。
[RFC4105] and [RFC4216] describe requirements for diverse LSPs. There are various types of diversity, and this document focuses on node, link, and shared risk link group (SRLG) diversity.
[RFC4105]和[RFC4216]描述了不同LSP的要求。多样性有多种类型，本文档重点介绍节点、链路和共享风险链路组（SRLG）多样性。
Recovery LSPs may be used for 1+1 protection, 1:1 protection, or shared mesh restoration. However, the requirements for path diversity, the ways to compute diverse paths, and the signaling of these TE LSPs are common across all uses. These topics are the main scope of this document.
恢复LSP可用于1+1保护、1:1保护或共享网格恢复。然而，对路径多样性的要求、计算不同路径的方法以及这些TE-lsp的信令在所有用途中都是通用的。这些主题是本文档的主要范围。
Note that diverse LSPs may be used for various purposes in addition to recovery. An example is for load-balancing, so as to limit the traffic disruption to a portion of the traffic flow in case of a single node failure. This document does not preclude use of diverse LSP setup schemes for other purposes.
请注意，除了恢复之外，各种LSP还可用于各种目的。一个示例用于负载平衡，以便在单节点故障的情况下将业务中断限制在业务流的一部分。本文件不排除将不同的LSP设置方案用于其他目的。
The following are beyond the scope of this document.
以下内容超出了本文件的范围。
- Analysis of recovery techniques other than the use of link, node, or SRLG diverse LSPs (see Section 1.4).
- 分析除使用链路、节点或SRLG不同LSP以外的恢复技术（见第1.4节）。
- Details of maintenance of diverse LSPs, such as re-optimization and Operations and Maintenance (OAM).
- 各种LSP维护的详细信息，如重新优化和操作与维护（OAM）。
- Comparative evaluation of LSP setup schemes.
- LSP设置方案的比较评估。
Fast Reroute and segment recovery in multi-domain networks are described in Section 5.4 of [RFC4726], and a more detailed analysis is provided in Section 5 of [RFC5151]. This document does not cover any additional analysis for Fast Reroute and segment recovery in multi-domain networks.
[RFC4726]第5.4节描述了多域网络中的快速重路由和段恢复，而[RFC5151]第5节提供了更详细的分析。本文档不包括对多域网络中快速重路由和段恢复的任何其他分析。
The recovery type of an LSP or service may change at a domain boundary. That is, the recovery type could remain the same within one domain, but might be different in the next domain or on the connections between domains. This may be due to the capabilities of each domain, administrative policies, or to topology limitations. An example is where protection at the domain boundary is provided by link protection on the inter-domain links, but where protection within each domain is achieved through segment recovery. This mixture of protection techniques is beyond the scope of this document.
LSP或服务的恢复类型可能在域边界处更改。也就是说，恢复类型在一个域中可以保持不变，但在下一个域或域之间的连接上可能不同。这可能是由于每个域的功能、管理策略或拓扑限制造成的。例如，域边界上的保护由域间链路上的链路保护提供，但每个域内的保护是通过段恢复实现的。这种混合保护技术超出了本文件的范围。
Domain diversity (that is, the selection of paths that have only the ingress and egress domains in common) may be considered as one form of diversity in multi-domain networks, but this is beyond the scope of this document (see Section 2.2).
域分集（即，选择仅具有公共入口和出口域的路径）可被视为多域网络中的一种分集形式，但这超出了本文件的范围（参见第2.2节）。
There are three signaling options for establishing inter-domain TE LSPs: nesting, contiguous LSPs, and stitching [RFC4726]. The description in this document of diverse LSP setup is agnostic in relation to the signaling option used, unless otherwise specified.
建立域间TE LSP有三种信令选项：嵌套、连续LSP和缝合[RFC4726]。除非另有规定，否则本文件中对不同LSP设置的描述与所使用的信令选项无关。
Note that signaling option considerations for Fast Reroute and segment recovery are described in [RFC5151].
请注意，[RFC5151]中描述了快速重路由和段恢复的信令选项注意事项。
This section describes some assumptions about achieving path diversity in multi-domain networks.
本节描述了在多域网络中实现路径多样性的一些假设。
Figures 1 and 2 show examples of multi-domain network topologies. In Figure 1, domains are connected in a linear topology. There are multiple paths between nodes A and L, but all of them cross domain#1- domain#2-domain#3 in that order.
图1和图2显示了多域网络拓扑的示例。在图1中，域以线性拓扑连接。节点A和L之间有多条路径，但所有路径都按顺序跨域#1-域#2-域#3。
+--Domain#1--+ +--Domain#2--+ +--Domain#3--+
| | | | | |
| B------+---+---D-----E--+---+------J |
| / | | \ / | | \ |
| / | | \ / | | \ |
| A | | H | | L |
| \ | | / \ | | / |
| \ | | / \ | | / |
| C------+---+---F-----G--+---+------K |
| | | | | |
+------------+ +------------+ +------------+
+--Domain#1--+ +--Domain#2--+ +--Domain#3--+
| | | | | |
| B------+---+---D-----E--+---+------J |
| / | | \ / | | \ |
| / | | \ / | | \ |
| A | | H | | L |
| \ | | / \ | | / |
| \ | | / \ | | / |
| C------+---+---F-----G--+---+------K |
| | | | | |
+------------+ +------------+ +------------+
Figure 1: Linear Domain Connectivity
图1：线性域连接
+-----Domain#2-----+
| |
| E--------------F |
| | | |
| | | |
+-+--------------+-+
| |
| |
+--Domain#1-+--+ +-------+------+
| | | | | |
| | | | | |
| A----B--+---+--C----D |
| | | | | |
| | | | | |
+------+-------+ +--+-Domain#4--+
| |
+-+--------------+-+
| | | |
| | | |
| G--------------H |
| |
+-----Domain#3-----+
+-----Domain#2-----+
| |
| E--------------F |
| | | |
| | | |
+-+--------------+-+
| |
| |
+--Domain#1-+--+ +-------+------+
| | | | | |
| | | | | |
| A----B--+---+--C----D |
| | | | | |
| | | | | |
+------+-------+ +--+-Domain#4--+
| |
+-+--------------+-+
| | | |
| | | |
| G--------------H |
| |
+-----Domain#3-----+
Figure 2: Meshed Domain Connectivity
图2：网状域连接
In Figure 2, domains are connected in a mesh topology. There are multiple paths between nodes A and D, and these paths do not cross the same domains. If inter-domain connectivity forms a mesh, domain-level routing is required (even for the unprotected case). This is tightly coupled with the next-hop domain resolution/discovery mechanisms used in IP networks.
在图2中，域在网格拓扑中连接。节点A和D之间有多条路径，这些路径不跨相同的域。如果域间连接形成网状结构，则需要域级路由（即使在未受保护的情况下）。这与IP网络中使用的下一跳域解析/发现机制紧密结合。
In this document, we assume that domain-level routing is given via configuration, policy, or some external mechanism, and that this is not part of the path computation process described later in this document.
在本文中，我们假设域级路由是通过配置、策略或某些外部机制给出的，并且这不是本文后面描述的路径计算过程的一部分。
Domain-level routing may also allow "domain re-entry" where a path re-enters a domain that it has previously exited (e.g., domain#X-domain#Y-domain#X). This requires specific considerations when confidentiality (described in Section 3.2) is required, and is beyond the scope of this document.
域级路由也可允许“域重新进入”，其中路径重新进入其先前退出的域（例如，域#X-Domain#Y-Domain#X）。当需要保密性（如第3.2节所述）且超出本文件范围时，这需要具体考虑。
Furthermore, the working LSP and the recovery LSP may or may not be routed along the same set of domains in the same order. In this document, we assume that the working LSP and recovery LSP follow the same set of domains in the same order (via configuration, policy or some external mechanism). That is, we assume that the domain mesh topology is reduced to a linear domain topology for each pair of working and recovery LSPs.
此外，工作LSP和恢复LSP可以或不可以以相同的顺序沿相同的域集合路由。在本文档中，我们假设工作LSP和恢复LSP以相同的顺序遵循相同的域集（通过配置、策略或某些外部机制）。也就是说，我们假设对于每对工作和恢复LSP，域网格拓扑简化为线性域拓扑。
In summary,
总之，
- There is no assumption about the multi-domain network topology. For example, there could be more than two domain boundary nodes or inter-domain links (links connecting a pair of domain boundary nodes belonging to different domains).
- 没有关于多域网络拓扑的假设。例如，可能有两个以上的域边界节点或域间链路（连接属于不同域的一对域边界节点的链路）。
- It is assumed that in a multi-domain topology, the sequence of domains that the working LSP and the recovery LSP follow must be the same and is pre-configured.
- 假设在多域拓扑中，工作LSP和恢复LSP遵循的域序列必须相同，并且是预先配置的。
- Domain re-entry is out of scope and is not considered further.
- 域重新进入超出范围，不作进一步考虑。
As described in Section 1.4, domain diversity means the selection of paths that have only the ingress and egress domains in common. This may provide enhanced resilience against failures, and is a way to ensure path diversity for most of the path of the LSP.
如第1.4节所述，域分集是指仅具有相同入口和出口域的路径的选择。这可以提供增强的故障恢复能力，并且是确保LSP大部分路径的路径多样性的一种方法。
In Section 2.1, we assumed that the working LSP and the recovery LSP follow the same set of domains in the same order. Under this assumption, domain diversity cannot be achieved. However, by relaxing this assumption, domain diversity could be achieved, e.g., by either of the following schemes.
在第2.1节中，我们假设工作LSP和恢复LSP以相同的顺序遵循相同的域集。在此假设下，无法实现域多样性。然而，通过放松该假设，可以实现域分集，例如，通过以下方案之一。
- Consider domain diversity as a special case of SRLG diversity (i.e., assign an SRLG ID to each domain).
- 考虑域多样性作为SRLG分集的特殊情况（即，将SRLG ID分配给每个域）。
- Configure domain-level routing to provide domain-diverse paths (e.g., by means of AS_PATH in BGP).
- 配置域级路由以提供域不同路径（例如，通过BGP中的AS_路径）。
Further details of the operation of domain diversity are beyond the scope of this document.
域多样性操作的更多细节超出了本文档的范围。
As described in [RFC4726], scalability and optimality are two conflicting objectives. Note that the meaning of optimality differs depending on each network operation. Some examples of optimality in the context of diverse LSPs are:
如[RFC4726]所述，可伸缩性和最佳性是两个相互冲突的目标。请注意，最佳性的含义因每个网络操作而异。在不同LSP环境下的一些优化示例如下：
- Minimizing the sum of their cost while maintaining diversity.
- 在保持多样性的同时最大限度地降低成本。
- Restricting the difference of their costs (for example, so as to minimize the delay difference after switch-over) while maintaining diversity.
- 在保持分集的同时，限制其成本差异（例如，以最小化切换后的延迟差异）。
By restricting TE information distribution to only within each domain (and not across domain boundaries) as required by [RFC4105] and [RFC4216], it may not be possible to compute an optimal path. As such, it might not be possible to compute diverse paths, even if they exist. However, if we assume domain-level routing is given (as discussed in Section 2), it would be possible to compute diverse paths using specific computation schemes, if such paths exist. This is discussed further in Section 4.
根据[RFC4105]和[RFC4216]的要求，通过将TE信息分布限制在每个域内（而不是跨域边界），可能无法计算最佳路径。因此，即使存在不同的路径，也可能无法计算它们。然而，如果我们假设给定了域级路由（如第2节中所讨论的），则可以使用特定的计算方案计算不同的路径（如果存在这样的路径）。这将在第4节中进一步讨论。
Three key concepts to classify various diverse LSP computation and setup schemes are presented below.
下面介绍了分类各种不同LSP计算和设置方案的三个关键概念。
o With or without confidentiality
o 有无保密
- Without confidentiality
- 不保密
It is possible to specify a path across multiple domains in signaling (by means of the Resource Reservation Protocol-TE (RSVP-TE) Explicit Route Object (ERO)), and to obtain record of the inter-domain path used (by means of the RSVP-TE Record Route Object (RRO)). In this case, it is clear that one domain has control over the path followed in another domain, and that the path actually used in one domain is visible from within another domain.
可以（通过资源保留协议TE（RSVP-TE）显式路由对象（ERO））在信令中指定跨多个域的路径，并（通过RSVP-TE记录路由对象（RRO））获得所使用的域间路径的记录。在这种情况下，很明显，一个域可以控制另一个域中遵循的路径，并且一个域中实际使用的路径可以从另一个域中看到。
Examples of this configuration are multi-area networks, and some forms of multi-AS networks (especially within the same provider). In these cases, there is no requirement for confidentiality.
此配置的示例包括多区域网络和某些形式的多AS网络（尤其是在同一提供商内）。在这些情况下，不需要保密。
- With confidentiality
- 保密
Where confidentiality of domain topology and operational policy is required, it is not possible to specify or obtain a full path across other domains. Partial paths may be specified and reported using domain identifiers or the addresses of domain border routers in the EROs and RROs.
如果需要域拓扑和操作策略的机密性，则无法指定或获取跨其他域的完整路径。可以使用域标识符或ERO和RRO中的域边界路由器的地址来指定和报告部分路径。
Examples of this configuration are some forms of multi-AS networks (especially inter-provider networks), GMPLS-UNI networks, and L1VPNs.
这种配置的示例包括一些形式的多AS网络（特别是提供商间网络）、GMPLS-UNI网络和L1VPN。
o Multi-domain path computation, per-domain path computation, and inter-domain collaborative path computation
o 多域路径计算、每域路径计算和域间协作路径计算
- Multi-domain path computation
- 多域路径计算
If a single network element can see the topology of all domains along the path, it is able to compute a full end-to-end path. Clearly, this is only possible where confidentiality is not required.
如果单个网元可以看到路径上所有域的拓扑，那么它就能够计算完整的端到端路径。显然，这只有在不需要保密的情况下才可能实现。
Such a network element might be the head-end Label Switching Router (LSR), a Path Computation Element (PCE) [RFC4655], or a Network Management System (NMS). This mode of path computation is discussed in Sections 4 and 5.
这样的网络元件可以是前端标签交换路由器（LSR）、路径计算元件（PCE）[RFC4655]或网络管理系统（NMS）。第4节和第5节讨论了这种路径计算模式。
- Per-domain path computation
- 每域路径计算
The path of an LSP may be computed domain-by-domain as LSP signaling progresses through the network. This scheme requires ERO expansion in each domain to construct the next segment of the path toward the destination. The establishment of unprotected LSPs in this way is covered in [RFC5152].
LSP的路径可以随着LSP信令通过网络而逐域计算。该方案需要在每个域中进行ERO扩展，以构建通向目的地的下一段路径。[RFC5152]中介绍了以这种方式建立无保护的LSP。
- Inter-domain collaborative path computation
- 域间协同路径计算
In this scheme, path computation is typically done before signaling and uses communication between cooperating PCEs. An example of such a scheme is Backward Recursive Path Computation (BRPC) [BRPC].
在该方案中，路径计算通常在信令之前完成，并使用协作pce之间的通信。这种方案的一个例子是反向递归路径计算（BRPC）[BRPC]。
It is possible to combine multiple path computation techniques (including using a different technique for the working and recovery LSPs), but details are beyond the scope of this document.
可以组合多路径计算技术（包括对工作和恢复LSP使用不同的技术），但详细信息超出了本文档的范围。
o Sequential path computation or simultaneous path computation
o 顺序路径计算或同时路径计算
- Sequential path computation
- 顺序路径计算
The path of the working LSP is computed without considering the recovery LSP, and then the path of the recovery LSP is computed. This scheme is applicable when the recovery LSP is added later as a change to the service grade, but may also be used when both the working and recovery LSPs are established from the start.
在不考虑恢复LSP的情况下计算工作LSP的路径，然后计算恢复LSP的路径。此方案适用于以后添加恢复LSP作为服务等级变更时，但也可用于从一开始就建立工作LSP和恢复LSP时。
Using this approach, it may not be possible to find diverse paths for the LSPs in "trap" topologies. Furthermore, such sequential path computation approaches reduce the likelihood of selecting an "optimal" solution with regards to a specific objective function.
使用这种方法，可能无法为“陷阱”拓扑中的LSP找到不同的路径。此外，这种顺序路径计算方法降低了针对特定目标函数选择“最优”解的可能性。
- Simultaneous path computation
- 同时路径计算
The path of the working LSP and the path of the recovery LSP are computed simultaneously. In this scheme, it is possible to avoid trap conditions and it may be more possible to achieve an optimal result.
同时计算工作LSP的路径和恢复LSP的路径。在该方案中，可以避免陷阱条件，并且更可能实现最佳结果。
Note that LSP setup, with or without confidentiality, depends on per-domain configuration. The choice of per-domain path computation or inter-domain collaborative path computation, and the choice between sequential path computation or simultaneous path computation can be determined for each individual pair of working/recovery LSPs.
请注意，LSP设置（带或不带机密性）取决于每个域的配置。可以为每对工作/恢复lsp确定每域路径计算或域间协作路径计算的选择，以及顺序路径计算或同时路径计算之间的选择。
The analysis of various diverse LSP setup schemes is described in Sections 4 and 5, based on the concepts set out above.
基于上述概念，第4节和第5节描述了各种不同LSP设置方案的分析。
Some other considerations, such as network topology-specific considerations, addressing considerations, and SRLG diversity are described in Sections 6, 7, and 8.
第6、7和8节描述了一些其他考虑因素，如网络拓扑特定考虑因素、寻址考虑因素和SRLG多样性。
This section examines schemes for diverse LSP setup based on different path computation techniques assuming that there is no requirement for domain confidentiality. Section 5 makes a similar examination of schemes where domain confidentiality is required.
本节研究基于不同路径计算技术的不同LSP设置方案，假设不需要域机密性。第5节对需要域机密性的方案进行了类似的检查。
[RFC4726] describes this path computation technique where the full explicit paths for the working and recovery LSPs are specified by a management application at the head-end, and no further computation or signaling considerations are needed.
[RFC4726]描述了这种路径计算技术，其中工作和恢复LSP的完整显式路径由前端的管理应用程序指定，不需要进一步的计算或信令考虑。
Section 3.2.1 [RFC4726] describes this path computation technique. The full explicit paths for the working and recovery LSPs are computed at the head-end either by the head-end itself or by a PCE. In either case, the computing entity has full TE visibility across multiple domains and no further computation or signaling considerations are needed.
第3.2.1节[RFC4726]描述了该路径计算技术。工作和恢复LSP的完整显式路径在前端由前端本身或PCE计算。在任何一种情况下，计算实体都具有跨多个域的完全可视性，并且不需要进一步的计算或信令考虑。
Sections 3.2.2, 3.2.3, and 3.3 of [RFC4726] describe this path computation technique. More detailed procedures are described in [RFC5152].
[RFC4726]的第3.2.2、3.2.3和3.3节描述了这种路径计算技术。[RFC5152]中描述了更详细的程序。
In this scheme, the explicit paths of the working and recovery LSPs are specified as the complete strict paths through the source domain followed by either of the following:
在此方案中，工作和恢复LSP的显式路径被指定为通过源域的完整严格路径，后跟以下任一路径：
- The complete list of boundary LSRs or domain identifiers (e.g., AS numbers) along the paths.
- 沿路径的边界LSR或域标识符（例如，作为编号）的完整列表。
- The LSP destination.
- LSP目的地。
Thus, in order to navigate each domain, the path must be expanded at each domain boundary, i.e., per-domain. This path computation is performed by the boundary LSR or by a PCE on its behalf.
因此，为了导航每个域，必须在每个域边界（即每个域）扩展路径。该路径计算由边界LSR或PCE代表其执行。
There are two schemes for establishing diverse LSPs using per-domain computation. These are described Sections 4.3.1 and 4.3.2.
使用每域计算建立不同LSP有两种方案。第4.3.1节和第4.3.2节对此进行了说明。
As previously noted, the main issue with sequential path computation is that diverse paths cannot be guaranteed. Where a per-domain path computation scheme is applied, the computation of second path needs to be aware of the path used by the first path in order that path diversity can be attempted.
如前所述，顺序路径计算的主要问题是无法保证不同的路径。在应用每域路径计算方案的情况下，第二路径的计算需要知道第一路径使用的路径，以便可以尝试路径分集。
The RSVP-TE EXCLUDE_ROUTE Object (XRO) [RFC4874] can be used when the second path is signaled to report the details of the first path. It should be noted that the PRIMARY_PATH_ROUTE Object defined in [RFC4872] for end-to-end protection is not intended as a path exclusion mechanism and should not be used for this purpose.
当向第二条路径发送信号以报告第一条路径的详细信息时，可以使用RSVP-TE EXCLUDE_ROUTE Object（XRO）[RFC4874]。需要注意的是，[RFC4872]中定义的用于端到端保护的主路径路由对象不应用作路径排除机制，也不应用于此目的。
The process for sequential path computation is as follows:
顺序路径计算的过程如下所示：
- The working LSP is established using per-domain path computation as described in [RFC5152]. The path of the working LSP is available at the head-end through the RSVP-TE RRO since domain confidentiality is not required.
- 使用[RFC5152]中所述的每域路径计算建立工作LSP。工作LSP的路径在前端通过RSVP-TE RRO可用，因为不需要域机密性。
- The path of the recovery LSP across the first domain is computed excluding the resources used by the working LSP within that domain. If a PCE is used, the resources to be avoided can be passed to the PCE using the Exclude Route Object (XRO) extensions to the PCE Protocol [PCEP-XRO], [PCEP].
- 计算第一个域中恢复LSP的路径，不包括该域中工作LSP使用的资源。如果使用PCE，可以使用PCE协议[PCEP-XRO]，[PCEP]的排除路由对象（XRO）扩展将要避免的资源传递给PCE。
- The recovery LSP is now signaled across the first domain as usual, but the path of the working LSP is also conveyed in an RSVP-TE XRO. The XRO lists nodes, links and SRLGs that must be avoided by the LSP being signaled, and its contents are copied from the RRO of the working LSP.
- 恢复LSP现在像往常一样通过第一个域发出信号，但工作LSP的路径也在RSVP-TE XRO中传送。XRO列出了发送信号的LSP必须避免的节点、链接和SRLGs，其内容从工作LSP的RRO复制。
- At each subsequent domain boundary, a segment of the path of the recovery LSP can be computed across the new domain excluding the resources indicated in the RSVP-TE XRO.
- 在每个后续域边界处，可以跨新域计算恢复LSP路径的一段，不包括RSVP-TE XRO中指示的资源。
This scheme cannot guarantee to establish diverse LSPs (even if they could exist) because the first (working) LSP is established without consideration of the need for a diverse recovery LSP. It is possible to modify the path of the working LSP using the crankback techniques [RFC4920] if the setup of the recovery LSP is blocked or if some resources are shared.
此方案不能保证建立不同的LSP（即使它们可能存在），因为第一个（工作）LSP的建立没有考虑不同恢复LSP的需要。如果恢复LSP的设置被阻止或某些资源被共享，则可以使用回退技术[RFC4920]修改工作LSP的路径。
Note that, even if a solution is found, the degree of optimality of the solution (i.e., of the set of diverse TE LSPs) might not be maximal.
注意，即使找到了一个解决方案，该解决方案的最优性程度（即，不同TE LSP的集合）也可能不是最大的。
Simultaneous path computation gives a better likelihood of finding a pair of diverse paths as the diversity requirement forms part of the computation process. In per-domain path computation mechanisms, there are several aspects to consider.
由于多样性要求是计算过程的一部分，因此同时路径计算提供了找到一对不同路径的更好可能性。在每个域路径计算机制中，有几个方面需要考虑。
Simultaneous path computation means that the paths of the working and recovery LSPs are computed at the same time. Since we are considering per-domain path computation, these two paths must be computed at the boundary of each domain.
同时路径计算意味着同时计算工作和恢复LSP的路径。由于我们正在考虑每个域的路径计算，因此必须在每个域的边界处计算这两条路径。
The process for simultaneous path computation is as follows:
同时路径计算的过程如下所示：
- The ingress LSR (or a PCE) computes a pair of diverse paths across the first domain. If a PCE is used, PCEP offers the ability to request disjoint paths.
- 入口LSR（或PCE）计算跨越第一域的一对不同路径。如果使用PCE，PCEP提供请求不相交路径的能力。
- The working LSP is signaled across the first domain as usual, but must carry with it the requirement for a disjoint recovery LSP and the information about the path already computed for the recovery LSP across the first domain. In particular, the domain boundary node used by the recovery LSP must be reported.
- 正常情况下，工作LSP通过第一个域发送信号，但必须携带不相交恢复LSP的要求以及关于已为第一个域恢复LSP计算的路径的信息。特别是，必须报告恢复LSP使用的域边界节点。
- Each domain boundary router, in turn, computes a pair of disjoint paths across the next domain. The working LSP is signaled as usual, and the computed path of the recovery LSP is collected in the signaling messages.
- 每个域边界路由器依次计算跨下一个域的一对不相交路径。工作LSP照常发信号，恢复LSP的计算路径收集在信号消息中。
- When the working LSP has been set up, the full path of the recovery LSP is returned to the head-end LSR in the signaling messages for the working LSP. This allows the head-end LSR to signal the recovery LSP using a full path without the need for further path computation.
- 当已设置工作LSP时，恢复LSP的完整路径在工作LSP的信令消息中返回到前端LSR。这允许前端LSR使用完整路径向恢复LSP发送信号，而无需进一步的路径计算。
Note that the signaling protocol mechanisms do not currently exist to collect the path of the recovery LSP during the signaling of the working LSP. Definition of protocol mechanisms are beyond the scope of this document, but it is believed that such mechanisms would be simple to define and implement.
注意，信令协议机制目前不存在，用于在工作LSP的信令期间收集恢复LSP的路径。协议机制的定义超出了本文件的范围，但据信，此类机制的定义和实施将非常简单。
Note also that the mechanism described is still not able to guarantee the selection of diverse paths even where they exist since, when domains are multiply interconnected, the determination of diverse
还要注意的是，所描述的机制仍然不能保证多样路径的选择，即使它们存在，因为当域多重互连时，多样路径的确定
end-to-end paths may depend on the correct selection of inter-domain links. Crankback [RFC4920] may also be used in combination with this scheme to improve the chances of success.
端到端路径可能取决于域间链路的正确选择。回退[RFC4920]也可与此方案结合使用，以提高成功的机会。
Note that even if a solution is found, the degree of optimality of the solution (i.e., set of diverse TE LSPs) might not be maximal.
注意，即使找到了一个解决方案，该解决方案的最优性程度（即，一组不同的TE LSP）也可能不是最大的。
Collaborative path computation requires the cooperation between PCEs that are responsible for different domains. This approach is described in Section 3.4 of [RFC4726]. Backward recursive path computation (BRPC) [BRPC] provides a collaborative path computation technique where the paths of LSPs are fully determined by communication between PCEs before the LSPs are established. Two ways to use BRPC for diverse LSPs are described in the following sections.
协作路径计算需要负责不同领域的PCE之间的协作。[RFC4726]第3.4节描述了该方法。反向递归路径计算（BRPC）[BRPC]提供了一种协作路径计算技术，其中LSP的路径在LSP建立之前完全由PCE之间的通信确定。以下部分介绍了将BRPC用于不同LSP的两种方法。
In sequential path computation, the path of the working LSP is computed using BRPC as described in [BRPC]. The path of the recovery LSP is then computed also using BRPC with the addition that the path of the working LSP is explicitly excluded using the XRO route exclusion techniques described in [PCEP-XRO].
在顺序路径计算中，使用[BRPC]中所述的BRPC计算工作LSP的路径。然后还使用BRPC计算恢复LSP的路径，并使用[PCEP-XRO]中描述的XRO路由排除技术明确排除工作LSP的路径。
In this case, the working LSP could be set up before or after the path of the recovery LSP is computed. In the latter case, the actual path of the working LSP as reported in the RSVP-TE RRO should be used when computing the path of the recovery LSP.
在这种情况下，可以在计算恢复LSP的路径之前或之后设置工作LSP。在后一种情况下，在计算恢复LSP的路径时，应使用RSVP-TE RRO中报告的工作LSP的实际路径。
This scheme cannot guarantee to establish diverse LSPs (even if they exist) because the working LSP may block the recovery LSP. In such a scenario, re-optimization of the working and recovery LSPs may be used to achieve fully diverse paths.
此方案不能保证建立不同的LSP（即使存在），因为工作LSP可能会阻塞恢复LSP。在这种情况下，可以使用工作和恢复lsp的重新优化来实现完全多样化的路径。
In simultaneous path computation, the PCEs collaborate to compute the paths of both the working and the recovery LSPs at the same time. Since both LSPs are computed in a single pass, the LSPs can be signaled simultaneously of sequentially according to the preference of the head-end LSR.
在同步路径计算中，PCE协作同时计算工作LSP和恢复LSP的路径。由于两个lsp在单个过程中计算，因此可以根据前端LSR的偏好同时或顺序地发送lsp信号。
Collaborative simultaneous path computation is achieved using the Synchronization Vector (SVEC) object in the PCE Protocol [PCEP]. This object allows two computation requests to be associated and made dependent. The coordination of multiple computation requests within the BRPC mechanism is not described in [BRPC]. It is believed that it is possible to specify procedures for such coordination, but the development of new procedures is outside the scope of this document.
协同同步路径计算是使用PCE协议[PCEP]中的同步向量（SVEC）对象实现的。此对象允许关联两个计算请求并使它们相互依赖。[BRPC]中未描述BRPC机制内多个计算请求的协调。据认为，可以具体规定此类协调的程序，但新程序的制定不在本文件的范围之内。
This scheme can guarantee to establish diverse LSPs where they are possible, assuming that domain-level routing is pre-determined as described in Section 2. Furthermore, the computed set of TE LSPs can be guaranteed to be optimal with respect to some objective functions.
该方案可以保证在可能的情况下建立不同的LSP，前提是域级路由是预先确定的，如第2节所述。此外，对于某些目标函数，计算出的TE-lsp集可以保证是最优的。
In the context of this section, the term confidentiality applies to the protection of information about the topology and resources present within one domain from visibility by people or applications outside that domain. This includes, but is not limited to, recording of LSP routes, and the advertisements of TE information. The confidentiality does not apply to the protection of user traffic.
在本节的上下文中，术语机密性适用于保护一个域中存在的拓扑和资源的信息不被该域之外的人员或应用程序看到。这包括但不限于LSP路由的记录和TE信息的广告。保密性不适用于用户流量的保护。
Diverse LSP setup schemes with confidentiality are similar to ones without confidentiality. However, several additional mechanisms are needed to preserve confidentiality. Examples of such mechanisms are:
具有机密性的不同LSP设置方案与不具有机密性的方案类似。然而，还需要一些额外的机制来保护机密性。这类机制的例子有：
- Path key: A path key is used in place of a segment of the path of an LSP when the LSP is signaled, when the path of the LSP is reported by signaling, or when the LSP's path is generated by a PCE. This allows the exact path of the LSP to remain confidential through the substitution of "confidential path segments" (CPSs) by these path keys.
- 路径密钥：当LSP被发信号时，当LSP的路径通过发信号报告时，或者当LSP的路径由PCE生成时，使用路径密钥代替LSP的路径段。这允许通过用这些路径密钥替换“机密路径段”（CP），LSP的确切路径保持机密。
[PCE-PATH-KEY] describes how path keys can be used by PCEs to preserve path confidentiality, and [RSVP-PATH-KEY] explains how path keys are used in signaling. Note that if path keys are signaled in RSVP-TE EROs they must be expanded so that the signaling can proceed. This expansion normally takes place when the first node in the CPS is reached. The expansion of the path key would normally be carried out by the PCE that generated the key, and for that reason, the path key contains an identifier of the PCE (the PCE-ID).
[PCE-PATH-KEY]描述了PCE如何使用路径密钥来保护路径机密性，[RSVP-PATH-KEY]解释了如何在信令中使用路径密钥。注意，如果在RSVP-TE EROs中发送路径键信号，则必须扩展路径键，以便继续发送信号。这种扩展通常在到达CPS中的第一个节点时发生。路径密钥的扩展通常由生成密钥的PCE执行，因此，路径密钥包含PCE的标识符（PCE-ID）。
- LSP segment: LSP segments can be pre-established across domains according to some management policy. The LSP segments can be used to support end-to-end LSPs as hierarchical LSPs [RFC4206] or as LSP stitching segments [RFC5150].
- LSP段：根据某些管理策略，可以跨域预先建立LSP段。LSP段可用于支持端到端LSP，如分层LSP[RFC4206]或LSP缝合段[RFC5150]。
The end-to-end LSPs are signaled indicating just the series of domains or domain border routers. Upon entry to each domain, an existing trans-domain LSP is selected and used to carry the end-to-end LSP across the domain.
端到端LSP发出信号，仅指示一系列域或域边界路由器。进入每个域后，将选择一个现有的跨域LSP，并使用该LSP跨域传输端到端LSP。
Note that although the LSP segments are described as being pre-established, they could be set up on demand on receipt of the request for the end-to-end LSP at the domain border.
注意，尽管LSP段被描述为预先建立的，但是它们可以在收到域边界处的端到端LSP请求时根据需要进行设置。
It is also worth noting that in schemes that result in a single contiguous end-to-end LSP (without LSP tunneling or stitching), the same concept of LSP segments may apply provided that ERO expansion is applied at domain boundaries and that the path of the LSP is not reported in the RSVP-TE RRO.
还值得注意的是，在导致单个连续端到端LSP（无LSP隧道或缝合）的方案中，LSP段的相同概念可能适用，前提是在域边界应用ERO扩展，并且RSVP-TE RRO中未报告LSP的路径。
These techniques may be applied directly or may require protocol extensions depending on the specific diverse LSP setup schemes described below. Note that in the schemes below, the paths of the working and recovery LSPs are not impacted by the confidentiality requirements.
这些技术可以直接应用，或者可能需要协议扩展，这取决于下面描述的特定的不同LSP设置方案。请注意，在下面的方案中，工作和恢复LSP的路径不受保密要求的影响。
Although management systems may exist that can determine end-to-end paths even in the presence of domain confidentiality, the full paths cannot be provided to the head-end LSR for LSP signaling as this would break the confidentiality requirements.
尽管可能存在即使在存在域机密性的情况下也可以确定端到端路径的管理系统，但是不能为用于LSP信令的头端LSR提供完整路径，因为这将破坏机密性要求。
Thus, for LSPs that are configured through management applications, the end-to-end path must either be constructed using LSP segments that cross the domains, or communicated to the head-end LSR with the use of path keys.
因此，对于通过管理应用程序配置的LSP，端到端路径必须使用跨域的LSP段构建，或者使用路径键与前端LSR通信。
It is not possible for the head-end LSR to compute the full end-to-end path of an inter-domain LSP when domain confidentiality is in use because the LSR will not have any TE information about the other domains.
当域机密性正在使用时，前端LSR不可能计算域间LSP的完整端到端路径，因为LSR将不具有关于其他域的任何TE信息。
Per-domain path computation for working and recovery LSPs is practical with domain confidentiality. As when there are no confidentiality restrictions, we can separate the cases of sequential and simultaneous path computation.
工作和恢复LSP的每域路径计算在域机密性方面是切实可行的。当没有保密限制时，我们可以将顺序路径计算和同时路径计算的情况分开。
In sequential path computation, we can assume that the working LSP has its path computed and is set up using the normal per-domain technique as described in [RFC5152]. However, because of confidentiality issues, the full path of the working LSP is not returned in the signaling messages and is not available to the head-end LSR.
在顺序路径计算中，我们可以假设工作LSP已计算其路径，并使用[RFC5152]中所述的正常每域技术进行设置。然而，由于机密性问题，工作LSP的完整路径不在信令消息中返回，并且不可用于前端LSR。
To compute a disjoint path for the recovery LSP, each domain border node needs to know the path of the working LSP within the domain to which it provides entry. This is easy for the ingress LSR as it has access to the RSVP-TE RRO within first domain. In subsequent domains, the process requires that the path of the working LSP is somehow made available to the domain border router as the recovery LSP is signaled. Note that the working and recovery LSPs do not use the same border routers if the LSPs are node or SRLG diverse.
要计算恢复LSP的不相交路径，每个域边界节点需要知道其提供入口的域内工作LSP的路径。这对于入口LSR来说很容易，因为它可以访问第一个域中的RSVP-TE RRO。在随后的域中，该过程要求在恢复LSP发出信号时，工作LSP的路径以某种方式可供域边界路由器使用。请注意，如果LSP是节点或SRLG，则工作和恢复LSP不使用相同的边界路由器。
There are several possible mechanisms to achieve this.
有几种可能的机制来实现这一点。
- Path keys could be used in the RRO for the working LSP. As the signaling messages are propagated back towards the head-end LSR, each domain border router substitutes a path key for the segment of the working LSP's path within its domain. Thus, the RRO received at the head-end LSR consists of the path within the initial domain followed by a series of path keys.
- 路径键可用于工作LSP的RRO中。当信令消息传播回前端LSR时，每个域边界路由器用路径密钥替换其域内工作LSP的路径段。因此，在前端LSR处接收的RRO由初始域内的路径和一系列路径密钥组成。
When the recovery LSP is signaled, the path keys can be included in the ERO as exclusions. Each domain border router in turn can expand the path key for its domain and know which resources must be avoided. PCEP provides a protocol that can be used to request the expansion of the path key from the domain border router used by the working LSP, or from some third party such as a PCE.
当恢复LSP发出信号时，路径密钥可作为排除项包含在ERO中。每个域边界路由器依次可以扩展其域的路径密钥，并知道必须避免哪些资源。PCEP提供了一个协议，可用于从工作LSP使用的域边界路由器或某些第三方（如PCE）请求扩展路径密钥。
- Instead of using path keys, each confidential path segment in the RRO of the working LSP could be encrypted by the domain border routers. These encrypted segments would appear as exclusions in the ERO for the recovery LSP and could be decrypted by the domain border routers.
- 域边界路由器可以对工作LSP的RRO中的每个机密路径段进行加密，而不是使用路径密钥。这些加密段将在恢复LSP的ERO中显示为排除项，并可由域边界路由器解密。
No mechanism currently exists in RSVP-TE for this function, which would probably assume a domain-wide encryption key.
RSVP-TE中目前不存在用于此功能的机制，这可能会假定域范围的加密密钥。
- The identity of the working LSP could be included in the XRO of the recovery LSP to indicate that a disjoint path must be found.
- 工作LSP的标识可以包含在恢复LSP的XRO中，以指示必须找到不相交的路径。
This option could require a simple extension to the current XRO specification [RFC4874] to allow LSP identifiers to be included.
此选项可能需要对当前XRO规范[RFC4874]进行简单扩展，以允许包含LSP标识符。
It could also use the Association Object [RFC4872] to identify the working LSP.
它还可以使用关联对象[RFC4872]来标识工作LSP。
This scheme would also need a way for a domain border router to find the path of an LSP within its domain. An efficient way to achieve this would be to also include the domain border router used by the working LSP in the signaling for the recovery LSP, but other schemes based on management applications or stateful PCEs might also be developed.
该方案还需要一种域边界路由器在其域内查找LSP路径的方法。实现这一点的有效方法将是在恢复LSP的信令中还包括工作LSP使用的域边界路由器，但是也可以开发基于管理应用程序或有状态pce的其他方案。
Clearly, the details of this alternative have not been specified.
显然，这一备选方案的细节尚未具体说明。
In per-domain simultaneous path computation the path of the recovery LSP is computed at the same time as the working LSP (i.e., as the working LSP is signaled). The computed path of the recovery LSP is propagated to the head-end LSR as part of the signaling process for the working LSP, but confidentiality must be maintained, so the full path cannot be returned. There are two options as follows.
在每域同步路径计算中，恢复LSP的路径与工作LSP同时计算（即，当工作LSP被发信号时）。恢复LSP的计算路径作为工作LSP的信令过程的一部分传播到前端LSR，但必须保持机密性，因此无法返回完整路径。有两种选择，如下所示。
- LSP segment: As the signaling of the working LSP progresses and the path of the recovery LSP is computed domain-by-domain, trans-domain LSPs can be set up for use by the recovery LSP. When the recovery LSP is signaled, it will pick up these LSP segments and use them for tunneling or stitching.
- LSP段：随着工作LSP的信令进行，恢复LSP的路径是逐域计算的，跨域LSP可以设置为由恢复LSP使用。当恢复LSP发出信号时，它将拾取这些LSP段并将其用于隧道或缝合。
This mechanism needs coordination through the management plane between domain border routers so that a router on the working path can request the establishment of an LSP segment for use by the protection path. This could be achieved through the TE MIB modules [RFC3812], [RFC4802].
该机制需要通过域边界路由器之间的管理平面进行协调，以便工作路径上的路由器可以请求建立LSP段以供保护路径使用。这可以通过TE MIB模块[RFC3812]、[RFC4802]实现。
Furthermore, when the recovery LSP is signaled it needs to be sure to pick up the correct LSP segment. Therefore, some form of LSP segment identifier needs to be reported in the signaling of the working LSP and propagated in the signaling of the recovery LSP. Mechanisms for this do not currently exist, but would be relatively simple to construct.
此外，当恢复LSP发出信号时，需要确保拾取正确的LSP段。因此，需要在工作LSP的信令中报告某种形式的LSP段标识符，并在恢复LSP的信令中传播。目前尚不存在这方面的机制，但构建起来相对简单。
Alternatively, the LSP segments could be marked as providing protection for the working LSP. In this case, the recovery LSP can be signaled with the identifier of the working LSP using the Association Object [RFC4872] enabling the correct LSP segments to be selected.
或者，可以将LSP段标记为为为工作LSP提供保护。在这种情况下，可以使用关联对象[RFC4872]用工作LSP的标识符向恢复LSP发送信号，从而能够选择正确的LSP段。
- Path key: The path of the recovery LSP can be determined and returned to the head-end LSR just described in Section 4.4.2, but each CPS is replaced by a path key. As the recovery path is signaled each path key is expanded, domain-by-domain to achieve the correct path. This requires that the entity that computes the path of the recovery LSP (domain border LSR or PCE) is stateful.
- 路径密钥：恢复LSP的路径可以确定并返回到第4.4.2节中所述的前端LSR，但每个CPS都由一个路径密钥替换。当向恢复路径发送信号时，每个路径密钥都会逐域展开，以获得正确的路径。这要求计算恢复LSP（域边界LSR或PCE）路径的实体是有状态的。
Cooperative collaboration between PCEs is also applicable when domain confidentiality is required.
当需要域机密性时，PCE之间的合作也适用。
In sequential cooperative path computation, the path of the working LSP is determined first using a mechanism such as BRPC. Since domain confidentiality is in use, the path returned may contain path keys.
在顺序协作路径计算中，首先使用BRPC等机制确定工作LSP的路径。由于正在使用域机密性，因此返回的路径可能包含路径密钥。
When the path of the recovery LSP is computed (which may be before or after the working LSP is signaled) the path exclusions supplied to the PCE and exchanged between PCEs must use path keys as described in [PCEP-XRO].
当计算恢复LSP的路径时（可能在工作LSP发出信号之前或之后），提供给PCE并在PCE之间交换的路径排除必须使用[PCEP-XRO]中所述的路径键。
As described in Section 4.4.2, diverse path computation can be requested using the PCEP SVEC Object [PCEP], and BRPC could be extended for inter-domain diverse path computation. However, to conform to domain confidentiality requirements, path keys must be used in the paths returned by the PCEs and signaled by RSVP-TE.
如第4.4.2节所述，可以使用PCEP SVEC对象[PCEP]请求多样化路径计算，并且可以扩展BRPC以进行域间多样化路径计算。但是，为了符合域机密性要求，必须在PCE返回并由RSVP-TE发出信号的路径中使用路径密钥。
Note that the LSP segment approach may not be applicable here because a path cannot be determined until BRPC procedures are completed.
请注意，LSP段方法可能不适用于此处，因为在BRPC程序完成之前无法确定路径。
In some specific network topologies the schemes for setting up diverse LSPs could be significantly simplified.
在某些特定的网络拓扑中，设置不同LSP的方案可以大大简化。
For example, consider the L1VPN or GMPLS UNI case. This may be viewed as a linear sequence of three domains where the first and last domains contain only a single node each. In such a scenario, no BRPC procedures are needed, because there is no need for path computation in the first and last domains even if the source and destination nodes are multi-homed.
例如，考虑L1VPN或GMPLS UNI情况。这可以看作是三个域的线性序列，其中第一个域和最后一个域仅包含单个节点。在这种情况下，不需要BRPC过程，因为即使源节点和目标节点是多宿的，也不需要在第一个域和最后一个域中进行路径计算。
All of the schemes described in this document are applicable when a single address space is used across all domains.
当在所有域中使用单个地址空间时，本文档中描述的所有方案都适用。
There may also be cases where private address spaces are used within some of the domains. This problem is similar to the use of domain confidentiality since the ERO and RRO are meaningless outside a domain even if they are available, and the problem can be solved using the same techniques.
在某些域中也可能使用私有地址空间。这个问题类似于域机密性的使用，因为ERO和RRO在域之外没有意义，即使它们可用，并且可以使用相同的技术解决这个问题。
The schemes described in this document are applicable when the nodes and links in different domains belong to different SRLGs, which is normally the case.
当不同域中的节点和链路属于不同的SRLGs时（通常情况下），本文档中描述的方案适用。
However, it is possible that nodes or links in different domains belong to the same SRLG. That is, an SRLG may span domain boundaries. In such cases, in order to establish SRLG diverse LSPs, several considerations are needed:
但是，不同域中的节点或链路可能属于同一SRLG。也就是说，SRLG可以跨越域边界。在这种情况下，为了建立SRLG不同的LSP，需要考虑以下几点：
- Record of the SRLGs used by the working LSP.
- 工作LSP使用的SRLGs记录。
- Indication of a set of SRLGs to exclude in the computation of the recovery LSP's path.
- 指示在计算恢复LSP路径时要排除的一组SRLGs。
In this case, there is a conflict between any requirement for domain confidentiality, and the requirement for SRLG diversity. One of the requirements must be compromised.
在这种情况下，域机密性要求与SRLG多样性要求之间存在冲突。其中一项要求必须妥协。
Furthermore, SRLG IDs may be assigned independently in each domain, and might not have global meaning. In such a scenario, some mapping functions are necessary, similar to the mapping of other TE parameters mentioned in Section 1.2.
此外，SRLG ID可以在每个域中独立分配，并且可能没有全局意义。在这种情况下，一些映射函数是必要的，类似于第1.2节中提到的其他TE参数的映射。
The core protocols used to achieve the procedures described in this document are RSVP-TE and PCEP. These protocols include policy and authentication capabilities as described in [RFC3209] and [PCEP]. Furthermore, these protocols may be operated using more advanced security features such as IPsec [RFC4301] and TLS [RFC4346].
用于实现本文件所述程序的核心协议为RSVP-TE和PCEP。这些协议包括[RFC3209]和[PCEP]中所述的策略和身份验证功能。此外，这些协议可以使用更高级的安全特性（如IPsec[RFC4301]和TLS[RFC4346]）来操作。
Security may be regarded as particularly important in inter-domain deployments and serious consideration should be given to applying the available security techniques, as described in the documents referenced above and as set out in [RFC4726].
安全性在域间部署中可能被视为特别重要，应认真考虑应用可用的安全技术，如上述文件所述和[RFC4726]中所述。
Additional discussion of security considerations for MPLG/GMPLS networks can be found in [SECURITY-FW].
有关MPLG/GMPLS网络安全注意事项的更多讨论，请参见[security-FW]。
This document does not of itself require additional security measures and does not modify the trust model implicit in the protocols used. Note, however, that domain confidentiality (that is the confidentiality of the topology and path information from within any one domain) is an important consideration in this document, and a significant number of the mechanisms described in this document are designed to preserve domain confidentiality.
本文档本身不需要额外的安全措施，也不修改所用协议中隐含的信任模型。但是，请注意，域机密性（即来自任何一个域的拓扑和路径信息的机密性）是本文档中的一个重要考虑因素，并且本文档中描述的大量机制旨在保护域机密性。
[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月。
[RFC4216] Zhang, R., Ed., and J.-P. Vasseur, Ed., "MPLS Inter-Autonomous System (AS) Traffic Engineering (TE) Requirements", RFC 4216, November 2005.
[RFC4216]Zhang，R.，Ed.，和J.-P.Vasseur，Ed.，“MPLS自治系统间（AS）流量工程（TE）要求”，RFC 42162005年11月。
[RFC4427] Mannie, E., Ed., and D. Papadimitriou, Ed., "Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4427, March 2006.
[RFC4427]Mannie，E.，Ed.和D.Papadimitriou，Ed.“通用多协议标签交换（GMPLS）的恢复（保护和恢复）术语”，RFC 4427，2006年3月。
[RFC4726] Farrel, A., Vasseur, J.-P., and A. Ayyangar, "A Framework for Inter-Domain Multiprotocol Label Switching Traffic Engineering", RFC 4726, November 2006.
[RFC4726]Farrel，A.，Vasseur，J.-P.，和A.Ayyangar，“域间多协议标签交换流量工程框架”，RFC 4726，2006年11月。
[RFC3812] Srinivasan, C., Viswanathan, A., and T. Nadeau, "Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Management Information Base (MIB)", RFC 3812, June 2004.
[RFC3812]Srinivasan，C.，Viswanathan，A.，和T.Nadeau，“多协议标签交换（MPLS）流量工程（TE）管理信息库（MIB）”，RFC 3812，2004年6月。
[RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May 2005.
[RFC4090]Pan，P.，Ed.，Swallow，G.，Ed.，和A.Atlas，Ed.，“LSP隧道RSVP-TE快速重路由扩展”，RFC 40902005年5月。
[RFC4105] Le Roux, J.-L., Ed., Vasseur, J.-P., Ed., and J. Boyle, Ed., "Requirements for Inter-Area MPLS Traffic Engineering", RFC 4105, June 2005.
[RFC4105]Le Roux，J.-L.，Ed.，Vasseur，J.-P.，Ed.，和J.Boyle，Ed.，“区域间MPLS流量工程的要求”，RFC 4105，2005年6月。
[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月。
[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, October 2005.
[RFC4208]Swallow，G.，Drake，J.，Ishimatsu，H.，和Y.Rekhter，“通用多协议标签交换（GMPLS）用户网络接口（UNI）：覆盖模型的资源预留协议流量工程（RSVP-TE）支持”，RFC 4208，2005年10月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]Kent，S.和K.Seo，“互联网协议的安全架构”，RFC 43012005年12月。
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006.
[RFC4346]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.1”，RFC 4346，2006年4月。
[RFC4428] Papadimitriou, D., Ed., and E. Mannie, Ed., "Analysis of Generalized Multi-Protocol Label Switching (GMPLS)-based Recovery Mechanisms (including Protection and Restoration)", RFC 4428, March 2006.
[RFC4428]Papadimitriou，D.，Ed.，和E.Mannie，Ed.，“基于通用多协议标签交换（GMPLS）的恢复机制分析（包括保护和恢复）”，RFC 4428，2006年3月。
[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月。
[RFC4802] Nadeau, T., Ed., and A. Farrel, Ed., "Generalized Multiprotocol Label Switching (GMPLS) Traffic Engineering Management Information Base", RFC 4802, February 2007.
[RFC4802]Nadeau，T.，Ed.，和A.Farrel，Ed.，“通用多协议标签交换（GMPLS）流量工程管理信息库”，RFC 4802，2007年2月。
[RFC4847] Takeda, T., Ed., "Framework and Requirements for Layer 1 Virtual Private Networks", RFC 4847, April 2007.
[RFC4847]武田，T.，编辑，“第1层虚拟专用网络的框架和要求”，RFC 4847，2007年4月。
[RFC4872] Lang, J., Ed., Rekhter, Y., Ed., and D. Papadimitriou, Ed., "RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery", RFC 4872, May 2007.
[RFC4872]Lang，J.，Ed.，Rekhter，Y.，Ed.，和D.Papadimitriou，Ed.，“支持端到端通用多协议标签交换（GMPLS）恢复的RSVP-TE扩展”，RFC 4872，2007年5月。
[RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel, "GMPLS Segment Recovery", RFC 4873, May 2007.
[RFC4873]Berger，L.，Bryskin，I.，Papadimitriou，D.，和A.Farrel，“GMPLS段恢复”，RFC 4873，2007年5月。
[RFC4874] Lee, CY., Farrel, A., and S. De Cnodder, "Exclude Routes - Extension to Resource ReserVation Protocol-Traffic Engineering (RSVP-TE)", RFC 4874, April 2007.
[RFC4874]Lee，CY.，Farrel，A.和S.De Cnodder，“排除路由-资源预留协议流量工程（RSVP-TE）的扩展”，RFC 48742007年4月。
[RFC4920] Farrel, A., Ed., Satyanarayana, A., Iwata, A., Fujita, N., and G. Ash, "Crankback Signaling Extensions for MPLS and GMPLS RSVP-TE", RFC 4920, July 2007.
[RFC4920]Farrel，A.，Ed.，Satyanarayana，A.，Iwata，A.，Fujita，N.，和G.Ash，“MPLS和GMPLS RSVP-TE的回退信令扩展”，RFC 4920，2007年7月。
[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, February 2008.
[RFC5150]Ayyangar，A.，Kompella，K.，Vasseur，JP.，和A.Farrel，“使用通用多协议标签交换流量工程（GMPLS TE）的标签交换路径缝合”，RFC 51502008年2月。
[RFC5151] Farrel, A., Ed., Ayyangar, A., and JP. Vasseur, "Inter-Domain MPLS and GMPLS Traffic Engineering -- Resource Reservation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 5151, February 2008.
[RFC5151]Farrel，A.，Ed.，Ayyangar，A.，和JP。Vasseur，“域间MPLS和GMPLS流量工程——资源预留协议流量工程（RSVP-TE）扩展”，RFC 51512008年2月。
[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, February 2008.
[RFC5152]Vasseur，JP.，Ed.，Ayyangar，A.，Ed.，和R.Zhang，“用于建立域间流量工程（TE）标签交换路径（LSP）的每域路径计算方法”，RFC 5152，2008年2月。
[BRPC] Vasseur, JP., Ed., Zhang, R., Bitar, N., and JL. Le Roux, "A Backward Recursive PCE-Based Computation (BRPC) Procedure to Compute Shortest Inter-Domain Traffic Engineering Label Switched Paths", Work in Progress, April 2008.
[BRPC]Vasseur，JP.，Ed.，Zhang，R.，Bitar，N.，和JL。Le Roux，“基于PCE的反向递归计算（BRPC）程序，用于计算最短域间流量工程标签交换路径”，正在进行的工作，2008年4月。
[PCE-PATH-KEY] Bradford, R., Vasseur, JP., and A. Farrel, "Preserving Topology Confidentiality in Inter-Domain Path Computation Using a Key-Based Mechanism", Work in Progress, May 2008.
[PCE-PATH-KEY]Bradford，R.，Vasseur，JP.，和A.Farrel，“使用基于密钥的机制在域间路径计算中保持拓扑机密性”，正在进行的工作，2008年5月。
[PCEP] Vasseur, JP., Ed., and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", Work in Progress, March 2008.
[PCEP]Vasseur，JP.，Ed.，和JL。Le Roux，Ed.，“路径计算元素（PCE）通信协议（PCEP）”，正在进行的工作，2008年3月。
[PCEP-XRO] Oki, E., Takeda, T., and A. Farrel, "Extensions to the Path Computation Element Communication Protocol (PCEP) for Route Exclusions", Work in Progress, July 2008.
[PCEP-XRO]Oki，E.，Takeda，T.，和A.Farrel，“路由排除路径计算元素通信协议（PCEP）的扩展”，正在进行的工作，2008年7月。
[RSVP-PATH-KEY] Bradford, R., Vasseur, JP., and A. Farrel, "RSVP Extensions for Path Key Support", Work in Progress, May 2008.
[RSVP-PATH-KEY]Bradford，R.，Vasseur，JP.，和A.Farrel，“路径密钥支持的RSVP扩展”，正在进行的工作，2008年5月。
[SECURITY-FW] Fang, L., Ed., " Security Framework for MPLS and GMPLS Networks", Work in Progress, July 2008.
[SECURITY-FW]Fang，L.，Ed.，“MPLS和GMPLS网络的安全框架”，正在进行的工作，2008年7月。
The authors would like to thank Eiji Oki, Ichiro Inoue, Kazuhiro Fujihara, Dimitri Papadimitriou, and Meral Shirazipour for valuable comments. Deborah Brungard provided useful advice about the text.
作者要感谢Oki Eiji、井上一郎、藤原和弘、Dimitri Papadimitriou和Meral Shirazipour的宝贵评论。黛博拉·布伦加德就文本提供了有用的建议。
Authors' Addresses
作者地址
Tomonori Takeda NTT Network Service Systems Laboratories, NTT Corporation 3-9-11, Midori-Cho Musashino-Shi, Tokyo 180-8585 Japan EMail : takeda.tomonori@lab.ntt.co.jp
日本东京武藏市三井町3-9-11 NTT公司武田县武田网络服务系统实验室，武田县武田县武田县武田町町180-8585电子邮件：武田。tomonori@lab.ntt.co.jp
Yuichi Ikejiri NTT Communications Corporation Tokyo Opera City Tower 3-20-2 Nishi Shinjuku, Shinjuku-ku Tokyo 163-1421, Japan EMail: y.ikejiri@ntt.com
Yuichi Ikejiri NTT通信公司东京歌剧城3-20-2号楼，新宿，新宿东京163-1421电子邮件：y。ikejiri@ntt.com
Adrian Farrel Old Dog Consulting EMail: adrian@olddog.co.uk
Adrian Farrel老狗咨询电子邮件：adrian@olddog.co.uk
Jean-Philippe Vasseur Cisco Systems, Inc. 300 Beaver Brook Road Boxborough, MA 01719 USA EMail: jpv@cisco.com
Jean-Philippe Vasseur Cisco Systems，Inc.地址：美国马萨诸塞州Boxborough市比弗布鲁克路300号电子邮件：01719jpv@cisco.com
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2008).
版权所有（C）IETF信托基金（2008年）。
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.