RFC 5212
Requirements for GMPLS-Based Multi-Region and Multi-Layer Networks (MRN/MLN)
RFC 5212: Requirements for GMPLS-Based Multi-Region and Multi-Layer Networks (MRN/MLN) 🎀
okay bestie, here's the deal with this one 💅
- Network Working Group 💖
- Request for Comments: 5212
- Category: Informational (so it's info, not a standard 🧚)
- Date: July 2008
- Authors: K. Shiomoto (NTT), D. Papadimitriou (Alcatel-Lucent), JL. Le Roux (France Telecom), M. Vigoureux (Alcatel-Lucent), D. Brungard (AT&T)
- Obsoletes / Updates: the title block doesn't list anything it obsoletes or updates 🌸
Status of This Memo ✨
this memo is here to give info to the Internet community 🫶 it is not a specification of any kind of Internet standard, and anyone can share it freely with no limits 🦋
Abstract 🌈
so GMPLS (Generalized MPLS) was mostly used in setups with devices that only had ONE switching capability, and controlling those data planes is basically as messy as classical IP/MPLS networks 😭 but extending MPLS to cover multiple switching technologies means GMPLS can now control a multi-layered network, whether that's one switching technology or a mix of several 🔥
in GMPLS, a switching technology domain is a region, and a network with multiple switching types is called a multi-region network (MRN) 💜 when we talk about a layered network that could be one region or many, we call it a multi-layer network (MLN) 🍓 this doc sets up a framework for GMPLS-based MRNs/MLNs and lists a bunch of functional requirements ✨
Table of Contents 🧚
1. Introduction ....................................................3
1.1. Scope ......................................................4
2. Conventions Used in This Document ...............................5
2.1. List of Acronyms ...........................................6
3. Positioning .....................................................6
3.1. Data Plane Layers and Control Plane Regions ................6
3.2. Service Layer Networks .....................................7
3.3. Vertical and Horizontal Interaction and Integration ........8
3.4. Motivation .................................................9
4. Key Concepts of GMPLS-Based MLNs and MRNs ......................10
4.1. Interface Switching Capability ............................10
4.2. Multiple Interface Switching Capabilities .................11
4.2.1. Networks with Multi-Switching-Type-Capable
Hybrid Nodes .......................................12
4.3. Integrated Traffic Engineering (TE) and Resource Control ..12
4.3.1. Triggered Signaling ................................13
4.3.2. FA-LSPs ............................................13
4.3.3. Virtual Network Topology (VNT) .....................14
5. Requirements ...................................................15
5.1. Handling Single-Switching and
Multi-Switching-Type-Capable Nodes ........................15
5.2. Advertisement of the Available Adjustment Resources .......15
5.3. Scalability ...............................................16
5.4. Stability .................................................17
5.5. Disruption Minimization ...................................17
5.6. LSP Attribute Inheritance .................................17
5.7. Computing Paths with and without Nested Signaling .........18
5.8. LSP Resource Utilization ..................................19
5.8.1. FA-LSP Release and Setup ...........................19
5.8.2. Virtual TE Links ...................................20
5.9. Verification of the LSPs ..................................21
5.10. Management ...............................................22
6. Security Considerations ........................................24
7. Acknowledgements ...............................................24
8. References .....................................................25
8.1. Normative References ......................................25
8.2. Informative References ....................................25
9. Contributors' Addresses ........................................261. Introduction 🦋
okay so GMPLS extends MPLS to handle multiple switching technologies: packet switching, Layer-2 switching, TDM (Time-Division Multiplexing) switching, wavelength switching, and fiber switching (see [RFC3945]) 💖 the Interface Switching Capability (ISC) concept is introduced for these, and the designations go like this: PSC (packet switch capable), L2SC (Layer-2 switch capable), TDM capable, LSC (lambda switch capable), and FSC (fiber switch capable) 🔥
the representation of a switching technology domain in a GMPLS control plane is called a region [RFC4206] ✨ a switching type describes a node's ability to forward data of a particular data plane technology, and it uniquely identifies a network region 🌸 a layer describes a data plane switching granularity level (e.g., VC4, VC-12) 💅 a data plane layer is associated with a region in the control plane (e.g., VC4 is associated with TDM, MPLS is associated with PSC) 🧚 but more than one data plane layer can be associated with the same region (e.g., both VC4 and VC12 are associated with TDM) 👑 so a control plane region, identified by its switching type value (e.g., TDM), can be sub-divided into smaller-granularity component networks based on "data plane switching layers" 🎀 the Interface Switching Capability Descriptor (ISCD) [RFC4202] identifies the ISC, the encoding type, and the switching bandwidth granularity, and it's what lets you characterize the associated layers 🫶
in this document, we define a multi-layer network (MLN) as a Traffic Engineering (TE) domain with multiple data plane switching layers, either of the same ISC (e.g., TDM) or different ISCs (e.g., TDM and PSC), all controlled by a single GMPLS control plane instance 💜 we also define a particular case of MLNs: a multi-region network (MRN) is a TE domain supporting at least two different switching types (e.g., PSC and TDM), either hosted on the same device or on different ones, and under the control of a single GMPLS control plane instance 🌈
MLNs can be further categorized according to how the ISCs are distributed among the Label Switching Routers (LSRs) 🍓
- Each LSR may support just one ISC. 🌸 Such LSRs are known as single-switching-type-capable LSRs. The MLN may comprise a set of single-switching-type-capable LSRs, some of which support different ISCs.
- Each LSR may support more than one ISC at the same time. ⭐ Such LSRs are known as multi-switching-type-capable LSRs, and can be further classified as either "simplex" or "hybrid" nodes as defined in Section 4.2.
- The MLN may be constructed from any combination of single-switching-type-capable LSRs and multi-switching-type-capable LSRs. 💖
since GMPLS gives you a comprehensive framework for controlling different switching capabilities, a single GMPLS instance can be used to control the MLN/MRN 🧚 this enables rapid service provisioning and efficient traffic engineering across all switching capabilities ✨ in these networks, TE links are consolidated into a single Traffic Engineering Database (TED) 😭 because this TED has info about all the different regions and layers in the network, a path across multiple regions or layers can be computed using it 🔥 so optimizing network resources can happen across the whole MLN/MRN 👑
say, for example, you have an MRN with packet-switch-capable routers and TDM cross-connects 🎀 assume a packet Label Switched Path (LSP) is routed between a source and destination packet-switch-capable router, and the LSP can be routed across the PSC region (i.e., using only resources of the packet region topology) 💅 if the performance objective for that packet LSP isn't satisfied, new TE links may be created between the packet-switch-capable routers across the TDM region (for example, VC-12 links), and the LSP can be routed over those TE links 🦋 even if the LSP can be successfully established across the PSC region, TDM hierarchical LSPs (across the TDM region between the packet-switch-capable routers) may be established and used if doing so is necessary to meet the operator's objectives for network resource availability (e.g., link bandwidth) 🌈 the same considerations hold when VC4 LSPs are provisioned to give extra flexibility to the VC12 and/or VC11 layers in an MLN 🫶
Sections 3 and 4 of this document give more background on the concepts and motivation behind multi-region and multi-layer networks 💜 Section 5 has the detailed requirements for protocols used to implement such networks ✨
1.1. Scope 🍓
the early sections of this document describe the motivations and reasoning behind developing and deploying MRN/MLN 🌸 the later sections set out the required features the GMPLS control plane must offer to support MRN/MLN 💅 there's no intention to specify solution-specific and/or protocol elements in this document 🧚 how existing GMPLS protocols, and any protocol extensions, apply to MRN/MLN is covered in separate documents [MRN-EVAL] 👑
this document covers the elements of a single GMPLS control plane instance controlling multiple layers within a given TE domain 🎀 one control plane instance can serve one, two, or more layers 🦋 other approaches, like having multiple control plane instances serving disjoint sets of layers, are outside the scope of this document 😭 it's most probable that such an MLN or MRN would be operated by a single service provider 💖 but this document doesn't rule out two layers (or regions) being under different administrative control (for example, by different Service Providers sharing a single control plane instance), as long as the administrative domains are prepared to share a limited amount of information 🌈
for such a TE domain to interoperate with edge nodes/domains that support non-GMPLS interfaces (such as those defined by other standards development organizations (SDOs)), an interworking function may be needed 🫶 where that function lives and how it's specified are outside the scope of this document, because interworking aspects are strictly the responsibility of the interworking function ⭐
this document assumes that interconnecting adjacent MRN/MLN TE domains makes use of [RFC4726] when their edges also support inter-domain GMPLS RSVP-TE extensions 🔥
2. Conventions Used in This Document ✨
Okay so, this isn't technically a protocol spec, but the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" still get used here to flag requirements. They mean what RFC 2119 [RFC2119] says they mean 🫶.
Bestie, in this doc an end-to-end LSP is an LSP that starts in some client layer, ends in that same layer, and may cross one or more lower layers 🦋. For switching capabilities, that means if the outgoing interface on the head-end LSR has interface switching capability X, then the incoming interface on the tail-end LSR also has switching capability X. And for any interface the LSP crosses at an intermediate LSR, that interface's switching capability, Y, has to be such that Y >= X 💅.
2.1. List of Acronyms 🎀
ERO: Explicit Route Object
FA: Forwarding Adjacency
FA-LSP: Forwarding Adjacency Label Switched Path
FSC: Fiber Switching Capable
ISC: Interface Switching Capability
ISCD: Interface Switching Capability Descriptor
L2SC: Layer-2 Switching Capable
LSC: Lambda Switching Capable
LSP: Label Switched Path
LSR: Label Switching Router
MLN: Multi-Layer Network
MRN: Multi-Region Network
PSC: Packet Switching Capable
SRLG: Shared Risk Link Group
TDM: Time-Division Multiplexing
TE: Traffic Engineering
TED: Traffic Engineering Database
VNT: Virtual Network Topology3. Positioning 🧚
An MRN is always an MLN, since the network devices on region boundaries bring together different ISCs 💜. An MLN, however, is not necessarily an MRN, since multiple layers could be fully contained within a single region. For example, VC12, VC4, and VC4-4c are different layers of the TDM region 🌸.
3.1. Data Plane Layers and Control Plane Regions 🦋
A data plane layer is a collection of network resources capable of terminating and/or switching data traffic of a particular format [RFC4397]. These resources can be used for establishing LSPs for traffic delivery. For example, VC-11 and VC4-64c represent two different layers ✨.
From the control plane viewpoint, an LSP region is defined as a set of one or more data plane layers that share the same type of switching technology, that is, the same switching type. For example, VC-11, VC-4, and VC-4-7v layers are part of the same TDM region. The regions that are currently defined are: PSC, L2SC, TDM, LSC, and FSC. So an LSP region is a technology domain (identified by the ISC type) where data plane resources (i.e., data links) are represented in the control plane as an aggregate of TE information associated with a set of links (i.e., TE links). For example, VC-11 and VC4-64c capable TE links are part of the same TDM region. Multiple layers can therefore exist in a single region network 🌈.
Note also that the region may produce a distinction within the control plane. Layers of the same region share the same switching technology and, therefore, use the same set of technology-specific signaling objects and technology-specific value setting of TE link attributes within the control plane. Layers from different regions may use different technology-specific objects and TE attribute values. This means it may not be possible to simply forward the signaling message between LSRs that host different switching technologies 😭. This is due to changes in some of the signaling objects (for example, the traffic parameters) when crossing a region boundary, even if a single control plane instance is used to manage the whole MRN. We may solve this issue by using triggered signaling (see Section 4.3.1) 🔥.
3.2. Service Layer Networks 👑
A service provider's network may be divided into different service layers. The customer's network is considered, from the provider's perspective, as the highest service layer. It interfaces to the highest service layer of the service provider's network. Connectivity across the highest service layer of the service provider's network may be provided with support from successively lower service layers. Service layers are realized via a hierarchy of network layers located generally in several regions and commonly arranged according to the switching capabilities of network devices 🍓.
For instance, some customers purchase Layer-1 (i.e., transport) services from the service provider, some purchase Layer 2 (e.g., ATM) services, while others purchase Layer-3 (IP/MPLS) services. The service provider realizes these services by a stack of network layers located within one or more network regions. The network layers are commonly arranged according to the switching capabilities of the devices in the networks. So a customer network may be provided on top of the GMPLS-based multi-region/multi-layer network. For example, a Layer-1 service (realized via the network layers of TDM, and/or LSC, and/or FSC regions) may support a Layer-2 network (realized via ATM Virtual Path / Virtual Circuit (VP/VC)), which may itself support a Layer-3 network (IP/MPLS region). The supported data plane relationship is a data plane client-server relationship, where the lower layer provides a service for the higher layer using the data links realized in the lower layer 💅.
Services provided by a GMPLS-based multi-region/multi-layer network are referred to as "multi-region/multi-layer network services". For example, legacy IP and IP/MPLS networks can be supported on top of multi-region/multi-layer networks. It has to be emphasized that delivery of such diverse services is a strong motivator for the deployment of multi-region/multi-layer networks 🫶.
A customer network may be provided on top of a server GMPLS-based MRN/MLN which is operated by a service provider. For example, a pure IP and/or an IP/MPLS network can be provided on top of GMPLS-based packet-over-optical networks [RFC5146]. The relationship between the networks is a client/server relationship, and such services are referred to as "MRN/MLN services". In this case, the customer network may form part of the MRN/MLN or may be partially separated, for example, to maintain separate routing information but retain common signaling 🎀.
3.3. Vertical and Horizontal Interaction and Integration 🌸
Vertical interaction is defined as the collaborative mechanisms within a network element that is capable of supporting more than one layer or region and of realizing the client/server relationships between those layers or regions. Protocol exchanges between two network controllers managing different regions or layers are also a vertical interaction. Integration of these interactions as part of the control plane is referred to as vertical integration. So this refers to the collaborative mechanisms within a single control plane instance driving multiple network layers, whether or not those layers are part of the same region. This concept is useful for constructing a framework that facilitates efficient network resource usage and rapid service provisioning in carrier networks based on multiple layers, switching technologies, or ISCs 🧚.
Horizontal interaction is defined as the protocol exchange between network controllers that manage transport nodes within a given layer or region. For instance, the control plane interaction between two TDM network elements switching at OC-48 is an example of horizontal interaction. GMPLS protocol operations handle horizontal interactions within the same routing area. When the interaction takes place across a domain boundary, such as between two routing areas within the same network layer, it is evaluated as part of the inter-domain work [RFC4726], and it is referred to as horizontal integration. So horizontal integration refers to the collaborative mechanisms between network partitions and/or administrative divisions such as routing areas or autonomous systems 🦋.
This distinction needs further clarification when administrative domains match layer/region boundaries. Horizontal interaction is extended to cover such cases. For example, the collaborative mechanisms in place between two LSC areas relate to horizontal integration. On the other hand, the collaborative mechanisms in place between a PSC (e.g., IP/MPLS) domain and a separate TDM-capable (e.g., VC4 Synchronous Digital Hierarchy (SDH)) domain over which it operates are part of horizontal integration, while they can also be seen as a first step towards vertical integration 🤭.
3.4. Motivation 💖
The applicability of GMPLS to multiple switching technologies provides a unified control and management approach for both LSP provisioning and recovery. Indeed, one of the main motivations for unifying the capabilities and operations of the GMPLS control plane is the desire to support multi-LSP-region [RFC4206] routing and TE capabilities. For instance, this enables effective network resource utilization of both the Packet/Layer2 LSP regions and the TDM or Lambda LSP regions in high-capacity networks ✨.
The rationales for GMPLS-controlled multi-layer/multi-region networks are summarized below:
- The maintenance of multiple instances of the control plane on devices hosting more than one switching capability not only increases the complexity of the interactions between control plane instances, but also increases the total amount of processing each individual control plane instance must handle 😩.
- The unification of the addressing spaces helps in avoiding multiple identifiers for the same object (a link, for instance, or more generally, any network resource). On the other hand, such aggregation does not impact the separation between the control plane and the data plane 🎀.
- By maintaining a single routing protocol instance and a single TE database per LSR, a unified control plane model removes the requirement to maintain a dedicated routing topology per layer, and therefore does not mandate a full mesh of routing adjacencies as is the case with overlaid control planes 🧠.
- The collaboration between technology layers where the control channel is associated with the data channel (e.g., packet/framed data planes) and technology layers where the control channel is not directly associated with the data channel (SONET/SDH, G.709, etc.) is facilitated by the capability within GMPLS to associate in-band control plane signaling to the IP terminating interfaces of the control plane 🌈.
- Resource management and policies to be applied at the edges of such an MRN/MLN are made simpler (fewer control-to-management interactions) and more scalable (through the use of aggregated information) 💅.
- Multi-region/multi-layer traffic engineering is facilitated as TE links from distinct regions/layers are stored within the same TE Database 👑.
4. Key Concepts of GMPLS-Based MLNs and MRNs 🦋
A network comprising transport nodes with multiple data plane layers of either the same ISC or different ISCs, controlled by a single GMPLS control plane instance, is called a multi-layer network (MLN). A subset of MLNs consists of networks supporting LSPs of different switching technologies (ISCs). A network supporting more than one switching technology is called a multi-region network (MRN) 💜.
4.1. Interface Switching Capability ✨
Okay so the Interface Switching Capability (ISC) is GMPLS's way of handling lots of different switching technologies in one unified system 💅 [RFC4202]. Every ISC is identified by a switching type 🦋
A switching type (also called the switching capability type) describes what a node can forward for a particular data plane technology, and it uniquely identifies a network region 🌸 The ISC types (and so the regions) are: PSC, L2SC, TDM capable, LSC, and FSC. Each end of a data link (more precisely, each interface that connects a data link to a node) in a GMPLS network gets its own ISC, so it's giving organized 💖
The ISC value gets advertised as part of the Interface Switching Capability Descriptor (ISCD) attribute (a sub-TLV) of a TE link end tied to a specific link interface [RFC4202]. The ISCD holds more than just the ISC, too: it also has the encoding type, the bandwidth granularity, and the unreserved bandwidth for each of eight priorities that LSPs can be set up at ✨ Also, the ISCD does not "identify" network layers. It characterizes information linked to one or more network layers, which is a subtle difference but a big deal 🙈
TE link end advertisements can contain multiple ISCDs. That can be read as advertising a multi-layer (or multi-switching-capable) TE link end, meaning the TE link (and so the TE link end) exists in multiple layers at once 🌈
4.2. Multiple Interface Switching Capabilities 🧚
In an MLN, network elements can be single-switching-type-capable nodes or multi-switching-type-capable nodes 💜 Single-switching-type-capable nodes all advertise the same ISC value in their ISCD sub-TLV(s) to describe the termination capabilities of each of their TE link(s). That case is covered in [RFC4202], so go check there if you want the full tea ☕
Multi-switching-type-capable LSRs are sorted into "simplex" and "hybrid" nodes. The sorting depends on how they advertise their multiple ISCs 🎀
- A simplex node can terminate data links with different switching capabilities, as long as each data link comes in through its own separate link interface. So it advertises several TE links, each with one ISC value carried in its ISCD sub-TLV (following the rules in [RFC4206]). An example is an LSR with PSC and TDM links, each connected through a separate interface 💅
- A hybrid node can terminate data links with different switching capabilities when those data links all connect through the same interface. So it advertises a single TE link containing more than one ISCD, each with a different ISC value. For example, a node might terminate PSC and TDM data links and then interconnect those external links through internal links. The external interfaces on that node have both PSC and TDM capabilities 🔥
TE link advertisements from a simplex or hybrid node may also need to share info about the node's internal adjustment capabilities between the switching technologies it supports 🦋 "Adjustment" refers to a hybrid node's ability to interconnect the different switching capabilities it offers through its external interfaces ✨ Knowing the adjustment capabilities of nodes across the network lets the path computation process build an end-to-end multi-layer or multi-region path. That path can include links with different switching capabilities, joined by LSRs that can adapt (i.e., adjust) the signal between those links. Main character planning, honestly 👑
4.2.1. Networks with Multi-Switching-Type-Capable Hybrid Nodes 🌸
This kind of network has at least one hybrid node, zero or more simplex nodes, and a set of single-switching-type-capable nodes 💖
Figure 1 shows an example hybrid node 🧚 The hybrid node has two switching elements (matrices), which support, for instance, TDM and PSC switching respectively. The node terminates a PSC link and a TDM link (Link1 and Link2, respectively), and it has an internal link connecting the two switching elements 🫶
The two switching elements are interconnected internally in a way that lets the node terminate some of the resources of, say, Link2 and provide adjustment for PSC traffic sent and received over the PSC interface (#b). GMPLS models this by connecting the local end of Link2 to the TDM switching element through an extra interface that handles the termination/adjustment function 🙈 There are two possible ways to set up PSC LSPs through the hybrid node. The available resource advertisement (Unreserved and Min/Max LSP Bandwidth) should cover both of those methods 💅
.............................
: Network element :
: -------- :
: | PSC | :
Link1 -------------<->--|#a | :
: | | :
: +--<->---|#b | :
: | -------- :
: | ---------- :
TDM : +--<->--|#c TDM | :
+PSC : | | :
Link2 ------------<->--|#d | :
: ---------- :
:............................Figure 1. Hybrid node.
4.3. Integrated Traffic Engineering (TE) and Resource Control 👑
In GMPLS-based multi-region/multi-layer networks, TE links can be merged into a single Traffic Engineering Database (TED) that one control plane instance uses 🌈 Since that TED has info about every layer of every region in the network, a path crossing multiple layers (and maybe multiple regions) can be computed from it. So optimizing network resources across the layers of one region, and across multiple regions, becomes doable ✨
These concepts let one network layer run over the topology (the TE links) that other network layers provide. For example, a lower-layer LSC LSP can carry PSC LSPs on top of it 🦋 That gives a greater degree of control and interworking, including (but not limited to):
- Dynamic establishment of Forwarding Adjacency (FA) LSPs [RFC4206] (see Sections 4.3.2 and 4.3.3). 🧚
- Provisioning of end-to-end LSPs with dynamic triggering of FA LSPs. 💖
Heads up, though! In a multi-layer/multi-region network that includes multi-switching-type-capable nodes, an explicit route used to set up an end-to-end LSP can name nodes in different layers or regions. In that case, a mechanism to control the dynamic creation of FA-LSPs may be required (see Sections 4.3.2 and 4.3.3) 🙈
There's a full spectrum of options for controlling how FA-LSPs get dynamically established 🌸 The process can be governed by a policy, which a management component may set, and that policy may require the management plane to be consulted when the FA-LSP is established. Or the FA-LSP can be established at the request of the control plane with no management control at all 💅
4.3.1. Triggered Signaling 🎀
When an LSP crosses the boundary from an upper layer to a lower layer, it may be nested into a lower-layer FA-LSP that crosses the lower layer 💜 From a signaling perspective there are two ways to set up that lower-layer FA-LSP: static (pre-provisioned) and dynamic (triggered). A pre-provisioned FA-LSP may be started by the operator or automatically, using features like TE auto-mesh [RFC4972]. If such a lower-layer LSP doesn't already exist, the LSP may be established dynamically. That mechanism is called "triggered signaling" 🔥
4.3.2. FA-LSPs 🦋
Once an LSP is created across a layer, from one layer border node to another, it can be used as a data link in an upper layer ✨
It can also be advertised as a TE link, so other nodes can treat the LSP as a TE link in their path computation [RFC4206]. An LSP created either statically or dynamically by one instance of the control plane, and advertised as a TE link into that same instance, is called a Forwarding Adjacency LSP (FA-LSP). The FA-LSP is advertised as a TE link, and that TE link is called a Forwarding Adjacency (FA) 🧚 An FA has the special trait of not needing a routing adjacency (peering) between its end points, while still guaranteeing control plane connectivity between the FA-LSP end points through a signaling adjacency. That makes an FA a really useful and powerful tool for scaling GMPLS-TE capable networks, since multiple higher-layer LSPs can be nested (aggregated) over a single FA-LSP 💖
Aggregating LSPs creates a vertical (nested) LSP hierarchy 🌈 A set of FA-LSPs across or within a lower layer can be used during path selection by a higher-layer LSP. Higher-layer LSPs can also be carried over dynamic data links realized through LSPs, just like they're carried over any "regular" static data links 💅 This needs LSPs to be nested through a hierarchical process [RFC4206]. The TED holds a set of LSP advertisements from different layers, identified by the ISCD inside the TE link advertisement associated with each LSP [RFC4202] 👑
If a lower-layer LSP isn't advertised as an FA, it can still carry higher-layer LSPs across the lower layer 🫶 For instance, if the LSP is set up with triggered signaling, it will carry the higher-layer LSP that caused the trigger. The lower layer also stays available for other higher-layer LSPs arriving at the boundary ✨
Under some circumstances, it may be useful to control whether LSPs get advertised as FAs during their signaling establishment [DYN-HIER] 🌸
4.3.3. Virtual Network Topology (VNT) 🦋
okay so a set of one or more lower-layer LSPs gives the upper layers a heads-up for efficient path handling, aka a virtual network topology (VNT) 🗺️ bestie, a single lower-layer LSP is just the special-case version of a VNT, no cap. Like, a bunch of LSPs that each ride on an LSC LSP will hand a VNT to the layers of a PSC region (as long as that PSC region is connected to the LSC region) ✨. The VNT gets built by setting up or tearing down those lower-layer LSPs, and with GMPLS signaling and routing protocols it can adapt to whatever traffic demands show up 💅.
From the upper layer's point of view, a lower-layer LSP shows up as a TE link in the VNT 🎀. And the routes the lower-layer LSPs take are hidden from that upper layer, whether or not the diversely-routed lower-layer LSPs actually get used. So the VNT makes upper-layer routing and traffic engineering way simpler, because the messy routes underneath are literally out of sight 🙈. BUT, and this is a big but, hiding those routes can also lose important info that the higher-layer LSPs need in order to be reliable 😭.
Here's the tea: the routing and TE in the IP/MPLS layer usually doesn't think about how its IP/MPLS TE links were formed from optical paths routed in the fiber layer 🔌. Two optical paths can share the same fiber link down below, which means they can both die if that fiber gets cut 💀. So the shared risk properties of the TE links in the VNT must be made available to the higher layer during path computation 🫶. And the VNT should be designed so that a single fiber cut can't bisect it ✨. (These issues get addressed later in this document, so stay tuned 💜.)
Reconfiguring the VNT can be triggered by traffic demand changes, topology configuration changes, signaling requests from the upper layer, and network failures 🌈. For example, if you reconfigure the VNT based on the traffic demand between source and destination node pairs, you can optimize network performance factors like maximum link utilization and residual capacity 🔥. The way this works is by computing the new VNT from the traffic demand matrix and, optionally, from the current VNT 🧚. The exact details are out of scope for this document, but the method can be tailored to the service provider's policy on performance and quality of service (delay, loss/disruption, utilization, residual capacity, reliability) 👑.
5. Requirements ✨
5.1. Handling Single-Switching and Multi-Switching-Type-Capable Nodes
The MRN/MLN can be made up of single-switching-type-capable nodes and multi-switching-type-capable nodes 🌸. The path computation mechanism in the MLN should be able to compute paths made of any combination of those nodes 💅.
Both single-switching-type-capable and multi-switching-type-capable (simplex or hybrid) nodes could play the role of layer boundary 🦋. So MRN/MLN path computation should handle TE topologies built from any combination of nodes, no matter what mix you've got 🫶.
5.2. Advertisement of the Available Adjustment Resources
A hybrid node should maintain resources on its internal links (the links needed for vertical integration between layers) 🎀. Likewise, path computation elements should be ready to use info about the availability of termination and adjustment resources as a constraint in MRN/MLN path computations 🧚. Why? Because that lowers the odds that setting up a higher-layer LSP gets blocked by a lack of termination/adjustment resources in the lower layers 😭.
Advertising a node's MRN adjustment capabilities (the ability to terminate LSPs of lower regions and forward traffic in upper regions) is REQUIRED 🔥, since it's critical info when you're doing multi-region path computation 👑.
The path computation mechanism should also cover the case where upper-layer links that are directly connected to upper-layer switching elements coexist with the ones connected through internal links between an upper-layer element and a lower-layer element (see Section 4.2.1) 🌈.
5.3. Scalability
The MRN/MLN relies on unified routing and traffic engineering models 🌟.
- Unified routing model: By maintaining a single routing protocol instance and a single TE database per LSR, a unified control plane model removes the requirement to maintain a dedicated routing topology per layer. It also doesn't mandate a full mesh of routing adjacencies per layer 💖.
- Unified TE model: The TED in each LSR gets populated with TE links from all layers of all regions (TE link interfaces on multiple-switching-type-capable LSRs can be advertised with multiple ISCDs). This can bump up the amount of info that has to be flooded and stored across the network 📈.
On top of that, path computation times, which matter a lot during restoration, depend on the size of the TED 😭.
So, MRN/MLN routing mechanisms MUST be designed to scale well as any of the following increase:
- Number of nodes
- Number of TE links (including FA-LSPs)
- Number of LSPs
- Number of regions and layers
- Number of ISCDs per TE link
Also, the design of the routing protocols MUST NOT prevent TE information filtering based on ISCDs 🙅♀️. The path computation mechanism and the signaling protocol SHOULD be able to operate on partial TE information 🫶.
Since TE links can advertise multiple Interface Switching Capabilities (ISCs), you can limit the number of links (by combination) using specific topological maps called VNTs (Virtual Network Topologies) 🗺️. And bringing in these virtual topological maps leads us to the concept of emulating data plane overlays 🦋.
5.4. Stability
Path computation depends on the network topology and the associated link state 🧠. An upper layer's path computation stability can take a hit if the VNT changes frequently, and/or if the status and TE parameters of links in the VNT change frequently (the TE metric, for instance) 📉. In this context, robustness of the VNT means its capability to smooth out changes that happen and keep them from spreading into higher layers 🛡️. Changes to the VNT can come from creating, deleting, or modifying LSPs 🔄.
Protocol mechanisms MUST be provided to enable creation, deletion, and modification of LSPs triggered through operational actions 🔧. Protocol mechanisms SHOULD be provided to enable similar functions triggered by adjacent layers 🎀. Protocol mechanisms MAY be provided to enable similar functions that adapt to environment changes like traffic demand changes, topology changes, and network failures 🌈. Routing robustness should be traded off against adaptability to those changes ⚖️.
5.5. Disruption Minimization
When you reconfigure the VNT according to a change in traffic demand, the upper-layer LSP might get disrupted 😬. That disruption to the upper layers must be minimized 🫶.
When residual resource drops to a certain level, some lower-layer LSPs may be released according to local or network policies 📉. There's a trade-off here: minimizing the amount of resource reserved in the lower layer versus disrupting higher-layer traffic (i.e., moving traffic to other TE-LSPs so some LSPs can be released) 🤔. That traffic disruption may be allowed, but it MUST be under the control of policy that the operator can configure 👑. And any repositioning of traffic MUST be as non-disruptive as possible (for example, using make-before-break) 💅.
5.6. LSP Attribute Inheritance
TE link parameters should be inherited from the parameters of the LSP that provides the TE link, and so from the TE links in the lower layer that the LSP traverses 🧚.
These include:
- Interface Switching Capability
- TE metric
- Maximum LSP bandwidth per priority level
- Unreserved bandwidth for all priority levels
- Maximum reservable bandwidth
- Protection attribute
- Minimum LSP bandwidth (depending on the switching capability)
- SRLG
Inheritance rules must be applied based on specific policies 📋. Extra attention should go to inheriting the TE metric (which may be something other than a strict sum of the metrics of the component TE links at the lower layer), the protection attributes, and the SRLG 🔍.
As we covered earlier, hiding the routes of the lower-layer LSPs may lose important info needed to make LSPs in the higher-layer network reliable 😭. SRLGs can be used to identify which lower-layer LSPs share the same failure risk, so the potential risk of the VNT becoming disjoint can be minimized, and resource-disjoint protection paths can be set up in the higher layer 🛡️. How to inherit SRLG info from the lower layer up to the upper layer needs more discussion and is out of scope for this document 💜.
5.7. Computing Paths with and without Nested Signaling 🧚
okay so path computation can totally take LSP region and layer boundaries into account when it's figuring out a path for an LSP 🗺️ it's giving map-reading energy. Path computation may restrict the path an LSP takes to only the links whose interface switching capability is PSC 💅 For example, say a TDM-LSP is routed over a topology made of TE links from the same TDM layer. When calculating its path, the TED may be filtered so it only includes links where both ends include the requested LSP switching type. That's how hierarchical routing gets done: a TED filtered by switching capability (aka a particular layer) 🎀
If triggered signaling is allowed, the path computation mechanism may produce a route with multiple layers/regions 🦋 The path gets computed across those layers/regions even if it isn't "connected" in the same layer where the endpoints live. Note that we're assuming triggered signaling will be invoked to make the path "connected" when the upper-layer signaling request shows up at the boundary node 🫶
The upper-layer signaling request MAY contain an ERO (Explicit Route Object) that only includes hops in the upper layer 💖 In that case, the boundary node handles triggered creation of the lower-layer FA-LSP using a path of its choice, or picks any available lower-layer LSP to act as a data link for the higher layer. This is the move for environments where the TED is filtered in the higher layer, where separate routing instances run per layer, or where administrative policies stop the higher layer from specifying paths through the lower layer 👑
Obviously, if the lower-layer LSP has been advertised as a TE link (virtual or real) into the higher layer, then the higher-layer signaling request MAY contain the TE link identifier and so point at the lower-layer resources to use. But in this case, the path of the lower-layer LSP can be dynamically changed by the lower layer at any time 🌀
Alternatively, the upper-layer signaling request MAY contain an ERO specifying the lower-layer FA-LSP route. In this case, the boundary node MAY decide whether it should use the path contained in the strict ERO or re-compute the path within the lower layer 🙈
Even in the case that the lower-layer FA-LSPs are already established, a signaling request may also be encoded as a loose ERO. In this situation, it's up to the boundary node to decide whether to create a new lower-layer FA-LSP or use an existing one 🌸
The lower-layer FA-LSP can be advertised just as an FA-LSP in the upper layer, or an IGP adjacency can be brought up on the lower-layer FA-LSP ✨
5.8. LSP Resource Utilization 💜
Resource usage in all layers should be optimized as a whole (i.e., across all layers), in a coordinated manner (i.e., taking all layers into account). The number of lower-layer LSPs carrying upper-layer LSPs should be minimized (note that multiple LSPs may be used for load balancing). Lower-layer LSPs that could have their traffic re-routed onto other LSPs are unnecessary and should be avoided 🍓
5.8.1. FA-LSP Release and Setup 🧹
If there's low traffic demand, some FA-LSPs that don't carry any higher-layer LSP may be released so their lower-layer resources get freed up for other uses. Note that if a small fraction of an FA-LSP's bandwidth is still in use, the nested LSPs can also be re-routed to other FA-LSPs (optionally using the make-before-break technique) to completely free up the FA-LSP. Or, unused FA-LSPs may be kept around for future use. Releasing or retaining underutilized FA-LSPs is a policy decision 📋
As part of the re-optimization process, the solution MUST allow rerouting of an FA-LSP while keeping interface identifiers of corresponding TE links unchanged. Further, this process MUST be possible while the FA-LSP is carrying traffic (higher-layer LSPs) with minimal disruption to the traffic 🔥
Additional FA-LSPs may also be created based on policy, which might consider residual resources and the change of traffic demand across the region. Making new FA-LSPs can boost network performance, like maximum residual capacity may increase 📈
As the number of FA-LSPs grows, the residual resources may decrease. In this case, re-optimization of FA-LSPs may be invoked according to policy 🌈
Any solution MUST include measures to protect against network destabilization caused by the rapid setup and teardown of LSPs as traffic demand varies near a threshold 💀
Signaling of lower-layer LSPs SHOULD include a mechanism to rapidly advertise the LSP as a TE link and to coordinate into which routing instances the TE link should be advertised 🫶
5.8.2. Virtual TE Links 🦄
It may be considered disadvantageous to fully instantiate (i.e., pre-provision) the set of lower-layer LSPs that provide the VNT, since this might reserve bandwidth that could be used for other LSPs in the absence of upper-layer traffic 🙄
However, in order to allow path computation of upper-layer LSPs across the lower layer, the lower-layer LSPs may be advertised into the upper layer as though they had been fully established, but without actually establishing them. Such TE links that represent the possibility of an underlying LSP are termed "virtual TE links" ✨ It is an implementation choice at a layer boundary node whether to create real or virtual TE links, and the choice (if available in an implementation) MUST be under the control of operator policy 🎛️ Note that there's no requirement to support the creation of virtual TE links, since real TE links (with established LSPs) may be used. Even if there are no TE links (virtual or real) advertised to the higher layer, it's possible to route a higher-layer LSP into a lower layer on the assumption that proper hierarchical LSPs in the lower layer will be dynamically created (triggered) as needed 🧚
If an upper-layer LSP that makes use of a virtual TE link is set up, the underlying LSP MUST be immediately signaled in the lower layer ⚡
If virtual TE links are used in place of pre-established LSPs, the TE links across the upper layer can remain stable using pre-computed paths, while wastage of bandwidth within the lower layer and unnecessary reservation of adaptation resources at the border nodes can be avoided 🌸
The solution SHOULD provide operations to facilitate the build-up of such virtual TE links, taking into account the (forecast) traffic demand and available resources in the lower layer 🛠️
Virtual TE links can be added, removed, or modified dynamically (by changing their capacity) according to the change of the (forecast) traffic demand and the available resources in the lower layer. It MUST be possible to add, remove, and modify virtual TE links in a dynamic way 💪
Any solution MUST include measures to protect against network destabilization caused by the rapid changes in the VNT as traffic demand varies near a threshold 🚨
The concept of the VNT can be extended to allow the virtual TE links to form part of the VNT. The combination of the fully provisioned TE links and the virtual TE links defines the VNT provided by the lower layer. The VNT can be changed by setting up and/or tearing down virtual TE links as well as by modifying real links (i.e., the fully provisioned LSPs). How to design the VNT and how to manage it are out of scope of this document 🙃
In some situations, selective advertisement of the preferred connectivity among a set of border nodes between layers may be appropriate. Further decreasing the number of advertisements of the virtual connectivity can be achieved by abstracting the topology (between border nodes) using models similar to those detailed in [RFC4847] 🧠
5.9. Verification of the LSPs 🔍
When a lower-layer LSP is established for use as a data link by a higher layer, the LSP may be verified for correct connectivity and data integrity before it is made available for use. Such mechanisms are data-technology-specific and are beyond the scope of this document, but the GMPLS protocols SHOULD provide mechanisms for the coordination of data link verification 🫧
5.10. Management 🎀
Okay so an MRN/MLN needs solid management tools 🔧 Operators need the same level of control and management over switches and links that they'd have in a single-layer or single-region network, no drama 💅
We can look at two different operational models: (1) per-layer management entities and (2) cross-layer management entities 🧚
Starting with per-layer management entities: the MLN can be managed entirely as separate layers, but ngl that kinda defeats the whole point of defining a single multi-layer network 🙈 In that setup, each layer gets its own management system, and those systems have no idea the layers are tightly coupled in the control plane. Now, when LSPs get set up automatically because of control plane requests from other layers (like triggered signaling), the management apps have to register the new LSPs and the drop in available network resources. The layer boundary nodes need to do most of the heavy lifting by reporting that activity to the management apps 📣
A much more likely scenario is a closer coupling of the layer management systems with cross-layer management entities ✨ That could look like a unified management system that can operate multiple layers, or a meta-management system that coordinates separate management systems, each handling its own layer. The unified version might only be possible once new management systems get built, while the meta version is doable by coordinating the tools that already exist 🫶
Also, when a layer boundary is also an administrative boundary, it is highly unlikely there will be unified multi-layer management 😭 The layers will be managed separately by their own administrative entities. There may still be some "leakage" of information between the administrations so the MLN can actually work. For example, the management system in the lower-layer network might automatically send out reports on resource availability (alongside TE routing information) and alarm events 📊
This whole discussion is basically a look at how a VNT might be managed and operated 🦋 As noted in Section 5.8, how to design and manage a VNT is out of scope for this document. Just know that a VNT is a client-layer construct built from server-layer resources. That means running a VNT is a collaborative effort between the layers. It's still possible when the layers come from different administrations, but then it might also have commercial implications 💜
MIB modules exist for modeling and managing GMPLS networks [RFC4802] [RFC4803] 🌸 Some GMPLS deployments may choose to use MIB modules to operate individual network layers. In those cases, operators may want to coordinate the layers through another MIB module that could be developed. Multi-layer protocol solutions (meaning solutions where a single control plane instance operates in more than one layer) SHOULD be manageable through MIB modules 🎀 Another MIB module to coordinate multiple network layers with this control plane MIB module may be produced.
OAM (Operations and Management) tools are super important for successfully deploying any network 🔥
The OAM requirements for GMPLS networks are described in [GMPLS-OAM] 📖 That document points out that protocol solutions for individual network layers should include OAM mechanisms or make use of the OAM features built into the physical media of those layers. Further discussion of individual-layer OAM is out of scope for this document.
When you run OAM in an MLN, you have to think about how to provide OAM for end-to-end LSPs that cross layer boundaries (which may also be administrative boundaries) 🌈 You also have to figure out how to coordinate errors and alarms detected in a server layer that need to be reported to the client layer. These operational choices MUST be left open to the service provider, so MLN protocol solutions MUST include the following features:
- Within the context and technology capabilities of the highest technology layer of an LSP (i.e., the technology layer of the first hop), it MUST be possible to enable end-to-end OAM on an MLN LSP. This function looks like normal LSP-based OAM [GMPLS-OAM] to the ingress LSP. But at layer boundaries, depending on the technique used to span the lower layers, client-layer OAM operations may need to be mapped to server-layer OAM operations. Most of these requirements depend heavily on the OAM facilities of the data plane technologies of the client and server layers. However, control plane mechanisms used in the client layer per [GMPLS-OAM] MUST map and enable OAM in the server layer. 💅
- OAM operation enabled per [GMPLS-OAM] in a client layer for an LSP MUST operate for that LSP along its entire length. So if an LSP crosses a domain of a lower-layer technology, the client-layer OAM operation must operate seamlessly within the client layer at both ends of the client-layer LSP. 🦋
- OAM functions operating within a server layer MUST be controllable from the client layer, so that the server-layer LSP(s) supporting a client-layer LSP have OAM enabled at the request of the client layer. That control SHOULD be subject to policy at the layer boundary, just like automatic provisioning and LSP requests to the server layer are subject to policy. 🔐
- The status, including errors and alarms applicable to a server-layer LSP, MUST be available to the client layer. This information SHOULD be configurable so it gets automatically notified to the client layer at the layer boundary, and it SHOULD be subject to policy so the server layer can filter or hide information supplied to the client layer. On top of that, the client layer SHOULD be able to choose to not receive any or all of that information. 🙈
The interface between layers lives inside network nodes, so it's not necessarily the subject of a protocol specification 👀 Implementations MAY use standardized techniques (such as MIB modules) to convey status information (such as errors and alarms) between layers, but that's out of scope for this document.
6. Security Considerations 🔐
Okay, security time, and I'm taking it seriously 😤 The MLN/MRN architecture does not introduce any new security requirements over the general GMPLS architecture described in [RFC3945]. Additional security considerations for MPLS and GMPLS networks are described in [MPLS-SEC] 🛡️
BUT, where the separate layers of an MLN/MRN network are operated as different administrative domains, extra security considerations may apply to the mechanisms for allowing LSP setup across one or more layer boundaries, for triggering lower-layer LSPs, or for VNT management 🚨 Similarly, you may need to think about how much information gets shared between administrative domains, and the trade-off between multi-layer TE and the confidentiality of each administrative domain's information. Lowkey a big deal 💀
It is expected that solution documents will include a full analysis of the security issues that any protocol extensions introduce ✨
7. Acknowledgements 🫶
The authors want to thank Adrian Farrel and the participants of ITU-T Study Group 15, Question 14 for their careful review 🌸 They also want to thank the IESG review team for their rigorous review, with special thanks to Tim Polk, Miguel Garcia, Jari Arkko, Dan Romascanu, and Dave Ward 👑
8. References 📚
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3945] Mannie, E., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Architecture", RFC 3945, October 2004.
[RFC4202] Kompella, K., Ed., and Y. Rekhter, Ed., "Routing
Extensions in Support of Generalized Multi-Protocol Label
Switching (GMPLS)", RFC 4202, October 2005.
[RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP)
Hierarchy with Generalized Multi-Protocol Label Switching
(GMPLS) Traffic Engineering (TE)", RFC 4206, October
2005.
[RFC4397] Bryskin, I. and A. Farrel, "A Lexicography for the
Interpretation of Generalized Multiprotocol Label
Switching (GMPLS) Terminology within the Context of the
ITU-T's Automatically Switched Optical Network (ASON)
Architecture", RFC 4397, February 2006.
[RFC4726] Farrel, A., Vasseur, J.-P., and A. Ayyangar, "A Framework
for Inter-Domain Multiprotocol Label Switching Traffic
Engineering", RFC 4726, November 2006.8.2. Informative References
[DYN-HIER] Shiomoto, K., Rabbat, R., Ayyangar, A., Farrel, A. and
Z. Ali, "Procedures for Dynamically Signaled Hierarchical
Label Switched Paths", Work in Progress, February 2008.
[MRN-EVAL] Le Roux, J.L., Ed., and D. Papadimitriou, Ed.,
"Evaluation of existing GMPLS Protocols against Multi
Layer and Multi Region Networks (MLN/MRN)", Work in
Progress, December 2007.
[RFC5146] Kumaki, K., Ed., "Interworking Requirements to Support
Operation of MPLS-TE over GMPLS Networks", RFC 5146,
March 2008.
[MPLS-SEC] Fang, L., Ed., "Security Framework for MPLS and GMPLS
Networks", Work in Progress, February 2008.
[RFC4802] Nadeau, T., Ed., and A. Farrel, Ed., "Generalized
Multiprotocol Label Switching (GMPLS) Traffic Engineering
Management Information Base", RFC 4802, February 2007.
[RFC4803] Nadeau, T., Ed., and A. Farrel, Ed., "Generalized
Multiprotocol Label Switching (GMPLS) Label Switching
Router (LSR) Management Information Base", RFC 4803,
February 2007.
[RFC4847] Takeda, T., Ed., "Framework and Requirements for Layer 1
Virtual Private Networks", RFC 4847, April 2007.
[RFC4972] Vasseur, JP., Ed., Leroux, JL., Ed., Yasukawa, S.,
Previdi, S., Psenak, P., and P. Mabbey, "Routing
Extensions for Discovery of Multiprotocol (MPLS) Label
Switch Router (LSR) Traffic Engineering (TE) Mesh
Membership", RFC 4972, July 2007.
[GMPLS-OAM] Nadeau, T., Otani, T. Brungard, D., and A. Farrel, "OAM
Requirements for Generalized Multi-Protocol Label
Switching (GMPLS) Networks", Work in Progress, October
2007.9. Contributors' Addresses 🧚
Eiji Oki
NTT Network Service Systems Laboratories
3-9-11 Midori-cho, Musashino-shi
Tokyo 180-8585
Japan
Phone: +81 422 59 3441
EMail: oki.eiji@lab.ntt.co.jp
Ichiro Inoue
NTT Network Service Systems Laboratories
3-9-11 Midori-cho, Musashino-shi
Tokyo 180-8585
Japan
Phone: +81 422 59 3441
EMail: ichiro.inoue@lab.ntt.co.jp
Emmanuel Dotaro
Alcatel-Lucent
Route de Villejust
91620 Nozay
France
Phone: +33 1 3077 2670
EMail: emmanuel.dotaro@alcatel-lucent.frAuthors' Addresses ✨
okay so here are the authors, bestie 🫶 their contact details are right below, and you can absolutely reach out to them 💅
Kohei Shiomoto 🌸
Kohei Shiomoto
NTT Network Service Systems Laboratories
3-9-11 Midori-cho, Musashino-shi
Tokyo 180-8585
Japan
EMail: shiomoto.kohei@lab.ntt.co.jpDimitri Papadimitriou 🎀
Dimitri Papadimitriou
Alcatel-Lucent
Copernicuslaan 50
B-2018 Antwerpen
Belgium
Phone : +32 3 240 8491
EMail: dimitri.papadimitriou@alcatel-lucent.beJean-Louis Le Roux 🦋
Jean-Louis Le Roux
France Telecom R&D
Av Pierre Marzin
22300 Lannion
France
EMail: jeanlouis.leroux@orange-ftgroup.comMartin Vigoureux 🧚
Martin Vigoureux
Alcatel-Lucent
Route de Villejust
91620 Nozay
France
Phone: +33 1 3077 2669
EMail: martin.vigoureux@alcatel-lucent.frDeborah Brungard 👑
Deborah Brungard
AT&T
Rm. D1-3C22 - 200
S. Laurel Ave.
Middletown, NJ 07748
USA
Phone: +1 732 420 1573
EMail: dbrungard@att.comFull Copyright Statement 💖
okay the legal bit, and it matters 🙈 this is the copyright notice for the document. the IETF Trust holds the copyright, and it's Copyright (C) The IETF Trust (2008).
this document is covered by the rights, licenses and restrictions in BCP 78. except for what that BCP says, the authors keep all their rights.
the document and the info in it are given to you as-is, and the contributor, the organization they represent or are sponsored by (if any), the Internet Society, the IETF Trust and the Internet Engineering Task Force say they're not making any guarantees. that covers any warranty that using the info won't infringe anyone's rights, and any implied warranty of merchantability or fitness for a particular purpose.
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, THE IETF TRUST 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 side on whether any IPR (intellectual property rights) or other claimed rights are valid or how far they reach. that covers any rights that might apply to building or using the tech in this doc, and whether any license for them is actually available. it also doesn't claim it has searched for those rights on its own. 💅
if you want the procedures for rights in RFC documents, look in BCP 78 and BCP 79.
copies of IPR disclosures sent to the IETF Secretariat, any promises of licenses, and the results of any attempt to get a general license or permission to use those rights for implementers or users of this spec, can all be found in the IETF's online IPR repository at http://www.ietf.org/ipr.
and last but not least 🫶 the IETF invites anyone to let it know about any copyrights, patents, patent applications or other proprietary rights that might cover technology needed to implement this standard. send that info to ietf-ipr@ietf.org.
📦 where this page comes from
- ietf: rfc5212 2008-07
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms