RFC 4257
Framework for Generalized Multi-Protocol Label Switching (GMPLS)-based Control of Synchronous Digital Hierarchy/Synchronous Optical Networking (SDH/SONET) Networks
RFC 4257: Framework for Generalized Multi-Protocol Label Switching (GMPLS)-based Control of Synchronous Digital Hierarchy/Synchronous Optical Networking (SDH/SONET) Networks 🎀
okay bestie, this one is from the Network Working Group and it was published in December 2005 ✨ The authors are G. Bernstein (Grotto Networking), E. Mannie (Perceval), V. Sharma (Metanoia, Inc.), and E. Gray (Marconi Corporation, plc) 💖 It's labelled Informational 🧚 and the header doesn't list anything it obsoletes or updates. The title is a whole mouthful, but it's about using GMPLS to control SDH/SONET networks, which are the optical transport networks underneath so much of the internet 🌈
Status of This Memo 📣
This memo gives information to the Internet community. It doesn't set any kind of Internet standard 🫶 Distribution of this memo is unlimited 🦋
Copyright Notice ©️
Copyright (C) The Internet Society (2005).
Abstract 🌸
Okay so, GMPLS is a bunch of protocol extensions to MPLS that make it useful for way more than packet switching. It can control things like non-packet switching, and especially optical switching 🔥 One big idea is using GMPLS protocols to upgrade the control plane of optical transport networks, and this document shows how that works by describing the GMPLS extensions meant for controlling SDH or SONET networks 💅 SDH/SONET networks are a great example for this for a bunch of reasons. The doc highlights extensions to GMPLS-related routing protocols that spread around the info needed for transport path computation and network operations 👑 It also covers the (G)MPLS protocol extensions needed to set up transport circuits. And it talks about the new stuff a GMPLS control plane would bring to SDH/SONET, like new restoration methods and multi-layer circuit establishment ✨
Table of Contents 🗂️
1. Introduction ....................................................3
1.1. MPLS Overview ..............................................3
1.2. SDH/SONET Overview .........................................5
1.3. The Current State of Circuit Establishment in
SDH/SONET Networks .........................................7
1.3.1. Administrative Tasks ................................8
1.3.2. Manual Operations ...................................8
1.3.3. Planning Tool Operation .............................8
1.3.4. Circuit Provisioning ................................8
1.4. Centralized Approach versus Distributed Approach ...........9
1.4.1. Topology Discovery and Resource Dissemination ......10
1.4.2. Path Computation (Route Determination) .............10
1.4.3. Connection Establishment (Provisioning) ............10
1.5. Why SDH/SONET Will Not Disappear Tomorrow .................12
2. GMPLS Applied to SDH/SONET .....................................13
2.1. Controlling the SDH/SONET Multiplex .......................13
2.2. SDH/SONET LSR and LSP Terminology .........................14
3. Decomposition of the GMPLS Circuit-Switching Problem Space .....14
4. GMPLS Routing for SDH/SONET ....................................15
4.1. Switching Capabilities ....................................16
4.1.1. Switching Granularity ..............................16
4.1.2. Signal Concatenation Capabilities ..................17
4.1.3. SDH/SONET Transparency .............................19
4.2. Protection ................................................20
4.3. Available Capacity Advertisement ..........................23
4.4. Path Computation ..........................................24
5. LSP Provisioning/Signaling for SDH/SONET .......................25
5.1. What Do We Label in SDH/SONET? Frames or Circuits? .......25
5.2. Label Structure in SDH/SONET ..............................26
5.3. Signaling Elements ........................................27
6. Summary and Conclusions ........................................29
7. Security Considerations ........................................29
8. Acknowledgements ...............................................30
9. Informative References .........................................31
10. Acronyms ......................................................331. Introduction 🧚
The CCAMP Working Group of the IETF wants to extend MPLS [1] protocols so they can handle multiple network layers and brand-new services 💜 This extended MPLS was first called Multi-Protocol Lambda Switching, but it's now better known as Generalized MPLS (or GMPLS) 🌸
The GMPLS effort is basically extending IP/MPLS tech so it can control and manage lower layers 🔥 Using the same framework and similar signaling and routing protocols to control multiple layers can cut down the overall complexity of designing, deploying, and maintaining networks. It can also make it possible to run two neighbouring layers using an overlay model, a peer model, or an integrated model ✨ The benefits of a peer or overlay model between the IP layer and the layer(s) underneath it still need to be clarified and evaluated later. In the meantime, GMPLS could be used to control each layer independently 🫶
The goal here is to show how GMPLS could be used to dynamically set up, maintain, and tear down SDH/SONET circuits 🦋 The point of using these extended IP/MPLS protocols is to offer at least the same kinds of SDH/SONET services that exist today, but using signaling instead of provisioning through centralized management. That means operators can propose new services, and clients can create SDH/SONET paths on-demand, in real time, through the provider network 🍓 We'll first go over the essential properties of SDH/SONET networks and their operations, and then show how the GMPLS label concept can be extended to the SDH/SONET case 💅 After that we look at the important info a link state routing protocol should disseminate, and the important signal attributes a label distribution protocol needs to convey. Last, we look at some outstanding issues and future possibilities 👑
1.1. MPLS Overview 🌈
The big win of the MPLS architecture [1] as a general network control plane is its clear separation between the forwarding (or data) plane, the signaling (or connection control) plane, and the routing (or topology discovery/resource status) plane 💖 That lets the work on MPLS extensions focus on the forwarding and signaling planes, while well-known IP routing protocols can be reused in the routing plane 🧚 The same separation also means MPLS can be used to control networks that don't have a packet-based forwarding plane, which is lowkey iconic 🤩
An MPLS network is made up of MPLS nodes called Label Switch Routers (LSRs), connected via Label Switched Paths (LSPs) 🎀 An LSP is uni-directional, and it can be one of several types, like point-to-point, point-to-multipoint, and multipoint-to-point. Border LSRs in an MPLS network act as either ingress or egress LSRs, depending on which direction the traffic is going 🦋
Each LSP is tied to a Forwarding Equivalence Class (FEC), which you can think of as a set of packets that all get identical forwarding treatment at an LSR 🌸 The simplest example of an FEC is the set of destination addresses inside a given address range. Every packet with a destination address in that range gets forwarded the same way at each LSR configured with that FEC 💅
To set up an LSP, you need a signaling protocol (also called a label distribution protocol), such as LDP or RSVP-TE ✨ Between two adjacent LSRs, an LSP is locally identified by a fixed-length identifier called a label, and that label only means something between those two LSRs. A signaling protocol handles the inter-node communication that assigns and maintains these labels 🫶
When a packet enters an MPLS-based packet network, it gets classified according to its FEC and, possibly, some additional rules. Together those decide which LSP the packet has to be sent along 👑 So the ingress LSR attaches an appropriate label to the packet and forwards it to the next hop. The label can be attached in different ways. It might be a header wrapped around the packet (the "shim" header), or it might be written in the VPI/VCI field (or DLCI field) of the layer 2 encapsulation of the packet 🍓 With SDH/SONET networks, a label is simply associated with a segment of a circuit, and it's mainly used in the signaling plane to identify that segment (for example, a time-slot) between two adjacent nodes. We'll see that this works differently there 🧚
When a packet reaches a packet LSR, that LSR uses the label as an index into a forwarding table. From there it finds the next hop, the matching outgoing label (and possibly the QoS treatment for the packet), writes the new label into the packet, and forwards it to the next hop 💖 When the packet reaches the egress LSR, the label gets removed and the packet is forwarded using normal forwarding, such as normal IP forwarding. For an SDH/SONET network, these steps don't happen in quite the same way, and we'll get into that next 🌈✨
1.2. SDH/SONET Overview ✨
okay so optical networks are using two multiplexing techniques right now: wavelength-division multiplexing (WDM) and time division multiplexing (TDM). this doc is only about TDM 🫶
SDH and SONET are the two TDM standards operators use the most to carry and multiplex different tributary signals over optical links. Put together, that makes a multiplexing structure we call the SDH/SONET multiplex 🦋
ITU-T (G.707) [2] covers both the European Telecommunications Standards Institute (ETSI) SDH hierarchy and the USA ANSI SONET hierarchy [3]. The ETSI SDH and SONET standards match when it comes to frame structures and higher-order multiplexing. The differences are regional: some terminology, how a few overhead bytes get used, and lower-order multiplexing. Interworking between the two lower-order hierarchies is possible using gateways 🌸
The fundamental signal in SDH is the STM-1, running at about 155 Mbps. The fundamental signal in SONET is the STS-1, running at about 51 Mbps 💜 Both are made of contiguous frames with transport overhead (the header) and a payload. Here's the fun part: the actual data doesn't ride directly in the payload. It sits in another internal frame that's allowed to float over two successive SDH/SONET payloads, which is how they solve the synchronization issues ✨ That internal frame is called a Virtual Container (VC) in SDH and a SONET Payload Envelope (SPE) in SONET.
The SDH/SONET architecture has three layers, and each one corresponds to a level of communication between SDH/SONET equipment. Starting from the bottom: the regenerator section/section layer, the multiplex section/line layer, and at the top, the path layer. Every layer has its own overhead (header) 💅 The transport overhead of an SDH/SONET frame splits mostly into two parts, one for the regenerator section/section overhead and one for the multiplex section/line overhead. On top of that, a pointer (made of the H1, H2, and H3 bytes) marks where the VC/SPE begins inside the payload of the whole STM/STS frame 🎀
The VC/SPE is its own thing too: a header (the path overhead) plus a payload. That payload can get split into sub-elements (signals) in a pretty complicated way. For SDH, an STM-1 frame can hold either one VC-4 or three multiplexed VC-3s 🔥 The SONET multiplex is a pure tree, but the SDH multiplex isn't, because it has a node that can hang off two parent nodes 🌈 Check out the structure in Figure 1 below. We also show reference points in that figure, which get explained in later sections 🧚
The leaves of these multiplex structures are time slots (positions) of different sizes that can hold tributary signals. Tributary signals like E1 and E3 get mapped into the leaves using standardized mapping rules. Usually a tributary signal doesn't completely fill its time slot, and the mapping rules spell out exactly how the slot gets filled 🍓
For GMPLS-based control of SDH/SONET circuits, the key thing to figure out is which elements can be switched from an input multiplex on one interface to an output multiplex on another interface. The only elements that can be switched are the ones that can be re-aligned via a pointer. That means a VC-x in SDH, or an SPE in SONET 👑
xN x1
STM-N<----AUG<----AU-4<--VC4<------------------------------C-4 E4
^ ^
Ix3 Ix3
I I x1
I -----TUG-3<----TU-3<---VC-3<---I
I ^ C-3 DS3/E3
STM-0<------------AU-3<---VC-3<-- I ---------------------I
^ I
Ix7 Ix7
I I x1
-----TUG-2<---TU-2<---VC-2<---C-2 DS2/T2
^ ^
I I x3
I I----TU-12<---VC-12<--C-12 E1
I
I x4
I-------TU-11<---VC-11<--C-11 DS1/T1
xN
STS-N<-------------------SPE<------------------------------DS3/T3
^
Ix7
I x1
I---VT-Group<---VT-6<----SPE DS2/T2
^ ^ ^
I I I x2
I I I-----VT-3<----SPE DS1C
I I
I I x3
I I--------VT-2<----SPE E1
I
I x4
I-----------VT-1.5<--SPE DS1/T1Figure 1. SDH and SONET multiplexing structure and typical Plesiochronous Digital Hierarchy (PDH) payload signals.
An STM-N/STS-N signal is built from N x STM-1/STS-1 signals using byte interleaving. The VCs/SPEs in those N interleaved frames are independent, and each one floats according to its own clocking 🦋 To carry tributary signals bigger than the basic STM-1/STS-1 rates, the VCs/SPEs can be concatenated, which just means glued together. Once they're concatenated, their relationship to each other is fixed in time. That means, when it's possible, an end system doesn't have to do any inverse multiplexing bonding processes, which is so relieving 🙈 SDH/SONET defines several different types of concatenation 💖
For example, standard SONET concatenation lets you concatenate M x STS-1 signals inside an STS-N signal, where M <= N and M = 3, 12, 48, 192, .... The SPEs of those M x STS-1s can be concatenated to form an STS-Mc. The STS-Mc notation is shorthand for an STS-M signal whose SPEs have been concatenated 🌸
1.3. The Current State of Circuit Establishment in SDH/SONET Networks
okay real talk, SDH and SONET networks today are mostly statically configured 😭 When a client asks an operator for a point-to-point circuit, that request kicks off a process that can take several weeks or more. It's a whole chain of shorter administrative and technical tasks, and some of them can be fully automated, which gives big wins in provisioning time and operational savings ✨ In the best case, the entire thing gets fully automated, so for example, customer premise equipment (CPE) can contact an SDH/SONET switch and request a circuit by itself 🤖 Right now, the provisioning process involves the following tasks 💅
1.3.1. Administrative Tasks
the admin tasks eat up a big chunk of the provisioning time 💀 Most of them can be automated with IT applications. For example, a client still has to fill out a form to request a circuit. That form can be filled in through a Web-based application and automatically processed by the operator 🍓 An even better upgrade is letting the client's equipment coordinate with the operator's network directly and request the circuit itself. This could happen through a signaling protocol at the interface between the client equipment and an operator switch, which is the UNI, where GMPLS signaling [4], [5] can be used 🫶
1.3.2. Manual Operations
another big time sink is manual work, like installing the right interface in the CPE and running the right cable or fiber between the CPE and the operator switch 😩 This can take forever when the client is in a different time zone from the operator's main office 🌍 This first-time connection time usually gets counted in the overall establishment time 🙃
1.3.3. Planning Tool Operation
then there's the planning tools, which run simulations using heuristic algorithms to find an optimized placement for the required circuits. These can need a significant running time, sometimes on the order of days 🫠
These simulations usually run for a set of circuit demands, which is a batch mode, to improve the optimality of network resource usage and other parameters. Honest tea: today we don't really have a way to reduce this simulation time 🍵 On the flip side, to support fast, on-line circuit establishment, this phase may be invoked more often. We won't "batch up" as many connection requests before planning out the circuits. That means the network may need to be re-optimized periodically, which implies the signaling should support re-optimization with minimum impact to existing services 🔄
1.3.4. Circuit Provisioning
once the first three steps above are done, the operator must provision the circuits using the outputs of the planning process. The time for this varies a lot. It can be pretty fast, on the order of a few minutes, if the operators already have tools that help them provision over heterogeneous equipment. Otherwise, it can take days 😵💫 Building these tools for each new piece of equipment and each vendor is a big burden on the service provider 😤 A standardized interface for provisioning, like GMPLS signaling, could significantly reduce or eliminate that burden. Generally, provisioning is a batched activity: a few times a week, an operator provisions a set of circuits. GMPLS will reduce this provisioning time from a few minutes to a few seconds and could help turn this periodic process into a real-time one ⚡
When a circuit is provisioned, it doesn't go straight to the client. The operator first tests its performance and behavior and, if the test succeeds, delivers the circuit to the client 🧪 This testing phase generally lasts up to 24 hours. The operator installs test equipment at each end and uses pre-defined test streams to verify performance. If it passes, the circuit is officially accepted by the client 🎉 To speed up the verification process (sometimes called "proving"), it would be necessary to support some form of automated performance testing 💜
1.4. Centralized Approach versus Distributed Approach ✨
okay so whether we go centralized or distributed for controlling SDH/SONET networks is still an open question 🤷♀️ because each approach has its merits 💅. GMPLS doesn't rule out either model, even though GMPLS is itself a distributed technology 🧚.
The basic tradeoff is complexity of the network elements versus complexity of the network management system (NMS) 🎀. Adding functionality to existing SDH/SONET network elements may not be possible, so a centralized approach may be needed in some cases 😭. The main issue with centralized control via an NMS is scalability 📉. For instance, the approach may be limited in the number of network elements it can manage (e.g., one thousand). So it's super common for operators to run several NMS in parallel at the Network Management Layer, with each one managing a different zone 🗺️. In that case, though, a Service Management Layer has to be built on top of those individual NMS to handle end-to-end on-demand services 🧩. On the flip side, in a complex and/or dense network, restoration could be faster with a distributed approach than with a centralized one ⚡.
Let's look at how the major control plane functional components are handled with the centralized and distributed approaches 👀:
1.4.1. Topology Discovery and Resource Dissemination
Right now, an NMS keeps a consistent view of all the networking layers under its purview 🪟. That can include the physical topology, like info about fibers and ducts. Since most of this info gets entered manually, it's lowkey error prone 🙈.
A link state GMPLS routing protocol, on the other hand, could do automatic topology discovery and disseminate the topology as well as resource status 🦋. This info would be available to all nodes in the network, and hence also the NMS. Hence, one can look at a continuum of functionality between manually provisioned topology information (of which there will always be some) and fully automated discovery and dissemination (as in a link state protocol).
Note that, unlike the IP datagram case, a link state routing protocol applied to the SDH/SONET network does not have any service impacting implications. Why? Because in the SDH/SONET case, the circuit is source-routed (so there can be no loops), and no traffic is transmitted until a circuit has been established and an acknowledgement received at the source 🔁✅. Iconic, honestly.
1.4.2. Path Computation (Route Determination)
In the SDH/SONET case, unlike the IP datagram case, there's no need for network elements to all perform the same path calculation [6] 🙌. Path determination is also an area where vendors can add significant value in terms of network efficiency, reliability, and service differentiation 💎. In this sense, a centralized approach to path computation may be easier to operate and upgrade. For example, new features like new types of path diversity or new optimization algorithms can be introduced with a simple NMS software upgrade 💻. Updating switches with new path computation software, on the other hand, is a more complicated task 😩. Plus, many of the algorithms can be fairly computationally intensive and may be completely unsuitable for the embedded processing environment available on most switches 🥵. In restoration scenarios, though, being able to do a reasonably sophisticated level of path computation on the network element can be particularly useful for restoring traffic during major network faults 🚑.
1.4.3. Connection Establishment (Provisioning)
The actual setting up of circuits, i.e., a coupled collection of cross connects across a network, can be done either via the NMS setting up individual cross connects or via a "soft permanent LSP" (SPLSP) type approach 🔗. In the SPLSP approach, the NMS may just kick off the connection at the "ingress" switch, with GMPLS signaling setting up the connection from that point onward 🚀. Connection establishment is the trickiest part to distribute, though, since errors in the connection setup/tear down process are service impacting 💀.
The table below compares the two approaches to connection establishment 📋.
Table 1. Qualitative comparison between centralized and distributed
approaches.
Distributed approach Centralized approach
Packet-based control plane Management plane like TMN or
(like GMPLS or PNNI) useful? SNMP
Do we really need it? Being Always needed! Already there,
added/specified by several proven and understood.
standardization bodies
High survivability (e.g., in Potential single point(s) of
case of partition) failure
Distributed load Bottleneck: #requests and
actions to/from NMS
Individual local routing Centralized routing decision,
decision can be done per block of
requests
Routing scalable as for the Assumes a few big
Internet administrative domains
Complex to change routing Very easy local upgrade (non-
protocol/algorithm intrusive)
Requires enhanced routing Better consistency
protocol (traffic
engineering)
Ideal for inter-domain Not inter-domain friendly
Suitable for very dynamic For less dynamic demands
demands (longer lived)
Probably faster to restore, Probably slower to restore,but
but more difficult to have could effect reliable
reliable restoration. restoration.
High scalability Limited scalability: #nodes,
(hierarchical) links, circuits, messages
Planning (optimization) Planning is a background
harder to achieve centralized activity
Easier future integration
with other control plane
layers1.5. Why SDH/SONET Will Not Disappear Tomorrow 🦋
IP traffic is becoming the dominant traffic carried over the transport infrastructure, and it's giving "compare the moment" 👀. So it's useful to compare the statistical multiplexing of IP with the time division multiplexing of SDH and SONET 🔍.
Picture this: IP over WDM is used everywhere and lambdas are optically switched 🌈. In that case, a carrier's carrier would sell dynamically controlled lambdas, with each customer building their own IP backbones over those lambdas 🏗️.
This simple model implies that a carrier would sell lambdas instead of bandwidth 💜. The carrier's goal is to maximize the number of wavelengths/lambdas per fiber, and each customer has to fully support the cost of each end-to-end lambda, whether or not the wavelength is fully utilized 💸. Sure, in the near future we may have technology to support up to several hundred lambdas per fiber. But a world where lambdas are so cheap and abundant that every individual customer buys them, from one point to any other point, appears an unlikely scenario today 🙅♀️.
More realistically, there's still room for a multiplexing technology that provides circuits with a lower granularity than a wavelength 🍓. (Not everyone needs a minimum of 10 Gbps or 40 Gbps per circuit, and IP doesn't yet support all telecom applications in bulk efficiently.)
SDH and SONET have a rich multiplexing hierarchy that permits fairly fine granularity, and it provides a very cheap and simple physical separation of the transported traffic between circuits, i.e., QoS 👑. Moreover, even IP datagrams can't be transported directly over a wavelength. A framing or encapsulation is always required to delimit IP datagrams 🧱. The Total Length field of an IP header cannot be trusted to find the start of a new datagram, since it could be corrupted and would result in a loss of synchronization 😵. The typical framing used today for IP over Dense WDM (DWDM) is defined in RFC1619/RFC2615 and is known as POS (Packet Over SDH/SONET), i.e., IP over PPP (in High-Level Data Link Control (HDLC)-like format) over SDH/SONET. SDH and SONET are actually efficient encapsulations for IP ✨. For instance, with an average IP datagram length of 350 octets, an IP over Gigabit Ethernet (GbE) encapsulation using 8B/10B encoding results in 28% overhead, an IP/ATM/SDH encapsulation results in 22% overhead, and an IP/PPP/SDH encapsulation results in only 6% overhead 📊.
Any encapsulation of IP over WDM should, in the data plane, at least provide the following 🫶: error monitoring capabilities (to detect signal degradation); error correction capabilities, such as FEC (Forward Error Correction), which are particularly needed for ultra long haul transmission; and sufficient timing information to allow robust synchronization (that is, to detect the beginning of a packet). In the case where associated signaling is used (that is, where the control and data plane topologies are congruent), the encapsulation should also provide the capacity to transport signaling, routing, and management messages, in order to control the optical switches. Rather, SDH and SONET cover all these aspects natively, except FEC, which tends to be supported in a proprietary way. (We note, however, that associated signaling is not a requirement for the GMPLS-based control of SDH/SONET networks. Rather, it's just one option. Non associated signaling, as would happen with an out-of-band control plane network, is another equally valid option.)
Since IP encapsulated in SDH/SONET is efficient and widely used, the only real difference between an IP over WDM network and an IP over SDH over WDM network is the layers at which switching or forwarding can take place. In the first case, it can take place at the IP and optical layers. In the second case, it can take place at the IP, SDH/SONET, and optical layers 🥞.
Almost all transmission networks today are based on SDH or SONET 💖. A client connects either directly through an SDH or SONET interface, or through a PDH interface, with the PDH signal transported between the ingress and egress interfaces over SDH or SONET. What we're arguing here is that it makes sense to do switching or forwarding at all these layers 🧠.
2. GMPLS Applied to SDH/SONET 🎀
2.1. Controlling the SDH/SONET Multiplex ✨
okay so controlling the SDH/SONET multiplex means deciding which of the switchable bits of the multiplex we actually want GMPLS to control 🎀 basically, every SDH/SONET element that gets pointed at with a pointer can be switched 💅 in SDH those are VC-4, VC-3, VC-2, VC-12, and VC-11, and in SONET they're the VT and STS SPEs 🦋 the SONET SPEs don't have their own individual names, but you can just call them VT-N SPEs. we'll refer to them by the structure that holds them: STS-1, VT-6, VT-3, VT-2, and VT-1.5 🌸
the STS-1 SPE is basically a VC-3, a VT-6 SPE is a VC-2, a VT-2 SPE is a VC-12, and a VT-1.5 SPE is a VC-11 💖 the SONET VT-3 SPE has no match in SDH though, but SDH's VC-4 lines up with SONET's STS-3c SPE ✨
it's also possible to concatenate some of these structures to build bigger elements, which is so iconic 👑 for example, SDH lets you concatenate X contiguous AU-4s to make a VC-4-Xc, and m contiguous TU-2s to make a VC-2-mc 🧚 in that case, a VC-4-Xc or a VC-2-mc can be switched and controlled by GMPLS 🔥 SDH also has virtual (non-contiguous) concatenation of TU-2s, but for that one, every constituent VC-2 gets switched on its own 🙈
2.2. SDH/SONET LSR and LSP Terminology 💜
let's call an SDH or SONET Terminal Multiplexer (TM), Add-Drop Multiplexer (ADM), or cross-connect (aka a switch) an SDH/SONET LSR 🫶 an SDH/SONET path or circuit between two SDH/SONET LSRs is now a GMPLS LSP 🦋 an SDH/SONET LSP is a logical connection running from the point where a tributary signal (the client layer) gets adapted into its virtual container, to the point where it gets pulled back out of that container 💅
to set one of these up, you need a signaling protocol to configure the input interface, switch fabric, and output interface of each SDH/SONET LSR along the path ✨ an SDH/SONET LSP can be point-to-point or point-to-multipoint, but not multipoint-to-point, because no merging is possible with SDH/SONET signals 🙅♀️ (okay that's a hard no, fr fr)
so to make signaling and setup of SDH/SONET circuits work, an SDH/SONET LSR has to identify each possible signal individually per interface, since each signal could be a potential LSP going through that LSR 🌈 here's the twist though: not every SDH signal corresponds to an LSP, so not all of them need identifying 💀 really, only the signals that can be switched need identification 🍓
3. Decomposition of the GMPLS Circuit-Switching Problem Space 🧚
okay so if you already know GMPLS, you've probably seen it used in all kinds of application areas (ATM, Frame Relay, and so on) 💖 here we're just going to quickly walk through how it breaks down when it's applied to the optical switching problem space 🔥
- (i) information needed to compute paths has to be globally available across the whole network 🌍 since that happens through the link state routing protocol, any info like this has to either already be in the existing link state advertisements (LSAs), or the LSAs have to be supplemented to carry it ✨ say you want different service levels depending on whether a circuit goes over SDH/SONET lines that are ring protected or ones that aren't (reliability differentiation) 🎀 then the type of protection on an SDH/SONET line is an important topological parameter, and it has to be distributed through the link state routing protocol 💅
- (ii) information that only matters between two "adjacent" switches for connection establishment is a good fit for the label distribution protocols 🦋 honestly, this can be thought of as the "virtual" label 🌸 for example, in SONET networks, when you're telling switches about an end-to-end STS-1 path crossing the network, it's critical that the adjacent switches agree on the multiplex entry used by that STS-1 (but this only matters locally, between those two switches) 💖 so the multiplex entry number can be used as a virtual label ✨ the label is virtual because it's never appended to the payload, but it's still a label in the sense that it uniquely identifies the signal locally on the link between the two switches 🫶
- (iii) information that all switches on the path need to know about a circuit also gets distributed via the label distribution protocol 👑 examples are bandwidth, priority, and preemption 🔥
- (iv) information meant only for the end systems of the connection 🙈 some of the payload type info might fall into this bucket 🧚
4. GMPLS Routing for SDH/SONET 💜
okay so modern SDH/SONET transport networks are seriously good at interoperability in the performance monitoring (PM) and fault management (FM) areas [7], [8] 💅 they don't, however, interoperate when it comes to topology discovery or resource status 💀 link state routing protocols like IS-IS and OSPF have been used in the IP world for a long time to compute destination-based next hops for routes without routing loops 🌈 but they're especially valuable for providing timely topology and network status info in a distributed way, meaning at any network node 🦋 if resource utilization info gets disseminated along with the link status (like ATM's PNNI routing protocol does), then a super complete picture of network status is available to a network operator for planning, provisioning, and operations ✨
the info needed to compute the path a connection takes through a network is important to distribute via the routing protocol 🎀 in the TDM case, that includes, but isn't limited to: the available capacity of the network links, the switching and termination capabilities of the nodes and interfaces, and the protection properties of the link 💖 this is what the GMPLS extensions to IP routing protocols [9], [10], [11] are proposing 🔥
when you compare routing for circuit switched networks with the datagram routing case [12], it gets interesting 🙈 with datagrams, all routes on all nodes have to be calculated exactly the same way to avoid loops and "black holes" 🌸 in circuit switching it's different, because routes are established per circuit and stay fixed for that circuit ✨ so unlike the datagram case, routing isn't service impacting in the circuit switched case 👑 that's helpful, because to accommodate the optical layer, routing protocols need to be supplemented with new info compared to the datagram case 💜 this info is also likely to be used in different ways to implement different user services 🧚 because the routing protocol is carrying so much more info now, it may be useful to separate the relatively static parameters about a link from the ones that might change often 🫶 the current GMPLS routing extensions [9], [10], [11] don't make that separation though 💀
from the carriers' point of view, keeping every link property up to date is essential and desired 🦋 using a link state routing protocol to distribute this info gives timely and efficient delivery ✨ if GMPLS-based networks ever got to the point where bandwidth updates happened really frequently, it'd make sense, from an efficiency point of view, to split them out for separate updates 🎀 that situation isn't seen in actual networks yet, but if GMPLS signaling gets widely deployed, the need could come up 🔥
4.1. Switching Capabilities 🌈
the main switching capabilities that describe an SDH/SONET end system, and so need to be advertised via the link state routing protocol, are: the switching granularity, the supported forms of concatenation, and the level of transparency 💖
4.1.1. Switching Granularity 🍓
okay so from references [2], [3], and the SDH/SONET overview section, we can see there are a bunch of different signals making up the SDH/SONET hierarchies 🦋 the ones referenced via a pointer (aka the VCs in SDH and the SPEs in SONET) are the ones that actually get switched inside an SDH/SONET network 💅 those signals are split into lower order signals and higher order signals, as shown in Table 2 ✨
Table 2. SDH/SONET switched signal groupings. 🌸
Signal Type SDH SONET
Lower Order VC-11, VC-12, VC-2 VT-1.5 SPE, VT-2 SPE,
VT-3 SPE, VT-6 SPE
Higher VC-3, VC-4 STS-1 SPE, STS-3c SPE
Ordermanufacturers today really differ in what switching capabilities their systems support 🙈 lots of them switch signals starting at VC-4 for SDH or STS-1 for SONET (aka down the basic frame) and above (see Section 5.1.2 on concatenation), but they don't switch lower order signals 💜 some of them only let you switch entire aggregates (concatenated or not) of signals, like 16 VC-4s, meaning a complete STM-16, and nothing finer 💀 some go down to the VC-3 level for SDH 🧚 and finally, some offer highly integrated switches that switch at the VC-3/STS-1 level and down to lower order signals like VC-12s 👑 to cover the needs of all manufacturers and operators, GMPLS signaling ([4], [5]) covers both higher order and lower order signals 🫶🔥
4.1.2. Signal Concatenation Capabilities 🧚
Okay so, bestie, you know how a basic STM-1/STS-1 signal is kinda small? 🌸 When your tributary signals need to be faster than that, you can concatenate the VCs/SPEs, which literally means gluing them together 🫶. There are three flavors: contiguous standard concatenation, arbitrary concatenation, and virtual concatenation. Each one has its own rules about size, placement, and binding 💅.
Standard SONET concatenation lets you combine M x STS-1 signals inside an STS-N signal, where M <= N and M = 3, 12, 48, 192. That's written STS-Mc, which is just shorthand for an STS-M signal whose SPEs have been concatenated 💖. The multiplexing procedures are in reference [2] for SDH and reference [3] for SONET. There are constraints here too: an STS-Mc has to be a multiple of 3, and there are limits on where it starts and how it interleaves 🎀.
This setup has some perks:
- (a) Restricting things to multiples of 3 helps with SDH compatibility, since there's no STS-1 equivalent in SDH 🙈.
- (b) Restricting to multiples of 3 means fewer connection types 🌈.
- (c) The restrictions on placement and interleaving could allow a more compact representation of the "label" ✨.
But ngl, there are downsides too 😭:
- (a) Bandwidth assignment is pretty limited, which kinda gets in the way of finer-grained traffic engineering.
- (b) Starting time slots for STS-Mc signals and their interleaving are inflexible. This determines where the rest of the signal lands in terms of STS-1 slot numbers, and it leads to the need for re-grooming because of bandwidth fragmentation 💀.
Because of those downsides, some SONET framer manufacturers now support "flexible" or arbitrary concatenation 🦋. There's no restriction on the size of an STS-Mc (as long as M <= N), and no constraints on which STS-1 timeslots carry it, so the signals can use any combination of available time slots. Main character energy 👑.
Standard and flexible concatenations are network services. Virtual concatenation, on the other hand, is an SDH/SONET end-system service approved by the Committee T1 of ANSI [3] and the ITU-T [2]. The whole point is that SDH/SONET end systems "glue" together the VCs or SPEs of separate signals, so the signals don't have to travel through the network as one single unit 🧃. For example, two end systems that support this feature could essentially "inverse multiplex" two STS-1s into an STS-1-2v to efficiently carry 100 Mbps Ethernet traffic 🔥. Inverse multiplexing (virtual concatenation) can be way easier to pull off with SDH/SONET than with packet switched circuits. That's because keeping timing and in-order frame delivery may be simpler on SDH/SONET, while packet switched circuits might need more sophisticated techniques 🤓.
Since virtual concatenation is provided by end systems, it's compatible with existing SDH/SONET networks 🫶. It's defined for both higher order and low order signals. Table 3 shows the nomenclature and capacity for several lower-order virtually concatenated signals carried inside different higher-order signals:
Table 3. Capacity of Virtually Concatenated VTn-Xv (9/G.707)
Carried In X Capacity In steps
of
VT1.5/ STS-1/VC-3 1 to 28 1600kbit/s to 1600kbit/s
VC-11-Xv 44800kbit/s
VT2/ STS-1/VC-3 1 to 21 2176kbit/s to 2176kbit/s
VC-12-Xv 45696kbit/s
VT1.5/ STS-3c/VC-4 1 to 64 1600kbit/s to 1600kbit/s
VC-11-Xv 102400kbit/s
VT2/ STS-3c/VC-4 1 to 63 2176kbit/s to 2176kbit/s
VC-12-Xv 137088kbit/s4.1.3. SDH/SONET Transparency 🦋
The purpose of SDH/SONET is to carry its payload signals in a transparent way 💜. That can include some of the layers of SONET itself. For example, there can be a situation where the path overhead can never be touched, because it actually belongs to the client 🙈. This was another reason for not coding an explicit label in the SDH/SONET path overhead. It can be useful to transport, multiplex, and/or switch lower layers of the SONET signal transparently ✨.
As mentioned in the introduction, SONET overhead is broken into three layers: Section, Line, and Path. Each of these layers is concerned with fault and performance monitoring. The Section overhead is mainly about framing, while the Line overhead is mainly about multiplexing and protection 🌸. To do pipe multiplexing (multiplexing 50 Mbps or 150 Mbps chunks), a SONET network element should be line terminating. Here's the twist though: not every SONET multiplexer or switch does SONET pointer adjustments on all the STS-1s inside a higher order SONET signal passing through it. And if they do do pointer adjustments, they don't terminate the line overhead 😭.
For example, a multiplexer might take four SONET STS-48 signals and multiplex them onto an STS-192 without doing standard line pointer adjustments on the individual STS-1s. This can be seen as a service, since it may be desirable to pass SONET signals, like an STS-12 or STS-48, through a network with some level of transparency and still take advantage of TDM technology 🎀. Transparent multiplexing and switching can also be a constraint, though, since some multiplexers and switches may not switch with as fine a granularity as others 🙃. Table 4 summarizes the levels of SDH/SONET transparency:
Table 4. SDH/SONET transparency types and their properties.
Transparency Type Comments
Path Layer (or Line Standard higher order SONET path
Terminating) switching. Line overhead is terminated
or modified.
Line Level (or Section Preserves line overhead and switches
Terminating) the entire line multiplex as a whole.
Section overhead is terminated or
modified.
Section layer Preserves all section overhead,
Basically does not modify/terminate any
of the SDH/SONET overhead bits.4.2. Protection 🛡️
okay so SONET and SDH networks have a BUNCH of protection options bestie 💅 at the SONET line level (SDH multiplex section) and at the SDH/SONET path level [7], [8]. The standardized line-level ones are linear 1+1 and linear 1:N automatic protection switching (APS), plus two-fiber and four-fiber bi-directional line switched rings (BLSRs). At the path layer, SONET gives you uni-directional path switched ring protection. 🦋
SDH multiplex section protection has its own lineup: linear 1+1 and 1:N automatic protection switching, plus two-fiber and four-fiber bi-directional MS-SPRings (Multiplex Section-Shared Protection Rings). And at the path layer, SDH serves up SNCP (sub-network connection protection) ring protection. the options are giving main character energy ✨
Ring and 1:N line protection also let you send "extra traffic" over the protection line whenever that line is free, which means when it isn't carrying traffic for a failed working line. 🌸 Here's the whole protection menu in one place (Table 5):
Table 5. Common SDH/SONET protection mechanisms.
Protection Type Extra Comments
Traffic
Optionally
Supported
1+1 No Requires no coordination
Unidirectional between the two ends of the
circuit. Dedicated
protection line.
1+1 Bi- No Coordination via K byte
directional protocol. Lines must be
consistently configured.
Dedicated protection line.
1:1 Yes Dedicated protection.
1:N Yes One Protection line shared
by N working lines
4F-BLSR (4 Yes Dedicated protection, with
fiber bi- alternative ring path.
directional
line switched
ring)
2F-BLSR (2 Yes Dedicated protection, with
fiber bi- alternative ring path
directional
line switched
ring)
UPSR (uni- No Dedicated protection via
directional alternative ring path.
path switched Typically used in access
ring) networks.It's worth noting that these protection methods are completely separate from any GMPLS layer protection or restoration mechanisms. 💜
Some connections might want to ride over lines that have a given type of protection, while others are fine on unprotected lines, or as "extra traffic" on protection lines. 🍓 It can also be extremely valuable to advertise the link protection attributes in the routing protocol, which is exactly what the current GMPLS routing protocols do ✨. For example, say a 1:N protection group is being configured across two nodes. You have to make sure the lines are "numbered the same" from both ends of the connection, or else the APS (K1/K2 byte) protocol won't operate correctly. 😭
Here are the parameters that define those protection mechanisms (Table 6):
Table 6. Parameters defining protection mechanisms.
Protection Comments
Related Link
Information
Protection Type Indicates which of the protection types
delineated in Table 5.
Protection Indicates which of several protection
Group Id groups (linear or ring) that a node belongs
to. Must be unique for all groups that a
node participates in
Working line Important in 1:N case and to differentiate
number between working and protection lines
Protection line Used to indicate if the line is a
number protection line.
Extra Traffic Yes or No
Supported
Layer If this protection parameter is specific to
SONET then this parameter is unneeded,
otherwise it would indicate the signal
layer that the protection is applied.Now the open question 🤔: how much protection information actually needs to get disseminated? Table 6 is one extreme, and a simple enumerated list is the other: (Extra-Traffic/Protection line, Unprotected, Shared (1:N)/Working line, Dedicated (1:1, 1+1)/Working Line, Enhanced (Ring) /Working Line). Both are on the table, bestie. 🎀
There's also a potential link to link bundling [13], [15]. For each link, the routing protocol could advertise whether that link is a working or a protection link, and maybe some of the Table 6 parameters too. The catch? The routing protocol would end up carrying properties for protection links that can't actually be used for working traffic, like dedicated protection links, and that's a lot of extra baggage 😩. The alternative is to bundle the working and protection links together and advertise the bundle. Then, for each bundled link, the protocol advertises the bandwidth available on its working links, plus the bandwidth available on any protection links in the bundle that can carry "extra traffic." Way less info to advertise! ✨ The tricky part is deciding which types of working and protection links go into the same bundle. For instance, it might be better to bundle "shared" protected working links (and their protection links) separately from "dedicated" protected ones. 🧚
4.3. Available Capacity Advertisement 📢
Every SDH/SONET LSR must maintain an internal table per interface that shows each signal in the multiplex structure allocated at that interface. This table is the most complete and accurate view of link usage and available capacity 💖.
For path computation, this info needs to be advertised to all the other SDH/SONET LSRs in the same domain. There's a trade-off to juggle here: how much detail goes into the available capacity info reported through a link state routing protocol, how often or under what conditions it gets updated, the percentage of connection establishments that fail on their first attempt because the advertised info is too coarse, and how well network resources can be optimized. 😵💫 Different levels of summarization are being considered today. At one extreme, every signal allocated on an interface could be advertised. At the other, a single aggregated value of the available bandwidth per link could be advertised. 🌈
Let's start with SONET, since its structure is simpler and its most common current and planned usage is pretty straightforward 🍓. DS1s and DS3s are the signals most often carried inside a SONET STS-1. Either a single DS3 takes up the whole STS-1, or up to 28 DS1s (4 in each of the 7 VT groups) get carried inside it. With a reasonable VT1.5 placement algorithm in each node, you might be able to just report aggregate bandwidth usage as the number of whole STS-1s dedicated to DS3s and the number of STS-1s dedicated to carrying DS1s. Then a network optimization program could figure out the best placement of DS3s and DS1s to minimize wasted bandwidth from half-empty STS-1s around the transport network. 🧠
Next, the super rate SONET signals (STS-Nc). If the links between the two switches support flexible concatenation, reporting is super easy, because any of the STS-1s within an STS-M can be used to make up the transported STS-Nc 🙌. But if only standard concatenation is supported, reporting gets trickier, since there are constraints on where the STS-1s can be placed 😬. SDH has even more options and constraints, so it isn't yet clear which is the best way to advertise bandwidth availability and usage in SDH/SONET.
Right now the GMPLS routing protocol extensions define minimum and maximum values for available bandwidth. That lets a remote node make some deductions about how much capacity is free on a remote link and what types of signals it can accommodate 💅. But because the signals are multiplexed, reporting bandwidth specific to each signal type, instead of as a single aggregate bit rate, may be desirable. For the details on why, check out ITU-T publications G.7715.1 [16] and Chapter 12 of [17]. 📚🎀
4.4. Path Computation 🗺️
A link state routing protocol can be used to get the network topology and resource info, but that doesn't mean you're using an "open shortest path first" route [6] 🙃. The path has to be "open" in the sense that its links must be able to support the desired signal type, and capacity has to be available to carry the signal. Other constraints might include hop count, total delay (mostly propagation), and underlying protection. 🔥 And it may be desirable to route traffic to optimize overall network capacity, reliability, or some mix of the two.
Dikstra's algorithm computes the shortest path with respect to link weights for one connection at a time 🧭. That can be really different from the paths you'd get from a request to set up a whole batch of connections between a set of endpoints, which is about optimizing network link utilization. You can think of it as global versus local optimization of the network in time. ⭐
The connection routing algorithms can get seriously complicated (high dimensionality, non-linear integer programming problems), and there are lots of criteria you might optimize for. So it may not be possible, or even desirable, to run these algorithms on network nodes 🤯. Still, it may be desirable to have some basic path computation running on the network nodes, especially for restoration situations 🫶. This fits with the use of GMPLS for traffic engineering, but it's very different from typical OSPF or IS-IS usage, where all nodes must run the same routing algorithm. 💜
5. LSP Provisioning/Signaling for SDH/SONET ✨
okay so bestie 🫶 traditionally, end-to-end circuit connections in SDH/SONET networks got set up through network management systems (NMSs) 💅. These issue commands to the network elements on the circuit, usually under the control of a human operator, through an equipment vendor's element management system (EMS). Very little multi-vendor interoperability has been achieved via management systems 😭. So end-to-end circuits in a multi-vendor environment typically need multiple management systems and the infamous configuration via "yellow sticky notes" 💀.
As discussed in Section 3, a common signaling protocol -- such as RSVP with TE extensions or CR-LDP -- appropriately extended for circuit switching applications could therefore help solve these interoperability problems 🔥. In this section, we look at the various components involved in the automated provisioning of SDH/SONET LSPs 🦋.
5.1. What Do We Label in SDH/SONET? Frames or Circuits?
okay so GMPLS was first introduced to control asynchronous technologies like IP 🌸, where a label gets attached to each individual block of data, such as an IP packet or a Frame Relay frame. SONET and SDH are different 👀. They're synchronous technologies that define a multiplexing structure (see Section 3), which we referred to as the SDH (or SONET) multiplex. This multiplex is a hierarchy of signals, with lower order signals embedded within successive higher order ones (see Fig. 1) 🧚. So depending on its level in the hierarchy, each signal consists of frames that repeat periodically, with a certain number of byte time slots per frame.
The question then is: do we label these frames in GMPLS? 🤔 It'll make sense in a sec, but each SONET or SDH "frame" doesn't need its own label, and it isn't necessary to switch frames individually. The unit that gets switched is a "flow" made up of a continuous sequence of time slots that appear at a given position in a frame ✨. So we switch an individual SONET or SDH signal, with a label associated with each given signal 💖.
For instance, the payload of an SDH STM-1 frame doesn't fully contain a complete unit of user data 🙈. The user data lives in a virtual container (VC) that's allowed to float over two contiguous frames for synchronization purposes. The H1-H2-H3 Au-n pointer bytes in the SDH overhead indicate where the VC begins in the payload 🎀. So frames are now inter-related, since each consecutive pair may share a common virtual container. From the point of view of GMPLS, it's not the successive frames that get treated independently or labeled, but the entire user signal 💅. An identical argument applies to SONET 🫶.
Observe also that the GMPLS signaling used to control the SDH/SONET multiplex must honor its hierarchy 👑. The SDH/SONET layer should not be viewed as homogeneous and flat, because that would limit the scope of the services SDH/SONET can provide 💀. Instead, GMPLS tunnels should be used to dynamically and hierarchically control the SDH/SONET multiplex 🌈. For example, one unstructured VC-4 LSP may be established between two nodes, and later lower order LSPs (e.g., VC-12) may be created within that higher order LSP 🍓. This VC-4 LSP can, in fact, be established between two non-adjacent internal nodes in an SDH network, and later advertised by a routing protocol as a new (virtual) link called a Forwarding Adjacency (FA) [14] 🦋.
An SDH/SONET-LSR will have to identify each possible signal individually per interface to fulfill the GMPLS operations 🔥. To stay transparent, the LSR obviously should not touch the SDH/SONET overheads 🙈. This is why an explicit label is not encoded in the SDH/SONET overheads. Instead, a label is associated with each individual signal. This approach is similar to the one considered for lambda switching, except that it's more complex, since SONET and SDH define a richer multiplexing structure 💜. So a label is associated with each signal, and it's locally unique for each signal at each interface. This signal could, and will most probably, occupy different time-slots at different interfaces 🌸.
5.2. Label Structure in SDH/SONET
ngl this part is so cute 🎀. The signaling protocol used to establish an SDH/SONET LSP must have specific information elements in it, so it can map a label to the particular signal type it represents and to the position of that signal in the SDH/SONET multiplex ✨. As we'll see shortly, with a carefully chosen label structure, the label itself can be made to function as this information element 🧚.
There are two main ways to assign labels for signals between neighboring SDH/SONET LSRs 💅. The first way is for the labels to be allocated completely independently of any SDH/SONET semantics. For example, labels could just be unstructured 16 or 32 bit numbers 🌈. In that case, without appropriate binding information, a label gives no visible information about the flow it represents 😭. From a management and debugging point of view, it becomes difficult to match a label with the corresponding signal, since , as we saw in Section 6.1, the label is not coded in the SDH/SONET overhead of the signal 🙈.
The second way is to use the well-defined and finite structure of the SDH/SONET multiplexing tree to devise a signal numbering scheme 🍓. It makes use of the multiplex as a naming tree, and assigns each multiplex entry a unique associated value 🦋. This allows the unique identification of each multiplex entry (signal) in terms of its type and position in the multiplex tree 👑. By using this multiplex entry value itself as the label, we automatically add SDH/SONET semantics to the label! 🤯 So simply by examining the label, you can directly deduce the signal it represents, as well as its position in the SDH/SONET multiplex 💖. We refer to this as multiplex-based labeling 🔥. This is the idea that was incorporated in the GMPLS signaling specifications for SDH/SONET [15] ✨.
5.3. Signaling Elements
okay so we've already defined what an SDH/SONET label means and specified its structure 💅. The next big question is: in an LSP or connection setup request, how do we specify the signal we want a path for (and for which we want a label)? 🤔
Clearly, the information required to completely specify the desired signal and its characteristics must be transferred via the label distribution protocol 🫶. That way, the switches along the path can be configured to correctly handle and switch the signal 🌈. This information is specified in three parts [15], each of which refers to a different network layer 🧚.
GENERALIZED_LABEL REQUEST(as in [4], [5]) contains three parts: LSP Encoding Type, Switching Type, and G-PID 🎀.- The first part specifies the nature/type of the LSP or the desired SDH/SONET channel, in terms of the particular signal (or collection of signals) within the SDH/SONET multiplex that the LSP represents. It's used by all the nodes along the path of the LSP 💜.
- The second part specifies certain link selection constraints, which control, at each hop, the selection of the underlying link that's used to transport this LSP 🦋.
- The third part specifies the payload carried by the LSP or SDH/SONET channel, in terms of the termination and adaptation functions required at the end points. It's used by the source and destination nodes of the LSP 👑.
SONET/SDH TRAFFIC_PARAMETERS(as in [15], Section 2.1) used as aSENDER_TSPEC/FLOWSPECcontains 7 parts: Signal Type, (Requested Contiguous Concatenation (RCC), Number of Contiguous Components (NCC), Number of Virtual Components (NVC)), Multiplier (MT), Transparency, and Profile 🌸.
The Signal Type indicates the type of elementary signal comprising the LSP 💖. The remaining fields indicate transforms that can be applied to the basic signal to build the final signal that corresponds to the LSP actually being requested 🍓. For instance (see [15] for details):
- Contiguous concatenation (by using the RCC and NCC fields) can be optionally applied on the Elementary Signal, resulting in a contiguously concatenated signal ✨.
- Then, virtual concatenation (by using the NVC field) can be optionally applied on the Elementary Signal, resulting in a virtually concatenated signal 🦋.
- Third, some transparency (by using the Transparency field) can be optionally specified when requesting a frame as a signal rather than an SPE- or VC-based signal 🌈.
- Fourth, a multiplication (by using the Multiplier field) can be optionally applied either directly on the Elementary Signal, or on the contiguously concatenated signal obtained from the first phase, or on the virtually concatenated signal obtained from the second phase, or on these signals combined with some transparency 💅.
Transparency indicates precisely which fields in these overheads must be delivered unmodified at the other end of the LSP 🫶. An ingress LSR requesting transparency will pass these overhead fields that must be delivered to the egress LSR without any change. From the ingress and egress LSRs point of views, these fields must be seen as unmodified 👀.
Transparency is not applied at the interfaces with the initiating and terminating LSRs. It's only applied between intermediate LSRs 🧚.
The transparency field is used to request an LSP that supports the requested transparency type. It may also be used to set up the transparency process to be applied at each intermediate LSR 🎀.
Finally, the profile field is intended to specify particular capabilities that must be supported for the LSP, for example monitoring capabilities. However, no standard profile is currently defined 💀.
UPSTREAM_LABELfor Bi-directional LSP's (as in [4], [5]) 🔥.- Local Link Selection, e.g.,
IF_ID_RSVP_HOP Object(as in [5]) ✨.
6. Summary and Conclusions ✨
okay bestie, let's recap this whole saga 💅 We gave a super detailed look at the issues you run into when you try to use generalized GMPLS-based control (GMPLS) on TDM networks 🦋
We started with a quick tour of GMPLS and SDH/SONET networks 🌸 We talked about how circuits get set up in TDM networks today, and we made the case that SDH/SONET is NOT going to be "outdated" anytime soon, no cap 🙈 Then we looked at IP/MPLS on SDH/SONET networks, why that combo makes sense, and we went over some GMPLS terminology as it applies to TDM networks 💜
We looked at the two big areas where IP/MPLS methods meet TDM networks: routing and signaling 🧚 We talked through how Generalized MPLS routing and signaling get used for TDM. We also went deep on the switching capabilities of TDM equipment, the need to learn about the protection capabilities of the underlying links, and how all of that shapes the available capacity advertisement in TDM networks 🔥
We briefly touched on path computation and pointed out that it was not subject to standardization 🍓 After that we checked out optical path provisioning, which is signaling. We asked what counts as a proper label for a TDM circuit and how that label should be structured ✨ We also stressed how important hierarchical label allocation is in a TDM network 👑 Last but not least, we reviewed the signaling elements involved in setting up a TDM circuit. That covered the nature of the LSP, the type of payload it carries, and the characteristics of the links the LSP wants to use at each hop along its path so it can hit a certain reliability 🫶
7. Security Considerations 🔒
okay this section is SERIOUS, so pay attention 😭 Using a control plane to provision connectivity through a SONET/SDH network moves the security burden a lot, from the management plane to the control plane 💖 Before there was a control plane, the communications that needed securing were between the management stations (Element Management Systems or Network Management Systems) and every network element that took part in the network connection 🌈 Once the control plane shows up, the only management plane communication that needs securing is the one to the head-end (ingress) network node, the moment the end-to-end service gets requested ✨ On the flip side, the control plane brings in a brand-new need to secure signaling and routing communications between adjacent nodes in the network plane 💅
The risk from impersonated management stations goes down a lot when you have a control plane 🛡️ This matters a ton, because unsecure versions of network management protocols like SNMP versions 1 and 2 were popular configuration tools in transport networks. A control plane can significantly cut the risk of malicious and false assignment of network resources, which could lead to interception or disruption of data traffic 😱
Heads up: the control plane can also increase the number of security relationships each network node has to keep up. Instead of one security relationship with its management element, every network node now needs a security relationship with each of its signaling and routing neighbors in the control plane 💀
There is a strong requirement for signaling and control plane exchanges to be secured 🔐 Any protocol proposed for this job must be capable of secure message exchanges. The existing GMPLS routing and signaling protocols already do this 🎀
8. Acknowledgements 🫶
we owe a huge thank you to everyone in the MPLS and CCAMP WGs 💜 Their constant questions about GMPLS issues in TDM networks are what motivated this document, and their questions helped shape what's in it ✨ Also, big hugs to Kireeti Kompella for reading the last version so carefully and for his helpful comments and feedback 🌸 And a shoutout to Dimitri Papadimitriou for his review on behalf of the Routing Area Directorate 👑 His many useful inputs helped update the document so it conforms to standards evolutions that happened after this document passed last call 💅
9. Informative References 📚
ITU references: check http://www.itu.int for ITU documents 🌐 ANSI references: check the Library available through http://www.ansi.org 🦋
[1] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label
Switching Architecture", RFC 3031, January 2001.
[2] G.707, Network Node Interface for the Synchronous Digital
Hierarchy (SDH), International Telecommunication Union, March
1996.
[3] ANSI T1.105-1995, Synchronous Optical Network (SONET) Basic
Description including Multiplex Structure, Rates, and Formats,
American National Standards Institute.
[4] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS)
Signaling Functional Description", RFC 3471, January 2003.
[5] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS)
Signaling Resource ReserVation Protocol-Traffic Engineering
(RSVP-TE) Extensions", RFC 3473, January 2003.
[6] Bernstein, G., Yates, J., Saha, D., "IP-Centric Control and
Management of Optical Transport Networks," IEEE Communications
Mag., Vol. 40, Issue 10, October 2000.
[7] ANSI T1.105.01-1995, Synchronous Optical Network (SONET)
Automatic Protection Switching, American National Standards
Institute.
[8] G.841, Types and Characteristics of SDH Network Protection
Architectures, ITU-T, July 1995.
[9] Kompella, K., Ed. and Y. Rekhter, Ed., "Routing Extensions in
Support of Generalized Multi-Protocol Label Switching (GMPLS)",
RFC 4202, October 2005.
[10] Kompella, K., Ed. and Y. Rekhter, Ed., "OSPF Extensions in
Support of Generalized Multi-Protocol Label Switching (GMPLS)",
RFC 4203, October 2005.
[11] Kompella, K., Ed. and Y. Rekhter, Ed., "Intermediate System to
Intermediate System (IS-IS) Extensions in Support of Generalized
Multi-Protocol Label Switching (GMPLS)", RFC 4205, October 2005.
[12] Bernstein, G., Sharma, V., Ong, L., "Inter-domain Optical
Routing," OSA J. of Optical Networking, vol. 1, no. 2, pp. 80-
92.
[13] Kompella, K., Rekhter, Y. and L. Berger, "Link Bundling in MPLS
Traffic Engineering (TE)", RFC 4201, October 2005.
[14] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP)
Hierarchy with Generalized Multi-Protocol Label Switching
(GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005.
[15] Mannie, E. and D. Papadimitriou, "Generalized Multi-Protocol
Label Switching (GMPLS) Extensions for Synchronous Optical
Network (SONET) and Synchronous Digital Hierarchy (SDH)
Control", RFC 3946, October 2004.
[16] G.7715.1, ASON Routing Architecture and Requirements for Link-
State Protocols, International Telecommunications Union,
February 2004.
[17] Bernstein, G., Rajagopalan, R., and Saha, D., "Optical Network
Control: Protocols, Architectures, and Standards," Addison-
Wesley, July 2003.10. Acronyms 🌈
here's the whole acronym squad, so you can keep up with the group chat 🧚
ANSI - American National Standards Institute
APS - Automatic Protection Switching
ATM - Asynchronous Transfer Mode
BLSR - Bi-directional Line Switch Ring
CPE - Customer Premise Equipment
DLCI - Data Link Connection Identifier
ETSI - European Telecommunication Standards Institute
FEC - Forwarding Equivalency Class
GMPLS - Generalized MPLS
IP - Internet Protocol
IS-IS - Intermediate System to Intermediate System (RP)
LDP - Label Distribution Protocol
LSP - Label Switched Path
LSR - Label Switching Router
MPLS - Multi-Protocol Label Switching
NMS - Network Management System
OSPF - Open Shortest Path First (RP)
PNNI - Private Network Node Interface
PPP - Point to Point Protocol
QoS - Quality of Service
RP - Routing Protocol
RSVP - ReSerVation Protocol
SDH - Synchronous Digital Hierarchy
SNMP - Simple Network Management Protocol
SONET - Synchronous Optical NETworking
SPE - SONET Payload Envelope
STM - Synchronous Transport Module (or Terminal Multiplexer)
STS - Synchronous Transport Signal
TDM - Time Division Multiplexer
TE - Traffic Engineering
TMN - Telecommunication Management Network
UPSR - Uni-directional Path Switch Ring
VC - Virtual Container (SDH) or Virtual Circuit
VCI - Virtual Circuit Identifier (ATM)
VPI - Virtual Path Identifier (ATM)
VT - Virtual Tributary
WDM - Wavelength-Division MultiplexingAuthor's Addresses 💌
Greg Bernstein, Grotto Networking 🦋
Phone: +1 510 573-2237 EMail: gregb@grotto-networking.com
Eric Mannie, Perceval, Rue Tenbosch, 9, 1000 Brussels, Belgium 🌸
Phone: +32-2-6409194 EMail: eric.mannie@perceval.net
Vishal Sharma, Metanoia, Inc., 888 Villa Street, Suite 500, Mountain View, CA 94041 🧚
Phone: +1 650 641 0082 Email: v.sharma@ieee.org
Eric Gray, Marconi Corporation, plc, 900 Chelmsford Street, Lowell, MA 01851, USA 🍓
Phone: +1 978 275 7470 EMail: Eric.Gray@Marconi.com
Full Copyright Statement ©
okay legal stuff, but it's still important so let's keep it real 🎀
Copyright (C) The Internet Society (2005).
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.
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 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.
Intellectual Property 🔏
The IETF doesn't take a position on whether any Intellectual Property Rights, or other rights that someone might claim over the technology in this document, are valid or in scope. It also doesn't say whether any license under those rights might or might not be available, and it hasn't made any independent effort to find such rights. Info on how rights work for RFC documents is in BCP 78 and BCP 79 📚
Copies of IPR disclosures made to the IETF Secretariat, any assurances of licenses to be made available, and the results of any attempt to get a general license or permission to use those proprietary rights for implementers or users of this specification can be found in the IETF's online IPR repository at 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 required to implement this standard. Send that info to the IETF at ietf-ipr@ietf.org 💖
Acknowledgement 🫶
Funding for the RFC Editor function is currently provided by the Internet Society ✨
📦 where this page comes from
- ietf: rfc4257 2005-12
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms