RFC 3475
Documentation of IANA assignments for Constraint-Based LSP setup using LDP (CR-LDP) Extensions for Automatic Switched Optical Network (ASON)
RFC 3475 💖 Documentation of IANA assignments for Constraint-Based LSP setup using LDP (CR-LDP) Extensions for Automatic Switched Optical Network (ASON)
Okay bestie, this is RFC 3475 💅 It's an Informational doc, dated March 2003, written by O. Aboul-Magd from Nortel Networks. It doesn't list any RFCs it obsoletes or updates, so it's standing on its own 🦋
Status of This Memo 🎀
This memo gives info to the Internet community ✨ It does not specify an Internet standard of any kind. Distribution of this memo is unlimited 🌸
Copyright Notice 🌈
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract 🦋
Okay so ASON (Automatic Switched Optical Network) is an architecture that ITU-T Study Group 15 came up with to add a control plane to optical networks 🌟 ASON sets out a bunch of reference points that define how the ASON architectural entities relate to each other. Signaling over the interfaces at those reference points can use protocols the IETF defined for GMPLS (Generalized Multi-Protocol Label Switching) work 💜
This doc describes CR-LDP extensions (Constraint-Based LSP setup using LDP) for signaling over those ASON interfaces. The whole point is to ask IANA to assign the code points the CR-LDP extensions need 🙈 The actual protocol specs for using these extensions live in ITU-T documents, not here 📚
Table of Contents 🧚
1. Introduction ................................................. 2
2. Overview of CR-LDP Extensions for ASON ....................... 2
3. CR-LDP Messages for ASON ..................................... 3
3.1 Call Setup Message ........................................ 4
3.1.2 Call Setup Procedure ................................. 5
3.2 The Call Release Message .................................. 5
3.2.1 Call Release Procedure ............................... 6
4. CR-LDP TLV for ASON .......................................... 6
4.1 Call ID TLV ............................................... 6
4.1.1 Call ID Procedure .................................... 8
4.2 Call Capability TLV ....................................... 9
4.3 Crankback TLV ............................................. 9
5. Additional Error Codes ....................................... 10
6. IANA Consideration ........................................... 11
9. Security Considerations ...................................... 11
10. Normative References ......................................... 11
11. Intellectual Property ........................................ 12
12. Author's Address ............................................. 12
13. Full Copyright Statement ..................................... 131. Introduction 🌸
ASON is the same architecture we just talked about: ITU-T Study Group 15 (SG15) designed it to bring a control plane to optical networks. SG15 did all the development and standardization work, and it's written up in recommendation G.8080 [1] ✨ The architecture has a control plane with reference points sitting between its components. The ASON signaling that runs over those reference points is described in ITU-T recommendation G.7713 [2] 💅
Constraint-Based LSP Setup using LDP (CR-LDP) [3] is one of the protocols the ITU picked to make G.7713 and its dynamic connection management happen 🦋 The ASON-specific CR-LDP work is in ITU-T recommendation G.7713.3 [8] 🫶
This doc introduces the CR-LDP extensions that are specific to ASON and asks IANA to allocate code points for them 💖 It does not say how these extensions get used. That's the job of the ITU-T docs mentioned above 📚 > This doc should be considered alongside RFC 3036 [4], RFC 3212 [3], and the CR-LDP extensions for GMPLS [5] 💜
2. Overview of CR-LDP Extensions for ASON ✨
This doc describes the ASON-specific CR-LDP extensions that cover these ASON signaling requirements:
- Call and connection control separation
- Support of Soft Permanent Connections (SPC)
- Crankback
- Additional error codes
A big ASON architectural principle is separating the call controller from the connection controller, as described in G.8080 🌟 This separation lets one call have multiple connections attached to it. It also lets a call exist with no connections, which can be handy during recovery 🛟
There are two ways to get that separation 🎀 In the first model, the call setup request always comes with a connection request. In the second model, call setup happens independently from connection setup. The first is usually called logical separation, and the second is usually called complete separation 💅 CR-LDP extensions for ASON support both models 👑
Two new messages handle call operations: set up and release 💫 The Call Setup message is for cases where complete separation is needed. Otherwise, the LDP Label Request message does the job for logical separation 🧚
A connection setup request has to say which call the connection belongs to 🔗 That's what the Call ID TLV is for. The structure of the Call ID lets it have either a global or an operator scope 🌍
Call release always happens through the Call Release message 🫶 Receiving a Call Release message means the sender wants to remove all the connections associated with that call. Connection release uses the CR-LDP label release procedure instead, which means LDP Label Release and Label Withdraw messages, as defined in [4] 💜
There's also a Call Capability TLV that explicitly tells you what capabilities the requested call has 🦋
A Soft Permanent Connection (SPC) service assumes that both the source and destination user-to-network connection segments are already provisioned, and only the network connection segment gets set up through the control plane 🌸 For example, when the first request comes from an external source like a management system, the control plane is assumed to have enough info to figure out which specific destination (network-to-user) link connection to use 🔍 CR-LDP supports this through the Egress Label TLV, which is defined in the OIF UNI 1.0 section 11.7.5 [6] from the Optical Internetworking Forum, and in RFC3476 [7] 💖
3. CR-LDP Messages for ASON 💅
This section covers the formats and procedures for the two messages that ASON call and connection control separation requires: the Call Setup message and the Call Release message 🎀
3.1 Call Setup Message ✨
Here's the format of the Call Setup message:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Call Setup (0x0500) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source ID TLV |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Dest ID TLV |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Call ID TLV |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Call Capability TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Parameters |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Here's what each field means 🧚
- Message ID: it's as defined in RFC3036 [4] 🫶
- Source ID TLV: it's as defined in UNI 1.0 [6] and in [7] 💜
- Dest ID TLV: it's as defined in UNI 1.0 [6] and in [7] 🦋
- Call ID TLV: it's as defined in section 4.1 of this document 🌸
- Call Capability TLV: it's as defined in section 4.2 of this document 💖
3.1.2 Call Setup Procedure 👑
The calling party sends the Call Setup message whenever a new call needs to be set up with no connection attached 🌟 The Call Setup message shall contain all the info the network needs to process the call. Specifically, it shall include the calling and called party addresses, as given by the Source ID and Dest ID TLVs 📞 The setup message must include a Call ID TLV 🔑 The call control entity shall identify the call using the selected identifier for the call's whole lifetime ⏳ The Call Setup message shall move through the network to the called party 🚀 The called party may accept or reject the incoming call 🙌
To tell the calling party whether setup worked, an LDP Notification message with the appropriate status code shall be used 📬 A call can get rejected by the network (for example, for policy reasons) or by the called party 🙅♀️
3.2 The Call Release Message 🌈
Here's the layout of the Call Release message:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Call Release (0x0501) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source ID TLV |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Dest ID TLV |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Call ID TLV |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Parameters |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+To be continued in part 2 💜🫶
3.2.1 Call Release Procedure 🦋
okay so the Call Release message is what any entity in the network can send to hang up a call that's already up and running 📞💅 It MUST include the Call ID TLV of the call being terminated, so everyone knows which call we mean 🫶 The person who asked gets a confirmation through a Notification message with the right status code ✨ And when a Call Release gets received and processed, it MUST trigger the release of every connection tied to that call 🔥 The connection teardown just follows the normal CR-LDP routine, using Label Release and Label Withdraw messages 🌸
4. CR-LDP TLVs for ASON 🎀
this part covers the operator specific Call ID TLV, the globally unique Call ID TLV, the Call Capability TLV, and the Crankback TLV that got introduced for ASON 💖
4.1 Call ID TLV 🦋
an established call can be identified by a Call ID 🪪 It's a globally unique identifier set by the source network 🌍 To make sure it's actually globally unique, you glue together two pieces: a globally unique fixed identifier (country code + carrier code + unique access point code) and an operator specific identifier (NE address + local identifier) 🧩
so a generic CALL_ID with global uniqueness has a <global Id> (which is <country code> + <carrier code> + <unique access point code>) and an <operator specific Id> (which is <NE address> + <local Identifier>). if you only need operator specific uniqueness, the <operator specific Id> is all you need. but if it has to be globally unique, you need both the <global ID> and the <operator specific Id> 👑
the <global Id> SHALL consist of a three-character International Segment (the <country code>) and a twelve-character National Segment (the <carrier code> plus <unique access point code>). these characters SHALL be coded according to ITU-T Recommendation T.50 💅
here's the format of the operator specific (Op-Sp) CALL_ID TLV:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F|Op-Sp Call ID (0x0831) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NE Address (NEA Sub TLV) |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Identifier (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+NEA Sub TLV: the Source NE Address is the address of the transport network element controlled by the source network. its length can be 4, 6, 16, or 20 bytes long. the NEA Sub TLV is TLV Type 1 🧸
Local Identifier: a 64-bit identifier that stays constant over the whole life of the call 🔒
here's the format of the globally unique (GU) Call ID TLV:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F|GU Call ID (0x0832) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | IS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NS |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NE Address (NEA Sub TLV) |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Identifier (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+International Segment (IS): this is coded according to ITU-T recommendation T.50. the IS field gives a 3 character ISO 3166 Geographic/Political Country Code, based on the three-character uppercase alphabetic ISO 3166 Country Code (e.g., USA, FRA) 🌏
National Segment (NS): the NS field has two sub-fields:
- the first subfield contains the ITU Carrier Code
- the second subfield contains a Unique Access Point Code
the ITU Carrier Code is a code given to a network operator or service provider, maintained by the ITU-T Telecommunication Service Bureau in association with Recommendation M.1400. it's 1-6 left-justified alphabetic characters (bytes), or leading alphabetic followed by numeric. if it's less than 6 characters (bytes), it gets padded with a trailing NULL to fill the subfield 🫧
the Unique Access Point Code is up to the organization that got the country code and ITU carrier code, as long as uniqueness is guaranteed. it's 1-6 characters (bytes), with a trailing NULL, which completes the 12-character National Segment. if it's less than 6 characters, it's padded with a trailing NULL to fill the subfield 🍓
format of the National Segment:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ITU carrier code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ITU carrie dode (cont) | Unique access point code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unique access point code (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+4.1.1 Call ID Procedure ✨
these processing rules apply to the CALL ID TLV:
- for initial calls, the calling/originating party call controller MUST set the CALL ID values to all-zeros.
- for a new call request, the source networks call controller (SNCC) sets the right type and value for the CALL ID.
- for an existing call (where the Call ID is non zero), the SNCC checks that the call actually exists.
- intermediate nodes are not allowed to alter the Call ID TLV that was set by the ingress node.
- the destination user/client that receives the request uses the CALL ID values as a reference to the requested call between the source user and itself. any later actions about the call use the CALL ID as the reference identifier 🧠
4.2 Call Capability TLV 💖
here's the format of the Call Capability TLV:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Call Capabaility(0x0833) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Call Capability |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+the Call Capability TLV holds a 4 byte Call Capability field. that field is used to explicitly show the configuration potential of the call 🧩
an example of Call Capability field values:
0x0000 Point to Point call4.3 Crankback TLV 🔥
crankback works like this: when a Label Request message gets blocked at some node because resources aren't available, that node tells the initiator of the Label Request where the blockage is 🚧 the initiator can then re-compute new explicit routes that dodge the area with the resource shortage, and send a fresh Label Request with the new route 🛣️
CR-LDP supports crankback through a Crankback TLV. an LDP Notification message is used to tell the Label Request initiator about the blocking condition. that Notification carries the Crankback TLV, which says where the resource shortage is. the location is identified using the ER-HOP TLV. the encoding of the Crankback TLV is:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Crankback(0x0834) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ER-HOP TLV ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+the ER-HOP TLV is specified in rfc3212 [3]. it's an n x 4 bytes field, and it could e.g. hold an IPv4 or an IPv6 address 🌐
5. Additional Error Codes 🚨
G.7713 includes a bunch of error codes that aren't defined in earlier CR-LDP related RFCs yet. here's the list of those error conditions:
Invalid SNP ID (0x04000009)
Calling Party busy (0x0400000a)
Unavailable SNP ID (0x0400000b)
Invalid SNPP ID (0x0400000c)
Unavailable SNPP ID (0x0400000d)
Failed to create SNC (0x0400000e)
Failed to establish LC (0x040000f)
Invalid Source End-User Name (0x04000010)
Invalid Destination End-User Name (0x04000011)
Invalid CoS (0x04000012)
Unavailable CoS (0x04000013)
Invalid GoS (0x04000014)
Unavailable GoS (0x04000015)
Failed Security Check (0x04000016)
TimeOut (0x04000017)
Invalid Call Name (0x04000018)
Failed to Release SNC (0x04000019)
Failed to Free LC (0x0400001a)acronyms used in the error codes above:
SNP Sub-network Point
SNPP Sub-network Point Pool
SNC Sub-network Connection
LC Link Connection
CoS Class of Service
GoS Grade of Service6. IANA Consideration 🌈
this document uses the LDP RFC 3036 [4] name spaces. see http://www.iana.org/assignments/ldp-namespaces.
Call Setup (0x0500)
Call Release (0x0501)the assignment for the following TLVs:
Op-Sp Call ID TLV (0x0831)
GU Call ID TLV (0x0832)
Call Capability TLV (0x0833)
Crankback TLV (0x0834)the assignment for the new error codes is listed in section 5 of this document 🫶
9. Security Considerations 💀
this document does not introduce any new security concerns other than the ones defined in RFC 3036 and RFC 3212. but the security aspects (if any) w.r.t. the G.8080 and G.7713 documents still need to be addressed in those documents. 🙈
10. Normative References 📚
okay bestie, these are the docs the spec leans on the hardest 🤓 Think of them as the homework you have to read before you can even start.
- [1] Architecture for Automatically Switched Optical Network (ASON), ITU-T recommendation G.8080, Nov. 2001
- [2] Distributed Call and Connection Management (DCM), ITU-T recommendation G.7713, Dec. 2001
- [3] Jamoussi, B., Ed., Andersson, L., Callon, R., Dantu, R., Wu, L., Doolan, P., Worster, T., Feldman, N., Fredette, A., Girish, M., Gray, E., Heinanen, J., Kilty, T. and A. Malis, "Constraint-Based LSP Setup using LDP", RFC 3212, January 2002.
- [4] Andersson, L., Doolan, P., Feldman, N., Fredette, A. and B. Thomas, "LDP Specifications", RFC 3036, January 2001.
- [5] Ashwood-Smith, P. and L. Berger, (Editors),"Generalized Multi-Protocol Label Switching (GMPLS) Signaling Constraint-based Routed Label Distribution Protocol (CR-LDP) Extensions", RFC 3472, January 2003.
- [6] UNI 1.0 Signaling Specification, The Optical Internetworking Forum,
http://www.oiforum.com/public/UNI_1.0_ia.html - [7] Rajagopalan, B., "Label Distribution Protocol (LDP) and Resource ReserVation Protocol (RSVP) Extensions for Optical UNI Signaling", RFC 3476, March 2003.
- [8] Distributed Call and Connection Management signalling using GMPLS CR-LDP, ITU G.7713.3, Januray 2003.
11. Intellectual Property 💅
so the IETF is basically saying "we are NOT taking a side on whether any of this tech is covered by someone's rights" 🙅♀️ It also doesn't claim it went looking for any of them. If you want the rules for standards-track stuff, go read RFC 2028 📖
Any copies of rights claims that were submitted for publication, plus any assurances of licenses, or the results of an attempt to get a general license or permission for implementers or users of this spec, can be obtained from the IETF Secretariat 🗂️
And the IETF is inviting anyone who knows about copyrights, patents, patent applications, or other proprietary rights that might cover technology needed to practice this standard to speak up ✨ Send that info to the IETF Executive Director, periodt 📬
12. Author's Addresses 🎀
here's where you can find the author (ngl, I'd send her a thank-you 🫶)
Osama Aboul-Magd
Nortel Networks
P.O. Box 3511, Station C
Ottawa, Ontario, Canada
K1Y 4H7
Phone: 613-599-9104
EMail: osama@nortelnetworks.com13. Full Copyright Statement 🌈
the legal part, but make it cute 🥹
Copyright (C) The Internet Society (2003). All Rights Reserved.
so basically, you can copy this doc and pass it around, and you can write derivative works that comment on it, explain it, or help people implement it 🦋 Those can be prepared, copied, published, and distributed, in whole or in part, with no restriction of any kind. The one condition is that the above copyright notice and this paragraph stay on all of those copies and derivative works 📝
However, this document itself may not be modified in any way. That includes removing the copyright notice or the references to the Internet Society or other Internet organizations. The exceptions are when it's needed for developing Internet standards, in which case the Internet Standards process copyright procedures must be followed, or when it's needed to translate it into languages other than English 🌍
The limited permissions above are perpetual and won't be revoked by the Internet Society or its successors or assigns ♾️
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 🙈
Acknowledgement 🫶
funding for the RFC Editor function is currently coming from the Internet Society 💖 thank you, Internet Society, you're iconic 👑
📦 where this page comes from
- ietf: rfc3475 2003-04
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms