Network Working Group                                     K. Kumaki, Ed.
Request for Comments: 5146                              KDDI Corporation
Category: Informational                                       March 2008
        
Network Working Group                                     K. Kumaki, Ed.
Request for Comments: 5146                              KDDI Corporation
Category: Informational                                       March 2008
        

Interworking Requirements to Support Operation of MPLS-TE over GMPLS Networks

支持MPLS-TE在GMPLS网络上运行的互通要求

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

摘要

Operation of a Multiprotocol Label Switching (MPLS) traffic engineering (TE) network as a client network to a Generalized MPLS (GMPLS) network has enhanced operational capabilities compared to those provided by a coexistent protocol model (i.e., operation of MPLS-TE over an independently managed transport layer).

将多协议标签交换(MPLS)流量工程(TE)网络作为客户端网络运行到通用MPLS(GMPLS)网络,与共存协议模型(即,在独立管理的传输层上运行MPLS-TE)提供的操作能力相比,具有增强的操作能力。

The GMPLS network may be a packet or a non-packet network, and may itself be a multi-layer network supporting both packet and non-packet technologies. An MPLS-TE Label Switched Path (LSP) originates and terminates on an MPLS Label Switching Router (LSR). The GMPLS network provides transparent transport for the end-to-end MPLS-TE LSP.

GMPLS网络可以是分组或非分组网络,并且其本身可以是同时支持分组和非分组技术的多层网络。MPLS-TE标签交换路径(LSP)在MPLS标签交换路由器(LSR)上发起和终止。GMPLS网络为端到端MPLS-TE LSP提供透明传输。

This document describes a framework and Service Provider requirements for operating MPLS-TE networks over GMPLS networks.

本文件描述了在GMPLS网络上运行MPLS-TE网络的框架和服务提供商要求。

Table of Contents

目录

   1. Introduction ....................................................3
      1.1. Terminology ................................................4
   2. Reference Model .................................................4
   3. Detailed Requirements ...........................................5
      3.1. End-to-End Signaling .......................................5
      3.2. Triggered Establishment of GMPLS LSPs ......................5
      3.3. Diverse Paths for End-to-End MPLS-TE LSPs ..................6
      3.4. Advertisement of MPLS-TE Information via the GMPLS
           Network ....................................................6
      3.5. Selective Advertisement of MPLS-TE Information via
           a Border Node ..............................................6
      3.6. Interworking of MPLS-TE and GMPLS Protection ...............7
      3.7. Independent Failure Recovery and Reoptimization ............7
      3.8. Complexity and Risks .......................................7
      3.9. Scalability Considerations .................................7
      3.10. Performance Considerations ................................8
      3.11. Management Considerations .................................8
   4. Security Considerations .........................................8
   5. Recommended Solution Architecture ...............................9
      5.1. Use of Contiguous, Hierarchical, and Stitched LSPs ........10
      5.2. MPLS-TE Control Plane Connectivity ........................10
      5.3. Fast Reroute Protection ...................................10
      5.4. GMPLS LSP Advertisement ...................................11
      5.5. GMPLS Deployment Considerations ...........................11
   6. Acknowledgments ................................................11
   7. References .....................................................11
      7.1. Normative References ......................................11
      7.2. Informative References ....................................12
   8. Contributors' Addresses ........................................13
        
   1. Introduction ....................................................3
      1.1. Terminology ................................................4
   2. Reference Model .................................................4
   3. Detailed Requirements ...........................................5
      3.1. End-to-End Signaling .......................................5
      3.2. Triggered Establishment of GMPLS LSPs ......................5
      3.3. Diverse Paths for End-to-End MPLS-TE LSPs ..................6
      3.4. Advertisement of MPLS-TE Information via the GMPLS
           Network ....................................................6
      3.5. Selective Advertisement of MPLS-TE Information via
           a Border Node ..............................................6
      3.6. Interworking of MPLS-TE and GMPLS Protection ...............7
      3.7. Independent Failure Recovery and Reoptimization ............7
      3.8. Complexity and Risks .......................................7
      3.9. Scalability Considerations .................................7
      3.10. Performance Considerations ................................8
      3.11. Management Considerations .................................8
   4. Security Considerations .........................................8
   5. Recommended Solution Architecture ...............................9
      5.1. Use of Contiguous, Hierarchical, and Stitched LSPs ........10
      5.2. MPLS-TE Control Plane Connectivity ........................10
      5.3. Fast Reroute Protection ...................................10
      5.4. GMPLS LSP Advertisement ...................................11
      5.5. GMPLS Deployment Considerations ...........................11
   6. Acknowledgments ................................................11
   7. References .....................................................11
      7.1. Normative References ......................................11
      7.2. Informative References ....................................12
   8. Contributors' Addresses ........................................13
        
1. Introduction
1. 介绍

Multiprotocol Label Switching traffic engineering (MPLS-TE) networks are often deployed over transport networks such that the transport networks provide connectivity between the Label Switching Routers (LSRs) in the MPLS-TE network. Increasingly, these transport networks are operated using a Generalized Multiprotocol Label Switching (GMPLS) control plane. Label Switched Paths (LSPs) in the GMPLS network provide connectivity as virtual data links advertised as TE links in the MPLS-TE network.

