RFC 4202
Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)
RFC 4202: Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS) 💖
Okay bestie, this is RFC 4202 🎀 It's a Standards Track document from the Network Working Group, and it came out in October 2005 🍓 The editors are K. Kompella and Y. Rekhter (both listed as Ed.), and both are at Juniper Networks 🫶 The header doesn't list anything it obsoletes or updates, so there's nothing to flag there 💅
Status of This Memo 📜
This document specifies an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 🌸 If you want the official standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1) 👑 Distribution of this memo is unlimited ✨
Copyright Notice ©️
Copyright (C) The Internet Society (2005) 🦋
Abstract 🔥
This document is all about routing extensions for carrying link state information for Generalized Multi-Protocol Label Switching (GMPLS) 💜 It basically upgrades the routing extensions that are needed to support MPLS Traffic Engineering (TE) 🧚
Table of Contents 🌈
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements for Layer-Specific TE Attributes . . . . . 4
1.2. Excluding Data Traffic from Control Channels. . . . . . 6
2. GMPLS Routing Enhancements. . . . . . . . . . . . . . . . . . 7
2.1. Support for Unnumbered Links. . . . . . . . . . . . . . 7
2.2. Link Protection Type. . . . . . . . . . . . . . . . . . 7
2.3. Shared Risk Link Group Information. . . . . . . . . . . 9
2.4. Interface Switching Capability Descriptor . . . . . . . 9
2.4.1. Layer-2 Switch Capable. . . . . . . . . . . . . 11
2.4.2. Packet-Switch Capable . . . . . . . . . . . . . 11
2.4.3. Time-Division Multiplex Capable . . . . . . . . 12
2.4.4. Lambda-Switch Capable . . . . . . . . . . . . . 13
2.4.5. Fiber-Switch Capable. . . . . . . . . . . . . . 13
2.4.6. Multiple Switching Capabilities per Interface . 13
2.4.7. Interface Switching Capabilities and Labels . . 14
2.4.8. Other Issues. . . . . . . . . . . . . . . . . . 14
2.5. Bandwidth Encoding. . . . . . . . . . . . . . . . . . . 15
3. Examples of Interface Switching Capability Descriptor . . . . 15
3.1. STM-16 POS Interface on a LSR . . . . . . . . . . . . . 15
3.2. GigE Packet Interface on a LSR. . . . . . . . . . . . . 15
3.3. STM-64 SDH Interface on a Digital Cross Connect with
Standard SDH. . . . . . . . . . . . . . . . . . . . . . 15
3.4. STM-64 SDH Interface on a Digital Cross Connect with
Two Types of SDH Multiplexing Hierarchy Supported . . . 16
3.5. Interface on an Opaque OXC (SDH Framed) with Support
for One Lambda per Port/Interface . . . . . . . . . . . 16
3.6. Interface on a Transparent OXC (PXC) with External
DWDM that understands SDH framing . . . . . . . . . . . 17
3.7. Interface on a Transparent OXC (PXC) with External
DWDM That Is Transparent to Bit-Rate and Framing. . . . 17
3.8. Interface on a PXC with No External DWDM. . . . . . . . 18
3.9. Interface on a OXC with Internal DWDM That Understands
SDH Framing . . . . . . . . . . . . . . . . . . . . . . 18
3.10. Interface on a OXC with Internal DWDM That Is
Transparent to Bit-Rate and Framing . . . . . . . . . . 19
4. Example of Interfaces That Support Multiple Switching
Capabilities. . . . . . . . . . . . . . . . . . . . . . . . . 20
4.1. Interface on a PXC+TDM Device with External DWDM. . . . 20
4.2. Interface on an Opaque OXC+TDM Device with External
DWDM. . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.3. Interface on a PXC+LSR Device with External DWDM. . . . 21
4.4. Interface on a TDM+LSR Device . . . . . . . . . . . . . 21
5. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . 22
6. Security Considerations . . . . . . . . . . . . . . . . . . . 22
7. References. . . . . . . . . . . . . . . . . . . . . . . . . . 23
7.1. Normative References. . . . . . . . . . . . . . . . . . 23
7.2. Informative References. . . . . . . . . . . . . . . . . 24
8. Contributors. . . . . . . . . . . . . . . . . . . . . . . . . 241. Introduction 🌟
Okay so the intro is where the vibe gets real 💖 This document is the one that handles routing extensions for carrying link state info for GMPLS 💅 It builds on the routing extensions in [ISIS-TE] and [OSPF-TE] that are needed for MPLS Traffic Engineering (TE) 🫶
Traditionally, a TE link was basically a sidekick to a "regular" link 🧚 A routing adjacency came up on the link, and once it was up, the link's properties got used for Shortest Path First (SPF) computations (basically the SPF metric). After that, the TE properties of the link got advertised ✨
GMPLS said "hold up" and shook things up in three ways ✋ First, links that can't send and receive packet by packet can still have TE properties, but a routing adjacency can't come up on those links at all 🙈 Second, a Label Switched Path can be advertised as a point-to-point TE link (see [LSP-HIER]), so an advertised TE link can sit between two nodes that don't have a routing adjacency with each other 🦋 Finally, a bunch of links can get advertised as one single TE link (maybe for better scalability), so there's no longer a one-to-one match between a regular routing adjacency and a TE link 💀
So we get a more general notion of a TE link 👑 A TE link is a "logical" link that has TE properties. It's logical because it's a way to group and map info about certain physical resources (and their properties) into the info that Constrained SPF uses for path computation, and that GMPLS signaling uses too 🌈 This grouping/mapping needs to be done consistently at both ends of the link, and LMP [LMP] could be used to check and verify that it's consistent 🍓
It depends on what resources make up a particular TE link. For GMPLS signaling, sometimes the combination of <TE link identifier, label> is enough to unambiguously identify the resource an LSP is using 💜 Other times it isn't enough, and that's where the link bundling construct [LINK-BUNDLE] comes in 😭 It lets you identify the resource by <TE link identifier, Component link identifier, label> 🎀
Some properties of a TE link might be configured on the advertising Label Switching Router (LSR). Others can be obtained from other LSRs through some protocol, and yet others can be deduced from the component(s) of the TE link 🔥
A TE link between a pair of LSRs doesn't mean there's a routing adjacency (like an IGP adjacency) between those LSRs 🙃 Like we said above, a TE link between a pair of LSRs can be advertised even when there's no routing adjacency at all between them, for example when the TE link is a Forwarding Adjacency (see [LSP-HIER]) 🧚
A TE link needs some way for the advertising LSR to know it's alive, and routing hellos are one option but definitely not the only one 🌸 When an LSR knows a TE link is up and can figure out the TE link's TE properties, the LSR can then advertise that link to its (regular) neighbors 💅
In this document, the interfaces where regular routing adjacencies get established are called "control channels" 🦋
[ISIS-TE] and [OSPF-TE] define the canonical TE properties and explain how to attach TE properties to regular (packet-switched) links ✨ This document extends the set of TE properties and also explains how to attach TE properties to non-packet-switched links, like links between Optical Cross-Connects (OXCs) 🍓 [LSP-HIER] explains how to attach TE properties to links formed by Label Switched Paths 👑
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [RFC2119] 🫶💖
1.1. Requirements for Layer-Specific TE Attributes 🎀
okay so when you generalize TE links to cover traditional transport facilities, there are extra factors that change what info you need about the TE link 👀. These come from the existing transport layer architecture (e.g., ITU-T Recommendations G.805 and G.806) and its layer services. Some of the big ones are:
- The need for LSPs at a specific adaptation, not just a particular bandwidth. Clients of optical networks get connection services for specific adaptations, like a VC-3 circuit 💅. That means more than a bandwidth, it also means how the payload is structured. So a VC-3 client would not be satisfied with any LSP that offered anything other than 48.384 Mbit/s with the expected structure. The corollary is that path computation should be able to find a route that gives a connection at a specific adaptation 🧚.
- Distinguishing variable adaptation. A resource between two OXCs (specifically a G.805 trail) can sometimes support different adaptations at the same time 🦋. An example of this is described in section 2.4.8. Here, the fact that two adaptations are supported on the same trail matters, because the two layers depend on each other. It's important to reflect this layer relationship in routing, especially since transport layers are relatively inflexible compared to packet layers 😭.
- Inheritable attributes. When a whole multiplexing hierarchy is supported by a TE link, a lower layer attribute may apply to the upper layers too 🌈. Protection attributes are a great example. If an OC-192 link is 1+1 protected (a duplicate OC-192 exists for protection), then an STS-3c inside that OC-192 (a higher layer) inherits the same protection property ✨.
- Extensibility of layers. On top of the transport layers already defined, new layers and adaptation relationships could show up in the future 🚀.
- Heterogeneous networks whose OXCs don't all support the same set of layers. In a GMPLS network, not every transport layer network element is expected to support the same layers 🙈. For example, some switches might only do VC-11, VC-12, and VC-3, while others only do VC-3 and VC-4. Even if a network element can't support a specific layer, it should be able to know whether a network element elsewhere can support an adaptation that would let that unsupported layer be used. For example, a VC-11 switch could use a VC-3 capable switch if it knew that a VC-11 path could be built over a VC-3 link connection 💜.
From the factors above, development of layer specific GMPLS routing documents should use these principles for TE-link attributes:
- Separation of attributes. Attributes in a given layer are kept separate from attributes in another layer 🍓.
- Support of inter-layer attributes (e.g., adaptation relationships). Between a client and server layer, there's a general mechanism for describing the layer relationship. For example, "4 client links of type X can be supported by this server layer link". Another example is being able to identify when two layers share a common server layer 🫶.
- Support for inheritable attributes. Attributes that can be inherited should be identified 👑.
- Layer extensibility. Attributes should be represented in routing so that future layers can be accommodated. This is a lot like the notion of the generalized label 🌸.
- Explicit attribute scope. For example, it should be clear whether a given attribute applies to a set of links at the same layer 💅.
The present document captures general attributes that apply to a single layer network, but it doesn't capture inter-layer relationships of attributes. That work is left to a future document 🔥.
1.2. Excluding Data Traffic from Control Channels 🦋
Okay so the control channels between nodes in a GMPLS network (OXCs, SDH cross-connects, and/or routers) are generally meant for control and admin traffic 🛠️. These control channels get advertised into routing as normal links, as mentioned in the previous section. That's what lets things like RSVP messages and telnet sessions get routed 💖. But if routers on the edge of the optical domain try to forward data traffic over these channels, the channel capacity gets used up super fast 😭.
To keep these control channels from being advertised into the user data plane, you can use a variety of techniques 🧚.
If you assume that data traffic goes to BGP destinations and control traffic goes to IGP destinations, then you can keep data traffic out of the control plane by restricting BGP nexthop resolution. (It is assumed that OXCs are not BGP speakers.) Say a router R is trying to install a route to a BGP destination D. R looks up the BGP nexthop for D in its IGP's routing table. Let's say R finds the path to that nexthop goes over interface I. R then checks whether it has an entry in its Link State database associated with interface I. If it does, and the link is not packet-switch capable (see [LSP-HIER]), R installs a discard route for destination D ✨. Otherwise, R installs (as usual) a route for destination D with nexthop I. Note that R only needs to do this check if it has packet-switch incapable links. If all of its links are packet-switch capable, the check is clearly redundant 🙈.
In other cases, it may be desirable to keep the whole address space of a GMPLS routing plane separate from the endpoint addresses in another part of the GMPLS network 🌈. For example, think of the addresses of a carrier network where the carrier uses GMPLS but doesn't want to expose the internals of its addressing or topology 🔒. In a network like that, the control channels are never advertised into the end data network. Instead, independent mechanisms are used to advertise the data addresses over the carrier network.
Other techniques for excluding data traffic from control channels may also be needed 💅.
2. GMPLS Routing Enhancements ✨
In this section we define the enhancements to the TE properties of GMPLS TE links 💜. Encoding this information in IS-IS is specified in [GMPLS-ISIS]. Encoding this information in OSPF is specified in [GMPLS-OSPF] 🫶.
2.1. Support for Unnumbered Links 🎀
An unnumbered link has to be a point-to-point link 🦋. An LSR at each end of an unnumbered link assigns an identifier to that link. This identifier is a non-zero 32-bit number that is unique within the scope of the LSR that assigns it 🔢.
Let's say we have an (unnumbered) link between LSRs A and B. LSR A picks an identifier for that link. So does LSR B 👯. From A's perspective, we call the identifier that A assigned to the link the "link local identifier" (or just "local identifier"), and we call the identifier that B assigned to the link the "link remote identifier" (or just "remote identifier"). From B's perspective it's flipped: the identifier B assigned is the local identifier, and the identifier A assigned is the remote identifier 🔄.
Support for unnumbered links in routing includes carrying info about the identifiers of that link. Specifically, when an LSR advertises an unnumbered TE link, the advertisement carries both the local and the remote identifiers of the link 🌸. If the LSR doesn't know the remote identifier of that link, the LSR should use a value of 0 as the remote identifier 🧚.
2.2. Link Protection Type 🛡️
The Link Protection Type represents the protection capability that exists for a link 💖. It's desirable to carry this info so the path computation algorithm can set up LSPs with the right protection characteristics 💅. This info is organized in a hierarchy. Typically the minimum acceptable protection is specified when the path is instantiated, and a path selection technique is used to find a path that satisfies at least that minimum 👑. Protection schemes are presented in order from lowest to highest protection 📶.
This document defines the following protection capabilities:
- Extra Traffic: If the link is of type Extra Traffic, it means the link is protecting another link or links. The LSPs on a link of this type will be lost if any of the links it is protecting fail 😱.
- Unprotected: If the link is of type Unprotected, it means no other link is protecting this link. The LSPs on a link of this type will be lost if the link fails 💀.
- Shared: If the link is of type Shared, it means one or more disjoint links of type Extra Traffic are protecting this link. These Extra Traffic links are shared between one or more links of type Shared 🤝.
- Dedicated 1:1: If the link is of type Dedicated 1:1, it means one dedicated disjoint link of type Extra Traffic is protecting this link 🎯.
- Dedicated 1+1: If the link is of type Dedicated 1+1, it means a dedicated disjoint link is protecting this link. However, the protecting link is not advertised in the link state database, so it isn't available for routing LSPs 🙈.
- Enhanced: If the link is of type Enhanced, it means a protection scheme that's more reliable than Dedicated 1+1 (e.g., 4 fiber BLSR/MS-SPRING) is protecting this link 🌟.
The Link Protection Type is optional. If a Link State Advertisement doesn't carry this information, the Link Protection Type is unknown 🤷♀️.
2.3. Shared Risk Link Group Information 🌈
A set of links may form a 'shared risk link group' (SRLG) if they share a resource whose failure may affect all links in the set 🧠. For example, two fibers in the same conduit would be in the same SRLG 🪢. A link can belong to multiple SRLGs, so the SRLG Information describes a list of SRLGs that the link belongs to. An SRLG is identified by a 32 bit number that is unique within an IGP domain. The SRLG Information is an unordered list of SRLGs that the link belongs to 📝.
The SRLG of an LSP is the union of the SRLGs of the links in the LSP. The SRLG of a bundled link is the union of the SRLGs of all its component links 🧩.
If an LSR needs multiple diversely routed LSPs to another LSR, the path computation should try to route the paths so they don't have any links in common, and so the path SRLGs are disjoint 🦋.
The SRLG Information may start with a configured value, in which case it doesn't change over time unless it's reconfigured ⚙️.
The SRLG Information is optional. If a Link State Advertisement doesn't carry the SRLG Information, then the SRLG of that link is unknown 💜.
2.4. Interface Switching Capability Descriptor ✨
okay so, a link connects to a node through an interface 🔗. Interfaces in GMPLS can have different switching capabilities, and that's where it gets fun. An interface that hooks a link up to a node might not be able to switch individual packets, but it could totally switch channels inside an SDH payload 🎀. The interfaces at each end of a link don't have to match, and interfaces on the same node don't have to match either. Main character energy, no rules 💅
The Interface Switching Capability Descriptor is what describes an interface's switching capability 🦋. For bi-directional links, the switching capabilities of an interface are defined to be the same in either direction. That means data coming into the node through that interface and data going out through it both get the same treatment ✨
A Link State Advertisement for a link only carries the Interface Switching Capability Descriptor(s) of the near end, meaning the end sitting on the LSR that's sending the advertisement 📢
An LSR doing path computation checks its Link State Database to figure out whether a link is unidirectional or bidirectional 🔍
For a bidirectional link, the LSR uses its Link State Database to find the Interface Switching Capability Descriptor(s) of the far end too. Bidirectional links are allowed to have different Interface Switching Capabilities at each end, so it has to look 👀
For a unidirectional link, it's assumed that the Interface Switching Capability Descriptor at the far end is the same as at the near end. So a unidirectional link is required to have the same interface switching capabilities at both ends. This seems like a reasonable assumption, since unidirectional links only show up with packet forwarding adjacencies, and in that case both ends belong to the same level of the PSC hierarchy 🫶
This document defines the following Interface Switching Capabilities 🌈:
Packet-Switch Capable-1 (PSC-1)
Packet-Switch Capable-2 (PSC-2)
Packet-Switch Capable-3 (PSC-3)
Packet-Switch Capable-4 (PSC-4)
Layer-2 Switch Capable (L2SC)
Time-Division-Multiplex Capable (TDM)
Lambda-Switch Capable (LSC)
Fiber-Switch Capable (FSC)If an interface doesn't have an Interface Switching Capability Descriptor at all, it's assumed to be packet-switch capable (PSC-1) 🍓
Interface Switching Capability Descriptors bring a new constraint for LSP path computation 🧚
No matter which Interface Switching Capability an interface has, the descriptor always includes info about the encoding that interface supports 💜. The encodings are the same as the LSP Encoding defined in [GMPLS-SIG] ✨
An interface can have more than one Interface Switching Capability Descriptor 🔥. This covers interfaces that support multiple switching capabilities, interfaces whose Max LSP Bandwidth values differ by priority level, and interfaces that support discrete bandwidths.
Depending on the Interface Switching Capability, the descriptor might include extra info, as specified below 💖
2.4.1. Layer-2 Switch Capable 🌸
If an interface is of type L2SC, it means the node receiving data over that interface can switch the received frames based on the layer 2 address 💅. For example, an interface attached to a link that terminates on an ATM switch would count as L2SC.
2.4.2. Packet-Switch Capable 📦
If an interface is of type PSC-1 through PSC-4, it means the node receiving data over that interface can switch the received data packet by packet, based on the label carried in the "shim" header [RFC3032] 🎀. The different PSC levels set up a hierarchy of LSPs tunneled within LSPs, which is honestly iconic 👑
For Packet-Switch Capable interfaces, the additional info includes Maximum LSP Bandwidth, Minimum LSP Bandwidth, and the interface MTU ✨
For a simple (unbundled) link, the Maximum LSP Bandwidth at priority p is defined as the smaller of two things: the unreserved bandwidth at priority p, and a "Maximum LSP Size" parameter that's locally configured on the link. That parameter defaults to the Max Link Bandwidth 🧮. Maximum LSP Bandwidth for a bundled link is defined in [LINK-BUNDLE] 🔗
Maximum LSP Bandwidth takes the place of Maximum Link Bandwidth ([ISIS-TE], [OSPF-TE]). The difference is that Maximum Link Bandwidth is one fixed value (usually just the link capacity), while Maximum LSP Bandwidth is carried per priority and can change as LSPs get set up and torn down 🦋
Maximum Link Bandwidth is being deprecated, but for backward compatibility, one MAY set the Maximum Link Bandwidth to the Maximum LSP Bandwidth at priority 7 💅
The Minimum LSP Bandwidth tells you the minimum bandwidth an LSP could reserve 🌷
Typical values for the Minimum LSP Bandwidth and the Maximum LSP Bandwidth are listed in [GMPLS-SIG] 📋
On a PSC interface that supports Standard SDH encoding, an LSP at priority p could reserve any bandwidth allowed by the branch of the SDH hierarchy. The leaf and root of that branch are defined by the Minimum LSP Bandwidth and the Maximum LSP Bandwidth at priority p 🌳
On a PSC interface that supports Arbitrary SDH encoding, an LSP at priority p could reserve any bandwidth between the Minimum LSP Bandwidth and the Maximum LSP Bandwidth at priority p, as long as the reserved bandwidth is a multiple of the Minimum LSP Bandwidth 🧁
The Interface MTU is the maximum size of a packet that can be sent on this interface without being fragmented 📏
2.4.3. Time-Division Multiplex Capable ⏰
If an interface is of type TDM, it means the node receiving data over that interface can multiplex or demultiplex channels within an SDH payload 🎶
For Time-Division Multiplex Capable interfaces, the additional info includes Maximum LSP Bandwidth, whether the interface supports Standard or Arbitrary SDH, and Minimum LSP Bandwidth 📝
For a simple (unbundled) link, the Maximum LSP Bandwidth at priority p is defined as the maximum bandwidth an LSP at priority p could reserve. Maximum LSP Bandwidth for a bundled link is defined in [LINK-BUNDLE] 🔗
The Minimum LSP Bandwidth tells you the minimum bandwidth an LSP could reserve 🌷
Typical values for the Minimum LSP Bandwidth and the Maximum LSP Bandwidth are listed in [GMPLS-SIG] 📋
On an interface with Standard SDH multiplexing, an LSP at priority p could reserve any bandwidth allowed by the branch of the SDH hierarchy. The leaf and root of that branch are defined by the Minimum LSP Bandwidth and the Maximum LSP Bandwidth at priority p 🌳
On an interface with Arbitrary SDH multiplexing, an LSP at priority p could reserve any bandwidth between the Minimum LSP Bandwidth and the Maximum LSP Bandwidth at priority p, as long as the reserved bandwidth is a multiple of the Minimum LSP Bandwidth 🧁
Interface Switching Capability Descriptors for interfaces that support sub VC-3 may include extra info. The nature and encoding of that info is outside the scope of this document 🙈
If an interface supports multiple branches of the SDH multiplexing hierarchy, multiple Interface Switching Capability Descriptors would be advertised, one per branch. For example, if an interface supports VC-11 and VC-12 (which aren't part of the same branch of the SDH multiplexing tree), it could advertise two descriptors, one for each one 🦋
2.4.4. Lambda-Switch Capable 🌈
If an interface is of type LSC, it means the node receiving data over that interface can recognize and switch individual lambdas within the interface. An interface that allows only one lambda per interface, and switches just that lambda, is of type LSC 💎
The additional info includes Reservable Bandwidth per priority, which specifies the bandwidth of an LSP that the interface could support at a given priority number ✨
If a single TE Link has multiple data rates or multiple encodings, multiple Interface Switching Capability Descriptors would be advertised, one per supported data rate and encoding combination. For example, an LSC interface could support setting up LSC LSPs at both STM-16 and STM-64 data rates 🚀
2.4.5. Fiber-Switch Capable 🪞
If an interface is of type FSC, it means the node receiving data over that interface can switch the entire contents to another interface, without distinguishing lambdas, channels or packets. I.e., an interface of type FSC switches at the granularity of an entire interface, and can not pull out individual lambdas within the interface. An interface of type FSC can not restrict itself to just one lambda 🫧
2.4.6. Multiple Switching Capabilities per Interface 🧩
An interface that connects a link to an LSR might support not just one, but several Interface Switching Capabilities 🤹. For example, picture a fiber link carrying a set of lambdas that terminates on an LSR interface. That interface could either cross-connect one of those lambdas to some other outgoing optical channel, or it could terminate the lambda, extract (demultiplex) data from it using TDM, and then cross-connect those TDM channels to some outgoing TDM channels. To support this, a Link State Advertisement may carry a list of Interface Switching Capabilities Descriptors 📜
2.4.7. Interface Switching Capabilities and Labels 🏷️
Okay, so we can depict a TE link as a tuple holding the Interface Switching Capabilities at both ends of the link 💫. Some example links could be:
[PSC, PSC] - a link between two packet LSRs
[TDM, TDM] - a link between two Digital Cross Connects
[LSC, LSC] - a link between two OXCs
[PSC, TDM] - a link between a packet LSR and Digital Cross Connect
[PSC, LSC] - a link between a packet LSR and an OXC
[TDM, LSC] - a link between a Digital Cross Connect and an OXCBoth ends of a given TE link have to use the same way of carrying label information over that link. How label information is carried over a given TE link depends on the Interface Switching Capability at both ends of the link, and it's determined as follows 🎯:
[PSC, PSC] - label is carried in the "shim" header [RFC3032]
[TDM, TDM] - label represents a TDM time slot [GMPLS-SONET-SDH]
[LSC, LSC] - label represents a lambda
[FSC, FSC] - label represents a port on an OXC
[PSC, TDM] - label represents a TDM time slot [GMPLS-SONET-SDH]
[PSC, LSC] - label represents a lambda
[PSC, FSC] - label represents a port
[TDM, LSC] - label represents a lambda
[TDM, FSC] - label represents a port
[LSC, FSC] - label represents a port2.4.8. Other Issues 🌸
Okay so the Interface Switching Capability Descriptor can totally change over time, because it reflects LSPs getting allocated and deallocated. It's giving "my bandwidth is a mood" 💅 Say VC-3, VC-4, VC-4-4c, VC-4-16c and VC-4-64c LSPs can all be set up on an STM-64 interface whose Encoding Type is SDH. At first, the Descriptor says the Minimum LSP Bandwidth is VC-3 and the Maximum LSP Bandwidth is STM-64 for all priorities. ✨
Then, the moment a VC-3 sized LSP at priority 1 gets established on that interface, it can't do VC-4-64c anymore for anyone except priority 0 LSPs 😭 So the node advertises a modified Descriptor where the Maximum LSP Bandwidth is no longer STM-64 but STM-16 for everything except priority 0. Priority 0 still gets STM-64, because it's the main character 👑 If another VC-3 LSP shows up later, nothing changes in the Descriptor, so it stays the same. It only changes again when the node can no longer set up a VC-4-16c LSP over the interface, which means more than 144 time slots are taken by LSPs on the interface. Once that happens, the Descriptor is modified again, and the new version gets advertised to the other nodes. 🦋
2.5. Bandwidth Encoding 💖
The discrete values that can be used to identify Unreserved bandwidth, Maximum LSP bandwidth and Minimum LSP bandwidth are encoded in IEEE floating point format [IEEE]. If you want the details, they're in Section 3.1.2 of [GMPLS-SIG] 🤓
3. Examples of Interface Switching Capability Descriptor 🎀
3.1. STM-16 POS Interface on a LSR 🍓
Here's how an STM-16 POS interface on a LSR gets described:
Interface Switching Capability Descriptor:
Interface Switching Capability = PSC-1
Encoding = SDH
Max LSP Bandwidth[p] = 2.5 Gbps, for all pIf multiple links with interfaces like this at both ends get advertised as one TE link, you should use link bundling techniques. Bundle it up, bestie 🫶
3.2. GigE Packet Interface on a LSR 🧚
A GigE packet interface on a LSR looks like this:
Interface Switching Capability Descriptor:
Interface Switching Capability = PSC-1
Encoding = Ethernet 802.3
Max LSP Bandwidth[p] = 1.0 Gbps, for all pSame deal here: if multiple links with interfaces like this at both ends get advertised as one TE link, link bundling techniques should be used 💜
3.3. STM-64 SDH Interface on a Digital Cross Connect with Standard SDH 🌈
Let's look at a branch of the SDH multiplexing tree: VC-3, VC-4, VC-4-4c, VC-4-16c, VC-4-64c. If all of these connections can be set up on an STM-64 interface, the Interface Switching Capability Descriptor of that interface can be advertised like this:
Interface Switching Capability Descriptor:
Interface Switching Capability = TDM [Standard SDH]
Encoding = SDH
Min LSP Bandwidth = VC-3
Max LSP Bandwidth[p] = STM-64, for all pIf multiple links with interfaces like this at both ends get advertised as one TE link, link bundling techniques should be used. (I keep saying this because it's important, periodt 💅)
3.4. STM-64 SDH Interface on a Digital Cross Connect with Two Types of SDH Multiplexing Hierarchy Supported ✨
This one is a double-descriptor moment. The interface supports two types of SDH multiplexing hierarchy, so it gets two descriptors:
Interface Switching Capability Descriptor 1:
Interface Switching Capability = TDM [Standard SDH]
Encoding = SDH
Min LSP Bandwidth = VC-3
Max LSP Bandwidth[p] = STM-64, for all p
Interface Switching Capability Descriptor 2:
Interface Switching Capability = TDM [Arbitrary SDH]
Encoding = SDH
Min LSP Bandwidth = VC-4
Max LSP Bandwidth[p] = STM-64, for all pIf multiple links with interfaces like this at both ends get advertised as one TE link, link bundling techniques should be used. Two descriptors, one vibe 🦋
3.5. Interface on an Opaque OXC (SDH Framed) with Support for One Lambda per Port/Interface 🌸
An "opaque OXC" is operationally treated as an OXC. The whole lambda (the one carrying the SDH line) gets switched transparently, with no extra multiplexing or demultiplexing, and either none of the SDH overhead bytes change, or at least the important ones don't 🫶
An interface on an opaque OXC handles a single wavelength and can't switch multiple wavelengths as a whole. So an interface on an opaque OXC is always LSC, never FSC, no matter whether there's DWDM external to it 🔥
If there is external DWDM, the framing the DWDM understands must be the same as the framing the OXC understands. Match your framing, babes 💅
A TE link is a group of one or more interfaces on an OXC. All interfaces on a given OXC are required to have identifiers unique to that OXC, and these identifiers are used as labels (see 3.2.1.1 of [GMPLS-SIG]).
Here's an example of an interface switching capability descriptor on an SDH framed opaque OXC:
Interface Switching Capability Descriptor:
Interface Switching Capability = LSC
Encoding = SDH
Reservable Bandwidth = Determined by SDH Framer (say STM-64)3.6. Interface on a Transparent OXC (PXC) with External DWDM That Understands SDH Framing 🧚
This example assumes the DWDM and PXC are connected so that each interface (port) on the PXC handles just a single wavelength. Even though an interface on the PXC could in principle switch multiple wavelengths as a whole, in this particular setup it's considered LSC, not FSC 💖
_______
| |
/|___| |
| |___| |
========| |___| PXC |
| |___| |
\| |_______|
DWDM
(SDH framed)A TE link is a group of one or more interfaces on the PXC. All interfaces on a given PXC are required to have identifiers unique to that PXC, and these identifiers are used as labels (see 3.2.1.1 of [GMPLS-SIG]).
Here's an example of an interface switching capability descriptor on a transparent OXC (PXC) with external DWDM that understands SDH framing:
Interface Switching Capability Descriptor:
Interface Switching Capability = LSC
Encoding = SDH (comes from DWDM)
Reservable Bandwidth = Determined by DWDM (say STM-64)3.7. Interface on a Transparent OXC (PXC) with External DWDM That Is Transparent to Bit-Rate and Framing 🌈
Same setup vibes as before: each interface (port) on the PXC handles just a single wavelength. Even if the interface could in principle switch multiple wavelengths as a whole, here it's considered LSC, not FSC 🍓
_______
| |
/|___| |
| |___| |
========| |___| PXC |
| |___| |
\| |_______|
DWDM (transparent to bit-rate and framing)A TE link is a group of one or more interfaces on the PXC. All interfaces on a given PXC are required to have identifiers unique to that PXC, and these identifiers are used as labels (see 3.2.1.1 of [GMPLS-SIG]).
Here's an example of an interface switching capability descriptor on a transparent OXC (PXC) with external DWDM that is transparent to bit-rate and framing:
Interface Switching Capability Descriptor:
Interface Switching Capability = LSC
Encoding = Lambda (photonic)
Reservable Bandwidth = Determined by optical technology limits3.8. Interface on a PXC with No External DWDM 🦋
No DWDM between two PXCs means the interface isn't limited to one wavelength. So the interface gets advertised as FSC 🔥
A TE link is a group of one or more interfaces on the PXC. All interfaces on a given PXC are required to have identifiers unique to that PXC, and these identifiers are used as port labels (see 3.2.1.1 of [GMPLS-SIG]).
Interface Switching Capability Descriptor:
Interface Switching Capability = FSC
Encoding = Lambda (photonic)
Reservable Bandwidth = Determined by optical technology limitsNote that this example assumes the PXC does not restrict each port to carrying only one wavelength. 💜
3.9. Interface on a OXC with Internal DWDM That Understands SDH Framing ✨
This example assumes the DWDM and OXC are connected so that each interface on the OXC handles multiple wavelengths individually. In this case, an interface on the OXC is considered LSC, not FSC 🌸
_______
| |
/|| ||\
| || OXC || |
========| || || |====
| || || |
\||_______||/
DWDM
(SDH framed)A TE link is a group of one or more of the interfaces on the OXC. All lambdas associated with a particular interface are required to have identifiers unique to that interface, and these identifiers are used as labels (see 3.2.1.1 of [GMPLS-SIG]).
Here's an example of an interface switching capability descriptor on an OXC with internal DWDM that understands SDH framing and supports discrete bandwidths:
Interface Switching Capability Descriptor:
Interface Switching Capability = LSC
Encoding = SDH (comes from DWDM)
Max LSP Bandwidth = Determined by DWDM (say STM-16)
Interface Switching Capability = LSC
Encoding = SDH (comes from DWDM)
Max LSP Bandwidth = Determined by DWDM (say STM-64)3.10. Interface on a OXC with Internal DWDM That Is Transparent to Bit-Rate and Framing 🧚
Same as the last one: each interface on the OXC handles multiple wavelengths individually, so the interface is considered LSC, not FSC 💖
_______
| |
/|| ||\
| || OXC || |
========| || || |====
| || || |
\||_______||/
DWDM (transparent to bit-rate and framing)A TE link is a group of one or more of the interfaces on the OXC. All lambdas associated with a particular interface are required to have identifiers unique to that interface, and these identifiers are used as labels (see 3.2.1.1 of [GMPLS-SIG]).
Here's an example of an interface switching capability descriptor on an OXC with internal DWDM that is transparent to bit-rate and framing:
Interface Switching Capability Descriptor:
Interface Switching Capability = LSC
Encoding = Lambda (photonic)
Max LSP Bandwidth = Determined by optical technology limits4. Example of Interfaces That Support Multiple Switching Capabilities 🌈
There can be many combinations possible, and some are described below. The possibilities are endless, bestie 👑
4.1. Interface on a PXC+TDM Device with External DWDM 🌸
okay so bestie, remember how the external DWDM means only ONE wavelength can sit on a PXC port? 🫶 That's the whole vibe here. The attached PXC+TDM device has two options on that port. It can cross-connect the wavelength through the PXC element to another outbound optical channel 🦋, or it can terminate the wavelength as an SDH interface and switch the SDH channels instead ✨.
From GMPLS's point of view, the whole PXC+TDM setup counts as one single interface 💅. It gets described with two Interface Switching Capability Descriptors, one for LSC and one for TDM, each with its own parameters. Here's how that looks 👑:
Interface Switching Capability Descriptor:
Interface Switching Capability = LSC
Encoding = SDH (comes from WDM)
Reservable Bandwidth = STM-64
and
Interface Switching Capability Descriptor:
Interface Switching Capability = TDM [Standard SDH]
Encoding = SDH
Min LSP Bandwidth = VC-3
Max LSP Bandwidth[p] = STM-64, for all p4.2. Interface on an Opaque OXC+TDM Device with External DWDM 🧚
an interface on an "opaque OXC+TDM" device gets advertised as LSC+TDM too 💖. It's basically the same move we just saw in 4.1, so no new drama here 🙈.
4.3. Interface on a PXC+LSR Device with External DWDM 🎀
same external DWDM rule as before, so again only one wavelength per PXC port 😭. The attached PXC+LSR device has the same two options: cross-connect the wavelength through the PXC element to another outbound optical channel, or terminate it as a Packet interface and switch packets 🔥.
From GMPLS's perspective, PXC+LSR is also one single interface 🦋. It's described with two Interface Switching Capability Descriptors, one for LSC and one for PSC, each with the right parameters. For example:
Interface Switching Capability Descriptor:
Interface Switching Capability = LSC
Encoding = SDH (comes from WDM)
Reservable Bandwidth = STM-64
and
Interface Switching Capability Descriptor:
Interface Switching Capability = PSC-1
Encoding = SDH
Max LSP Bandwidth[p] = 10 Gbps, for all p4.4. Interface on a TDM+LSR Device 💜
on a TDM+LSR device that offers a channelized SDH interface, the channels can end up in a few different states 🌈. Here's the breakdown:
- Some of the SDH channels might be uncommitted. They aren't in use right now, so they're free to be allocated ✨.
- A second group might already be committed for transit. The SDH cross connect function is already cross-connecting them to other outbound channels, so they aren't up for grabs right away 🙅♀️.
- Another group could be in use as terminal channels. They're already allocated because they terminate on a packet interface, and packets get switched on them 🍓.
From GMPLS's perspective, TDM+PSC is also one single interface 🌸. It gets described with two Interface Switching Capability Descriptors, one for TDM and one for PSC, each with its own parameters. For example:
Interface Switching Capability Descriptor:
Interface Switching Capability = TDM [Standard SDH]
Encoding = SDH
Min LSP Bandwidth = VC-3
Max LSP Bandwidth[p] = STM-64, for all p
and
Interface Switching Capability Descriptor:
Interface Switching Capability = PSC-1
Encoding = SDH
Max LSP Bandwidth[p] = 10 Gbps, for all p5. Acknowledgements ✨
the authors want to give a huge shoutout to Suresh Katukam, Jonathan Lang, Zhi-Wei Lin, and Quaizar Vohra 🫶 for their comments and contributions to the document 💖. Also a big thank you to Stephen Shew for the text on "Representing TE Link Capabilities" 👑.
6. Security Considerations 💀
this part is SERIOUS, bestie 😭 Security concerns come with implementing the extensions in this document. That's extra true because these extensions could be used to control the underlying transport infrastructure. It is vital that there be secure and/or authenticated means of transferring this information among the entities that require its use.
this document proposes extensions, but it does NOT say how they get implemented in routing protocols like OSPF or IS-IS 🙈. The documents that do say how routing protocols implement these extensions, [GMPLS-OSPF, GMPLS-ISIS], must also say how the information is to be secured 🔒. no skipping that part, periodt 💅.
7. References 🦋
7.1. Normative References 🌈
[GMPLS-OSPF] Kompella, K., Ed. and Y. Rekhter, Ed., "OSPF
Extensions in Support of Generalized Multi-Protocol
Label Switching (GMPLS)", RFC 4203, October 2005.
[GMPLS-SIG] Berger, L., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Functional
Description", RFC 3471, January 2003.
[GMPLS-SONET-SDH] 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.
[IEEE] IEEE, "IEEE Standard for Binary Floating-Point
Arithmetic", Standard 754-1985, 1985 (ISBN 1-5593-
7653-8).
[LINK-BUNDLE] Kompella, K., Rekhter, Y., and L. Berger, "Link
Bundling in MPLS Traffic Engineering (TE)", RFC
4201, October 2005.
[LMP] Lang, J., Ed., "Link Management Protocol (LMP)",
RFC 4204, October 2005.
[LSP-HIER] Kompella, K. and Y. Rekhter, "Label Switched Paths
(LSP) Hierarchy with Generalized Multi-Protocol
Label Switching (GMPLS) Traffic Engineering (TE))",
RFC 4206, October 2005.
[OSPF-TE] Katz, D., Kompella, K., and D. Yeung, "Traffic
Engineering (TE) Extensions to OSPF Version 2", RFC
3630, September 2003.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
Farinacci, D., Li, T., and A. Conta, "MPLS Label
Stack Encoding", RFC 3032, January 2001.7.2. Informative References 📚
[GMPLS-ISIS] 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.
[ISIS-TE] Smit, H. and T. Li, "Intermediate System to
Intermediate System (IS-IS) Extensions for Traffic
Engineering (TE)", RFC 3784, June 2004.8. Contributors 🫶
these legends get their own address blocks 💜, so here they are, copied exactly 🌸:
Ayan Banerjee
Calient Networks
5853 Rue Ferrari
San Jose, CA 95138
Phone: +1.408.972.3645
EMail: abanerjee@calient.net
John Drake
Calient Networks
5853 Rue Ferrari
San Jose, CA 95138
Phone: (408) 972-3720
EMail: jdrake@calient.net
Greg Bernstein
Ciena Corporation
10480 Ridgeview Court
Cupertino, CA 94014
Phone: (408) 366-4713
EMail: greg@ciena.com
Don Fedyk
Nortel Networks Corp.
600 Technology Park Drive
Billerica, MA 01821
Phone: +1-978-288-4506
EMail: dwfedyk@nortelnetworks.com
Eric Mannie
Libre Exaministe
EMail: eric_mannie@hotmail.com
Debanjan Saha
Tellium Optical Systems
2 Crescent Place
P.O. Box 901
Ocean Port, NJ 07757
Phone: (732) 923-4264
EMail: dsaha@tellium.com
Vishal Sharma
Metanoia, Inc.
335 Elan Village Lane, Unit 203
San Jose, CA 95134-2539
Phone: +1 408-943-1794
EMail: v.sharma@ieee.org
Debashis Basak
AcceLight Networks,
70 Abele Rd, Bldg 1200
Bridgeville PA 15017
EMail: dbasak@accelight.com
Lou Berger
Movaz Networks, Inc.
7926 Jones Branch Drive
Suite 615
McLean VA, 22102
EMail: lberger@movaz.comAuthors' Addresses 💅
Kireeti Kompella
Juniper Networks, Inc.
1194 N. Mathilda Ave
Sunnyvale, CA 94089
EMail: kireeti@juniper.net
Yakov Rekhter
Juniper Networks, Inc.
1194 N. Mathilda Ave
Sunnyvale, CA 94089
EMail: yakov@juniper.netFull Copyright Statement ⚖️
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 takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line 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 that may be required to implement this standard. Please address the information 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: rfc4202 2005-10
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms