Network Working Group                                   K. Shiomoto, Ed.
Request for Comments: 5145                                           NTT
Category: Informational                                       March 2008
        
Network Working Group                                   K. Shiomoto, Ed.
Request for Comments: 5145                                           NTT
Category: Informational                                       March 2008
        

Framework for MPLS-TE to GMPLS Migration

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

摘要

The migration from Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) to Generalized MPLS (GMPLS) is the process of evolving an MPLS-TE control plane to a GMPLS control plane. An appropriate migration strategy will be selected based on various factors including the service provider's network deployment plan, customer demand, and operational policy.

从多协议标签交换(MPLS)流量工程(TE)到广义MPLS(GMPLS)的迁移是将MPLS-TE控制平面演化为GMPLS控制平面的过程。将根据各种因素(包括服务提供商的网络部署计划、客户需求和运营策略)选择适当的迁移策略。

This document presents several migration models and strategies for migrating from MPLS-TE to GMPLS. In the course of migration, MPLS-TE and GMPLS devices, or networks, may coexist that may require interworking between MPLS-TE and GMPLS protocols. Aspects of the required interworking are discussed as it will influence the choice of a migration strategy. This framework document provides a migration toolkit to aid the operator in selection of an appropriate strategy.

本文档介绍了几种从MPLS-TE迁移到GMPLS的迁移模型和策略。在迁移过程中,MPLS-TE和GMPLS设备或网络可能共存,这可能需要MPLS-TE和GMPLS协议之间的互通。讨论了所需互通的各个方面,因为它将影响迁移策略的选择。本框架文档提供了一个迁移工具包,以帮助操作员选择适当的策略。

This framework document also lists a set of solutions that may aid in interworking, and highlights a set of potential issues.

本框架文件还列出了一组可能有助于互通的解决方案,并强调了一组潜在问题。

Table of Contents

目录

   1. Introduction ....................................................3
   2. Conventions Used in This Document ...............................3
   3. Motivations for Migration .......................................4
   4. MPLS to GMPLS Migration Models ..................................5
      4.1. Island Model ...............................................5
           4.1.1. Balanced Islands ....................................6
           4.1.2. Unbalanced Islands ..................................6
      4.2. Integrated Model ...........................................7
      4.3. Phased Model ...............................................8
   5. Migration Strategies and Toolkit ................................8
      5.1. Migration Toolkit ..........................................9
           5.1.1. Layered Networks ....................................9
           5.1.2. Routing Interworking ...............................11
           5.1.3. Signaling Interworking .............................12
           5.1.4. Path Computation Element ...........................13
   6. Manageability Considerations ...................................13
      6.1. Control of Function and Policy ............................13
      6.2. Information and Data Models ...............................14
      6.3. Liveness Detection and Monitoring .........................14
      6.4. Verifying Correct Operation ...............................14
      6.5. Requirements on Other Protocols and Functional
           Components ................................................14
      6.6. Impact on Network Operation ...............................15
      6.7. Other Considerations ......................................15
   7. Security Considerations ........................................15
   8. Acknowledgements ...............................................16
   9. References .....................................................16
      9.1. Normative References ......................................16
      9.2. Informative References ....................................17
   10. Contributors' Addresses .......................................17
        
   1. Introduction ....................................................3
   2. Conventions Used in This Document ...............................3
   3. Motivations for Migration .......................................4
   4. MPLS to GMPLS Migration Models ..................................5
      4.1. Island Model ...............................................5
           4.1.1. Balanced Islands ....................................6
           4.1.2. Unbalanced Islands ..................................6
      4.2. Integrated Model ...........................................7
      4.3. Phased Model ...............................................8
   5. Migration Strategies and Toolkit ................................8
      5.1. Migration Toolkit ..........................................9
           5.1.1. Layered Networks ....................................9
           5.1.2. Routing Interworking ...............................11
           5.1.3. Signaling Interworking .............................12
           5.1.4. Path Computation Element ...........................13
   6. Manageability Considerations ...................................13
      6.1. Control of Function and Policy ............................13
      6.2. Information and Data Models ...............................14
      6.3. Liveness Detection and Monitoring .........................14
      6.4. Verifying Correct Operation ...............................14
      6.5. Requirements on Other Protocols and Functional
           Components ................................................14
      6.6. Impact on Network Operation ...............................15
      6.7. Other Considerations ......................................15
   7. Security Considerations ........................................15
   8. Acknowledgements ...............................................16
   9. References .....................................................16
      9.1. Normative References ......................................16
      9.2. Informative References ....................................17
   10. Contributors' Addresses .......................................17
        
1. Introduction
1. 介绍

Multiprotocol Label Switching Traffic Engineering (MPLS-TE) to Generalized MPLS (GMPLS) migration is the process of evolving an MPLS-TE-based control plane to a GMPLS-based control plane. The network under consideration for migration is, therefore, a packet-switching network.

多协议标签交换流量工程(MPLS-TE)到广义MPLS(GMPLS)迁移是将基于MPLS-TE的控制平面演化为基于GMPLS的控制平面的过程。因此,考虑迁移的网络是分组交换网络。

There are several motivations for such migration, mainly the desire to take advantage of new features and functions added to the GMPLS protocols, which are not present in MPLS-TE for packet networks. Additionally, before migrating a packet-switching network from MPLS-TE to GMPLS, one may choose to first migrate a lower-layer network with no control plane (e.g., controlled by a management plane) to using a GMPLS control plane. This may lead to the desire for MPLS-TE/GMPLS (transport network) interworking to provide enhanced TE support and facilitate the later migration of the packet-switching network.

这种迁移有几个动机,主要是希望利用添加到GMPLS协议中的新特性和功能,这在MPLS-TE中不适用于分组网络。此外,在将分组交换网络从MPLS-TE迁移到GMPLS之前,可以选择首先将没有控制平面(例如,由管理平面控制)的较低层网络迁移到使用GMPLS控制平面。这可能导致对MPLS-TE/GMPLS(传输网络)互通的期望,以提供增强的TE支持并促进分组交换网络的稍后迁移。

Although an appropriate migration strategy will be selected based on various factors including the service provider's network deployment plan, customer demand, deployed network equipments, operational policy, etc., the transition mechanisms used should also provide consistent operation of newly introduced GMPLS networks, while minimizing the impact on the operation of existing MPLS-TE networks.

尽管将根据各种因素选择适当的迁移策略,包括服务提供商的网络部署计划、客户需求、部署的网络设备、运营政策等,但所使用的过渡机制也应为新引入的GMPLS网络提供一致的运营,同时尽量减少对现有MPLS-TE网络运行的影响。

This document describes several migration strategies and the interworking scenarios that arise during migration. It also examines the implications for network deployments and for protocol usage. As the GMPLS signaling and routing protocols are different from the MPLS-TE control protocols, interworking mechanisms between MPLS-TE and GMPLS networks, or network elements, may be needed to compensate for the differences.

本文档描述了几种迁移策略以及迁移过程中出现的互通场景。它还研究了对网络部署和协议使用的影响。由于GMPLS信令和路由协议不同于MPLS-TE控制协议,因此可能需要MPLS-TE和GMPLS网络或网络元件之间的互通机制来补偿这些差异。

Note that MPLS-TE and GMPLS protocols can coexist as "ships in the night" without any interworking issues.

