From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc5493.txt | 619 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 619 insertions(+) create mode 100644 doc/rfc/rfc5493.txt (limited to 'doc/rfc/rfc5493.txt') diff --git a/doc/rfc/rfc5493.txt b/doc/rfc/rfc5493.txt new file mode 100644 index 0000000..8e7a1d8 --- /dev/null +++ b/doc/rfc/rfc5493.txt @@ -0,0 +1,619 @@ + + + + + + +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 + +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. + + 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. + + 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. + + + + + + + + + +Caviglia, et al. Informational [Page 1] + +RFC 5493 Conversion between PC and SC in GMPLS April 2009 + + +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. + + This memo sets out the requirements for such procedures within a + Generalized Multiprotocol Label Switching (GMPLS) network. + +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 + + + + + + + + + + + + + +Caviglia, et al. Informational [Page 2] + +RFC 5493 Conversion between PC and SC in GMPLS April 2009 + + +1. Introduction + + 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]. + + 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]. + + 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]. + + 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. + +1.1. Conventions Used in This Document + + 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. + +2. Label Switched Path Terminology + + A Label Switched Path (LSP) has different semantics depending on the + plane in which the term is used. + + 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. + + + + + + + +Caviglia, et al. Informational [Page 3] + +RFC 5493 Conversion between PC and SC in GMPLS April 2009 + + + 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. + + 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. + + 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. + + 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. + +3. LSP within GMPLS Control Plane + + 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). + +3.1. Resource Ownership + + 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). + + 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 + + + + +Caviglia, et al. Informational [Page 4] + +RFC 5493 Conversion between PC and SC in GMPLS April 2009 + + + control plane control use another set of resources. Other carriers + may choose to make this distinction resource-by-resource as LSPs are + established. + + 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. + +3.2. Setting Up a GMPLS-Controlled Network + + 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. + + 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. + + 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. + + 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). + + 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, + + + + +Caviglia, et al. Informational [Page 5] + +RFC 5493 Conversion between PC and SC in GMPLS April 2009 + + + 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. + + 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. + +4. Typical Use Cases + +4.1. PC-to-SC/SPC Conversion + + 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. + + 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. + + 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. + +4.2. SC-to-PC Conversion + + 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. + + + + +Caviglia, et al. Informational [Page 6] + +RFC 5493 Conversion between PC and SC in GMPLS April 2009 + + + 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. + + 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. + +5. Requirements + + 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. + +5.1. Data Plane LSP Consistency + + 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. + +5.2. No Disruption of User Traffic + + 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. + + SC-to-PC conversion and vice-versa SHALL occur without generating + alarms towards the end users or the NMS. + +5.3. Transfer from Management Plane to Control Plane + + It MUST be possible to transfer the ownership of an LSP from the + management plane to the control plane. + +5.4. Transfer from Control Plane to Management Plane + + It SHOULD be possible to transfer the ownership of an LSP from the + control plane to the management plane. + +5.5. Synchronization of State among Nodes during Conversion + + It MUST be assured that the state of the LSP is synchronized among + all nodes traversed by it before the conversion is considered + complete. + + + + + +Caviglia, et al. Informational [Page 7] + +RFC 5493 Conversion between PC and SC in GMPLS April 2009 + + +5.6. Support of Soft Permanent Connections + + It MUST be possible to segment an LSP such that it can be converted + to or from an SPC. + +5.7. Failure of Transfer + + 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. + + 2. The LSP status is consistent in all the network nodes involved in + the procedure. + + 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. + +6. Security Considerations + + 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. + + 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. + + 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. + + + + + +Caviglia, et al. Informational [Page 8] + +RFC 5493 Conversion between PC and SC in GMPLS April 2009 + + + Note also that implementations may support policy components to + determine whether individual LSPs may be transferred between planes. + +7. Contributors + + Nicola Ciulli + NextWorks + Corso Italia 116 + 56125 Pisa, Italy + EMail: 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 + + + Daniele Ceccarelli + Ericsson + Via A. Negrone 1/A + Genova-Sestri Ponente, Italy + Phone: +390106002515 + EMail: daniele.ceccarelli@ericsson.com + +8. Acknowledgments + + 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. + +9. References + +9.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC3410] Case, J., Mundy, R., Partain, D., and B. + Stewart,"Introduction and Applicability Statements for + Internet-Standard Management Framework", RFC 3410, + December 2002. + + + + +Caviglia, et al. Informational [Page 9] + +RFC 5493 Conversion between PC and SC in GMPLS April 2009 + + +9.2. Informative References + + [RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label + Switching (GMPLS) Signaling Functional Description", RFC + 3471, January 2003. + + [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label + Switching (GMPLS) Signaling Resource ReserVation + Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC + 3473, January 2003. + + [RFC3945] Mannie, E., Ed., "Generalized Multi-Protocol Label + Switching (GMPLS) Architecture", RFC 3945, October 2004. + + [RFC4741] Enns, R., Ed., "NETCONF Configuration Protocol", RFC 4741, + December 2006. + + [G.8081] International Telecommunications Union, "Terms and + definitions for Automatically Switched Optical Networks + (ASON)", Recommendation G.8081/Y.1353, June 2004. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Caviglia, et al. Informational [Page 10] + +RFC 5493 Conversion between PC and SC in GMPLS April 2009 + + +Authors' Addresses + + Diego Caviglia + Ericsson + Via A. Negrone 1/A + Genova - Sestri Ponente + Italy + + EMail: diego.caviglia@ericsson.com + + + Dino Bramanti + Ericsson + Via Moruzzi 1 C/O Area Ricerca CNR + Pisa + Italy + + EMail: dino.bramanti@ericsson.com + + + Dan Li + Huawei Technologies Co., Ltd. + Shenzhen 518129 + Huawei Base, Bantian, Longgang + China + + EMail: danli@huawei.com + + + Dave McDysan + Verizon + Ashburn, VA + USA + + EMail: dave.mcdysan@verizon.com + + + + + + + + + + + + + + + + +Caviglia, et al. Informational [Page 11] + -- cgit v1.2.3