多协议标签交换流量工程(MPLS-TE)网络通常部署在传输网络上,以便传输网络在MPLS-TE网络中的标签交换路由器(LSR)之间提供连接。这些传输网络越来越多地使用通用多协议标签交换(GMPLS)控制平面进行操作。GMPLS网络中的标签交换路径(LSP)提供连接,作为MPLS-TE网络中广告为TE链路的虚拟数据链路。

GMPLS protocols were developed as extensions to MPLS-TE protocols. MPLS-TE is limited to the control of packet switching networks, but GMPLS can also control technologies at layers one and two.

GMPLS协议是作为MPLS-TE协议的扩展而开发的。MPLS-TE仅限于控制分组交换网络,但GMPLS也可以控制第一层和第二层的技术。

The GMPLS network may be managed by an operator as a separate network (as it may have been when it was under management plane control before the use of GMPLS as a control plane), but optimizations of management and operation may be achieved by coordinating the use of the MPLS-TE and GMPLS networks and operating the two networks with a close client/server relationship.

GMPLS网络可由运营商作为一个单独的网络进行管理(在使用GMPLS作为控制平面之前,它可能处于管理平面控制之下),但是,通过协调MPLS-TE和GMPLS网络的使用,并以密切的客户机/服务器关系操作这两个网络,可以实现管理和操作的优化。

GMPLS LSP setup may be triggered by the signaling of MPLS-TE LSPs in the MPLS-TE network so that the GMPLS network is reactive to the needs of the MPLS-TE network. The triggering process can be under the control of operator policies without needing direct intervention by an operator.

GMPLS LSP设置可由MPLS-TE网络中的MPLS-TE LSP的信令触发,以便GMPLS网络对MPLS-TE网络的需求作出反应。触发过程可由运营商政策控制,无需运营商直接干预。

The client/server configuration just described can also apply in migration scenarios for MPLS-TE packet switching networks that are being migrated to be under GMPLS control. [RFC5145] describes a migration scenario called the Island Model. In this scenario, groups of nodes (islands) are migrated from the MPLS-TE protocols to the GMPLS protocols and operate entirely surrounded by MPLS-TE nodes (the sea). This scenario can be effectively managed as a client/server network relationship using the framework described in this document.

刚才描述的客户机/服务器配置也可以应用于迁移到GMPLS控制下的MPLS-TE分组交换网络的迁移场景。[RFC5145]描述了一种称为孤岛模型的迁移场景。在这种情况下,节点组(岛)从MPLS-TE协议迁移到GMPLS协议,并完全由MPLS-TE节点(sea)包围。使用本文档中描述的框架,可以将此场景作为客户机/服务器网络关系进行有效管理。

In order to correctly manage the dynamic interaction between the MPLS and GMPLS networks, it is necessary to understand the operational requirements and the control that the operator can impose. Although this problem is very similar to the multi-layer networks described in [MLN-REQ], it must be noted that those networks operate GMPLS protocols in both the client and server networks, which facilitates smoother interworking. Where the client network uses MPLS-TE protocols over the GMPLS server network, there is a need to study the interworking of the two protocol sets.

为了正确管理MPLS和GMPLS网络之间的动态交互,有必要了解运营商可以施加的操作要求和控制。尽管该问题与[MLN-REQ]中描述的多层网络非常相似,但必须注意的是,这些网络在客户端和服务器网络中运行GMPLS协议,这有助于更平滑的互通。当客户端网络在GMPLS服务器网络上使用MPLS-TE协议时,需要研究两个协议集的互通。

This document examines the protocol requirements for protocol interworking to operate an MPLS-TE network as a client network over a GMPLS server network, and provides a framework for such operations.

本文件检查了协议互通的协议要求,以将MPLS-TE网络作为GMPLS服务器网络上的客户端网络进行操作,并提供了此类操作的框架。

1.1. Terminology
1.1. 术语

Although this Informational document is not a protocol specification, The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] for clarity of exposure of the requirements.

尽管本信息性文件不是协议规范,但为了明确要求,本文件中的关键词“必须”、“必须”、“必须”、“不应该”、“应该”、“不应该”、“建议”、“可能”和“可选”应按照[RFC2119]中的描述进行解释。

2. Reference Model
2. 参考模型

The reference model used in this document is shown in Figure 1. It can easily be seen that the interworking between MPLS-TE and GMPLS protocols must occur on a node and not on a link. Nodes on the interface between the MPLS-TE and GMPLS networks must be responsible for handling both protocol sets and for providing any protocol interworking that is required. We call these nodes Border Routers.

