RFC 3604

Requirements for Adding Optical Support to the General Switch Management Protocol version 3 (GSMPv3)

📅 published October 2003, from ietf

Status of this Memo 📜

okay so this memo is just here to give the Internet community some info 🌸 It is not a standard of any kind, and it's totally free to share 🦋

The Internet Society owns the copyright here (2003), and all rights are reserved 💅

Abstract ✨

bestie, this memo lays out what GSMP needs in order to handle optical switching 🔥 It also has some clarifications and suggested tweaks for the GSMPv3 spec, so it's a whole glow-up 🌈

Conventions used in this document 💜

These key words are interpreted the way BCP 14 and RFC 2119 [1] describe them:

"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"

1. Overview 🦋

okay this is the main event ✨ The doc goes through the GSMP changes needed to switch optical (non-transparent and all optical), SONET/SDH, and spatial traffic, including IP packets, Layer 2 (L2) frames, and TDM data 🧚 Once it's done, GSMP controllers can run photonic cross-connects (optical-optical), transparent optical cross connects (optical-electrical-optical, frame independent), opaque cross connects (optical-electrical-optical, SONET/SDH frames), and classic TDM switches (all electrical) 💖 Put it all together and you get IP based optical routers, optical label switches, wavelength routers, and dynamic optical cross connects. Iconic 👑

There are a bunch of generic models for control plane functionality in an optical network [2], [3], [4] 🫶 This doc doesn't pick a favourite (for example, single or multiple routing plane instances). The one thing it assumes is that splitting control mechanisms away from data switching is just as useful for signaling optical paths (like GMPLS) as it is for L2 paths (like MPLS) 💅 So the requirements here only focus on separating control functions from data functions, so the network architecture ends up more flexible 🌸

GSMPv3 [5] is a great fit for the control interface that lets an IP based controller direct an optical switch 🔥 To make GSMP work between controllers and optical switches and cross connects, it needs optical labels and service and resource abstractions added 🎀

The doc also has changes that implementers recommended to make GSMP easier to build 🍓 These are about rearranging PDU formats, clarifying flags, transaction identifiers, and response codes 💜

2. Requirements for Optical Support ✨

2.1. Label 🧚

2.1.1. Label Types 💖

new labels are needed to identify the things that get switched in the optical fabric 💅 They're longer than GSMPv3 labels because they carry physical and structural context. GMPLS [2], [3] already had very similar label format needs, so lining up with GMPLS is the plan 🦋 That covers:

  • Digital Carrier Hierarchy (e.g., DS-1, E1)
  • SONET and SDH Hierarchy (e.g., OC-3, STM-1, VT1.5, VC-12)
  • Plesiochronous Data Hierarchy (PDH) labels [6]
  • OTN G.709 labels
  • Lambdas
  • Fibers

GSMP MUST include support for all of the label types listed above, plus label hierarchies and label lists as GMPLS defines them 🔥 That means operations on groups of those labels MUST also be supported too (for example, 5 OC-3s or contiguous wavebands) 👑

2.1.2. Label Management Issues 🌈

An updated label range message MUST be provided. There MUST also be support for multiplexing (for example, no multiplexing, SONET, or Gigabit Ethernet multiplexing) ✨

2.2. Statistics messages 📊

Optical switches track statistics that ATM or Frame Relay switches don't, so it's a whole different vibe 🙈 That's why the statistics messages SHOULD be updated to report the Performance Monitoring statistics defined for every new optical transport technology added to GSMP 💜

2.3. Configuration Issues 🎀

2.3.1. Switch Configuration 💅

An optical switch can provide connection services at several transport layers (for example, STS-3c, STS-1, VT-1.5, DS3, DS1) 🦋 Not every switch supports the same layers, so the switch needs to tell the controller exactly which layers it can handle 🫶

So the Switch Configuration message MUST be extended to list the transport layers an optical switch can switch 🔥

2.3.1.1. Layer Switching Identification 🧚

The port configuration message gives the controller the config info for a single port 🌸 Since that's the case, a lot of new stuff has to be added to this command 💖

2.3.2. Port Configuration 🍓

The port configuration message gives the controller the config info for a single port 🌸 That means a lot of new stuff has to be added to this command 💖

2.3.2.1. Port Type extensions ✨

Port types MUST be added to support the mix of optical signals that can run over a single fiber 🌈

The port info that MAY need to be conveyed includes [7]:

  • wavelengths available per interface
  • bit rate per wavelength
  • type of fiber