请注意,MPLS-TE和GMPLS协议可以作为“夜间船舶”共存,没有任何互通问题。

2. Conventions Used in This Document
2. 本文件中使用的公约

This is not a requirements document, nevertheless 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 RFC 2119 [RFC2119] in order to clarify the recommendations that are made.

本文件不是要求文件,但本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中的描述进行解释,以澄清所提出的建议。

In the rest of this document, the term "GMPLS" includes both packet switching capable (PSC) and non-PSC. Otherwise, the term "PSC GMPLS" or "non-PSC GMPLS" is used explicitly.

在本文件的其余部分中,术语“GMPLS”包括支持分组交换(PSC)和非PSC。否则,明确使用术语“PSC GMPLS”或“非PSC GMPLS”。

In general, the term "MPLS" is used to indicate MPLS traffic engineering (MPLS-TE) only ([RFC3209], [RFC3630], and [RFC3784]) and excludes other MPLS protocols, such as the Label Distribution Protocol (LDP). TE functionalities of MPLS could be migrated to GMPLS, but non-TE functionalities could not. If non-TE MPLS is intended, it is indicated explicitly.

通常,术语“MPLS”仅用于表示MPLS流量工程(MPLS-TE)([RFC3209]、[RFC3630]和[RFC3784]),不包括其他MPLS协议,例如标签分发协议(LDP)。MPLS的TE功能可以迁移到GMPLS,但非TE功能不能迁移到GMPLS。如果打算使用非TE MPLS,则明确指出。

The reader is assumed to be familiar with the terminology introduced in [RFC3945].

假定读者熟悉[RFC3945]中介绍的术语。

3. Motivations for Migration
3. 移徙动机

Motivations for migration will vary for different service providers. This section is presented to provide background so that the migration discussions may be seen in context. Sections 4 and 5 provide examples to illustrate the migration models and processes.

迁移的动机因服务提供商而异。本节旨在提供背景信息,以便从上下文中了解迁移讨论。第4节和第5节提供了示例来说明迁移模型和过程。

Migration of an MPLS-capable Label Switching Router (LSR) to include GMPLS capabilities may be performed for one or more reasons, including, not exhaustively:

可出于一个或多个原因执行具有MPLS能力的标签交换路由器(LSR)的迁移以包括GMPLS能力,包括但不完全包括:

o To add all GMPLS PSC features to an existing MPLS network (upgrade MPLS LSRs).

o 将所有GMPLS PSC功能添加到现有MPLS网络(升级MPLS LSR)。

o To add specific GMPLS PSC features and operate them within an MPLS network (e.g., [RFC4872] and [RFC4873]).

o 添加特定的GMPLS PSC功能,并在MPLS网络中操作它们(例如,[RFC4872]和[RFC4873])。

o To integrate a new GMPLS PSC network with an existing MPLS network (without upgrading any of the MPLS LSRs).

o 将新的GMPLS PSC网络与现有MPLS网络集成(无需升级任何MPLS LSR)。

o To allow existing MPLS LSRs to interoperate with new non-MPLS LSRs supporting only GMPLS PSC and/or non-PSC features.

o 允许现有MPLS LSR与仅支持GMPLS PSC和/或非PSC功能的新非MPLS LSR互操作。

o To integrate multiple control networks, e.g., managed by separate administrative organizations, and which independently utilize MPLS or GMPLS.

o 集成多个控制网络,例如,由独立的管理组织管理,并独立使用MPLS或GMPLS。

o To build integrated PSC and non-PSC networks. The non-PSC networks are controlled by GMPLS.

o 建立综合的PSC和非PSC网络。非PSC网络由GMPLS控制。

The objective of migration from MPLS to GMPLS is that all LSRs, and the entire network, support GMPLS protocols. During this process, various interim situations may exist, giving rise to the interworking situations described in this document. The interim situations may exist for considerable periods of time, but the ultimate objective is not to preserve these situations. For the purposes of this document, they should be considered as temporary and transitory.

从MPLS迁移到GMPLS的目标是所有LSR和整个网络都支持GMPLS协议。在此过程中,可能存在各种临时情况,导致本文件中描述的互通情况。临时局势可能会存在相当长的一段时间,但最终目标不是维持这些局势。就本文件而言,它们应被视为临时性和暂时性的。

4. MPLS to GMPLS Migration Models
4. MPLS到GMPLS的迁移模型

Three reference migration models are described below. Multiple migration models may coexist in the same network.

下面介绍三种参考迁移模型。多个迁移模型可能共存于同一网络中。

4.1. Island Model
4.1. 岛模型

In the island model, "islands" of network nodes operating one protocol exist within a "sea" of nodes using the other protocol.

在孤岛模型中,运行一个协议的网络节点的“孤岛”存在于使用另一个协议的节点的“海洋”中。

For example, consider an island of GMPLS-capable nodes (PSC) that is introduced into a legacy MPLS network. Such an island might be composed of newly added GMPLS nodes, or it might arise from the upgrade of existing nodes that previously operated MPLS protocols.

例如,考虑引入到传统MPLS网络中的GMPLS能力节点(PSC)岛。这样的孤岛可能由新添加的GMPLS节点组成,也可能是由于升级先前运行MPLS协议的现有节点而产生的。

The opposite is also quite possible. That is, there is a possibility that an island happens to be MPLS-capable within a GMPLS sea. Such a situation might arise in the later stages of migration, when all but a few islands of MPLS-capable nodes have been upgraded to GMPLS.

相反的情况也很可能发生。也就是说,在GMPLS海中,有一个岛恰好具有MPLS能力。这种情况可能会在迁移的后期阶段出现,此时除了少数几个支持MPLS的孤岛外,所有节点都已升级到GMPLS。

It is also possible that a lower-layer, manually-provisioned network (for example, a Time Division Multiplexing (TDM) network) is constructed under an MPLS PSC network. During the process of migrating both networks to GMPLS, the lower-layer network might be migrated first. This would appear as a GMPLS island within an MPLS sea.

也可能在MPLS PSC网络下构造较低层的手动配置网络(例如,时分复用(TDM)网络)。在将两个网络迁移到GMPLS的过程中,可能首先迁移下层网络。这将显示为MPLS海中的GMPLS岛。

Lastly, it is possible to consider individual nodes as islands. That is, it would be possible to upgrade or insert an individual GMPLS-capable node within an MPLS network, and to treat that GMPLS node as an island.

最后,可以考虑单个节点作为岛屿。也就是说,可以在MPLS网络中升级或插入单个支持GMPLS的节点,并将该GMPLS节点视为孤岛。

Over time, collections of MPLS devices are replaced or upgraded to create new GMPLS islands or to extend existing ones, and distinct GMPLS islands may be joined together until the whole network is GMPLS-capable.

随着时间的推移,MPLS设备的集合会被替换或升级,以创建新的GMPLS岛或扩展现有的GMPLS岛,不同的GMPLS岛可能会连接在一起,直到整个网络能够使用GMPLS。

From a migration/interworking point of view, we need to examine how these islands are positioned and how Label Switched Paths (LSPs) connect between the islands.

从迁移/互通的角度来看,我们需要检查这些孤岛是如何定位的,以及这些孤岛之间的标签交换路径(LSP)是如何连接的。

