RFC 4139

Requirements for Generalized MPLS (GMPLS) Signaling Usage and Extensions for Automatically Switched Optical Network (ASON)

📅 published July 2005, from ietf

RFC 4139: Requirements for Generalized MPLS (GMPLS) Signaling Usage and Extensions for Automatically Switched Optical Network (ASON) 🎀

Okay bestie, let's start with the title block 💅. This one was written by D. Papadimitriou (Alcatel), J. Drake (Boeing), J. Ash (ATT), A. Farrel (Old Dog Consulting), and L. Ong (Ciena). It's Informational, dated July 2005, so it's giving "here's some info" and not "here's a standard" 🦋. The title block doesn't list anything it obsoletes or updates, so it's not replacing or changing any earlier RFC. 🌸

Status of This Memo

So this memo is info for the Internet community ✨. It doesn't specify an Internet standard of any kind, and distribution is totally unlimited, so share it with everyone 🫶.

Copyright (C) The Internet Society (2005).

Abstract

GMPLS (Generalized Multi-Protocol Label Switching) is a whole suite of protocols that controls different switching technologies and different applications 🧚. That includes requesting TDM (Time Division Multiplexing) connections, like SONET/SDH (Synchronous Optical Network / Synchronous Digital Hierarchy) and OTNs (Optical Transport Networks) 🌈.

This doc is all about the signaling side of GMPLS 📡. It figures out which features the GMPLS signaling protocol needs to cover so it can support an ASON (Automatically Switched Optical Network) 🔥. It also gives a problem statement and extra requirements for GMPLS signaling to handle ASON functionality 💜.

1. Introduction ✨

Okay, so GMPLS is a suite of protocol specs that handles controlling different switching technologies and applications 🌸. That includes requesting TDM connections, like SONET/SDH (see [ANSI-T1.105] and [ITU-T-G.707], respectively) and Optical Transport Networks (see [ITU-T-G.709]) 💖. On top of that, there are some capabilities needed to support ASON control planes (their architecture is defined in [ITU-T-G.8080]) 🫶. These include generic stuff like call and connection separation, plus more specific stuff like support for soft permanent connections 🎀.

This doc focuses on requirements for the signaling part of the GMPLS suite 💅. It covers the functional requirements needed to support ASON, which might lead to more extensions to GMPLS signaling (see [RFC3471] and [RFC3473]) for these capabilities 🦋. Besides the ASON signaling requirements, it also includes GMPLS signaling requirements about backward compatibility (Section 5) 🍓. There's a terminology section in the Appendix too 🧚.

2. Conventions Used in This Document

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 [RFC2119] 🔥.

Even though [RFC2119] explains what these key words mean for protocol specs and implementations, this doc uses them to describe design requirements for protocol extensions 💜.

3. Problem Statement

Okay, so the ASON architecture is all about using an automated control plane for call and connection management services (for a detailed description see [ITU-T-G.8080]) 🌈. It's a reference architecture, meaning it describes functional components, abstract interfaces, and how they interact 🧚.

The ASON model has reference points, which are places where information gets exchanged 💖. There are three of them. The first is between a user (the service requester) and a service provider control domain, also called the user-network interface (UNI) 🎀. The second is between control domains, also called the external network-network interface (E-NNI) 📡. The third is within a control domain, also called the internal network-network interface (I-NNI) 🌸. The I-NNI and E-NNI are between protocol controllers, and they may or may not use transport plane (physical) links 🫶. You must not assume there's a one-to-one relationship between control plane interfaces and transport plane (physical) links, between control plane entities and transport plane entities, or between control plane identifiers and transport plane resources 🙈.

This doc describes requirements for using GMPLS signaling (in particular, [RFC3471] and [RFC3473]) to provide call and connection management (see [ITU-T-G.7713]) 🦋. The functionality it needs to support includes:

  • (a) soft permanent connection capability
  • (b) call and connection separation
  • (c) call segments
  • (d) extended restart capabilities during control plane failures
  • (e) extended label association
  • (f) crankback capability
  • (g) additional error cases

4. Requirements for Extending Applicability of GMPLS to ASON 💅

The sections below go into the signaling protocol requirements for GMPLS to support the ASON functions listed in Section 3 🌈. ASON defines a reference model and functions (information elements) so a protocol can handle end-to-end call and connection support across the interfaces, no matter which protocol or protocols the network uses ✨. ASON doesn't restrict other protocols or the protocol-specific messages used for ASON functions 🧚. So a protocol's support for these ASON functions shall not be restricted by (i.e., must be strictly independent of and agnostic to) any particular choice of UNI, I-NNI, or E-NNI used elsewhere in the network 🔥. For different protocol implementations to interwork, [ITU-T-G.7713] recognizes that an interworking function may be needed 🫶.

For the G.8080 end-to-end call model across different control domains, end-to-end signaling should be facilitated regardless of administrative boundaries, the protocols inside the network, or how connections are realized in any part of the network 💖. That means there needs to be a clear mapping of ASON signaling requests between GMPLS control domains and non-GMPLS control domains 🎀. This doc gives signaling requirements for G.8080 distributed call and connection management based on GMPLS, within a GMPLS-based control domain (I-NNI) and between GMPLS-based control domains (E-NNI) 🌸. It doesn't restrict other (non-GMPLS) protocols from being used inside a control domain or as an E-NNI or UNI 🦋. Interworking aspects of non-GMPLS protocols, such as UNI, E-NNI, or I-NNI, are not in scope for the GMPLS signaling protocol 🙈. That includes mapping non-GMPLS signaling requests to the matching ASON signaling functionality, and supporting non-GMPLS address formats 📡. Interworking aspects are implementation-specific and strictly the responsibility of the interworking function, so they're outside the scope of this doc 💜.

Any User-Network Interface (UNI) that complies with [RFC3473] (e.g., [GMPLS-OVERLAY] and [GMPLS-VPN]) counts as part of the GMPLS suite of protocols and MUST be supported by the ASON GMPLS signaling functionality 🔥.

This doc also describes compatibility aspects of non-GMPLS systems (nodes) inside a GMPLS control domain 🧚. That's the support of GMPLS systems alongside other systems that use other signaling protocols, or some that might not support any signaling protocol at all 🌈. For example, Section 4.5, 'Support for Extended Label Association', covers requirements for when a non-GMPLS-capable sub-network is introduced or when nodes don't support any signaling protocol 🫶.

4.1. Support for Soft Permanent Connection (SPC) Capability 🦋

A Soft Permanent Connection (SPC) is a combo of three things: a permanent connection on the source user-to-network side, a permanent connection on the destination user-to-network side, and a switched connection inside the network 💅. Usually an EMS (Element Management System) or NMS (Network Management System) starts setting up the switched connection by talking to the node that starts it, which is also called the ingress node ✨. Then the ingress node sets up the connection using the distributed GMPLS signaling protocol 🌸. For the SPC, how the EMS/NMS talks to the ingress node is beyond the scope of this doc (just like for every other function described here) 🙈.

The end-to-end connection is created by linking the incoming interface of the ingress node to the switched connection inside the network, plus the outgoing interface of the node that terminates the switched connection (also called the egress node) 🎀. An SPC connection is shown in the figure below. User's node A connects to provider's node B over link #1, user's node Z connects to provider's node Y over link #3, and there's an abstract link #2 between provider's nodes B and Y 🧚. Nodes B and Y are the ingress and egress (respectively) of the network's switched connection 💖.

       ---       ---                 ---       ---
      | A |--1--| B |-----2-//------| Y |--3--| Z |
       ---       ---                 ---       ---

Here, the connections on link #1 and link #3 are both provisioned (permanent connections that might just be simple links) 🌈. Link #2, on the other hand, is set up using the distributed control plane 🔥. So the SPC is made by stitching together links #1, #2, and #3 💜.

So, to support requesting an SPC connection:

  • The GMPLS signaling protocol MUST be capable of indicating the outgoing link and label information used when setting up the destination provisioned connection 🫶.
  • Also, because ASON networks can span multiple domains, the GMPLS signaling protocol SHOULD also support indicating the service level requested for the SPC 💅. When an SPC spans multiple domains, indicating both the source and destination endpoints that control the SPC request MAY be needed 🌸. These MAY be done through the source and destination signaling controller addresses 🦋.