2.3.2.2. Supported Signal Type extensions 💅

A port on an optical switch can support signals at multiple transport layers, so it's important to know which signals it supports and how one signal can be carried inside another 🔥

For OTN, SONET/SDH, and PDH optical switches, the Port configuration message MUST be extended to detail the different transport layer signals a port supports 💜 That extension MUST also detail which signals can be transported by another signal 🎀

This mechanism MUST also provide info about optional capabilities on a port (such as virtual concatenation and arbitrary concatenation for SONET/SDH) 👑

2.3.2.3. Trace Mechanism support Identification 🦋

Lots of transport layer signals include overhead channels that can identify where a signal came from 🧚 Those channels are embedded in the signal, so only the network element can see them 🫶 Not every network element can set or read those channels on every port, though, so the controller needs to know this port attribute 💖

The Port Configuration message MUST be extended to report which trace mechanisms a port supports 🌸

2.3.2.4. Port Location Identification 🌈

Modern optical switches can have tens of thousands of ports spread over hundreds of shelves, and those shelves can be in potentially just as many bays 😭 So the current "Slot/Port" location identifier just isn't enough 💀

The Slot/Port Location Identifier MUST be extended to encode Bay/Shelf/Slot/Port ✨

Partitioning can apply to any resource in the network element 💅 GSMP's partitioning draft already defines ports and switching resources as partitionable 🦋 Optical switches can run several transport network layers, so there's a new resource type: the transport layer signal 👑

The spot where a transport layer signal gets inserted into a lower layer signal (the ITU calls it an "access point" [8]) is very similar to a port 🎀 So when partitioning happens on a transport layer signal basis, the partition that uses the access point MUST have a port associated with that access point 🫶 Labels are then used to describe the subordinate signals 🧚

2.3.3. Service Configuration 💜

new capability sets MUST be added to support quality parameters in optical switches 🔥 But the service configuration message doesn't need changes, since its job is still to carry the service info defined in the applicable service model 🌸

2.4. Service Model Issues 🌈

Sure, one assumption about optical media is that bandwidth is plentiful, but traffic engineering will still be needed [5] 💅 GSMP lets each connection be created with specific attributes 💖 So service parameters need to be defined for each of the different optical technologies 🦋

2.4.1. Transparent Optical 🍓

The ability to control re-timing and re-shaping on a per port level MUST be added 🎀

2.4.2. SONET/SDH and OTN 👑

The ability to control the adaptation parameters used when one transport signal is inserted into another MUST be added 🔥 These parameters SHOULD be changeable at times other than when a branch is added, so things like Tandem Connection Monitoring can be configured 🧚 Right now GSMP's default service models are based on models defined elsewhere, like the Intserv model [9], [10], the Diffserv model [11], the ATM QoS models, and the Frame Relay Forum QoS models 🫶 Someone still needs to figure out which service models apply to optical channel trails 💀 Those models MUST then be mapped to the GSMP capability set mechanism 💖

2.5. Encapsulation issues 🫶

The working group still needs to decide whether a new encapsulation is required 🙈 In other words, will every optical switch used in MPLS over Optics or IP over Optics applications need IP on the control channel between the GSMP controller and the optical switch (the GSMP target) 🔥

A new encapsulation SHOULD be defined that allows a non-IP raw wavelength control connection 🌸

Likewise, a new encapsulation SHOULD be defined that lets GSMP run in legacy Data Communication Network (DCN) environments that use OSI CLNP 🦋

The security risks of extra non-IP encapsulations MUST be described 🚨 That's a big deal, because IPsec, the mandatory to implement mechanism, isn't available for these control channels, just like in the RFC 3293 Ethernet and ATM cases 😭 It's in scope to do a risk analysis and describe whether link-level security mechanisms reduce the risk 💅

2.6. MIB Issues 🎀

If a new encapsulation is defined, the encapsulation group SHOULD be updated 💜 No other changes should be needed 🌈

2.7. OXC Transaction Model ✨

2.7.1. Serial Transactions

okay so a lot of existing OXCs run a command interface that assumes a serial transaction model 🧚. That means a new command can't be issued or processed until the one before it is totally done. ngl that was fine when provisioning went through a network management app and paths were set up non-dynamically 💅

Once we move to dynamic path setup with a distributed control plane, a parallel transaction model is probably needed for performance 🚀. This matters most when setting up a TDM style connection is way slower than setting up an L2 connection table 😭. If the OXC can't support parallel transactions, a GSMP controller MUST be informed of this and adopt serial transaction behavior 🫶.