Four categories of interworking scenarios are considered: (1) MPLS-GMPLS-MPLS, (2) GMPLS-MPLS-GMPLS, (3) MPLS-GMPLS, and (4) GMPLS-MPLS. In case 1, the interworking behavior is examined based on whether the GMPLS islands are PSC or non-PSC.

考虑了四类互通场景:(1)MPLS-GMPLS-MPLS,(2)GMPLS-MPLS-GMPLS,(3)MPLS-GMPLS和(4)GMPLS-MPLS。在案例1中,基于GMPLS岛是PSC还是非PSC来检查互通行为。

Figure 1 shows an example of the island model for MPLS-GMPLS-MPLS interworking. The model consists of a transit GMPLS island in an MPLS sea. The nodes at the boundary of the GMPLS island (G1, G2, G5, and G6) are referred to as "island border nodes". If the GMPLS island was non-PSC, all nodes except the island border nodes in the GMPLS-based transit island (G3 and G4) would be non-PSC devices, i.e., optical equipment (TDM, Lambda Switch Capable (LSC), and Fiber Switch Capable (FSC)).

图1显示了MPLS-GMPLS-MPLS互通的孤岛模型示例。该模型由MPLS海中的过境GMPLS岛组成。GMPLS岛边界处的节点(G1、G2、G5和G6)称为“岛边界节点”。如果GMPLS岛是非PSC的,则基于GMPLS的中转岛(G3和G4)中除岛边界节点外的所有节点都将是非PSC设备,即光学设备(TDM、支持Lambda交换机(LSC)和支持光纤交换机(FSC))。

   .................  ..........................  ..................
   :      MPLS      :  :          GMPLS         :  :     MPLS       :
   :+---+  +---+   +----+         +---+        +----+   +---+  +---+:
   :|R1 |__|R11|___| G1 |_________|G3 |________| G5 |___|R31|__|R3 |:
   :+---+  +---+   +----+         +-+-+        +----+   +---+  +---+:
   :      ________/ :  :  _______/  |   _____ / :  :  ________/     :
   :     /          :  : /          |  /        :  : /              :
   :+---+  +---+   +----+         +-+-+        +----+   +---+  +---+:
   :|R2 |__|R21|___| G2 |_________|G4 |________| G6 |___|R41|__|R4 |:
   :+---+  +---+   +----+         +---+        +----+   +---+  +---+:
   :................:  :........................:  :................:
        
   .................  ..........................  ..................
   :      MPLS      :  :          GMPLS         :  :     MPLS       :
   :+---+  +---+   +----+         +---+        +----+   +---+  +---+:
   :|R1 |__|R11|___| G1 |_________|G3 |________| G5 |___|R31|__|R3 |:
   :+---+  +---+   +----+         +-+-+        +----+   +---+  +---+:
   :      ________/ :  :  _______/  |   _____ / :  :  ________/     :
   :     /          :  : /          |  /        :  : /              :
   :+---+  +---+   +----+         +-+-+        +----+   +---+  +---+:
   :|R2 |__|R21|___| G2 |_________|G4 |________| G6 |___|R41|__|R4 |:
   :+---+  +---+   +----+         +---+        +----+   +---+  +---+:
   :................:  :........................:  :................:
        
      |<-------------------------------------------------------->|
                                  e2e LSP
        
      |<-------------------------------------------------------->|
                                  e2e LSP
        

Figure 1: Example of the island model for MPLS-GMPLS-MPLS interworking

图1:MPLS-GMPLS-MPLS互通的孤岛模型示例

4.1.1. Balanced Islands
4.1.1. 平衡岛

In the MPLS-GMPLS-MPLS and GMPLS-MPLS-GMPLS cases, LSPs start and end using the same protocols. Possible strategies include:

在MPLS-GMPLS-MPLS和GMPLS-MPLS-GMPLS情况下,LSP使用相同的协议开始和结束。可能的战略包括:

- tunneling the signaling across the island network using LSP nesting or stitching [RFC5150] (the latter is only for GMPLS-PSC)

- 使用LSP嵌套或缝合[RFC5150](后者仅适用于GMPLS-PSC)在岛屿网络上通过隧道传输信令

- protocol interworking or mapping (both are only for GMPLS-PSC)

- 协议互通或映射(两者仅适用于GMPLS-PSC)

4.1.2. Unbalanced Islands
4.1.2. 不平衡岛屿

As previously discussed, there are two island interworking models that support bordering islands. GMPLS(PSC)-MPLS and MPLS-GMPLS(PSC) island cases are likely to arise where the migration strategy is not based on a core infrastructure, but has edge nodes (ingress or egress) located in islands of different capabilities.

如前所述,有两种支持相邻岛屿的岛屿互通模型。GMPLS(PSC)-MPLS和MPLS-GMPLS(PSC)孤岛情况可能会出现,迁移策略不基于核心基础设施,而是边缘节点(入口或出口)位于不同能力的孤岛中。

In this case, an LSP starts or ends in a GMPLS (PSC) island and correspondingly ends or starts in an MPLS island. This mode of operation can only be addressed using protocol interworking or

在这种情况下,LSP在GMPLS(PSC)岛中开始或结束,并相应地在MPLS岛中结束或开始。此操作模式只能使用协议互通或

mapping. Figure 2 shows the reference model for this migration scenario. Head-end and tail-end LSRs are in distinct control plane clouds.

映射。图2显示了此迁移场景的参考模型。前端和后端LSR位于不同的控制平面云中。

   ............................  .............................
   :            MPLS          :  :       GMPLS (PSC)         :
   :+---+        +---+       +----+        +---+        +---+:
   :|R1 |________|R11|_______| G1 |________|G3 |________|G5 |:
   :+---+        +---+       +----+        +-+-+        +---+:
   :      ______/  |   _____/ :  :  ______/  |   ______/     :
   :     /         |  /       :  : /         |  /            :
   :+---+        +---+       +----+        +-+-+        +---+:
   :|R2 |________|R21|_______| G2 |________|G4 |________|G6 |:
   :+---+        +---+       +----+        +---+        +---+:
   :..........................:  :...........................:
        
   ............................  .............................
   :            MPLS          :  :       GMPLS (PSC)         :
   :+---+        +---+       +----+        +---+        +---+:
   :|R1 |________|R11|_______| G1 |________|G3 |________|G5 |:
   :+---+        +---+       +----+        +-+-+        +---+:
   :      ______/  |   _____/ :  :  ______/  |   ______/     :
   :     /         |  /       :  : /         |  /            :
   :+---+        +---+       +----+        +-+-+        +---+:
   :|R2 |________|R21|_______| G2 |________|G4 |________|G6 |:
   :+---+        +---+       +----+        +---+        +---+:
   :..........................:  :...........................:
        
     |<-------------------------------------------------->|
                             e2e LSP
        
     |<-------------------------------------------------->|
                             e2e LSP
        

Figure 2: GMPLS-MPLS interworking model

图2:GMPLS-MPLS互通模型

It is important to underline that this scenario is also impacted by the directionality of the LSP, and the direction in which the LSP is established.

需要强调的是,该场景还受到LSP方向性以及LSP建立方向的影响。

4.2. Integrated Model
4.2. 综合模型

The second migration model involves a more integrated migration strategy. New devices that are capable of operating both MPLS and GMPLS protocols are introduced into the MPLS network.

第二种迁移模型涉及一种更为集成的迁移策略。MPLS网络中引入了能够同时运行MPLS和GMPLS协议的新设备。