Note that linking the permanent connection and the switched connection at the ingress node is an implementation matter 🙈. It may be under the control of the EMS/NMS, and it's not within the scope of the signaling protocol 📡. So it's outside the scope of this doc too 💜.

4.2. Support for Call and Connection Separation ✨

okay so a call is basically "An association between endpoints that supports an instance of a service" [ITU-T-G.8080] 💅 Think of it as a service running between two end-points, and there can be several calls between the same two. Multiple connections can be tied to one call. The call is an abstract relationship between two users that describes (or verifies) how willing users are to offer or accept service from each other. So a call does NOT carry user traffic at all 🙈 It just sets up the relationship that later connections can be made through.

A call MAY be associated with zero, one, or multiple connections. For the same call, connections MAY be of different types, and each connection MAY exist independently of the others. Each connection gets set up and released with its own separate signaling messages 🦋

The call concept gives way more flexibility in how endpoints set up connections and how networks offer services to users. For example, a call allows:

  • An upgrade strategy for control plane operations, where a call control component (service provisioning) may be separate from the actual nodes hosting the connections (where the connection control component may reside). 🌸
  • Identification of the call initiator (with both network call controller, as well as destination user) prior to connection, which may result in decreasing contention during resource reservation. 👑
  • General treatment of multiple connections, which may be associated for several purposes; for example, a pair of working and recovery connections may belong to the same call. 🫶

To support the call concept, GMPLS signaling SHOULD include a call identification mechanism and SHOULD allow for end-to-end call capability exchange. 🔥

Here's a feasible structure for the call identifier (to guarantee global uniqueness). It MAY concatenate a globally unique fixed ID (e.g., may be composed of country code or carrier code) with an operator specific ID (where the operator specific ID may be composed of a unique access point code, such as source node address, and a local identifier). Other formats SHALL also be possible, depending on the call identification conventions between the parties involved in the call setup process. 🧚

4.3. Support for Call Segments 🎀

As described in [ITU-T-G.8080], call segmentation MAY be applied when a call crosses several control domains. So when the call traverses multiple control domains, an end-to-end call MAY consist of multiple call segments. For a given end-to-end call, each call segment MAY have one or more associated connections, and the number of connections associated with each call segment MAY be different. 💜

The initiating caller talks to the called party through one or more intermediate network call controllers, which sit at control domain boundaries (i.e., at inter-domain reference points, UNI or E-NNI). The call segment capabilities are defined by the policies associated at these reference points. 🌈

This lets different control domains make their own policy-based choices for signaling, concatenation, data plane protection, and control plane driven recovery paradigms. Main character energy for each domain 👑

4.4. Support for Extended Restart Capabilities 💀

Okay, so a bunch of failures can hit the ASON control plane 😭 Here's what [ITU-T-G.8080] requires for control plane failure recovery:

  • Any control plane failure (i.e., single or multiple control channel and/or controller failure and any combination thereof) MUST NOT result in releasing established calls and connections (including the corresponding transport plane connections). 🚫
  • Upon recovery from a control plane failure, the recovered control entity MUST have the ability to recover the status of the calls and the connections established before failure occurrence. 🔁
  • Upon recovery from a control plane failure, the recovered control entity MUST have the ability to recover the connectivity information of its neighbors. 🤝
  • Upon recovery from a control plane failure, the recovered control entity MUST have the ability to recover the association between the call and its associated connections. 🧩
  • Upon recovery from a control plane failure, calls and connections in the process of being established (i.e., pending call/connection setup requests) SHOULD be released or continued (with setup). 🌸
  • Upon recovery from a control plane failure, calls and connections in the process of being released MUST be released. ✨

4.5. Support for Extended Label Association 🦋

It's an ASON requirement to enable support for G.805 [ITU-T-G.805] serial compound links. The example below shows what that looks like, plus the requirements that come with it 🧠

Labels are defined in GMPLS (see [RFC3471]) to describe the resources used on a link local basis for a particular connection. They can range from specifying a particular timeslot, to indicating a particular wavelength, to identifying a particular port/fiber. In the ASON context, a label's value may not be consistent across a link. For example, the figure below shows two GMPLS capable nodes (A and Z) interconnected across two non-GMPLS capable nodes (B and C). All of these nodes are SONET/SDH nodes, providing, for example, a VC-4 service.

    -----                     -----
   |     |    ---     ---    |     |
   |  A  |---| B |---| C |---|  Z  |
   |     |    ---     ---    |     |
    -----                     -----

Labels have an associated implicit imposed structure based on [GMPLS-SONET] and [GMPLS-OTN]. So once the local label is exchanged with its neighboring control plane node, the structure of the local label may not be significant to the neighbor node, since the association between the local and the remote label may not necessarily be the same 🙃 This is totally fine in simple point-to-point connections between two control plane-enabled nodes where the timeslots are mapped 1:1 across the interface. BUT if a non-GMPLS capable sub-network gets introduced between these nodes (like in the figure above, where the sub-network can rearrange the timeslots), label scoping may become an issue 😬

In this context there's an implicit assumption that the data plane connections between the GMPLS capable edges already exist before any connection request. For instance, node A's outgoing VC-4's timeslot #1 (with SUKLM label=[1,0,0,0,0]), as defined in [GMPLS-SONET]), may be mapped onto node B's outgoing VC-4's timeslot #6 (label=[6,0,0,0,0]), or it may be mapped onto node C's outgoing VC-4's timeslot #4 (label=[4,0,0,0,0]). So by the time node Z gets the request from node A with label=[1,0,0,0,0], node Z's local label and timeslot no longer line up with the received label and timeslot information 🥲

So, to support this capability, a label association mechanism SHOULD be used by the control plane node to map the received (remote) label into a locally significant label. The info needed to map a received label value to a locally significant label value can be derived in several ways, including:

  • Manual provisioning of the label association 🛠️
  • Discovery of the label association 🔍

Either method MAY be used. With dynamic association, the discovery mechanism operates at the timeslot/label level before the connection request is processed at the ingress node. Also, when two nodes are directly connected, no association is required. In particular, for directly connected TDM interfaces, no mapping function (at all) is required due to the implicit label structure (see [GMPLS-SONET] and [GMPLS-OTN]). In these cases, the label association function gives a one-to-one mapping of the received to local label values 💖

4.6. Support for Crankback ✨