2.7.2. Bulk Transactions

Same energy here 💖. Setting up TDM connections can take OXCs way longer than L2 fabrics (like a VC-4/STS-1 SPE fabric in an HOVC/STS switch), so sending multiple transactions in one message is a super useful optimization 🍓. When an OXC gets a bulk message, it acts on each individual transaction and then sends back a single reply ✨. Even if parallel transactions aren't supported, bulk messages can still help performance by cutting down on transaction overhead 🌸. Bulk transactions SHOULD be supported.

2.8. OXC Protection Capabilities

To get good link protection performance (think 50 ms after failure detection) 😤, SONET/SDH and some OXC systems use hardware based protection schemes, like ring protection. Getting that kind of performance from only a data control plane like GMPLS is a seriously hard challenge 💀. The alternate move is to use the protection capabilities of an OXC along with a dynamic control plane. The catch with this hybrid approach is that GSMP needs extensions to provision how an OXC should behave in anticipation of a link failure 🎀.

This is different from the strict master-slave relationship GSMP has for Layer 2 switches, because here the OXC can take an action on its own without the GSMP controller and then tell the controller about it afterwards 🦋. So the GSMP port configuration command MUST be extended to allow autonomous protection behaviors to be provisioned into the Network Element. The controller MUST also be able to provide the parameters that decide when reversion from a backup link to the original link is allowed. This may look like hold-off timers, BER parameters, or a requirement for controller directed reversion 👑.

Example time 🧚. When a link fails, a backup link may be used to protect traffic. That backup link could be picked from a set of links, none of which are pre-reserved. One backup link could even be shared with one or more "working" links, which is a form of 1:n shared protection 🔥. Specifying the set of possible backup links SHOULD be done as an option to the Add-Branch message.

When a backup link gets used, or the OXC reverts back to the original link, the control plane (aka signaling) might need to know about the new path state so it can notify the operator or take some other OAM action, like billing or SLA monitoring 💅. An additional GSMP message to inform the controller SHOULD be added to do this.

This one is giving "1+1" vibes 🌈. It's a more specialized form of restoration where a (usually node disjoint) protection path in a transport/optical network is defined for a given working path. At the ingress node, the traffic signal gets sent along both the working and protection paths at the same time 🪞. Under non-failure conditions at the egress node, only the last link of the working path is connected to the client. If any link in the working path fails, traffic stops arriving at the end of the working path 😭. The egress OXC notices this and switches over to the last link of the protection path, all without the controller having to issue a Move-Input-Branch message 🙈. The ingress node never finds out which link the egress node is using, and picking the protection path and all of its links is outside the scope of GSMP 🫶.

The two output branches at the ingress node can be set up with the usual Add-Branch semantics. The ingress node's protection link isn't shared with any other working link 💜.

The two input branches at the egress node should be specified when the Add-Branch message is sent. This SHOULD be an option to that message. The egress node's protection link also isn't shared with any other working link 🌸.

When a protection link gets used, or the OXC reverts back to the working link, the control plane (aka signaling) might need to know about the new path state so it can notify the operator or take some other OAM action, like billing or SLA monitoring ✨. An additional GSMP message to inform the controller SHOULD be added to do this.

If an alternate input port isn't specified with the original Add-Branch message, it MAY be specified in a later Add-Branch message. In that case, it helps to include info about the existing users of the output port in that Add-Branch message 🧚. That way the OXC can immediately learn the link between the new input port and an existing one, and that association is what lets it run its protection procedures. This capability MUST be added to the add-branch message 💖.

The same kind of context is needed for a Delete-Branch message, so the OXC can figure out whether a path has become unprotected 🥺. This capability MUST be added to the Delete-branch message.

2.8.3. Protection Triggers

Okay so it's not just link or equipment failures that can make the backup or protection links kick in. There's a whole bunch of maintenance conditions too 🛠️. These may include:

  • Scheduled maintenance of the working link. The network operator deliberately takes a link out of service to do maintenance 🍓.
  • Reconfiguration of fiber/node/network that temporarily needs backup links 🌊.

It might be useful to specify these triggers when the backup or protection links are defined with the Add-Branch message 🎀. Whether that works depends on how the OXC is implemented to be aware of such triggers. This is for further study 👀.