本文档中使用的参考模型如图1所示。很容易看出,MPLS-TE和GMPLS协议之间的互通必须发生在节点上,而不是链路上。MPLS-TE和GMPLS网络之间接口上的节点必须负责处理这两个协议集,并提供所需的任何协议互通。我们称这些节点为边界路由器。

       --------------    -------------------------    --------------
      | MPLS Client  |  |   GMPLS Server Network  |  |  MPLS Client |
      |   Network    |  |                         |  |    Network   |
      |              |  |                         |  |              |
      |     ----   --+--+--    -----   -----    --+--+--   ----     |
      |    |    | |        |  |     | |     |  |        | |    |    |
      |    |MPLS|_| Border |__|GMPLS|_|GMPLS|__| Border |_|MPLS|    |
      |    |LSR | | Router |  | LSR | | LSR |  | Router | |LSR |    |
      |    |    | |        |  |     | |     |  |        | |    |    |
      |     ----   --+--+--    -----   -----    --+--+--   ----     |
      |              |  |                         |  |              |
      |              |  |                         |  |              |
       --------------    -------------------------    --------------
        
       --------------    -------------------------    --------------
      | MPLS Client  |  |   GMPLS Server Network  |  |  MPLS Client |
      |   Network    |  |                         |  |    Network   |
      |              |  |                         |  |              |
      |     ----   --+--+--    -----   -----    --+--+--   ----     |
      |    |    | |        |  |     | |     |  |        | |    |    |
      |    |MPLS|_| Border |__|GMPLS|_|GMPLS|__| Border |_|MPLS|    |
      |    |LSR | | Router |  | LSR | | LSR |  | Router | |LSR |    |
      |    |    | |        |  |     | |     |  |        | |    |    |
      |     ----   --+--+--    -----   -----    --+--+--   ----     |
      |              |  |                         |  |              |
      |              |  |                         |  |              |
       --------------    -------------------------    --------------
        
             |         |         GMPLS LSP         |         |
             |         |<------------------------->|         |
             |                                               |
             |<--------------------------------------------->|
                           End-to-End MPLS-TE LSP
        
             |         |         GMPLS LSP         |         |
             |         |<------------------------->|         |
             |                                               |
             |<--------------------------------------------->|
                           End-to-End MPLS-TE LSP
        

Figure 1. Reference model of MPLS-TE/GMPLS interworking

图1。MPLS-TE/GMPLS互通参考模型

MPLS-TE network connectivity is provided through a GMPLS LSP which is created between Border Routers. End-to-end connectivity between MPLS LSRs in the client MPLS-TE networks is provided by an MPLS-TE LSP that is carried across the MPLS-TE network by the GMPLS LSP using hierarchical LSP techniques [RFC4206], LSP stitching segments

MPLS-TE网络连接通过在边界路由器之间创建的GMPLS LSP提供。客户端MPLS-TE网络中的MPLS LSR之间的端到端连接由MPLS-TE LSP提供,GMPLS LSP使用分层LSP技术[RFC4206],LSP缝合段在MPLS-TE网络上承载该MPLS-TE LSP

[RFC5150], or a contiguous LSP. LSP stitching segments and contiguous LSPs are only available where the GMPLS network is a packet switching network.

[RFC5150]或连续LSP。LSP缝合段和连续LSP仅在GMPLS网络为分组交换网络的情况下可用。

3. Detailed Requirements
3. 详细要求

This section describes detailed requirements for MPLS-TE/GMPLS interworking in support of the reference model shown in Figure 1.

本节描述了支持图1所示参考模型的MPLS-TE/GMPLS互通的详细要求。

The functional requirements for GMPLS-MPLS interworking described in this section must be met by any device participating in the interworking. This may include routers, servers, network management devices, path computation elements, etc.

参与互通的任何设备都必须满足本节所述GMPLS-MPLS互通的功能要求。这可能包括路由器、服务器、网络管理设备、路径计算元件等。

3.1. End-to-End Signaling
3.1. 端到端信令

The solution MUST be able to preserve MPLS signaling information signaled within the MPLS-TE client network at the start of the MPLS-TE LSP and deliver it on the other side of the GMPLS server network for use within the MPLS-TE client network at the end of the MPLS-TE LSP. This may require protocol mapping (and re-mapping), protocol tunneling, or the use of remote protocol adjacencies.

该解决方案必须能够在MPLS-TE LSP开始时保留MPLS-TE客户端网络内发信号的MPLS信令信息,并将其传送到GMPLS服务器网络的另一端,以便在MPLS-TE LSP结束时在MPLS-TE客户端网络内使用。这可能需要协议映射(和重新映射)、协议隧道或使用远程协议邻接。

3.2. Triggered Establishment of GMPLS LSPs
3.2. 触发建立GMPLS LSP

The solution MUST provide the ability to establish end-to-end MPLS-TE LSPs over a GMPLS server network. It SHOULD be possible for GMPLS LSPs across the core network to be set up between Border Routers triggered by the signaling of MPLS-TE LSPs in the client network, and in this case, policy controls MUST be made available at the border routers so that the operator of the GMPLS network can manage how core network resources are utilized. GMPLS LSPs MAY also be pre-established as the result of management plane control.

解决方案必须提供通过GMPLS服务器网络建立端到端MPLS-TE LSP的能力。通过客户端网络中的MPLS-TE LSP信令触发的边界路由器之间应该可以建立跨核心网络的GMPLS LSP,在这种情况下,必须在边界路由器上提供策略控制,以便GMPLS网络的运营商可以管理核心网络资源的利用方式。GMPLS LSP也可以作为管理平面控制的结果预先建立。

