Network Working Group D. Caviglia
Request for Comments: 5493 D. Bramanti
Category: Informational Ericsson
D. Li
Huawei Technologies Co., Ltd.
D. McDysan
Verizon
April 2009
Network Working Group D. Caviglia
Request for Comments: 5493 D. Bramanti
Category: Informational Ericsson
D. Li
Huawei Technologies Co., Ltd.
D. McDysan
Verizon
April 2009
Requirements for the Conversion between Permanent Connections and Switched Connections in a Generalized Multiprotocol Label Switching (GMPLS) Network
通用多协议标签交换（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.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2009 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
本文件受BCP 78和IETF信托在本文件出版之日生效的与IETF文件有关的法律规定的约束(http://trustee.ietf.org/license-info). 请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Abstract
摘要
From a carrier perspective, the possibility of turning a permanent connection (PC) into a soft permanent connection (SPC) and vice versa, without actually affecting data plane traffic being carried over it, is a valuable option. In other terms, such operation can be seen as a way of transferring the ownership and control of an existing and in-use data plane connection between the management plane and the control plane, leaving its data plane state untouched.
从运营商的角度来看，将永久性连接（PC）转变为软永久性连接（SPC）以及将软永久性连接（SPC）转变为软永久性连接（SPC）的可能性是一个有价值的选择，而不会实际影响通过其传输的数据平面流量。换句话说，这种操作可以被看作是在管理平面和控制平面之间转移现有和正在使用的数据平面连接的所有权和控制权的一种方式，保持其数据平面状态不变。
This memo sets out the requirements for such procedures within a Generalized Multiprotocol Label Switching (GMPLS) network.
本备忘录规定了通用多协议标签交换（GMPLS）网络中此类程序的要求。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Conventions Used in This Document ..........................3
2. Label Switched Path Terminology .................................3
3. LSP within GMPLS Control Plane ..................................4
3.1. Resource Ownership .........................................4
3.2. Setting Up a GMPLS-Controlled Network ......................5
4. Typical Use Cases ...............................................6
4.1. PC-to-SC/SPC Conversion ....................................6
4.2. SC-to-PC Conversion ........................................6
5. Requirements ....................................................7
5.1. Data Plane LSP Consistency .................................7
5.2. No Disruption of User Traffic ..............................7
5.3. Transfer from Management Plane to Control Plane ............7
5.4. Transfer from Control Plane to Management Plane ............7
5.5. Synchronization of State among Nodes during Conversion .....7
5.6. Support of Soft Permanent Connections ......................8
5.7. Failure of Transfer ........................................8
6. Security Considerations .........................................8
7. Contributors ....................................................9
8. Acknowledgments .................................................9
9. References ......................................................9
9.1. Normative References .......................................9
9.2. Informational References ..................................10
1. Introduction ....................................................3
1.1. Conventions Used in This Document ..........................3
2. Label Switched Path Terminology .................................3
3. LSP within GMPLS Control Plane ..................................4
3.1. Resource Ownership .........................................4
3.2. Setting Up a GMPLS-Controlled Network ......................5
4. Typical Use Cases ...............................................6
4.1. PC-to-SC/SPC Conversion ....................................6
4.2. SC-to-PC Conversion ........................................6
5. Requirements ....................................................7
5.1. Data Plane LSP Consistency .................................7
5.2. No Disruption of User Traffic ..............................7
5.3. Transfer from Management Plane to Control Plane ............7
5.4. Transfer from Control Plane to Management Plane ............7
5.5. Synchronization of State among Nodes during Conversion .....7
5.6. Support of Soft Permanent Connections ......................8
5.7. Failure of Transfer ........................................8
6. Security Considerations .........................................8
7. Contributors ....................................................9
8. Acknowledgments .................................................9
9. References ......................................................9
9.1. Normative References .......................................9
9.2. Informational References ..................................10
In a typical, traditional transport network scenario, data plane connections between two end-points are controlled by means of a Network Management System (NMS) operating within the management plane (MP). The NMS/MP is the owner of such transport connections, being responsible of their setup, teardown, and maintenance. Provisioned connections of this type, initiated and managed by the management plane, are known as permanent connections (PCs) [G.8081].
在典型的传统传输网络场景中，两个端点之间的数据平面连接由在管理平面（MP）内运行的网络管理系统（NMS）控制。NMS/MP是此类传输连接的所有者，负责其设置、拆卸和维护。由管理平面发起和管理的这种类型的供应连接称为永久连接（PCs）[G.8081]。
When the setup, teardown, and maintenance of connections are achieved by means of a signaling protocol owned by the control plane (CP), such connections are known as switched connections (SCs) [G.8081].
当通过控制平面（CP）拥有的信令协议实现连接的设置、拆卸和维护时，这种连接称为交换连接（SCs）[G.8081]。
In many deployments, a hybrid connection type will be used. A soft permanent connection (SPC) is a combination of a permanent connection segment at the source-user-to-network side, a permanent connection segment at the destination-user-to-network side, and a switched connection segment within the core network. The permanent parts of the SPC are owned by the management plane, and the switched parts are owned by the control plane [G.8081].
在许多部署中，将使用混合连接类型。软永久连接（SPC）是源用户到网络侧的永久连接段、目标用户到网络侧的永久连接段和核心网络内的交换连接段的组合。SPC的永久部分归管理平面所有，交换部分归控制平面所有[G.8081]。
Note, some aspects of a control-plane-initiated connection must be capable of being queried/controlled by the management plane. These aspects should be independent of how the connection was established.
注意，控制平面启动的连接的某些方面必须能够被管理平面查询/控制。这些方面应独立于如何建立联系。
Although this requirements document is an informational document, 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 RFC 2119 [RFC2119] for clarity of requirement specification.
尽管本要求文件是一份信息性文件，而非协议规范，但为了明确要求规范，本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应该”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中的描述进行解释。
A Label Switched Path (LSP) has different semantics depending on the plane in which the term is used.
标签交换路径（LSP）具有不同的语义，这取决于使用该术语的平面。
In the data plane, an LSP indicates the data plane forwarding path. It defines the forwarding or switching operations at each network entity. It is the sequence of data plane resources (links, labels, cross-connects) that achieves end-to-end data transport.
在数据平面中，LSP指示数据平面转发路径。它定义了每个网络实体的转发或交换操作。正是数据平面资源序列（链接、标签、交叉连接）实现了端到端数据传输。
In the management plane, an LSP is the management plane state information (such as the connection attributes and path information) associated with and necessary for the creation and maintenance of a data plane connection.
在管理平面中，LSP是与数据平面连接的创建和维护相关联且必要的管理平面状态信息（例如连接属性和路径信息）。
In the control plane, an LSP is the control plane state information (such as the RSVP-TE [RFC3473] Path and Resv state) associated with and necessary for the creation and maintenance of a data plane connection.
在控制平面中，LSP是与数据平面连接的创建和维护相关联且必要的控制平面状态信息（例如RSVP-TE[RFC3473]路径和Resv状态）。
A permanent connection has an LSP presence in the data plane and the management plane. A switched connection has an LSP presence in the data plane and the control plane. An SPC has an LSP presence in the data plane for its entire length, but has a management plane presence for part of its length and a control plane presence for part of its length.
永久连接在数据平面和管理平面中存在LSP。交换连接在数据平面和控制平面中存在LSP。SPC在其整个长度的数据平面中存在LSP，但在其部分长度中存在管理平面，在其部分长度中存在控制平面。
In this document, when we discuss the LSP conversion between management plane and control plane, we mainly focus on the conversion of control plane state information and management plane state information.
在本文中，当我们讨论管理平面和控制平面之间的LSP转换时，我们主要关注控制平面状态信息和管理平面状态信息的转换。
GMPLS ([RFC3471], [RFC3473], and [RFC3945]) defines a control plane architecture for transport networks. This includes both routing and signaling protocols for the creation and maintenance of LSPs in networks whose data plane is based on different technologies, such as Time Division Multiplexing (SDH/SONET, G.709 at ODUk level) and Wavelength Division Multiplexing (G.709 at OCh level).
GMPLS（[RFC3471]、[RFC3473]和[RFC3945]）定义了传输网络的控制平面架构。这包括用于在数据平面基于不同技术的网络中创建和维护LSP的路由和信令协议，例如时分复用（SDH/SONET，ODUk级别的G.709）和波分复用（OCh级别的G.709）。
A resource used by an LSP is said to be 'owned' by the plane that was used to set up the LSP through that part of the network. Thus, all the resources used by a permanent connection are owned by the management plane, and all the resources used by a switched connection are owned by the control plane. The resources used by an SPC are divided between the management plane (for the resources used by the permanent connection segments at the edge of the network) and the control plane (for the resources used by the switched connection segments in the middle of the network).
LSP使用的资源被称为“拥有”于用于通过该部分网络建立LSP的平面。因此，永久连接使用的所有资源都属于管理平面，而交换连接使用的所有资源都属于控制平面。SPC所使用的资源被划分在管理平面（用于网络边缘的永久连接段所使用的资源）和控制平面（对于网络中间的交换连接段所使用的资源）之间。
The division of resources available for ownership by the management and control planes is an architectural issue. A carrier may decide to pre-partition the resources at a network entity so that LSPs under management plane control use one set of resources and LSPs under
管理层和控制层可用于所有权的资源划分是一个体系结构问题。运营商可以决定在网络实体处预划分资源，以便在管理平面控制下的lsp使用一组资源，并且在管理平面控制下的lsp
control plane control use another set of resources. Other carriers may choose to make this distinction resource-by-resource as LSPs are established.
控制平面控制使用另一组资源。当建立lsp时，其他运营商可以选择按资源进行此区分。
It should be noted, however, that even when a resource is owned by the control plane it will usually be the case that the management plane has a controlling interest in the resource. For example, consider the basic safety requirements that management commands must be able to put a laser out of service.
然而，应该注意的是，即使资源由控制平面拥有，通常情况下管理平面对资源拥有控制权益。例如，考虑管理命令必须能够使激光器失效的基本安全要求。
The implementation of a new network using a Generalized Multiprotocol Label Switching (GMPLS) control plane may be considered as a green field deployment. But in many cases, it is desirable to introduce a GMPLS control plane into an existing transport network that is already populated with permanent connections under management plane control.
使用通用多协议标签交换（GMPLS）控制平面实现一个新网络可被视为一种新的部署。但在许多情况下，最好将GMPLS控制平面引入现有的传输网络中，该网络中已经存在管理平面控制下的永久连接。
In a mixed scenario, permanent connections owned by the management plane and switched connections owned by the control plane have to coexist within the network.
在混合场景中，管理平面拥有的永久连接和控制平面拥有的交换连接必须在网络中共存。
It is also desirable to transfer the control of connections from the management plane to the control plane so that connections that were originally under the control of an NMS are now under the control of the GMPLS protocols. In case such connections are in service, such conversion must be performed in a way that does not affect traffic.
还希望将对连接的控制从管理平面转移到控制平面，以便最初由NMS控制的连接现在由GMPLS协议控制。如果此类连接正在使用中，则必须以不影响流量的方式执行此类转换。
Since attempts to move an LSP under GMPLS control might fail due to a number of reasons outside the scope of this document, it is also highly desirable to have a mechanism to convert the control of an LSP back to the management plane.
由于本文件范围之外的许多原因，在GMPLS控制下移动LSP的尝试可能会失败，因此也非常希望有一种机制将LSP的控制权转换回管理平面。
Note that a permanent connection may be converted to a switched connection or to an SPC, and an SPC may be converted to a switched connection as well (PC to SC, PC to SPC, and SPC to SC). So the reverse mappings may also be needed (SC to PC, SPC to PC, and SC to SPC).
注意，永久连接可以转换为交换连接或SPC，SPC也可以转换为交换连接（PC到SC、PC到SPC和SPC到SC）。因此，可能还需要反向映射（SC到PC、SPC到PC和SC到SPC）。
Conversion to/from control/management will occur in MIBs or in information stored on the device (e.g., cross-connect, label assignment, label stacking, etc.) and is identified as either initiated by a specific control protocol or by manual operation (i.e., via an NMS). When converting, this hop-level owner information needs to be completed for all hops. If conversion cannot be done for all hops, then the conversion must be done for no hops,
控制/管理的转换将在MIB或设备上存储的信息（例如交叉连接、标签分配、标签堆叠等）中发生，并被识别为由特定控制协议或手动操作（即通过NMS）启动。转换时，需要完成所有跃点的跃点级别所有者信息。如果不能对所有跃点进行转换，则必须对无跃点进行转换，
the state of the hop-level information must be restored to that before the conversion was attempted, and an error condition must be reported to the management system.
跃点级别信息的状态必须恢复到尝试转换之前的状态，并且必须向管理系统报告错误情况。
In either case of conversion, the management plane shall initiate the change. When converting from a PC to an SC, the management system must indicate to each hop that a control protocol is now to be used, and then configure the data needed by the control protocol at the connection endpoints. When converting from an SC to a PC, the management plane must change the owner of each hop. Then the instance in the control plane must be removed without affecting the data plane.
在任何一种转换情况下，管理层都应发起变更。从PC转换到SC时，管理系统必须向每个跃点指示现在要使用控制协议，然后在连接端点配置控制协议所需的数据。从SC转换到PC时，管理平面必须更改每个跃点的所有者。然后，必须在不影响数据平面的情况下删除控制平面中的实例。
The case where the CP and/or MP fail at one or more nodes during the conversion procedure must be handled in the solution. If the network is viewed as the database of record (including data, control, and management plane elements), then a solution that has procedures similar to those of a two-phase database commit process may be needed to ensure integrity and to support the need to revert to the state prior to the conversion attempt if there is a CP and/or MP failure during the attempted conversion.
在转换过程中，必须在解决方案中处理CP和/或MP在一个或多个节点失败的情况。如果网络被视为记录数据库（包括数据、控制和管理平面元素），然后，可能需要具有类似于两阶段数据库提交过程的过程的解决方案，以确保完整性，并支持在尝试转换期间出现CP和/或MP故障时恢复到转换尝试之前的状态。
A typical scenario where a PC-to-SC (or SPC) procedure can be a useful option is at the initial stage of control plane deployment in an existing network. In such a case, all the network connections, possibly carrying traffic, are already set up as PCs and are owned by the management plane.
PC到SC（或SPC）程序可能是一个有用选项的典型场景是在现有网络中控制平面部署的初始阶段。在这种情况下，所有可能承载流量的网络连接都已设置为PC，并归管理层所有。
At a latter stage, when the network is partially controlled by the management plane and partially controlled by the control plane (PCs and SCs/SPCs coexist) and it is desired to extend the control plane, a PC-to-SC procedure can be used to transfer a PC or SPC to a SC.
在后一阶段，当网络部分由管理平面控制，部分由控制平面控制（PC和SCs/SPC共存）并且希望扩展控制平面时，可以使用PC到SC程序将PC或SPC传输到SC。
In both cases, a connection, set up and owned by the management plane, needs to be transferred to control plane control. If a connection is carrying traffic, its control transfer has to be done without any disruption to the data plane traffic.
在这两种情况下，都需要将管理平面建立并拥有的连接转移到控制平面控制。如果连接承载流量，则必须在不中断数据平面流量的情况下进行控制传输。
The main need for an SC-to-PC conversion is to give an operator the capability of undoing the action of the above introduced PC-to-SC conversion.
SC到PC转换的主要需要是使操作员能够撤消上述PC到SC转换的操作。
In other words, the SC-to-PC conversion is a back-out procedure and as such is not specified as mandatory in this document, but it is still a highly desirable function.
换言之，SC到PC的转换是一个退出程序，因此在本文件中没有规定为强制性的，但它仍然是一个非常理想的功能。
Again, it is worth stressing the requirement that such an SPC-to-PC conversion needs to be achieved without any effect on the associated data plane state so that the connection continues to be operational and to carry traffic during the transition.
同样，值得强调的是，需要在不影响相关数据平面状态的情况下实现这种SPC到PC的转换，以便连接继续运行，并在转换期间承载流量。
This section sets out the basic requirements for procedures and processes that are used to perform the functions of this document. Notation from [RFC2119] is used to clarify the level of each requirement.
本节规定了用于执行本文件功能的程序和流程的基本要求。[RFC2119]中的符号用于阐明每个需求的级别。
The data plane LSP MUST stay in place throughout the whole control transfer process. It MUST follow the same path through the network and MUST use the same network resources.
在整个控制传输过程中，数据平面LSP必须保持在原位。它必须在网络中遵循相同的路径，并且必须使用相同的网络资源。
The transfer process MUST NOT cause any disruption of user traffic flowing over the LSP whose control is being transferred or over any other LSP in the network.
传输过程不得导致通过其控制权正在传输的LSP或网络中的任何其他LSP的用户流量中断。
SC-to-PC conversion and vice-versa SHALL occur without generating alarms towards the end users or the NMS.
SC到PC转换，反之亦然，应在不向最终用户或NMS发出警报的情况下进行。
It MUST be possible to transfer the ownership of an LSP from the management plane to the control plane.
必须能够将LSP的所有权从管理平面转移到控制平面。
It SHOULD be possible to transfer the ownership of an LSP from the control plane to the management plane.
应该可以将LSP的所有权从控制平面转移到管理平面。
It MUST be assured that the state of the LSP is synchronized among all nodes traversed by it before the conversion is considered complete.
在转换完成之前，必须确保LSP的状态在其遍历的所有节点之间是同步的。
It MUST be possible to segment an LSP such that it can be converted to or from an SPC.
必须能够对LSP进行分段，以便可以将其转换为SPC或从SPC转换为LSP。
It MUST be possible for a transfer from one plane to the other to fail in a non-destructive way, leaving the ownership unchanged and without impacting traffic.
从一架飞机到另一架飞机的转移必须能够以非破坏性的方式失败，保持所有权不变，并且不影响交通。
If during the transfer procedure issues arise causing an unsuccessful or unexpected result, it MUST be assured that:
如果在传输过程中出现问题，导致不成功或意外结果，则必须确保：
1. Traffic over the data plane is not affected.
1. 数据平面上的流量不受影响。
2. The LSP status is consistent in all the network nodes involved in the procedure.
2. LSP状态在过程中涉及的所有网络节点中都是一致的。
Point 2, above, assures that even in case of some failure during the transfer, the state of the affected LSP is brought back to the initial one and is fully under the control of the owning entity.
上文第2点确保，即使在传输过程中出现某些故障，受影响LSP的状态也会恢复到初始状态，并完全处于拥有实体的控制之下。
Allowing control of an LSP to be taken away from a plane introduces a possible way in which services may be disrupted by malicious intervention.
允许LSP的控制权从飞机上移开引入了一种可能的方式，通过这种方式，恶意干预可能会中断服务。
A solution to the requirements in this document will utilize the security mechanisms supported by the management plane and GMPLS control plane protocols, and no new security requirements over the general requirements described in [RFC3945] are introduced. It is expected that solution documents will include an analysis of the security issues introduced by any new protocol extensions.
本文件中要求的解决方案将利用管理平面和GMPLS控制平面协议支持的安全机制，并且在[RFC3945]中所述的一般要求之上没有引入新的安全要求。预计解决方案文档将包括对任何新协议扩展引入的安全问题的分析。
The management plane interactions MUST be supported through protocols that can offer adequate security mechanisms to secure the configuration and protect the operation of the devices that are managed. These mechanisms MUST include at least cryptographic security and the ability to ensure that the entity giving access to configuration parameters is properly configured to give access only to those principals (users) that have legitimate rights to read/create/change/delete the parameters. IETF standard management protocols (Netconf [RFC4741] and SNMPv3 [RFC3410]) offer these mechanisms.
必须通过协议支持管理平面交互，这些协议可以提供足够的安全机制，以确保配置的安全并保护所管理设备的操作。这些机制必须至少包括加密安全性和确保授予配置参数访问权限的实体正确配置为仅授予具有读取/创建/更改/删除参数合法权限的主体（用户）访问权限的能力。IETF标准管理协议（Netconf[RFC4741]和SNMPv3[RFC3410]）提供了这些机制。
Note also that implementations may support policy components to determine whether individual LSPs may be transferred between planes.
还请注意，实现可能支持策略组件，以确定单个LSP是否可以在平面之间传输。
Nicola Ciulli NextWorks Corso Italia 116 56125 Pisa, Italy EMail: n.ciulli@nextworks.it
Nicola Ciulli NextWorks Corso Italia 116 56125意大利比萨电子邮件：n。ciulli@nextworks.it
Han Li China Mobile Communications Co. 53 A Xibianmennei Ave. Xuanwu District Deijing 100053 P.R. China Phone: 10-66006688 ext.3092 EMail: lihan@chinamobile.com
汉力中国移动通信有限公司，地址：中华人民共和国宣武区西边门内大街53号A，邮编：100053电话：10-66006688分机3092电子邮件：lihan@chinamobile.com
Daniele Ceccarelli Ericsson Via A. Negrone 1/A Genova-Sestri Ponente, Italy Phone: +390106002515 EMail: daniele.ceccarelli@ericsson.com
Daniele Ceccarelli Ericsson通过A.Negrone 1/A Genova Sestri Ponente，意大利电话：+390106002515电子邮件：Daniele。ceccarelli@ericsson.com
We wish to thank the following people (listed randomly): Adrian Farrel for his editorial assistance to prepare this document for publication; Dean Cheng, Julien Meuric, Dimitri Papadimitriou, Deborah Brungard, Igor Bryskin, Lou Berger, Don Fedyk, John Drake, and Vijay Pandian for their suggestions and comments on the CCAMP list.
我们要感谢以下人员（随机列出）：阿德里安·法雷尔，感谢他为本文件的出版提供编辑协助；Cheng院长、Julien Meuria、Dimitri Papadimitriou、Deborah Brungard、Igor Bryskin、Lou Berger、Don Fedyk、John Drake和Vijay Pandian感谢他们对CCAMP名单的建议和评论。
[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月。
[RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart,"Introduction and Applicability Statements for Internet-Standard Management Framework", RFC 3410, December 2002.
[RFC3410]Case，J.，Mundy，R.，Partain，D.，和B.Stewart，“互联网标准管理框架的介绍和适用性声明”，RFC 34102002年12月。
[RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003.
[RFC3471]Berger，L.，Ed.“通用多协议标签交换（GMPLS）信令功能描述”，RFC 3471，2003年1月。
[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月。
[RFC3945] Mannie, E., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", RFC 3945, October 2004.
[RFC3945]Mannie，E.，Ed.“通用多协议标签交换（GMPLS）体系结构”，RFC 39452004年10月。
[RFC4741] Enns, R., Ed., "NETCONF Configuration Protocol", RFC 4741, December 2006.
[RFC4741]恩斯，R.，编辑，“网络配置协议”，RFC 47412006年12月。
[G.8081] International Telecommunications Union, "Terms and definitions for Automatically Switched Optical Networks (ASON)", Recommendation G.8081/Y.1353, June 2004.
[G.8081]国际电信联盟，“自动交换光网络（ASON）的术语和定义”，建议G.8081/Y.1353，2004年6月。
Authors' Addresses
作者地址
Diego Caviglia Ericsson Via A. Negrone 1/A Genova - Sestri Ponente Italy
Diego Caviglia Ericsson途经A.Negrone 1/A Genova-意大利塞斯特里·波南特
EMail: diego.caviglia@ericsson.com
EMail: diego.caviglia@ericsson.com
Dino Bramanti Ericsson Via Moruzzi 1 C/O Area Ricerca CNR Pisa Italy
Dino Bramanti Ericsson Via Moruzzi 1 C/O区Ricerca CNR意大利比萨酒店
EMail: dino.bramanti@ericsson.com
EMail: dino.bramanti@ericsson.com
Dan Li Huawei Technologies Co., Ltd. Shenzhen 518129 Huawei Base, Bantian, Longgang China
丹丽华为技术有限公司深圳518129中国龙岗半天华为基地
EMail: danli@huawei.com
EMail: danli@huawei.com
Dave McDysan Verizon Ashburn, VA USA
Dave McDysan Verizon Ashburn，弗吉尼亚州，美国
EMail: dave.mcdysan@verizon.com
EMail: dave.mcdysan@verizon.com