If an OXC can do protection switching without the Optical Call Controller (OCC), it may help for the OCC to know about those capabilities when switch and/or port configuration happens 💅. Applications in the GSMP controller could use that info. For example, signaling clients could set up a path protection scheme across multiple GSMP enabled OXCs 🦋. This is for further study.

2.9. Controller directed restoration

Bi-directional Connection Replacement

Connections in the transport network are inherently point-to-point bi-directional 🌈. Unfortunately, GSMPv3 currently doesn't let the B and R flags be set on an add branch message 😭. So it isn't possible to do an atomic replacement of a bi-directional connection, which is exactly the kind of move that's desirable for controller directed restoration 💀. Consequently, the protocol MUST be changed to allow these flags to be used at the same time 👑.

2.10. Support for optical burst switching

GSMP for Optical Switching should also support optical burst switching 🌟. As described in [12], [13], and [14], part of burst switching connection setup includes reserving time on the transport medium for the client 🧚.

That time is described by two parameters: a start time and a duration. These values MAY define a one-time reservation or a repeating reservation 🔁. When a burst connection setup request comes in, the GSMP controller MUST perform appropriate Connection Admission Control for the time and duration specified. If the connection is allowed, the controller MUST signal these parameters to the burst switching device so it reserves the exact bandwidth required [12], [14] 💅. The burst switch MUST perform the switching operation autonomously, using the synchronization methods prescribed for the burst network it's operating in 🫶.

3. Requirements from Implementers ✨

This section lists requirements for GSMP v3 based on some real implementation experience 🛠️. They cover areas of ambiguity, missing semantics, and configuration recommendations 🎀.

3.1. GSMP Packet Format

The Basic GSMP Message Format in chapter 3.1.1 in [5] describes the common fields present in all GSMP messages except for the Adjacency protocol 📦.

3.1.1. Message segmentation

If a message is bigger than the MTU of the link layer, it has to be segmented 🧩. This used to be done with the "More" value in the Result field. Adding the I flag and the SubMessage Number to the header made the "More" value obsolete 💀. The I flag and SubMessage numbers should be used in all messages that can be segmented 🌸.

3.1.1.1. SubMessage Number and I flag

It should be specified whether the SubMessage Number starts at 0 or 1 in a segmented message, and what value the I flag should have in a message that isn't segmented 🙈.

3.1.1.2. Message Length

This needs clarifying: what should go in the Length field for segmented messages? Specifically, does the Length field hold the total length of the message, or just the length of the current segment? 🤔

3.1.1.3. Message Segmentation example

To avoid all ambiguity, an example of message segmentation should be provided 🦋.

3.1.2. Transaction Identifier

The Transaction Identifier in [5] doesn't tell apart replies to a request with "AckAll" and replies to one with "NoSuccessAck" 😤. It also doesn't say anything about how to handle replies where the Transaction ID doesn't match a Transaction ID from a request sent earlier 🫠.

If multiple controllers are connected to a single switch, and the switch sends an event message with "ReturnReceipt" set to all of them, the switch has no way to tell which controller a receipt is coming from 💀.

The "ReturnReceipt" value should not be permitted for Events 🚫.

3.2. Window Size

The Switch Configuration Message defined in chapter 8.1 in [5] sets a Window size for the controller to use when sending messages to the switch 🪟. It doesn't say whether this window should apply to all messages, or only to messages that will always generate a reply 🤷‍♀️.

If messages that might not generate a reply should count against the window, a time-out period should be defined for when they get removed from the window ⏳.

It also isn't defined whether the window should be cleared when the adjacency is lost and later recovered 🌊.

3.3. Retransmission

A retransmission policy with a well-designed exponential backoff should be used if no reply is received for a message with "AckAll" set 🔁.

3.4. Delete Branches Message

The "Delete Branch Element" has a 4 bit Error field that should be redefined to match the size of the "Failure Response Codes" 📏.

3.5. Adjacency

The chapter about how to handle a new adjacency, and re-established adjacencies, should be clarified 🫶.

3.5.1. Loss of Synchronization

The switch must not reset the connection states if another adjacency has already been established, since that would destroy an already valid state 🙅‍♀️.

4. Security Considerations 🔐

The security of GSMP's TCP/IP control channel has been addressed in [15] 🛡️. Any potential remaining security considerations are not addressed in this requirements document 😱.

5. Acknowledgements ✨

okay so the author list you see up top is a trimmed-down version of the original one 🥺 the people still listed want to give a shoutout to Avri Doria and Kenneth Sundell, who put in a LOT of work on this too 🫶