Note that multiple GMPLS LSPs may be set up between a given pair of Border Routers in support of connectivity in the MPLS client network. If these LSPs are advertised as TE links in the client network, the use of link bundling [RFC4201] can reduce any scaling concerns associated with the advertisements.

注意,可以在给定的一对边界路由器之间设置多个GMPLS lsp,以支持MPLS客户端网络中的连接。如果这些lsp在客户端网络中被广告为TE链路,则使用链路捆绑[rfc4021]可以减少与广告相关联的任何缩放问题。

The application of the Path Computation Element (PCE) [RFC4655] in the context of an inter-layer network [PCE-INT] may be considered to determine an end-to-end LSP with triggered GMPLS segment or tunnel.

可考虑在层间网络[PCE-INT]的上下文中应用路径计算元件(PCE)[RFC4655],以确定具有触发的GMPLS段或隧道的端到端LSP。

3.3. Diverse Paths for End-to-End MPLS-TE LSPs
3.3. 端到端MPLS-TE LSP的多种路径

The solution SHOULD provide the ability to establish end-to-end MPLS-TE LSPs having diverse paths for protection of the LSP traffic. This means that MPLS-TE LSPs SHOULD be kept diverse both within the client MPLS-TE network and as they cross the server GMPLS network. This means that there SHOULD be a mechanism to request the provision of diverse GMPLS LSPs between a pair of Border Routers to provide protection of the GMPLS span, but also that there SHOULD be a way to keep GMPLS LSPs between different Border Routers disjoint.

该解决方案应提供建立具有不同路径的端到端MPLS-TE LSP的能力,以保护LSP流量。这意味着,MPLS-TE LSP在客户机MPLS-TE网络内和跨服务器GMPLS网络时应保持多样性。这意味着应该有一种机制来请求在一对边界路由器之间提供不同的GMPLS LSP,以提供GMPLS跨度的保护,但也应该有一种方法来保持不同边界路由器之间的GMPLS LSP不相交。

3.4. Advertisement of MPLS-TE Information via the GMPLS Network
3.4. 通过GMPLS网络发布MPLS-TE信息

The solution SHOULD provide the ability to exchange advertisements of TE information between MPLS-TE client networks across the GMPLS server network.

该解决方案应提供跨GMPLS服务器网络在MPLS-TE客户端网络之间交换TE信息广告的能力。

The advertisement of TE information from within an MPLS-TE client network to all LSRs in the client network enables a head-end LSR to compute an optimal path for an LSP to a tail-end LSR that is reached over the GMPLS server network.

从MPLS-TE客户端网络内向客户端网络中的所有LSR播发TE信息使得前端LSR能够计算通过GMPLS服务器网络到达的LSP到后端LSR的最佳路径。

Where there is more than one client MPLS-TE network, the TE information from separate MPLS-TE networks MUST be kept private, confidential and secure.

如果存在多个客户端MPLS-TE网络,则来自不同MPLS-TE网络的TE信息必须保持私有、机密和安全。

3.5. Selective Advertisement of MPLS-TE Information via a Border Node
3.5. 通过边界节点选择性地公布MPLS-TE信息

The solution SHOULD provide the ability to distribute TE reachability information from the GMPLS server network to MPLS-TE networks selectively. This information is useful for the LSRs in the MPLS-TE networks to compute paths that cross the GMPLS server network and to select the correct Border Routers to provide connectivity.

该解决方案应提供有选择地将TE可达性信息从GMPLS服务器网络分发到MPLS-TE网络的能力。此信息有助于MPLS-TE网络中的LSR计算穿过GMPLS服务器网络的路径,并选择正确的边界路由器以提供连接。

The solution MUST NOT distribute TE information from within a non-PSC (Packet Switch Capable) GMPLS server network to any client MPLS-TE network as that information may cause confusion and selection of inappropriate paths.

解决方案不得将TE信息从非PSC(支持分组交换)的GMPLS服务器网络分发到任何客户MPLS-TE网络,因为该信息可能会导致混淆和选择不适当的路径。

The use of PCE [RFC4655] may provide a solution for non-PSC GMPLS networks supporting PSC MPLS networks.

PCE[RFC4655]的使用可为支持PSC MPLS网络的非PSC GMPLS网络提供解决方案。

3.6. Interworking of MPLS-TE and GMPLS Protection
3.6. MPLS-TE与GMPLS保护的互通

If an MPLS-TE LSP is protected using MPLS Fast Reroute (FRR) [RFC4090], then similar protection MUST be provided over the GMPLS island. Operator and policy controls SHOULD be made available at the Border Router to determine how suitable protection is provided in the GMPLS island.

如果使用MPLS快速重路由(FRR)[RFC4090]保护MPLS-TE LSP,则必须在GMPLS岛上提供类似的保护。边界路由器应提供运营商和政策控制,以确定如何在GMPLS岛上提供适当的保护。

3.7. Independent Failure Recovery and Reoptimization
3.7. 独立故障恢复和重新优化

The solution SHOULD provide failure recovery and reoptimization in the GMPLS server network without impacting the MPLS-TE client network and vice versa. That is, it SHOULD be possible to recover from a fault within the GMPLS island or to reoptimize the path across the GMPLS island without requiring signaling activity within the MPLS-TE client network. Similarly, it SHOULD be possible to perform recovery or reoptimization within the MPLS-TE client network without requiring signaling activity within the GMPLS server networks.

该解决方案应在GMPLS服务器网络中提供故障恢复和重新优化,而不会影响MPLS-TE客户端网络,反之亦然。也就是说,应该可以从GMPLS岛内的故障中恢复,或者在不需要MPLS-TE客户端网络内的信令活动的情况下重新优化GMPLS岛上的路径。类似地,应该可以在MPLS-TE客户端网络内执行恢复或重新优化,而不需要GMPLS服务器网络内的信令活动。

If a failure in the GMPLS server network can not be repaired transparently, some kind of notification of the failure SHOULD be transmitted to MPLS-TE network.

如果无法透明地修复GMPLS服务器网络中的故障,则应向MPLS-TE网络发送某种故障通知。

3.8. Complexity and Risks
3.8. 复杂性和风险

The solution SHOULD NOT introduce unnecessary complexity to the current operating network to such a degree that it would affect the stability and diminish the benefits of deploying such a solution in service provider networks.

该解决方案不应给当前运营网络带来不必要的复杂性,从而影响稳定性并降低在服务提供商网络中部署该解决方案的好处。

3.9. Scalability Considerations
3.9. 可伸缩性考虑

The solution MUST scale well with consideration to at least the following metrics.

解决方案必须能够很好地扩展,并至少考虑以下指标。

- The number of GMPLS-capable nodes (i.e., the size of the GMPLS server network).

- 支持GMPLS的节点数量(即GMPLS服务器网络的大小)。

- The number of MPLS-TE-capable nodes (i.e., the size of the MPLS-TE client network).

- 支持MPLS TE的节点数(即,MPLS-TE客户端网络的大小)。

- The number of MPLS-TE client networks.

- MPLS-TE客户端网络的数量。

- The number of GMPLS LSPs.

- GMPLS LSP的数量。

- The number of MPLS-TE LSPs.

- MPLS-TE LSP的数量。

3.10. Performance Considerations
3.10. 性能注意事项

The solution SHOULD be evaluated with regard to the following criteria.

应根据以下标准评估解决方案。

- Failure and restoration time.

- 故障和恢复时间。

- Impact and scalability of the control plane due to added overheads.

- 由于额外的开销,控制平面的影响和可伸缩性。

- Impact and scalability of the data/forwarding plane due to added overheads.

- 由于额外的开销,数据/转发平面的影响和可扩展性。

3.11. Management Considerations
3.11. 管理考虑

Manageability of the deployment of an MPLS-TE client network over GMPLS server network MUST addresses the following considerations.

通过GMPLS服务器网络部署MPLS-TE客户机网络的可管理性必须考虑以下因素。

- Need for coordination of MIB modules used for control plane management and monitoring in the client and server networks.

- 需要协调客户机和服务器网络中用于控制平面管理和监控的MIB模块。

- Need for diagnostic tools that can discover and isolate faults across the border between the MPLS-TE client and GMPLS server networks.

- 需要能够跨MPLS-TE客户端和GMPLS服务器网络之间的边界发现和隔离故障的诊断工具。

4. Security Considerations
4. 安全考虑

Border routers in the model described in this document are present on administrative domain boundaries. That is, the administrative boundary does not lie on a link as it might in the inter-Autonomous-System (inter-AS) case seen in IP networks. Thus, many security concerns for the inter-domain exchange of control plane messages do not arise in this model -- the border router participates fully in both the MPLS and the GMPLS network and must participate in the security procedures of both networks. Security considerations for MPLS-TE and GMPLS protocols are discussed in [SECURITY].

本文档中描述的模型中的边界路由器位于管理域边界上。也就是说,管理边界不象在IP网络中看到的自治系统(inter-as)情况那样位于链路上。因此,在该模型中不会出现控制平面消息域间交换的许多安全问题——边界路由器完全参与MPLS和GMPLS网络,并且必须参与这两个网络的安全过程。MPLS-TE和GMPLS协议的安全注意事项在[安全]中讨论。

However, policy considerations at the border routers are very important and may be considered to form part of the security of the networks. In particular, the server network (the GMPLS network) may wish to protect itself from behavior in the client network (such as frequent demands to set up and tear down server LSPs) by appropriate policies implemented at the border routers. It should be observed that, because the border routers form part of both networks, they are trusted in both networks, and policies configured (whether locally or centrally) for use by a border router are expected to be observed.

然而,边界路由器的政策考虑非常重要,可能被视为构成网络安全的一部分。特别地,服务器网络(GMPLS网络)可能希望通过在边界路由器处实施的适当策略来保护自己免受客户端网络中的行为(例如频繁地要求设置和拆除服务器lsp)的影响。应该注意的是,由于边界路由器构成两个网络的一部分,因此它们在两个网络中都是可信的,并且预期将遵守为边界路由器使用而配置的策略(无论是本地的还是集中的)。

