RFC 5493

RFC 5493: Requirements for the Conversion between Permanent Connections and Switched Connections in a Generalized Multiprotocol Label Switching (GMPLS) Network 🦋

Okay bestie, this one's from April 2009 and it's an Informational doc 📚. It's written by D. Caviglia and D. Bramanti (both from Ericsson), D. Li (Huawei Technologies Co., Ltd.), and D. McDysan (Verizon). The title block doesn't list anything it obsoletes or updates, so it stands on its own ✨.

Status of This Memo 🎀

This memo gives information to the Internet community. It is not an Internet standard of any kind, and distribution of it is unlimited 💖.

Copyright Notice 💅

Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.

Heads up 🫶: this document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents, as they stood on the publication date (http://trustee.ietf.org/license-info). Read those carefully, because they spell out your rights and restrictions for this doc.

This document might include material from IETF Documents or IETF Contributions that were published or made publicly available before November 10, 2008. The people who control the copyright in some of that material might not have given the IETF Trust permission to allow modifications outside the IETF Standards Process 🙈. So unless you get a proper license from those copyright holders, this document can't be modified outside the IETF Standards Process, and derivative works of it can't be created outside it either. The exceptions are formatting it for publication as an RFC or translating it into languages other than English.

Abstract 🌸

Carrier-side, there's a really useful trick: turning a permanent connection (PC) into a soft permanent connection (SPC), and back again, without touching the data traffic flowing over it 🧚. Think of it as handing over ownership and control of a connection that's already live, moving it between the management plane and the control plane, while its data plane state stays exactly as it was.

This memo lays out the requirements for doing that inside 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

---

1. Introduction ✨

Picture a classic, traditional transport network 🌸. Data plane connections between two endpoints are run by a Network Management System (NMS) sitting in the management plane (MP). The NMS/MP owns those transport connections, which means it's responsible for their setup, teardown, and maintenance 💅. Provisioned connections like this, which are initiated and managed by the management plane, are called permanent connections (PCs) [G.8081].

When setup, teardown, and maintenance are handled by a signaling protocol owned by the control plane (CP), those connections are called switched connections (SCs) [G.8081] ⭐.

In lots of deployments you'll see a hybrid type 🌈. A soft permanent connection (SPC) is a combo of a permanent connection segment on the source-user-to-network side, a permanent connection segment on the destination-user-to-network side, and a switched connection segment in the core network. The permanent parts 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 and controlled by the management plane. These aspects should be independent of how the connection was set up 🫶.

1.1. Conventions Used in This Document 🎀

Even though this is a requirements doc (informational, not a protocol spec), the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are read as described in RFC 2119 [RFC2119], so the requirements stay crystal clear 💖.

---

2. Label Switched Path Terminology 🧚

A Label Switched Path (LSP) means something different depending on which plane you're talking about 💜.

In the data plane, an LSP is the data plane forwarding path. It defines the forwarding or switching operations at each network entity. It's the sequence of data plane resources (links, labels, cross-connects) that gets data transported end-to-end 🚀.

In the management plane, an LSP is the management plane state information (like the connection attributes and path information) that's associated with, and needed for, creating and maintaining a data plane connection 📋.

In the control plane, an LSP is the control plane state information (like the RSVP-TE [RFC3473] Path and Resv state) that's associated with, and needed for, creating and maintaining 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 it 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 talk about LSP conversion between the management plane and the control plane, we mainly focus on converting the control plane state information and the management plane state information 💅.

---

3. LSP within GMPLS Control Plane 🌈

GMPLS ([RFC3471], [RFC3473], and [RFC3945]) defines a control plane architecture for transport networks. It covers both routing and signaling protocols for creating and maintaining LSPs, in networks whose data plane is built on different technologies. Those include 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 whichever plane was used to set up the LSP through that part of the network. So 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 split: the management plane owns the resources used by the permanent connection segments at the edge of the network, and the control plane owns the resources used by the switched connection segments in the middle of the network 🎀.

How resources get divided up between management and control plane ownership is an architectural issue 🧠. A carrier might decide to pre-partition the resources at a network entity, so LSPs under management plane control use one set of resources and LSPs under control plane control use another. Other carriers might make that distinction resource by resource as LSPs get established 🦋.

It should be noted, though, that even when a resource is owned by the control plane, the management plane usually still has a controlling interest in it 🙈. For example, think about the basic safety requirement that management commands must be able to put a laser out of service 🔥.

3.2. Setting Up a GMPLS-Controlled Network ✨

Okay so setting up a GMPLS control plane is kind of a fresh-start situation IF you're building a brand new network 🌱. But bestie, lowkey most of the time people want to drop a GMPLS control plane into a transport network that's ALREADY full of permanent connections being managed by the management plane 📋. Main character energy of "how do we add this without breaking everything" 💅.

So in a mixed setup, permanent connections owned by the management plane and switched connections owned by the control plane have to live together in the same network 🫶.

It's also super desirable to hand control of connections over from the management plane to the control plane. So stuff that an NMS used to control is now controlled by the GMPLS protocols 🦋. And if those connections are in service, the handover has to happen WITHOUT touching the traffic. No cap, that's the whole vibe 😭.

Here's the thing though: attempts to move an LSP under GMPLS control can fail for a bunch of reasons that are outside the scope of this document 💀. So it's also highly desirable to have a way to give control of an LSP back to the management plane 🌸.

Quick note: a permanent connection can become a switched connection or an SPC, and an SPC can become a switched connection too (PC to SC, PC to SPC, and SPC to SC) ✨. That means the reverse mappings might also be needed (SC to PC, SPC to PC, and SC to SPC) 🔁.

Conversion to or from control/management happens in MIBs or in information stored on the device (for example cross-connect, label assignment, label stacking, etc.) 🧚. It's identified as either initiated by a specific control protocol or by manual operation, meaning via an NMS 🎀. When converting, this hop-level owner information has to be completed for ALL hops 💖. If conversion can't be done for all hops, then it has to be done for NO hops, the hop-level information has to be restored to what it was before the conversion was attempted, and an error condition has to be reported to the management system 🚨.

Either way, the management plane is the one that starts the change 👑. When going from a PC to an SC, the management system has to tell each hop that a control protocol is now in charge, and then configure the data the control protocol needs at the connection endpoints 🌈. When going from an SC to a PC, the management plane has to change the owner of each hop first 🔄. Then the instance in the control plane gets removed WITHOUT affecting the data plane 🦋.

The case where the CP and/or MP fail at one or more nodes during the conversion procedure has to 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 with procedures similar to a two-phase database commit process might be needed 💜. That's how you keep integrity and make sure you can revert to the state from before the conversion attempt if the CP and/or MP fails during it 🫧.

---

4. Typical Use Cases 🎀

4.1. PC-to-SC/SPC Conversion 🌷

A typical scenario where a PC-to-SC (or SPC) procedure is a useful option is at the very beginning of control plane deployment in an existing network 🌱. In that case, all the network connections, possibly carrying traffic, are already set up as PCs and owned by the management plane 📋.

Later on, the network is partially controlled by the management plane and partially by the control plane (PCs and SCs/SPCs living side by side) 🤝. When someone wants to extend the control plane, a PC-to-SC procedure can transfer a PC or SPC to an 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, that control transfer has to happen WITHOUT any disruption to the data plane traffic 😭.

4.2. SC-to-PC Conversion 🔙

The main reason for an SC-to-PC conversion is to give an operator the ability to undo the PC-to-SC conversion we just talked about 💅.

Basically, SC-to-PC is a back-out procedure, so it's NOT specified as mandatory in this document 🙅‍♀️. It's still a highly desirable function though 🌟.

Again, it's worth stressing that this SPC-to-PC conversion needs to be done without any effect on the associated data plane state, so the connection keeps working and carrying traffic during the transition 🫶.

5. Requirements 📝

This section lays out the basic requirements for the procedures and processes used to perform the functions of this document ✨. The notation from [RFC2119] is used to clarify how strict each requirement is 🔍.

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 💯.

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 if something fails during the transfer, the state of the affected LSP is brought back to the initial one and stays fully under the control of the owning entity 👑.

6. Security Considerations 🔐

😱 Okay this section is SERIOUS, bestie, so read it carefully!

Letting control of an LSP get taken away from a plane opens up a possible way for services to be disrupted by malicious intervention 💀.

A solution to the requirements in this document will use the security mechanisms supported by the management plane and GMPLS control plane protocols. No new security requirements over the general requirements described in [RFC3945] are introduced 🔒. It's 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 being managed 🛡️. These mechanisms MUST include at least cryptographic security, and the ability to make sure the entity giving access to configuration parameters is properly configured to give access only to those principals (users) who have legitimate rights to read, create, change, or delete the parameters 🗝️. IETF standard management protocols (Netconf [RFC4741] and SNMPv3 [RFC3410]) offer these mechanisms 🎀.

Also, implementations may support policy components to decide 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 💜. Iconic cast, honestly 👑.

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.

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.

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