In the integrated model, there are two types of nodes present during migration:

在集成模型中,迁移期间存在两种类型的节点:

- those that support MPLS only (legacy nodes); and

- 仅支持MPLS的节点(遗留节点);和

- those that support MPLS and GMPLS.

- 支持MPLS和GMPLS的。

In this model, as existing MPLS devices are upgraded to support both MPLS and GMPLS, the network continues to operate with an MPLS control plane, but some LSRs are also capable of operating with a GMPLS control plane. So, LSPs are provisioned using MPLS protocols where one end point of a service is a legacy MPLS node and/or where the selected path between end points traverses a legacy node that is not GMPLS-capable. But where the service can be provided using only GMPLS-capable nodes [RFC5073], it may be routed accordingly and can achieve a higher level of functionality by utilizing GMPLS features.

在该模型中,随着现有MPLS设备升级以支持MPLS和GMPLS,网络继续使用MPLS控制平面运行,但一些LSR也能够使用GMPLS控制平面运行。因此,使用MPLS协议供应lsp,其中服务的一个端点是遗留MPLS节点和/或端点之间的所选路径穿过不支持GMPLS的遗留节点。但是,如果只能使用支持GMPLS的节点提供服务[RFC5073],则可以相应地对其进行路由,并可以通过利用GMPLS功能实现更高级别的功能。

Once all devices in the network are GMPLS-capable, the MPLS-specific protocol elements may be turned off, and no new devices need to support these protocol elements.

一旦网络中的所有设备都支持GMPLS,MPLS特定的协议元素就可以关闭,并且没有新设备需要支持这些协议元素。

In this model, the questions to be addressed concern the coexistence of the two protocol sets within the network. Actual interworking is not a concern.

在该模型中,需要解决的问题涉及网络中两个协议集的共存。实际的互通不是一个问题。

4.3. Phased Model
4.3. 阶段模型

The phased model introduces GMPLS features and protocol elements into an MPLS network one by one. For example, some objects or sub-objects (such as the Explicit Route Object (ERO) label sub-object, [RFC3473]) might be introduced into the signaling used by LSRs that are otherwise MPLS-capable. This would produce a kind of hybrid LSR.

分阶段模型将GMPLS特性和协议元素逐一引入MPLS网络。例如,一些对象或子对象(例如显式路由对象(ERO)标签子对象[RFC3473])可能被引入到lsr所使用的信令中,否则这些lsr就具有MPLS能力。这将产生一种混合LSR。

This approach may appear simpler to implement as one is able to quickly and easily pick up new key functions without needing to upgrade the whole protocol implementation. It is most likely to be used where there is a desire to rapidly implement a particular function within a network without the necessity to install and test the full GMPLS function.

这种方法似乎更易于实现,因为可以快速、轻松地获取新的关键功能,而无需升级整个协议实现。它最有可能用于希望在网络中快速实现特定功能而无需安装和测试完整的GMPLS功能的情况。

Interoperability concerns though are exacerbated by this migration model, unless all LSRs in the network are updated simultaneously and there is a clear understanding of which subset of features are to be included in the hybrid LSRs. Interworking between a hybrid LSR and an unchanged MPLS LSR would put the hybrid LSR in the role of a GMPLS LSR, as described in the previous sections, and puts the unchanged LSR in the role of an MPLS LSR. The potential for different hybrids within the network will complicate matters considerably. This model is, therefore, only appropriate for use when the set of new features to be deployed is well known and limited, and where there is a clear understanding of and agreement on this set of features by the network operators of the ISP(s) involved as well as all vendors whose equipment will be involved in the migration.

但是,这种迁移模型加剧了互操作性问题,除非网络中的所有LSR都同时更新,并且清楚地了解混合LSR中包含哪些功能子集。如前几节所述,混合LSR和未更改的MPLS LSR之间的互通将使混合LSR扮演GMPLS LSR的角色,并使未更改的LSR扮演MPLS LSR的角色。网络内不同混合动力车的潜力将使问题变得相当复杂。因此,此模型仅适用于待部署的一组新功能已知且有限,且相关ISP的网络运营商以及设备将参与迁移的所有供应商对这组功能有明确的理解并达成一致意见的情况。

5. Migration Strategies and Toolkit
5. 移徙战略和工具包

An appropriate migration strategy is selected by a network operator based on factors including the service provider's network deployment plan, customer demand, existing network equipment, operational policy, support from its vendors, etc.

网络运营商根据服务提供商的网络部署计划、客户需求、现有网络设备、运营策略、供应商支持等因素选择合适的迁移策略。

For PSC networks, the migration strategy involves the selection between the models described in the previous section. The choice will depend upon the final objective (full GMPLS capability, partial

对于PSC网络,迁移策略涉及在上一节中描述的模型之间进行选择。选择将取决于最终目标(全部GMPLS能力,部分

upgrade to include specific GMPLS features, or no change to existing IP/MPLS networks), and upon the immediate objectives (full, phased, or staged upgrade).

升级以包括特定的GMPLS功能,或不改变现有IP/MPLS网络),并根据当前目标(全面、分阶段或分阶段升级)。

For PSC networks serviced by non-PSC networks, two basic migration strategies can be considered. In the first strategy, the non-PSC network is made GMPLS-capable, first, and then the PSC network is migrated to GMPLS. This might arise when, in order to expand the network capacity, GMPLS-based non-PSC sub-networks are introduced into the legacy MPLS-based networks. Subsequently, the legacy MPLS-based PSC network is migrated to be GMPLS-capable, as described in the previous paragraph. Finally, the entire network, including both PSC and non-PSC nodes, may be controlled by GMPLS.

对于由非PSC网络服务的PSC网络,可以考虑两种基本迁移策略。在第一种策略中,首先使非PSC网络具有GMPLS能力,然后将PSC网络迁移到GMPLS。当为了扩展网络容量,将基于GMPLS的非PSC子网引入基于MPLS的传统网络时,可能会出现这种情况。随后,如前一段所述,将基于MPLS的传统PSC网络迁移为具有GMPLS能力。最后,整个网络,包括PSC和非PSC节点,可以由GMPLS控制。

The second strategy is to migrate the PSC network to GMPLS first, and then enable GMPLS within the non-PSC network. The PSC network is migrated as described before, and when the entire PSC network is completely converted to GMPLS, GMPLS-based non-PSC devices and networks may be introduced without any issues of interworking between MPLS and GMPLS.

第二种策略是首先将PSC网络迁移到GMPLS,然后在非PSC网络中启用GMPLS。如前所述迁移PSC网络,并且当整个PSC网络完全转换为GMPLS时,可以引入基于GMPLS的非PSC设备和网络,而不存在MPLS和GMPLS之间的互通问题。

These migration strategies and the migration models described in the previous section are not necessarily mutually exclusive. Mixtures of all strategies and models could be applied. The migration models and strategies selected will give rise to one or more of the interworking cases described in the following section.

这些迁移策略和上一节中描述的迁移模型不一定相互排斥。所有策略和模型的混合都可以应用。选择的迁移模型和策略将产生下一节中描述的一个或多个互通案例。

5.1. Migration Toolkit
5.1. 迁移工具包

As described in the previous sections, an essential part of a migration and deployment strategy is how the MPLS and GMPLS or hybrid LSRs interwork. This section sets out some of the alternatives for achieving interworking between MPLS and GMPLS, and it identifies some of the issues that need to be addressed. This document does not describe solutions to these issues.