Nevertheless, authentication and access controls for operators will be particularly important at border routers. Operators of the client

然而,对运营商的身份验证和访问控制在边境路由器上尤为重要。客户的运营商

MPLS-TE network MUST NOT be allowed to configure the server GMPLS network (including setting server network policies), and operators of the server GMPLS network MUST NOT be able configure the client MPLS-TE network. Obviously, it SHOULD be possible to grant an operator privileges in both networks. It may also be desirable to give operators of one network access to (for example) status information about the other network.

不得允许MPLS-TE网络配置服务器GMPLS网络(包括设置服务器网络策略),且服务器GMPLS网络的运营商不得配置客户端MPLS-TE网络。显然,应该可以在两个网络中授予操作员权限。还可能希望允许一个网络的运营商访问(例如)关于另一个网络的状态信息。

Mechanisms for authenticating operators and providing access controls are not part of the responsibilities of the GMPLS protocol set, and will depend on the management plane protocols and techniques implemented.

验证操作员和提供访问控制的机制不属于GMPLS协议集的职责,将取决于实施的管理平面协议和技术。

5. Recommended Solution Architecture
5. 推荐的解决方案体系结构

The recommended solution architecture to meet the requirements set out in Section 3 is known as the Border Peer Model. This architecture is a variant of the Augmented Model described in [RFC3945]. The remainder of this document presents an overview of this architecture.

满足第3节所述要求的推荐解决方案体系结构称为Border Peer模型。该体系结构是[RFC3945]中描述的增强模型的变体。本文档的其余部分概述了该体系结构。

In the Augmented Model, routing information from the lower layer (server) network is filtered at the interface to the higher layer (client) network and a subset of the information is distributed within the higher layer network.

在增强模型中,来自较低层(服务器)网络的路由信息在与较高层(客户端)网络的接口处被过滤,并且信息的子集分布在较高层网络中。

In the Border Peer Model, the interface between the client and server networks is the Border Router. This router has visibility of the routing information in the server network yet also participates as a peer in the client network. Thus, the Border Router has full visibility into both networks. However, the Border Router does not distribute server routing information into the client network, nor does it distribute client routing information into the server network.

在边界对等模型中,客户端和服务器网络之间的接口是边界路由器。此路由器可以查看服务器网络中的路由信息,但也可以作为对等方参与客户端网络。因此,边界路由器对这两个网络都有充分的可视性。但是,边界路由器不会将服务器路由信息分发到客户端网络,也不会将客户端路由信息分发到服务器网络。

The Border Peer Model may also be contrasted with the Overlay Model [RFC3945]. In this model there is a protocol request/response interface (the user network interface (UNI)) between the client and server networks. [RFC4208] shows how this interface may be supported by GMPLS protocols operated between client edge and server edge routers while retaining the routing information within the server network. That is, in the Overlay Model there is no exchange of routing or reachability information between client and server networks, and no network element has visibility into both client and server networks. The Border Peer Model can be viewed as placing the UNI within the Border Router thus giving the Border Router peer capabilities in both the client and server network.

边界对等模型也可以与覆盖模型进行对比[RFC3945]。在这个模型中,客户端和服务器网络之间有一个协议请求/响应接口(用户网络接口(UNI))。[RFC4208]显示了在客户端边缘路由器和服务器边缘路由器之间运行的GMPLS协议如何支持此接口,同时在服务器网络中保留路由信息。也就是说,在覆盖模型中,客户端和服务器网络之间没有路由或可达性信息的交换,并且没有网络元素可以同时看到客户端和服务器网络。边界对等模型可视为将UNI放置在边界路由器内,从而在客户端和服务器网络中提供边界路由器对等能力。

5.1. Use of Contiguous, Hierarchical, and Stitched LSPs
5.1. 使用连续、分层和缝合的LSP

All three LSP types MAY be supported in the Border Peer Model, but contiguous LSPs are the hardest to support because they require protocol mapping between the MPLS-TE client network and the GMPLS server network. Such protocol mapping can be achieved currently since MPLS-TE signaling protocols are a subset of GMPLS, but this mechanism is not future-proofed.

边界对等模型中可能支持所有三种LSP类型,但相邻LSP最难支持,因为它们需要MPLS-TE客户端网络和GMPLS服务器网络之间的协议映射。目前可以实现这种协议映射,因为MPLS-TE信令协议是GMPLS的一个子集,但这种机制没有经过未来验证。

Contiguous and stitched LSPs can only be supported where the GMPLS server network has the same switching type (that is, packet switching) as the MPLS-TE network. Requirements for independent failure recovery within the GMPLS island require the use of loose path reoptimization techniques [RFC4736] and end-to-end make-before-break [RFC3209], which will not provide rapid recovery.

只有在GMPLS服务器网络具有与MPLS-TE网络相同的交换类型(即分组交换)的情况下,才能支持连续和缝合LSP。GMPLS岛内的独立故障恢复要求使用松路径再优化技术[RFC4736]和端到端先通后断[RFC3209],这将无法提供快速恢复。

For these reasons, the use of hierarchical LSPs across the server network is RECOMMENDED for the Border Peer Model, but see the discussion of Fast Reroute protection in Section 5.3.