Okay bestie, crankback is literally one of the most important things for ASON networks 💅. When a setup fails, it lets the connection request try again on a different path that goes around the blocked link or node (like if a link or node on the chosen path doesn't have enough resources) 🦋.

Crankback MAY also be used during connection recovery by pointing out where the failed link or node is 🔥. This would seriously boost the recovery success rate for failed connections, especially when a whole bunch of setup requests get triggered at once 😭.

Here's what crankback signaling assumes 🧚:

  • The blocking resource (link or node) MUST be identified and returned in the error response message to the repair node (that may or may not be the ingress node). It's also assumed this happens within a limited period of time ⏳.
  • The repair node computes an alternate path around the blocking link or node that still satisfies the original connection constraints 🗺️.
  • The repair node (the one that caught and processed the error response message) re-initiates the connection setup request 🔁.

And here are the properties we expect from crankback signaling 💖:

  • Error information persistence: The entity computing the alternate (re-routing) path SHOULD store the identifiers of the blocking resources, as shown in the error message, until the connection is successfully established or the node gives up on rerouting attempts 🌸. Crankback can happen more than once while setting up one connection, so the history of every blockage for that connection SHOULD be kept (at least until the routing protocol updates the state of this information). That way the path computation can be accurate and avoid all the blockages 🎯.
  • Rerouting attempts limitation: To stop connection setup attempts (using crankback information) from repeating forever, the number of retries SHOULD be strictly limited 🛑. The maximum number of crankback rerouting attempts allowed MAY be limited per connection or per node:
    • When the number of retries at a particular node is exceeded, the node currently handling the failure reports the error message upstream to the next repair node, where further rerouting attempts MAY be performed. It's super important that the crankback information says rerouting through this node won't succeed 🙅‍♀️.
    • When the maximum number of retries for a specific connection has been exceeded, the repair node handling the current failure SHOULD send an error message upstream to indicate the "Maximum number of re-routings exceeded" 🚫. This error message gets sent back to the ingress node with no further rerouting attempts. Then the ingress node MAY choose to retry the connection setup according to local policy, either using its original path or by computing a path that avoids the blocking resources 🧭.

Note: After several retries, a given repair point MAY be unable to compute a path to the destination node that avoids all of the blockages. In this case, it MUST pass the error message upstream to the next repair point 🫶.

4.7. Support for Additional Error Cases 🙈

To support the ASON network, this additional category of error cases is defined:

  • Errors associated with basic call and soft permanent connection support. For example, these MAY include incorrect assignment of IDs for the Call or an invalid interface ID for the soft permanent connection 🎀.
  • Errors associated with policy failure during processing of the new call and soft permanent connection capabilities. These MAY include unauthorized requests for the particular capability 🔐.
  • Errors associated with incorrect specification of the service level 📉.

5. Backward Compatibility 🌈

As noted above, to support GMPLS protocol requirements, any extensions to the GMPLS signaling protocol that support the requirements in this document MUST be backward compatible 💜.

Backward compatibility means that in a network of nodes where some support GMPLS signaling extensions for the functions in this document, and some don't, it MUST be possible to set up conventional connections (as described by [RFC3473]) between any arbitrary pair of nodes and to traverse any arbitrary set of nodes 🦋. Also, using any GMPLS signaling extensions to set up calls or connections that support the functions in this document MUST not perturb existing conventional connections 🌸.

When transit nodes that don't need to take part in the new functions in this document are on the path of a call or connection, the GMPLS signaling extensions MUST be designed so those transit nodes can still take part in setting up the call or connection by passing the setup information onward, unmodified 🧚.

Lastly, when a transit or egress node is asked to support a function in this document but doesn't support it, the GMPLS signaling extensions MUST be designed so they can be rejected by pre-existing GMPLS signaling mechanisms, in a way that doesn't hurt the network as a whole 🛡️.

6. Security Considerations 🔒💀

Per [ITU-T-G.8080], it is not possible to establish a connection before call setup is complete 🙅‍♀️. Also, policy and authentication procedures are applied before the call is established (and can then also be restricted to connection establishment in the context of this call) 🔐.

This document introduces no new security requirements to GMPLS signaling (see [RFC3471]) ✨.

7. Acknowledgements 🫶

The authors would like to thank Nic Larkin, Osama Aboul-Magd, and Dimitrios Pendarakis for their contribution to the previous version of this document 💖. They also want to thank Zhi-Wei Lin for his contribution to this document 🌷, Deborah Brungard for her input and guidance in understanding the ASON model 🧠, and Gert Grammel for his decryption effort during the reduction of some parts of this document 🙌.

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.

[RFC3471]       Berger, L., "Generalized Multi-Protocol Label
                Switching (GMPLS) Signaling Functional Description",
                RFC 3471, January 2003.

[RFC3473]       Berger, L., "Generalized Multi-Protocol Label
                Switching (GMPLS) Signaling Resource ReserVation
                Protocol-Traffic Engineering (RSVP-TE) Extensions",
                RFC 3473, January 2003.

8.2. Informative References

[ANSI-T1.105]   ANSI, "Synchronous Optical Network (SONET): Basic
                Description Including Multiplex Structure, Rates, and
                Formats", T1.105, October 2000.

[GMPLS-OTN]     Papadimitriou, D., Ed., "Generalized MPLS (GMPLS)
                Signaling Extensions for G.709 Optical Transport
                Networks Control", Work in Progress, January 2005.

[GMPLS-OVERLAY] Swallow, G., Drake, J., Ishimatsu, H., and Y.
                Rekhter, "Generalize Multiprotocol Label Switching
                (GMPLS) User-Network Interface (UNI): Resource
                ReserVation Protocol-Traffic Engineering (RSVP-TE)
                Support for the Overlay Model", Work in Progress,
                October 2004.

[GMPLS-SONET]   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.

[GMPLS-VPN]     Ould-Brahim, H. and Y. Rekhter, Eds., "GVPN Services:
                Generalized VPN Services using BGP and GMPLS
                Toolkit", Work in Progress, May 2004.

[ITU-T-G.707]   ITU-T, "Network Node Interface for the Synchronous
                Digital Hierarchy (SDH)", Recommendation G.707,
                October 2000.

[ITU-T-G.709]   ITU-T, "Interface for the Optical Transport Network
                (OTN)", Recommendation G.709 (and Amendment 1),
                February 2001 (October 2001).  http://www.itu.int

[ITU-T-G.7713]  ITU-T "Distributed Call and Connection Management",
                Recommendation G.7713/Y.1304, November 2001.
                http://www.itu.int

[ITU-T-G.805]   ITU-T, "Generic functional architecture of transport
                networks)", Recommendation G.805, March 2000.
                http://www.itu.int