如前几节所述,迁移和部署策略的一个重要部分是MPLS和GMPLS或混合LSR如何互通。本节列出了实现MPLS和GMPLS之间互通的一些备选方案,并确定了需要解决的一些问题。本文件不描述这些问题的解决方案。

Note that it is possible to consider upgrading the routing and signaling capabilities of LSRs from MPLS to GMPLS separately.

注意,可以考虑将LSR从MPLS路由到GMPLS的路由和信令能力分别提升。

5.1.1. Layered Networks
5.1.1. 分层网络

In the balanced island model, LSP tunnels [RFC4206] are a solution to carry the end-to-end LSPs across islands of incompatible nodes. Network layering is often used to separate domains of different data plane technology. It can also be used to separate domains of different control plane technology (such as MPLS and GMPLS protocols), and the solutions developed for multiple data plane

在平衡岛模型中,LSP隧道[RFC4206]是跨不兼容节点的岛承载端到端LSP的解决方案。网络分层通常用于分离不同数据平面技术的域。它还可以用于分离不同控制平面技术(如MPLS和GMPLS协议)的域,以及为多个数据平面开发的解决方案

technologies can be usefully applied to this situation [RFC3945], [RFC4206], and [RFC4726]. [MLN-REQ] gives a discussion of the requirements for multi-layered networks.

技术可以有效地应用于这种情况[RFC3945]、[RFC4206]和[RFC4726]。[MLN-REQ]讨论了多层网络的要求。

The GMPLS architecture [RFC3945] identifies three architectural models for supporting multi-layer GMPLS networks, and these models may be applied to the separation of MPLS and GMPLS control plane islands.

GMPLS体系结构[RFC3945]确定了三种支持多层GMPLS网络的体系结构模型,这些模型可用于分离MPLS和GMPLS控制平面孤岛。

- In the peer model, both MPLS and GMPLS nodes run the same routing instance, and routing advertisements from within islands of one level of protocol support are distributed to the whole network. This is achievable only, as described in Section 5.1.2, either by direct distribution or by mapping of parameters.

- 在对等模型中,MPLS和GMPLS节点运行相同的路由实例,并且来自一级协议支持孤岛内的路由广告分布到整个网络。如第5.1.2节所述,这只能通过直接分布或参数映射实现。

Signaling in the peer model may result in contiguous LSPs, stitched LSPs [RFC5150] (only for GMPLS PSC), or nested LSPs. If the network islands are non-PSC, then the techniques of [MLN-REQ] may be applied, and these techniques may be extrapolated to networks where all nodes are PSC, but where there is a difference in signaling protocols.

对等模型中的信令可能导致连续LSP、缝合LSP[RFC5150](仅适用于GMPLS PSC)或嵌套LSP。如果网络孤岛是非PSC的,则可以应用[MLN-REQ]的技术,并且这些技术可以外推到所有节点都是PSC但信令协议中存在差异的网络。

- The overlay model preserves strict separation of routing information between network layers. This is suitable for the balanced island model, and there is no requirement to handle routing interworking. Even though the overlay model preserves separation of signaling information between network layers, there may be some interaction in signaling between network layers.

- 覆盖模型保留了网络层之间路由信息的严格分离。这适用于平衡岛模型,并且不需要处理路由互通。尽管覆盖模型保留了网络层之间信令信息的分离,但网络层之间的信令可能存在一些交互。

The overlay model requires the establishment of control plane connectivity for the higher layer across the lower layer.

叠加模型要求在较低层上建立较高层的控制平面连接。

- The augmented model allows limited routing exchange from the lower-layer network to the higher-layer network. Generally speaking, this assumes that the border nodes provide some form of filtering, mapping, or aggregation of routing information advertised from the lower-layer network. This architectural model can also be used for balanced island model migrations. Signaling interworking is required as described for the peer model.

- 扩展模型允许从较低层网络到较高层网络的有限路由交换。一般来说,这假设边界节点提供某种形式的过滤、映射或聚合从较低层网络发布的路由信息。此体系结构模型也可用于平衡岛模型迁移。如对等模型所述,需要信令互通。

- The border peer architecture model is defined in [RFC5146]. This is a modification of the augmented model where the layer border routers have visibility into both layers, but no routing information is otherwise exchanged between routing protocol instances. This architectural model is particularly suited to the MPLS-GMPLS-MPLS island model for PSC and non-PSC GMPLS islands. Signaling interworking is required as described for the peer model.

- 边界对等体系结构模型在[RFC5146]中定义。这是对增强模型的修改,其中层边界路由器对两层都有可见性,但没有路由协议实例之间交换的路由信息。该体系结构模型特别适用于PSC和非PSC GMPLS孤岛的MPLS-GMPLS-MPLS孤岛模型。如对等模型所述,需要信令互通。

5.1.2. Routing Interworking
5.1.2. 路由互通

Migration strategies may necessitate some interworking between MPLS and GMPLS routing protocols. GMPLS extends the TE information advertised by the IGPs to include non-PSC information and extended PSC information. Because the GMPLS information is provided as additional TLVs that are carried along with the MPLS information, MPLS LSRs are able to "see" all GMPLS LSRs as though they were MPLS PSC LSRs. They will also see other GMPLS information, but will ignore it, flooding it transparently across the MPLS network for use by other GMPLS LSRs.

迁移策略可能需要在MPLS和GMPLS路由协议之间进行一些互通。GMPLS扩展了IGPs发布的TE信息,包括非PSC信息和扩展PSC信息。由于GMPLS信息作为附加TLV提供,并与MPLS信息一起携带,因此MPLS LSR能够“查看”所有GMPLS LSR,就好像它们是MPLS PSC LSR一样。他们也会看到其他GMPLS信息,但会忽略它,通过MPLS网络将其透明地淹没,供其他GMPLS LSR使用。

- Routing separation is achieved in the overlay and border peer models. This is convenient since only the border nodes need to be aware of the different protocol variants, and no mapping is required. It is suitable to the MPLS-GMPLS-MPLS and GMPLS-MPLS-GMPLS island migration models.

- 在覆盖和边界对等模型中实现了路由分离。这很方便,因为只有边界节点需要知道不同的协议变体,并且不需要映射。它适用于MPLS-GMPLS-MPLS和GMPLS-MPLS-GMPLS孤岛迁移模型。

- Direct distribution involves the flooding of MPLS routing information into a GMPLS network, and GMPLS routing information into an MPLS network. The border nodes make no attempt to filter the information. This mode of operation relies on the fact that MPLS routers will ignore, but continue to flood, GMPLS routing information that they do not understand. The presence of additional GMPLS routing information will not interfere with the way that MPLS LSRs select routes. Although this is not a problem in a PSC-only network, it could cause problems in a peer architecture network that includes non-PSC nodes, as the MPLS nodes are not capable of determining the switching types of the other LSRs and will attempt to signal end-to-end LSPs assuming all LSRs to be PSC. This fact would require island border nodes to take triggered action to set up tunnels across islands of different switching capabilities.