出于这些原因,建议在边界对等模型中跨服务器网络使用分层LSP,但请参见第5.3节中关于快速重路由保护的讨论。

5.2. MPLS-TE Control Plane Connectivity
5.2. MPLS-TE控制平面连接

Control plane connectivity between MPLS-TE LSRs connected by a GMPLS island in the Border Peer Model MAY be provided by the control channels of the GMPLS network. If this is done, a tunneling mechanism (such as GRE [RFC2784]) SHOULD be used to ensure that MPLS-TE information is not consumed by the GMPLS LSRs. But care is required to avoid swamping the control plane of the GMPLS network with MPLS-TE control plane (particularly routing) messages.

边界对等模型中由GMPLS岛连接的MPLS-TE LSR之间的控制平面连接可由GMPLS网络的控制信道提供。如果这样做,则应使用隧道机制(如GRE[RFC2784])确保GMPLS LSR不会使用MPLS-TE信息。但是需要注意避免MPLS-TE控制平面(特别是路由)消息淹没GMPLS网络的控制平面。

In order to ensure scalability, control plane messages for the MPLS-TE client network MAY be carried between Border Routers in a single hop MPLS-TE LSP routed through the data plane of the GMPLS server network.

为了确保可伸缩性,用于MPLS-TE客户端网络的控制平面消息可以在通过GMPLS服务器网络的数据平面路由的单跳MPLS-TE LSP中的边界路由器之间传送。

5.3. Fast Reroute Protection
5.3. 快速重路由保护

If the GMPLS network is packet switching, Fast Reroute protection can be offered on all hops of a contiguous LSP. If the GMPLS network is packet switching then all hops of a hierarchical GMPLS LSP or GMPLS stitching segment can be protected using Fast Reroute. If the end-to-end MPLS-TE LSP requests Fast Reroute protection, the GMPLS packet switching network SHOULD provide such protection.

如果GMPLS网络是分组交换,则可以在连续LSP的所有跳上提供快速重路由保护。如果GMPLS网络是分组交换,则分层GMPLS LSP或GMPLS缝合段的所有跳数都可以使用快速重路由进行保护。如果端到端MPLS-TE LSP请求快速重路由保护,则GMPLS分组交换网络应提供此类保护。

However, note that it is not possible to provide FRR node protection of the upstream Border Router without careful consideration of available paths, and protection of the downstream Border Router is not possible where hierarchical LSPs or stitching segments are used.

然而,请注意,在未仔细考虑可用路径的情况下,不可能提供上游边界路由器的FRR节点保护,并且在使用分层lsp或缝合段的情况下不可能保护下游边界路由器。

Note further that Fast Reroute is not available in non-packet technologies. However, other protection techniques are supported by GMPLS for non-packet networks and are likely to provide similar levels of protection.

进一步注意,快速重路由在非分组技术中不可用。然而,对于非分组网络,GMPLS支持其他保护技术,并且可能提供类似级别的保护。

The limitations of FRR need careful consideration by the operator and may lead to the decision to provide end-to-end protection for the MPLS-TE LSP.

运营商需要仔细考虑FRR的限制,并可能决定为MPLS-TE LSP提供端到端保护。

5.4. GMPLS LSP Advertisement
5.4. GMPLS LSP广告

In the Border Peer Model, the LSPs established by the Border Routers in the GMPLS server network SHOULD be advertised in the MPLS-TE client network as real or virtual links. In case real links are advertised into the MPLS-TE client network, the Border Routers in the MPLS-TE client network MAY establish IGP neighbors. The Border Routers MAY automatically advertise the GMPLS LSPs when establishing them.

在边界对等模型中,由GMPLS服务器网络中的边界路由器建立的LSP应在MPLS-TE客户端网络中作为真实或虚拟链路发布。在将真实链路播发到MPLS-TE客户端网络的情况下,MPLS-TE客户端网络中的边界路由器可以建立IGP邻居。边界路由器可在建立GMPLS LSP时自动公布这些LSP。

5.5. GMPLS Deployment Considerations
5.5. GMPLS部署注意事项

The Border Peer Model does not require the existing MPLS-TE client network to be GMPLS aware and does not affect the operation and management of the existing MPLS-TE client network. Only border routers need to be upgraded with the GMPLS functionality. In this fashion, the Border Peer Model renders itself for incremental deployment of the GMPLS server network, without requiring reconfiguration of existing areas/ASs, changing operation of IGP and BGP or software upgrade of the existing MPLS-TE client network.

Border Peer模型不要求现有MPLS-TE客户端网络具有GMPLS意识,并且不影响现有MPLS-TE客户端网络的操作和管理。只有边界路由器需要升级GMPLS功能。以这种方式,边界对等模型呈现为GMPLS服务器网络的增量部署,而不需要重新配置现有区域/ASs、更改IGP和BGP的操作或现有MPLS-TE客户端网络的软件升级。

6. Acknowledgments
6. 致谢

The author would like to express thanks to Raymond Zhang, Adrian Farrel, and Deborah Brungard for their helpful and useful comments and feedback.