[ITU-T-G.8080]  ITU-T "Architecture for the Automatically Switched
                Optical Network (ASON)", Recommendation
                G.8080/Y.1304, November 2001 (and Revision, January
                2003).  http://www.itu.int

Appendix - Terminology 🧠✨

This document makes use of the following terms 💅:

  • Administrative domain: See Recommendation G.805 [ITU-T-G.805].
  • Call: Association between endpoints that supports an instance of a service.
  • Connection: Concatenation of link connections and sub-network connections that allows the transport of user information between the ingress and egress points of a sub-network.
  • Control Plane: Performs the call control and connection control functions. The control plane sets up and releases connections through signaling, and may restore a connection in case of a failure.
  • (Control) Domain: Represents a collection of entities that are grouped for a particular purpose. G.8080 applies this G.805 recommendation concept (that defines two particular forms: the administrative domain and the management domain) to the control plane in the form of a control domain. Entities grouped in a control domain are components of the control plane.
  • External NNI (E-NNI): Interfaces are located between protocol controllers that are situated between control domains.
  • Internal NNI (I-NNI): Interfaces are located between protocol controllers within control domains.
  • Link: See Recommendation G.805 [ITU-T-G.805].
  • Management Plane: Performs management functions for the Transport Plane, the control plane, and the system as a whole. It also provides coordination between all the planes. The following management functional areas are performed in the management plane: performance, fault, configuration, accounting, and security management.
  • Management Domain: See Recommendation G.805 [ITU-T-G.805].
  • Transport Plane: Provides bi-directional or unidirectional transfer of user information, from one location to another. It can also provide transfer of some control and network management information. The Transport Plane is layered and is equivalent to the Transport Network defined in G.805 [ITU-T-G.805].
  • User Network Interface (UNI): Interfaces are located between protocol controllers, between a user and a control domain.

Authors' Addresses ✨

Okay bestie, here are the five legends who made this happen 🎀 Each one gets their own little address card. Let's go!

Dimitri Papadimitriou
Alcatel
Francis Wellesplein 1,
B-2018 Antwerpen, Belgium

Phone: +32 3 2408491
EMail: dimitri.papadimitriou@alcatel.be
John Drake
Boeing Satellite Systems
2300 East Imperial Highway
El Segundo, CA 90245

EMail: John.E.Drake2@boeing.com
Adrian Farrel
Old Dog Consulting

Phone: +44 (0) 1978 860944
EMail: adrian@olddog.co.uk
Gerald R. Ash
ATT
AT&T Labs, Room MT D5-2A01
200 Laurel Avenue
Middletown, NJ 07748, USA

EMail: gash@att.com
Lyndon Ong
Ciena
PO Box 308
Cupertino, CA 95015, USA

EMail: lyong@ciena.com

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. That includes, but isn't limited to, any warranty that using the information here won't infringe any rights, and any implied warranties of merchantability or fitness for a particular purpose. ⚠️

Real talk: "AS IS" means no promises. Read the fine print before you build anything 🙈

Intellectual Property 🦋

The IETF takes no position on whether any Intellectual Property Rights, or other rights that might be claimed to apply to implementing or using the technology in this document, are valid or in scope. It also doesn't say whether any license under those rights might or might not be available. And it doesn't claim to have made any independent effort to find out about such rights. 🔍 If you want the details on how rights work for RFC documents, check out BCP 78 and BCP 79 📚

Copies of IPR disclosures made to the IETF Secretariat, and any assurances of licenses that might be made available, can be obtained from the IETF's online IPR repository at http://www.ietf.org/ipr. The same goes for the result of any attempt to get a general license or permission to use these proprietary rights, for implementers or users of this specification. 🧚

The IETF invites any interested party 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 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