- 直接分发涉及将MPLS路由信息注入GMPLS网络,并将GMPLS路由信息注入MPLS网络。边界节点不尝试过滤信息。这种操作模式依赖于这样一个事实,即MPLS路由器将忽略但继续泛滥他们不理解的GMPLS路由信息。附加GMPLS路由信息的存在不会干扰MPLS LSR选择路由的方式。尽管这在仅PSC的网络中不是问题,但它可能在包括非PSC节点的对等体系结构网络中引起问题,因为MPLS节点不能确定其他lsr的交换类型,并且将尝试向端到端lsp发送信号,假设所有lsr都是PSC。这一事实将要求岛屿边界节点采取触发动作,在具有不同交换能力的岛屿之间建立隧道。

GMPLS LSRs might be impacted by the absence of GMPLS-specific information in advertisements initiated by MPLS LSRs. Specific procedures might be required to ensure consistent behavior by GMPLS nodes. If this issue is addressed, then direct distribution can be used in all migration models (except the overlay and border peer architectural models where the problem does not arise).

由于MPLS LSR发起的广告中缺少GMPLS特定信息,GMPLS LSR可能会受到影响。可能需要特定的程序来确保GMPLS节点的行为一致。如果解决了这个问题,那么可以在所有迁移模型中使用直接分发(不存在问题的覆盖和边界对等体系结构模型除外)。

- Protocol mapping converts routing advertisements so that they can be received in one protocol and transmitted in the other. For example, a GMPLS routing advertisement could have all of its GMPLS-specific information removed and could be flooded as an MPLS advertisement. This mode of interworking would require careful standardization of the correct behavior especially where an MPLS advertisement requires default values of GMPLS-specific fields to

- 协议映射转换路由播发,以便它们可以在一个协议中接收,在另一个协议中传输。例如,一个GMPLS路由广告可以删除其所有GMPLS特定信息,并可以作为MPLS广告淹没。这种互通模式需要对正确的行为进行仔细的标准化,特别是在MPLS广告要求使用GMPLS特定字段的默认值的情况下

be generated before the advertisement can be flooded further. There is also considerable risk of confusion in closely meshed networks where many LSRs have MPLS- and GMPLS-capable interfaces. This option for routing interworking during migration is NOT RECOMMENDED for any migration model. Note that converting GMPLS-specific sub-TLVs to MPLS-specific ones but not stripping the GMPLS-specific ones is considered a variant of the proposed solution in the previous bullet (unknown sub-TLVs should be ignored [RFC3630] but must continue to be flooded).

在广告进一步泛滥之前生成。在许多LSR具有MPLS和GMPLS接口的密集网络中,也存在相当大的混淆风险。对于任何迁移模型,都不建议使用此迁移期间路由互通选项。请注意,将特定于GMPLS的子TLV转换为特定于MPLS的子TLV,但不剥离特定于GMPLS的子TLV,这被认为是前一个项目符号中建议解决方案的变体(未知子TLV应被忽略[RFC3630],但必须继续淹没)。

- Ships in the night refers to a mode of operation where both MPLS and GMPLS routing protocol variants are operated in the same network at the same time as separate routing protocol instances. The two instances are independent and are used to create routing adjacencies between LSRs of the same type. This mode of operation may be appropriate to the integrated migration model.

- 夜间装运指的是一种操作模式,其中MPLS和GMPLS路由协议变体与单独的路由协议实例同时在同一网络中操作。这两个实例是独立的,用于在相同类型的LSR之间创建路由邻接。这种操作模式可能适用于集成迁移模型。

5.1.3. Signaling Interworking
5.1.3. 信号互通

Signaling protocols are used to establish LSPs and are the principal concern for interworking during migration. Issues of compatibility arise because of differences in the encodings and codepoints used by MPLS and GMPLS signaling, but also because of differences in functionality provided by MPLS and GMPLS.

信令协议用于建立LSP,是迁移期间互通的主要关注点。兼容性问题的产生是因为MPLS和GMPLS信令使用的编码和代码点不同,但也因为MPLS和GMPLS提供的功能不同。

- Tunneling and stitching [RFC5150] (GMPLS-PSC case) mechanisms provide the potential to avoid direct protocol interworking during migration in the island model because protocol elements are transported transparently across migration islands without being inspected. However, care may be needed to achieve functional mapping in these modes of operation since one set of features may need to be supported across a network designed to support a different set of features. In general, this is easily achieved for the MPLS-GMPLS-MPLS model, but may be hard to achieve in the GMPLS-MPLS-GMPLS model, for example, when end-to-end bidirectional LSPs are requested, since the MPLS island does not support bidirectional LSPs.

- 隧道和缝合[RFC5150](GMPLS-PSC案例)机制提供了在孤岛模型中迁移期间避免直接协议互通的可能性,因为协议元素在迁移孤岛之间透明传输,而无需检查。然而,在这些操作模式下实现功能映射可能需要谨慎,因为可能需要在设计用于支持不同功能集的网络上支持一组功能。一般来说,这对于MPLS-GMPLS-MPLS模型来说是容易实现的,但是在GMPLS-MPLS-GMPLS模型中可能很难实现,例如,当请求端到端双向LSP时,因为MPLS岛不支持双向LSP。

Note that tunneling and stitching are not available in unbalanced island models because in these cases, the LSP end points use different protocols.

请注意,隧道和缝合在不平衡孤岛模型中不可用,因为在这些情况下,LSP端点使用不同的协议。

- Protocol mapping is the conversion of signaling messages between MPLS and GMPLS. This mechanism requires careful documentation of the protocol fields and how they are mapped. This is relatively straightforward in the MPLS-GMPLS unbalanced island model for LSPs signaled in the MPLS-GMPLS direction. However, it may be more complex for LSPs signaled in the opposite direction, and this will

- 协议映射是MPLS和GMPLS之间信令消息的转换。这种机制需要仔细记录协议字段及其映射方式。对于在MPLS-GMPLS方向发送信号的LSP,这在MPLS-GMPLS不平衡岛模型中是相对简单的。然而,在相反方向发出信号的LSP可能更复杂,这将

lead to considerable complications for providing GMPLS services over the MPLS island and for terminating those services at an egress LSR that is not GMPLS-capable. Further, in balanced island models, and in particular where there are multiple small (individual node) islands, the repeated conversion of signaling parameters may lead to loss of information (and functionality) or mis-requests.

在MPLS岛上提供GMPLS服务以及在无法使用GMPLS的出口LSR处终止这些服务会导致相当大的复杂性。此外,在平衡岛模型中,特别是在存在多个小(单个节点)岛的情况下,信令参数的重复转换可能导致信息(和功能)丢失或错误请求。

- Ships in the night could be used in the integrated migration model to allow MPLS-capable LSRs to establish LSPs using MPLS signaling protocols and GMPLS LSRs to establish LSPs using GMPLS signaling protocols. LSRs that can handle both sets of protocols could work with both types of LSRs, and no conversion of protocols would be needed.

- 可在集成迁移模型中使用夜间船舶,以允许支持MPLS的LSR使用MPLS信令协议建立LSP,并允许GMPLS LSR使用GMPLS信令协议建立LSP。可以处理两组协议的LSR可以同时处理两种类型的LSR,并且不需要对协议进行转换。

5.1.4. Path Computation Element
5.1.4. 路径计算元件

The Path Computation Element (PCE) [RFC4655] may provide an additional tool to aid MPLS to GMPLS migration. If a layered network approach (Section 5.1.1) is used, PCEs may be used to facilitate the computation of paths for LSPs in the different layers [PCE-INT].