作者要感谢Raymond Zhang、Adrian Farrel和Deborah Brungard提供的有用的评论和反馈。

7. References
7. 工具书类
7.1. Normative References
7.1. 规范性引用文件

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2119]Bradner,S.,“RFC中用于表示需求水平的关键词”,BCP 14,RFC 2119,1997年3月。

[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月。

[RFC3945] Mannie, E., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", RFC 3945, October 2004.

[RFC3945]Mannie,E.,Ed.“通用多协议标签交换(GMPLS)体系结构”,RFC 39452004年10月。

[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月。

[RFC4201] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling in MPLS Traffic Engineering (TE)", RFC 4201, October 2005.

[RFC4201]Kompella,K.,Rekhter,Y.,和L.Berger,“MPLS流量工程(TE)中的链路捆绑”,RFC 42012005年10月。

[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月。

[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月。

7.2. Informative References
7.2. 资料性引用

[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000.

[RFC2784]Farinaci,D.,Li,T.,Hanks,S.,Meyer,D.,和P.Traina,“通用路由封装(GRE)”,RFC 27842000年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月。

[RFC4736] Vasseur, JP., Ed., Ikejiri, Y., and R. Zhang, "Reoptimization of Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Loosely Routed Label Switched Path (LSP)", RFC 4736, November 2006.

[RFC4736]Vasseur,JP.,Ed.,Ikejiri,Y.,和R.Zhang,“多协议标签交换(MPLS)流量工程(TE)松路由标签交换路径(LSP)的再优化”,RFC 47362006年11月。

[RFC5145] Shiomoto, K., Ed., "Framework for MPLS-TE to GMPLS Migration", RFC 5145, March 2008.

[RFC5145]Shiomoto,K.,Ed.“MPLS-TE到GMPLS迁移的框架”,RFC 51452008年3月。

[MLN-REQ] Shiomoto, K., Papadimitriou, D., Le Roux, J.L., Vigoureux, M., and D. Brungard, "Requirements for GMPLS-Based Multi-Region and Multi-Layer Networks (MRN/MLN)", Work in Progress, January 2008.

[MLN-REQ]Shiomoto,K.,Papadimitriou,D.,Le Roux,J.L.,Vigoureux,M.,和D.Brungard,“基于GMPLS的多区域和多层网络(MRN/MLN)的要求”,正在进行的工作,2008年1月。

[PCE-INT] Oki, E., Le Roux , J-L., and A. Farrel, "Framework for PCE-Based Inter-Layer MPLS and GMPLS Traffic Engineering," Work in Progress, January 2008.

[PCE-INT]Oki,E.,Le Roux,J-L.,和A.Farrel,“基于PCE的层间MPLS和GMPLS流量工程框架”,正在进行的工作,2008年1月。

[SECURITY] Fang, L., "Security Framework for MPLS and GMPLS Networks", Work in Progress, November 2007.

[SECURITY]Fang,L.,“MPLS和GMPLS网络的安全框架”,正在进行的工作,2007年11月。

8. Contributors' Addresses
8. 投稿人地址

Tomohiro Otani KDDI R&D Laboratories, Inc. 2-1-15 Ohara Kamifukuoka Saitama, 356-8502, Japan

大谷智博KDDI研发实验室有限公司,地址:2-1-15大原县斋玉县,356-8502,日本

   Phone:  +81-49-278-7357
   EMail:  otani@kddilabs.jp
        
   Phone:  +81-49-278-7357
   EMail:  otani@kddilabs.jp
        

Shuichi Okamoto NICT JGN II Tsukuba Reserach Center 1-8-1, Otemachi Chiyoda-ku, Tokyo, 100-0004, Japan

日本东京千代田区大町1-8-1号水池冈本NICT JGN II筑波研究中心,东京,100-0004

   Phone: +81-3-5200-2117
   EMail: okamoto-s@nict.go.jp
        
   Phone: +81-3-5200-2117
   EMail: okamoto-s@nict.go.jp
        

Kazuhiro Fujihara NTT Communications Corporation Tokyo Opera City Tower 3-20-2 Nishi Shinjuku, Shinjuku-ku Tokyo 163-1421, Japan

藤原和弘NTT通信公司东京歌剧城3-20-2号楼,新宿,东京新宿163-1421

   EMail: kazuhiro.fujihara@ntt.com
        
   EMail: kazuhiro.fujihara@ntt.com
        

Yuichi Ikejiri NTT Communications Corporation Tokyo Opera City Tower 3-20-2 Nishi Shinjuku, Shinjuku-ku Tokyo 163-1421, Japan

Yuichi Ikejiri NTT通信公司东京歌剧城3-20-2号楼,新宿,新宿东京163-1421

   EMail: y.ikejiri@ntt.com
        
   EMail: y.ikejiri@ntt.com
        

Editor's Address

编辑地址

Kenji Kumaki KDDI Corporation Garden Air Tower Iidabashi, Chiyoda-ku, Tokyo, 102-8460, JAPAN

日本东京千代田区第三达巴希市久木健二株式会社花园航空塔,102-8460

   EMail: ke-kumaki@kddi.com
        
   EMail: ke-kumaki@kddi.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.