the authors also want to thank Dimitri Papadimitriou, Torbjorn Hedqvist, Satoru Okamoto, and Kohei Shiomoto for their careful review and comments 💖 bestie, that's a real review squad 👑

6. References

6.1. Normative References

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

6.2. Informative References

  • [2] Berger, L., Ed., "Generalized MPLS - Signaling Functional Description", RFC 3471, January 2003.
  • [3] Mannie, E., et al., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", Work in Progress, May 2003.
  • [4] ITU-T Recommendation, "Architecture for the Automatically Switched Optical Network (ASON)", G.8080/Y.1304, January 2003
  • [5] Doria, A., Sundell, K., Hellstrand, F. and T. Worster, "General Switch Management Protocol V3", RFC 3292, June 2002.
  • [6] Sadler, J., Mack-Crane, B., "TDM Labels for GSMP", Work in Progress, February 2001.
  • [7] Rajagopalan, B., et al., "IP over Optical Networks: A Framework", Work in Progress, September 2003.
  • [8] ITU-T Recommendation, "Generic functional architecture of transport networks", G.805, March 2000.
  • [9] Braden, R., Clark, D. and S. Shenker, "Integrated Services in the Internet Architecture: An Overview", RFC 1633, June 1994.
  • [10] Wroclawski, J., "Specification of the Controlled-Load Network Element Service", RFC 2211, September 1997.
  • [11] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and W. Weiss, _"An Architecture for Differentiated Services", RFC 2475, December 1998.
  • [12] C. Qiao, M. Yoo, "Choice, and Feature and Issues in Optical Burst Switching", Optical Net. Mag., vol.1, No.2, Apr.2000, pp.36-44.
  • [13] Ilia Baldine, George N. Rouskas, Harry G. Perros, Dan Stevension, "JumpStart: A Just-in-time Signaling Architecture for WDM Burst-Switching Networks", IEEE Comm. Mag., Fab. 2002.
  • [14] Sanjeev Verma, et al. "Optical burst switching: a viable solution for terabit IP backbone", IEEE network, pp. 48-53, Nov/Dec 2000.
  • [15] Worster, T., Doria, A. and J. Buerkle, "GSMP Packet Encapsulations for ATM, Ethernet and TCP", RFC 3293, June 2002.

7. Authors' Addresses 💌

Hormuzd Khosravi
Intel
2111 NE 25th Avenue
Hillsboro, OR 97124 USA

Phone: +1 503 264 0334
EMail: hormuzd.m.khosravi@intel.com


Georg Kullgren
Nortel Networks AB
S:t Eriksgatan 115 A
P.O. Box 6701
SE-113 85 Stockholm Sweden

EMail: geku@nortelnetworks.com


Jonathan Sadler
Tellabs Operations, Inc.
1415 West Diehl Road
Naperville, IL 60563

Phone: +1 630-798-6182
EMail: Jonathan.Sadler@tellabs.com


Stephen Shew
Nortel Networks
PO Box 3511 Station C
Ottawa, ON
K1Y 4H7

EMail: sdshew@nortelnetworks.com


Kohei Shiomoto

EMail: Shiomoto.Kohei@lab.ntt.co.jp
Atsushi Watanabe
Nippon Telegraph and Telephone Corporation
807A 1-1 Hikari-no-oka, Yokosuka-shi
Kanagawa 239-0847, Japan

EMail: atsushi@exa.onlab.ntt.co.jp


Satoru Okamoto
Nippon Telegraph and Telephone Corporation
9-11 Midori-cho 3-chome, Musashino-shi
Tokyo 180-8585, Japan

EMail: okamoto@exa.onlab.ntt.co.jp

Copyright (C) The Internet Society (2003). All Rights Reserved.

okay, legal bit but it's important 💅 anyone can copy this document and share it, and make derivative works that comment on or explain it or help with implementing it, and publish and distribute those in whole or in part with no restriction, as long as the copyright notice and this paragraph are included on every copy and derivative work. the document itself, though, may NOT be modified in any way, like removing the copyright notice or references to the Internet Society or other Internet organizations. the exception is when you're developing Internet standards, in which case the Internet Standards process copyright procedures must be followed, or when you need to translate it into languages other than English.

the limited permissions above are perpetual and the Internet Society or its successors or assignees will not revoke them ✨

this document and the information in it is provided "AS IS", and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.

Acknowledgement 🫶

Funding for the RFC Editor function is currently provided by the Internet Society 💜

📦 where this page comes from