路径计算元素(PCE)[RFC4655]可以提供辅助MPLS到GMPLS迁移的附加工具。如果使用分层网络方法(第5.1.1节),则PCE可用于促进不同层中LSP路径的计算[PCE-INT]。

6. Manageability Considerations
6. 可管理性考虑

Attention should be given during migration planning to how the network will be managed during and after migration. For example, will the LSRs of different protocol capabilities be managed separately or as one management domain? For example, in the Island Model, it is possible to consider managing islands of one capability separately from the surrounding sea. In the case of islands that have different switching capabilities, it is possible that the islands already have separate management in place before the migration: the resultant migrated network may seek to merge the management or to preserve the separation.

在迁移规划期间,应注意如何在迁移期间和之后管理网络。例如,不同协议功能的LSR是单独管理还是作为一个管理域管理?例如,在岛模型中,可以考虑单独管理一个能力的岛屿与周围海域。对于具有不同交换能力的孤岛,在迁移之前,这些孤岛可能已经有了单独的管理:生成的迁移网络可能会寻求合并管理或保留分离。

6.1. Control of Function and Policy
6.1. 职能和政策的控制

The most critical control functionality to be applied is at the moment of changeover between different levels of protocol support. Such a change may be made without service halt or during a period of network maintenance.

要应用的最关键的控制功能是在协议支持的不同级别之间转换时。这种改变可以在不停止服务或网络维护期间进行。

Where island boundaries exist, it must be possible to manage the relationships between protocols and to indicate which interfaces support which protocols on a border LSR. Further, island borders are a natural place to apply policy, and management should allow configuration of such policies.

如果存在岛边界,则必须能够管理协议之间的关系,并指示哪些接口支持边界LSR上的哪些协议。此外,岛屿边界是适用政策的自然场所,管理层应允许配置此类政策。

6.2. Information and Data Models
6.2. 信息和数据模型

No special information or data models are required to support migration, but note that migration in the control plane implies migration from MPLS management tools to GMPLS management tools. During migration, therefore, it may be necessary for LSRs and management applications to support both MPLS and GMPLS management data.

不需要特殊的信息或数据模型来支持迁移,但请注意,控制平面中的迁移意味着从MPLS管理工具迁移到GMPLS管理工具。因此,在迁移期间,LSR和管理应用程序可能需要同时支持MPLS和GMPLS管理数据。

The GMPLS MIB modules are designed to allow support of the MPLS protocols, and they are built on the MPLS MIB modules through extensions and augmentations. This may make it possible to migrate management applications ahead of the LSRs that they manage.

GMPLS MIB模块旨在支持MPLS协议,并通过扩展和扩充在MPLS MIB模块上构建。这可能使管理应用程序在其管理的LSR之前迁移成为可能。

6.3. Liveness Detection and Monitoring
6.3. 活性检测与监测

Migration will not impose additional issues for Operations, Administration, and Management (OAM) above those that already exist for inter-domain OAM and for OAM across multiple switching capabilities.

迁移不会给操作、管理和管理(OAM)带来比域间OAM和跨多个交换功能的OAM更大的问题。

Note, however, that if a flat PSC MPLS network is migrated using the island model, and is treated as a layered network using tunnels to connect across GMPLS islands, then requirements for a multi-layer OAM technique may be introduced into what was previously defined in the flat OAM problem-space. The OAM framework of MPLS/GMPLS interworking will need further consideration.

但是,请注意,如果使用孤岛模型迁移平面PSC MPLS网络,并将其视为使用隧道跨GMPLS孤岛连接的分层网络,则多层OAM技术的要求可能会引入先前在平面OAM问题空间中定义的内容。MPLS/GMPLS互通的OAM框架需要进一步考虑。

6.4. Verifying Correct Operation
6.4. 验证操作是否正确

The concerns for verifying correct operation (and in particular, correct connectivity) are the same as for liveness detection and monitoring. Specifically, the process of migration may introduce tunneling or stitching [RFC5150] into what was previously a flat network.

验证正确操作(尤其是正确连接)的关注点与活动检测和监控的关注点相同。具体而言,迁移过程可能会将隧道或缝合[RFC5150]引入到以前的平面网络中。

6.5. Requirements on Other Protocols and Functional Components
6.5. 对其他协议和功能组件的要求

No particular requirements are introduced on other protocols. As it has been observed, the management components may need to migrate in step with the control plane components, but this does not impact the management protocols, just the data that they carry.

在其他协议上没有引入特殊要求。正如所观察到的,管理组件可能需要与控制平面组件同步迁移,但这并不影响管理协议,只影响它们所承载的数据。

It should also be observed that providing signaling and routing connectivity across a migration island in support of a layered architecture may require the use of protocol tunnels (such as Generic

还应注意,为支持分层体系结构而提供跨迁移岛的信令和路由连接可能需要使用协议隧道(例如通用协议隧道)

Routing Encapsulation (GRE)) between island border nodes. Such tunnels may impose additional configuration requirements at the border nodes.

岛边界节点之间的路由封装(GRE))。此类隧道可在边界节点处施加额外的配置要求。

6.6. Impact on Network Operation
6.6. 对网络运营的影响

The process of migration is likely to have significant impact on network operation while migration is in progress. The main objective of migration planning should be to reduce the impact on network operation and on the services perceived by the network users.

迁移过程可能会在迁移过程中对网络运行产生重大影响。迁移规划的主要目标应该是减少对网络运营和网络用户感知的服务的影响。

To this end, planners should consider reducing the number of migration steps that they perform and minimizing the number of migration islands that are created.

为此,规划者应该考虑减少它们执行的迁移步骤的数量,并最小化所创建的迁移岛的数量。

A network manager may prefer the island model especially when migration will extend over a significant operational period because it allows the different network islands to be administered as separate management domains. This is particularly the case in the overlay, augmented network and border peer models where the details of the protocol islands remain hidden from the surrounding LSRs.

网络管理员可能更喜欢孤岛模型,尤其是当迁移将延长一段较长的运营期时,因为它允许将不同的网络孤岛作为单独的管理域进行管理。在覆盖、增强网络和边界对等模型中尤其如此,在这些模型中,协议岛的细节仍然对周围的LSR隐藏。

6.7. Other Considerations
6.7. 其他考虑

A migration strategy may also imply moving an MPLS state to a GMPLS state for an in-service LSP. This may arise once all of the LSRs along the path of the LSP have been updated to be both MPLS- and GMPLS-capable. Signaling mechanisms to achieve the replacement of an MPLS LSP with a GMPLS LSP without disrupting traffic exist through make-before-break procedures [RFC3209] and [RFC3473], and should be carefully managed under operator control.

迁移策略还可能意味着将MPLS状态移动到服务中LSP的GMPLS状态。一旦LSP路径上的所有LSR都被更新为支持MPLS和GMPLS,就会出现这种情况。通过先通后断程序[RFC3209]和[RFC3473]可以实现在不中断通信的情况下用GMPLS LSP替换MPLS LSP的信令机制,并应在操作员控制下小心管理。

7. Security Considerations
7. 安全考虑

Security and confidentiality is often applied (and attacked) at administrative boundaries. Some of the models described in this document introduce such boundaries, for example, between MPLS and GMPLS islands. These boundaries offer the possibility of applying or modifying the security as when crossing an IGP area or Autonomous System (AS) boundary, even though these island boundaries might lie within an IGP area or AS.

安全性和保密性通常在管理边界应用(并受到攻击)。本文档中描述的一些模型引入了这样的边界,例如MPLS和GMPLS岛之间的边界。这些边界提供了在跨越IGP区域或自治系统(as)边界时应用或修改安全性的可能性,即使这些岛屿边界可能位于IGP区域或as内。

No changes are proposed to the security procedures built into MPLS and GMPLS signaling and routing. GMPLS signaling and routing inherit their security mechanisms from MPLS signaling and routing without any changes. Hence, there will be no additional issues with security in interworking scenarios. Further, since the MPLS and GMPLS signaling and routing security is provided on a hop-by-hop basis, and since all

不建议更改MPLS和GMPLS信令和路由中内置的安全程序。GMPLS信令和路由继承了MPLS信令和路由的安全机制,没有任何变化。因此,在互通场景中不会出现其他安全问题。此外,由于MPLS和GMPLS信令和路由安全是在逐跳的基础上提供的,并且由于

signaling and routing exchanges described in this document for use between any pair of LSRs are based on either MPLS or GMPLS, there are no changes necessary to the security procedures.

本文件中描述的用于任何一对LSR之间的信令和路由交换基于MPLS或GMPLS,安全程序无需更改。

8. Acknowledgements
8. 致谢

The authors are grateful to Daisaku Shimazaki for discussion during the initial work on this document. The authors are grateful to Dean Cheng and Adrian Farrel for their valuable comments.

作者感谢岛崎大作在本文件初始工作期间的讨论。作者感谢Cheng院长和Adrian Farrel的宝贵意见。

9. References
9. 工具书类
9.1. Normative References
9.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月。

[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.

[RFC3473]Berger,L.,Ed.“通用多协议标签交换(GMPLS)信令资源预留协议流量工程(RSVP-TE)扩展”,RFC 3473,2003年1月。

[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, September 2003.

[RFC3630]Katz,D.,Kompella,K.,和D.Yeung,“OSPF版本2的交通工程(TE)扩展”,RFC 3630,2003年9月。

[RFC3784] Smit, H. and T. Li, "Intermediate System to Intermediate System (IS-IS) Extensions for Traffic Engineering (TE)", RFC 3784, June 2004.

[RFC3784]Smit,H.和T.Li,“交通工程(TE)的中间系统到中间系统(IS-IS)扩展”,RFC 37842004年6月。

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

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

[RFC4872] Lang, J., Ed., Rekhter, Y., Ed., and D. Papadimitriou, Ed., "RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery", RFC 4872, May 2007.

[RFC4872]Lang,J.,Ed.,Rekhter,Y.,Ed.,和D.Papadimitriou,Ed.,“支持端到端通用多协议标签交换(GMPLS)恢复的RSVP-TE扩展”,RFC 4872,2007年5月。

[RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel, "GMPLS Segment Recovery", RFC 4873, May 2007.

[RFC4873]Berger,L.,Bryskin,I.,Papadimitriou,D.,和A.Farrel,“GMPLS段恢复”,RFC 4873,2007年5月。

[RFC5073] Vasseur, J., Ed., and J. Le Roux, Ed., "IGP Routing Protocol Extensions for Discovery of Traffic Engineering Node Capabilities", RFC 5073, December 2007.

[RFC5073]Vasseur,J.,Ed.,和J.Le Roux,Ed.,“发现流量工程节点能力的IGP路由协议扩展”,RFC 5073,2007年12月。

9.2. Informative References
9.2. 资料性引用

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

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

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

[RFC5150] Ayyangar, A., Kompella, A., Vasseur, JP., and A. Farrel, "Label Switched Path Stitching with Generalized Multiprotocol Label Switching Traffic Engineering", RFC 5150, February 2008.

[RFC5150]Ayyangar,A.,Kompella,A.,Vasseur,JP.,和A.Farrel,“具有通用多协议标签交换流量工程的标签交换路径缝合”,RFC 51502008年2月。

[RFC5146] Kumaki, K., Ed., "Interworking Requirements to Support Operation of MPLS-TE over GMPLS Networks", RFC 5146, March 2008.

[RFC5146]Kumaki,K.,Ed.“支持MPLS-TE在GMPLS网络上运行的互通要求”,RFC 5146,2008年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月。

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

Dimitri Papadimitriou Alcatel Francis Wellensplein 1, B-2018 Antwerpen, Belgium Phone: +32 3 240 8491 EMail: dimitri.papadimitriou@alcatel-lucent.be

Dimitri Papadimitriou Alcatel Francis Wellensplein 1,B-2018比利时安特卫普电话:+32 3 240 8491电子邮件:Dimitri。papadimitriou@alcatel-朗讯

Jean-Louis Le Roux France Telecom av Pierre Marzin 22300 Lannion, France Phone: +33 2 96 05 30 20 EMail: jeanlouis.leroux@orange-ftgroup.com

Jean-Louis Le Roux法国电信av Pierre Marzin 22300法国拉尼翁电话:+33 2 96 05 30 20电子邮件:jeanlouis。leroux@orange-ftgroup.com

Deborah Brungard AT&T Rm. D1-3C22 - 200 S. Laurel Ave. Middletown, NJ 07748, USA Phone: +1 732 420 1573 EMail: dbrungard@att.com

德博拉·布伦加德AT&T室。D1-3C22-200美国新泽西州米德尔顿市劳雷尔大道南07748号电话:+1732 420 1573电子邮件:dbrungard@att.com

Zafar Ali Cisco Systems, Inc. EMail: zali@cisco.com

Zafar Ali Cisco Systems,Inc.电子邮件:zali@cisco.com

Kenji Kumaki KDDI Corporation Garden Air Tower Iidabashi, Chiyoda-ku, Tokyo 102-8460, JAPAN Phone: +81-3-6678-3103 EMail: ke-kumaki@kddi.com

Kenji Kumaki KDDI Corporation Garden Air Tower Iidabashi,Chiyoda ku,东京102-8460,日本电话:+81-3-6678-3103电子邮件:ke-kumaki@kddi.com

Eiji Oki NTT Midori 3-9-11 Musashino, Tokyo 180-8585, Japan Phone: +81 422 59 3441 EMail: oki.eiji@lab.ntt.co.jp

日本东京武藏野3-9-11,180-8585电话:+81422593441电子邮件:Oki。eiji@lab.ntt.co.jp

Ichiro Inoue NTT Midori 3-9-11 Musashino, Tokyo 180-8585, Japan Phone: +81 422 59 3441 EMail: inoue.ichiro@lab.ntt.co.jp

井上一郎NTT Midori 3-9-11武藏野,日本东京180-8585电话:+81 422 59 3441电子邮件:井上一郎。ichiro@lab.ntt.co.jp

Tomohiro Otani KDDI Laboratories EMail: otani@kddilabs.jp

大谷智博KDDI实验室电子邮件:otani@kddilabs.jp

Editor's Address

编辑地址

Kohei Shiomoto NTT Midori 3-9-11 Musashino, Tokyo 180-8585, Japan Phone: +81 422 59 4402 EMail: shiomoto.kohei@lab.ntt.co.jp

日本东京武藏野3-9-11武藏野,邮编:180-8585电话:+81 422 59 4402电子邮件:Shiomoto。kohei@lab.ntt.co.jp

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.