RFC 2761

Terminology for ATM Benchmarking

📅 published February 2000, from ietf

RFC 2761: Terminology for ATM Benchmarking ✨

  • Authors: J. Dunn and C. Martin, ANC, Inc. 🎀
  • Category: Informational 💅
  • Date: February 2000 🌸
  • Network Working Group: this one came from the IETF's Benchmarking Methodology Working Group (BMWG) 🦋
  • Obsoletes / Updates: none listed in the title block 🫶

Status of this Memo ✨

Okay so, this memo is just here to give information to the Internet community 💖 It is not a standard of any kind, so nobody has to implement anything from it. Distribution is unlimited, so share it with everyone 🌈

Copyright (C) The Internet Society (2000). All Rights Reserved. 🔒

Abstract 🦋

This memo is all about terms used for performance benchmarking tests and their results, specifically for ATM (Asynchronous Transfer Mode) based switching devices 🔥 The terms defined here are meant to be used alongside the terms already defined in RFCs 1242, 2285, and 2544. It's a product of the Benchmarking Methodology Working Group (BMWG) of the Internet Engineering Task Force (IETF) ✨

Introduction 🌸

So this document gives you terminology for benchmarking ATM based switching devices 💅 It builds on the terms already defined for benchmarking network interconnect devices in RFCs 1242, 2285, and 2544. Some of the definitions might also apply to a wider group of network interconnect devices, but the main focus is ATM cell relay and signaling 🎀

The memo has two big sections: Background and Definitions 📚 Inside Definitions there's a formal definitions subsection, which is there as a courtesy to you, and a measurement definitions subsection with performance metrics that have inherent units 🧚 The measurement subsection is split up to follow the BISDN model.

The BISDN model has four layers and two planes 🌈 This document looks at how those layers interact and how they affect IP and TCP throughput. Here's a schematic of the B-ISDN model, no cap it's giving architecture 🤓

---------|--------------------------|-------------------------------
         |     User Plane           |       Control Plane
---------|--------------------------|--------------------------------
Services |          IP              |   ILMI   |       UNI, PNNI
---------|--------------------------|----------|---------------------
AAL      | AAL1, AAL2, AAL3/4, AAL5 |   AAL5   |        SAAL
---------|--------------------------|----------|---------------------
ATM      |      Cell Relay          |        OAM, RM
---------|--------------------------|--------------------------------
         |       Convergence        |
Physical |--------------------------|--------------------------------
         |         Media            |
---------|--------------------------|--------------------------------

This document assumes the necessary services are already available and active 🫶 For example, IP connectivity needs SSCOP connectivity between signaling entities. It's also assumed that the SUT can configure ATM addresses (via hard coded addresses, ILMI or PNNI neighbor discovery), can run SSCOP, and can perform signaled call setups (via UNI or PNNI signaling) 💖 This document only covers CBR, VBR and UBR traffic types. ABR is going to be handled in a separate document 🦋 And finally, this document only has the terminology for benchmarking IP performance over ATM, so it is NOT a complete collection of ATM test terminology 👀

Oh, and the BMWG makes two major kinds of documents: Benchmarking Terminology documents and Benchmarking Methodology documents ✨ Terminology docs present the benchmarks and related terms. Methodology docs define the procedures you need to collect the benchmarks cited in the matching Terminology document 💅

Existing Definitions 📚

Before you even try to use this document, you should read RFC 1242, "Benchmarking Terminology for Network Interconnect Devices" 🤓 RFC 2544, "Benchmarking Methodology for Network Interconnect Devices", discusses a bunch of terms that matter for benchmarking switching devices, so you should consult it too. RFC 2285, "Benchmarking Terminology for LAN Switching Devices", has a number of terms about traffic distributions and datagram interarrival 🌈 For clarity and continuity, this RFC uses the definition template set out in Section 2 of RFC 1242. The definitions are indexed and grouped into sections so they're easy to find 🎀

And 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 RFC 2119 🔥

Definitions 💜

Okay this part is split into two groups 💅 The first group is formal definitions. They're required for writing the performance metrics but aren't metrics themselves. They were borrowed from other work done in other working groups, both inside and outside the IETF, and they're here as a courtesy to you 🫶

1. Formal Definitions ✨

1.1. Definition Format (from RFC 1242) 🌸

Every entry has the same shape 🦋 First the term being defined, then a Definition: with the specific meaning of the term, then a Discussion: with a short talk about the term, how it's applied, and any restrictions on measurement procedures. These discussions only cover how a particular ATM parameter affects IP or TCP, so definitions with no configurable components (or whose components have the discussion: None) just say None. Last is Specification:, which names the working group and document where the term is specified, all listed in the references section 💖

1.2.1. ATM Adaptation Layer (AAL) 🎀

Definition: The layer in the B-ISDN reference model (see B-ISDN) that adapts higher layer PDUs into the ATM layer 🧚

Discussion: There are four types of adaptation layers 💅

  • AAL 1: used for circuit emulation and voice over ATM 🎀
  • AAL2: used for sub-rated voice over ATM 🌸
  • AAL3/4: used for data over noisy ATM lines 😭
  • AAL5: used for data over ATM, the most widely used AAL type 👑

These AAL types aren't measurements, but you can measure the time it takes for Segmentation and Reassembly (SAR) ✨

Specification: I.363

1.2.2. ATM Adaptation Layer Type 5 (AAL5) 🔥

Definition: AAL5 adapts multi-cell higher layer PDUs into ATM with minimal error checking and no error detection 💅 The AAL5 CPCS (Common Paer Convergence Sub-layer) PDU is laid out like this:

|---------------------------|---------------------------|--------------|
|    Higher Layer PDU       |   Padding (If needed)     |    Trailer   |
|---------------------------|---------------------------|--------------|

The padding is there to make sure the trailer sits in the final 8 octets of the last cell 🫶

The trailer looks like this:

|--------------|--------------|--------------|--------------|
|   CPCS-UU    |     CPI      |    Length    |   CRC-32     |
|--------------|--------------|--------------|--------------|

where:

  • CPCS-UU is the 1 octet Common Part Convergence Sub-layer User to User Indication, and it may be used to communicate between two AAL5 entities 💖
  • CPI is the 1 octet Common Part Indicator, and it must be set to 0 🧚
  • Length is the 2 octet length of the higher layer PDU 🌈
  • CRC-32 is a 32 bit (4 octet) cyclic redundancy check over the entire PDU 🔒

Discussion: AAL5 is the adaptation layer for UNI signaling, ILMI, PNNI signaling, and IP PDUs 👑 It's the most widely used AAL type so far 🎀 AAL5 needs two distinct processes. The first is encapsulation on the transmit side, and de-encapsulation on the receive side, of the higher layer PDU into the AAL5 CPCS PDU. This needs the length and the CRC-32 to be computed 🤓 How long that takes depends on whether the CRC-32 is computed on the interface (on-board) or in machine central memory (in core). On-board computation should only add a small, constant delay. In-core computation can add variable delay, which will hurt TCP RTT computations 😭 The second process is segmentation and re-assembly (SAR), defined below (see SAR) 🦋

Specification: I.363.5

1.2.3. Asynchronous Transfer Mode (ATM) 🌸

Definition: A transfer mode where information is organized into 53 octet PDUs called cells 💫 It's asynchronous, meaning the recurrence of cells carrying information from one user isn't necessarily periodic ✨

Discussion: ATM is based on the ISDN model, but unlike ISDN, ATM uses fixed length (53 octet) cells 💅 Because ATM PDUs are fixed length, higher layer PDUs have to be adapted into ATM using one of the four ATM adaptation layers (see AAL) 🧚

Specification: AF-UNI3.1

Definition: A virtual path link (VPL) or a virtual channel link (VCL) 🦋

Discussion: none. 🫶

Specification: AF-UNI3.1

1.2.5. ATM Peer-to-Peer Connection 🌈

Definition: A virtual channel connection (VCC) or a virtual path connection (VPC) 💖

Discussion: none. 🫶

Specification: AF-UNI3.1

1.2.6. ATM Traffic Descriptor 🔥

Definition: A generic list of traffic parameters that specify the intrinsic traffic characteristics of a requested ATM connection (see GCRA). It must include PCR and QoS, and may include BT, SCR and best effort (UBR) indicator 👑

Discussion: The effects of each traffic parameter are discussed individually 🌸

Specification: AF-UNI3.1

1.2.7. ATM User-User Connection 💜

Definition: An association set up by the ATM Layer to support communication between two or more ATM service users (i.e., between two or more next higher entities, or between two or more ATM-entities) 🧚 Communications over an ATM Layer connection can be bi-directional or unidirectional. The same Virtual Channel Identifier (VCI) is issued for both directions of a connection at an interface 🎀

Discussion: Because ATM is connection oriented, certain IP features (i.e. those which require multicast) aren't available 😭

Specification: AF-UNI3.1

1.2.8. Broadband ISDN (B-ISDN) Model 🌈

Definition: A layered service model that specifies how higher layer protocols map onto ATM and its underlying physical layer 💅 The model has four layers: Physical, ATM, AAL and Service ✨

Discussion: See discussion above. 🫶

Specification: I.321

1.2.9. Burst Tolerance (BT) 🦋

Definition: A traffic parameter that, along with the Sustainable Cell Rate (SCR), specifies the maximum number of cells that will be accepted at the Peak Cell Rate (PCR) on an ATM connection 🔥

Discussion: BT applies to ATM connections supporting VBR services, and it's the limit parameter of the GCRA 🤓 BT affects TCP and IP PDU loss, since cells presented to an interface that violate the BT may be dropped, which can cause AAL5 PDU corruption. BT also affects TCP RTT calculation 😭 The formula is:

BT=(MBS-1)*(1/SCR 1/PCR)

(see MBS, PCR, SCR) 💖

Specification: AF-TM4.0

1.2.10. Call 🌸

Definition: A call is an association between two or more users, or between a user and a network entity, that is established by using network capabilities. This association may have zero or more connections 👑

Discussion: none. 🫶

Specification: AF-UNI3.1

1.2.11. Cell 💅

Definition: A unit of transmission in ATM. It's a fixed-size frame made of a 5-octet header and a 48-octet payload 🧚

Discussion: none. 🎀

Specification: AF-UNI3.1

1.2.12. Call-based 📞

Definition: Okay so this is a transport that needs call setups first, so go check the CALL definition 💅

Discussion: none 🙈

Specification: AF-UNI3.1

1.2.13. Cell Delay Variation Tolerance (CDVT) 🌊

Definition: Okay, the ATM layer can totally mess with the traffic patterns of ATM connections by adding Cell Delay Variation 😭 When cells from two or more ATM connections get multiplexed together, cells from one connection can get delayed while cells from another connection are being slotted in at the multiplexer output. Same deal when some cells get held up so physical layer overhead or OAM cells can be inserted. So the time between consecutive cells of a connection, as watched at the UNI, gets a little bit random 🦋 The upper bound on that "clumping" measure is the CDVT, and that's the whole vibe.

Discussion: Real talk, CDVT messes with TCP round trip time calculations 🥺 If the CDVT values are large, they'll adversely effect TCP throughput and can cause SAR timeout. See the discussion under SAR, bestie 💖

Specification: AF-TM4.0

1.2.14. Cell Header 🧚

Definition: This is the ATM Layer protocol control information, the little ID card on every cell ✨

Discussion: The ATM cell header is a 5-byte header, and it's packed with these fields:

  • Generic Flow Control (GFC): 4 bits
  • Virtual Path Identifier (VPI): 8 bits
  • Virtual Channel Identifier (VCI): 16 bits
  • Payload Type (PT): 3 bits
  • Cell Loss Priority (CLP): 1 bit
  • Header Error Check (HEC): 8 bit CRC computed over the previous four octets

Each field gets its own spotlight in this document, so stay tuned 🎀

Specification: AF-UNI3.1

1.2.15. Cell Loss Priority (CLP) 🫶

Definition: This bit in the ATM cell header gives cells two priority levels. CLP=0 cells are higher priority than CLP=1 cells. When there's congestion, CLP=1 cells can get discarded so the CLR of CLP=0 cells stays protected 🛡️ Protect the VIP, obviously.

Discussion: The CLP bit is what decides GCRA contract compliance 👑 A single connection can have two traffic contracts applying to it: one where only cells with CLP=0 count, and one called CLP=0+1 where cells with CLP=0 or CLP=1 both count. Iconic behaviour, honestly.

Specification: AF-UNI3.1

1.2.16. Connection 🔗

Definition: An ATM connection is a concatenation of ATM Layer links. Put them together and you get an end-to-end information transfer capability between access points. Linked up and ready to go 💕

Discussion: none 🙈

Specification: AF-UNI3.1

1.2.17. Connection Admission Control (CAC) 🚪

Definition: Connection Admission Control is the set of actions the network takes during the call set-up phase, or during the call re-negotiation phase, to figure out whether a connection request gets accepted or rejected. It also decides whether a request for re-allocation can be accommodated. The bouncer of the network, basically 💅

Discussion: CAC is based on the ATM traffic descriptor (see ATM traffic descriptor) tied to the call, plus the presented and existing load 📊 It can also be based on administrative policies, like calling party number required or access limitations. How these policies affect performance is beyond the scope of this document, and that gets covered in the BMWG document: Benchmarking Terminology for Firewall Performance. Different doc, different era of drama 😌

Specification: AF-UNI3.1

1.2.18. Constant Bit Rate (CBR) 🎵

Definition: This is an ATM service category that supports a constant and guaranteed rate for transport services like video or voice, plus circuit emulation, which needs really strict timing control and performance parameters. CBR requires you to specify PCR and QoS (see PCR and QoS) 💖

Discussion: CBR gives minimal cell delay variation (see CDV), so it should improve TCP throughput by stabilising the RTT calculation 🌸 It also usually gets high priority, meaning CBR cells tend to win during congestion, so TCP segment and IP packet loss should be minimised ✨ The catch? You lose statistical multiplexing 😭 Since CBR guarantees both throughput and CDV control, connections have to be subscribed at PCR. That's extremely wasteful, because most protocols, TCP for example, only use full bandwidth on one half of a bi-directional connection. Major "paying for the whole pizza when you only ate one slice" energy 🍕

Specification: AF-UNI3.1

1.2.19. Cyclic Redundancy Check (CRC) 🔁

Definition: This is a mathematical algorithm that computes a numerical value from the bits in a block of data. The number gets sent along with the data. The receiver runs the same algorithm and compares its result with the number it received. If they don't match, transmission error is presumed. Basically a vibe check for your data 🥰

Discussion: CRC isn't a measurement itself, but you can measure how long it takes to perform a CRC on a string of bits. That measurement won't be covered in this document, so don't go looking for it here 🙈 See the discussion under AAL5.

Specification: AF-UNI3.1

1.2.20. End System (ES) 💻

Definition: An End System is a system where an ATM connection gets terminated or initiated. An originating end system starts the ATM connection, and a terminating end system ends it. OAM cells may be generated and received here ✨

Discussion: An ES can be the user side of a UNI signaling interface 💜

Specification: AF-TEST-0022

1.2.21. Explicit Forward Congestion Indication (EFCI) 🚨

Definition: EFCI is an indication in the PTI field of the ATM cell header. A network element that's in an impending-congested state or a congested state can set EFCI, so the destination end-system can check it out. For example, the end-system might use this indication to run a protocol that adaptively lowers the cell rate of the connection during congestion or impending congestion 🐢 A network element that isn't in a congestion state or an impending congestion state won't modify this indication. And impending congestion just means network equipment is running around its engineered capacity level. Ngl, very tense 😰

Discussion: EFCI can help prevent congestion by alerting a positive acknowledgement protocol so it takes action 🙌 With TCP, when EFCI cells get received, the driver software could alert the TCP software about impending congestion. The TCP receiver would then acknowledge the current segment and set the window size to some very small number. Dramatic, but it works 💅

Specification: AF-TM4.0

1.2.22. Generic Cell Rate Algorithm (GCRA) 🧮

Definition: The GCRA is used to define conformance with the traffic contract of the connection. For every cell arrival, the GCRA decides whether that cell conforms to the traffic contract. The UPC function may implement the GCRA, or one or more equivalent algorithms, to enforce conformance. The GCRA is defined with two parameters: the Increment (I) and the Limit (L) 🎀

Discussion: The GCRA increment and limit parameters map to CBR and VBR like this. For CBR, I=1/PCR and L=CDVT (CDV tolerance). For VBR, two GCRA algorithms run at the same time, kind of a dual leaky bucket 🪣 The first one works the same way as CBR, with I=1/PCR and L=CDVT. The second one polices the cells that already conform to the first GCRA, and it uses I=1/SCR and L=BT (see BT, CDV, MBS, PCR and SCR). Two checkpoints, no cap 😤

Specification: AF-TM4.0

1.2.23. Generic Flow Control (GFC) 🌷

Definition: GFC is a field in the ATM header that can be used to provide local functions, like flow control. It only has local significance, so the value encoded in the field isn't carried end-to-end. It stays local, bestie 🤫

Discussion: none 🙈

Specification: AF-UNI3.1

1.2.24. Guaranteed Frame Rate (GFR) 🌈

Definition: The GFR service gives the user a Minimum Cell Rate (MCR) guarantee, assuming a given maximum frame size (MFS) and a given Maximum Burst Size (MBS). Both the MFS and MBS are expressed in units of cells. GFR only applies to virtual channel connections (VCCs) 🦄

Discussion: GFR is made for users who either can't specify the range of traffic parameters needed to request most ATM services, or aren't set up to follow the (source) behaviour rules that existing ATM services require 🥹 Specifically, GFR gives the user this minimum service guarantee: when the network is congested, every frame that's shorter than MFS, shows up in bursts smaller than MBS, and comes in at a rate below PCR will get handled with minimum frame loss. When the network isn't congested, the user can burst at higher rates. Main character energy 🌟

The effect of GFR on performance is kinda complicated, since the policing algorithm for GFR depends on network load. Still, under congestion, and assuming the user is following the GFR service agreement, it should improve performance 💫

Specification: AF-TM4.1

1.2.25. Header Error Control (HEC) 🩹

Definition: HEC is a check character calculated with an 8 bit CRC computed over the first 4 octets of the ATM cell header. It allows for single bit error correction or multiple bit error detection. So if something gets bent out of shape, it can usually get fixed 🛠️

Discussion: none 🙈

Specification: AF-UNI3.1

1.2.26. Integrated Local Management Interface 📋

Definition: This is a management protocol that uses SNMPv1 carried on AAL5. It gives ATM network devices status and configuration information about VPCs, VCCs, registered ATM addresses, and the capabilities of ATM interfaces. Think of it as the group chat where all the devices update each other 💬

Discussion: ILMI is a conditionally required portion of UNI3.1. However, ILMI 4.0 has been issued as a separate specification, and this document will refer to ILMI 4.0 🌸

Specification: AF-ILMI4.0

1.2.27. Intermediate System (IS) 🔀

Definition: An Intermediate System is a system that provides forwarding functions, relaying functions, or both, for a specific ATM connection. OAM cells may be generated and received here too 🧃

Discussion: An IS can be either the user side or the network side of a UNI signaling interface, or the network side of a PNNI signaling interface 💖

Specification: AF-TEST-0022

1.2.28. Leaky Bucket (LB) 🪣

Definition: Leaky Bucket is the term used as an analogy for the algorithm that checks conformance of cell flows coming from a user or the network. See GCRA and UPC. The "leaking hole in the bucket" stands for the sustained rate at which cells can be accommodated, while the "bucket depth" stands for how much cell bursting you can tolerate over a given time period 🫧

Discussion: There are two types of LB algorithms: single and dual. Single LB is used in CBR, and dual LB is used in VBR (see CBR and VBR) 💜

Specification: AF-TM4.0

1.2.29. Maximum Burst Size (MBS) 💥

Definition: In the signaling message, the Burst Tolerance (BT) is conveyed through the MBS, which is coded as a number of cells. The BT, together with the SCR and the PCR, determines the MBS that may be transmitted at the peak rate and still conform to the GCRA 🎯

Discussion: See the discussion under BT 🙈

Specification: AF-TM4.0

1.2.30. Maximum Frame Size (MFS) 🌙

Definition: The MFS is the maximum length of a frame, expressed in units of cells, that an interface implementing GFR will accept during congested conditions (see GFR) 🎀

Discussion: During congestion, frames bigger than the MFS may be dropped or tagged 😬 As long as the user sticks to the MFS limit, this behaviour should improve performance by easing congestion. Rules are rules, and this one is honestly a W 💅

Specification: AF-TM4.1

1.2.31. Operations, Administration, and Maintenance (OAM) 🔧

Definition: OAM is a group of network management functions. Together they give you network fault indication, performance information, and data and diagnosis functions. Main character management energy 💅

Discussion: There are four types of ATM OAM flows. They are segment or end-to-end VP termination management (F4 segment, F4 E2E) and segment or end-to-end VC termination management (F5 segment, F5 E2E). These OAM cells can be used for fault management, connection verification, and loop back measurements 🧚

Specification: AF-UNI3.1

1.2.32. Payload Type Indicator (PTI) 🎀

Definition: PTI is the Payload Type field value. It tells apart the management cells and user cells, and it also carries explicit forward congestion indication (see EFCI) 💜

Example: A Resource Management cell is indicated as PTI=110. An End-to-end OAM F5 Flow cell is indicated as PTI=101.

Discussion: none.

Specification: AF-UNI3.1

1.2.33. Peak Cell Rate (PCR) 🚀

Definition: PCR is a traffic parameter that sets the upper bound on how fast ATM cells can be submitted to an ATM connection. The GCRA uses this parameter 🦋

Discussion: PCR directly limits the maximum data rate on an ATM connection. If a user violates the PCR, cells may be dropped, and that leads to Cell Loss. This is lowkey bad news for AAL5 PDUs, which may be carrying IP datagrams. Check the discussion under SAR for the full tea ☕

Specification: AF-TM4.0

1.2.34. Permanent Virtual Circuit (PVC) 🌸

Definition: A PVC is a link with static route(s) defined in advance, usually through manual setup. Very planned, very intentional 🗓️

Discussion: none.

Specification: AF-UNI3.1

1.2.35. Permanent Virtual Channel Connection (PVCC) 🌈

Definition: A Virtual Channel Connection (VCC) is an ATM connection where switching is done on the VPI/VCI fields of each cell. A permanent VCC is one that gets provisioned through some network management function and stays up indefinitely. Forever and ever, iconic 👑

Discussion: none.

Specification: AF-UNI3.1

1.2.36. Permanent Virtual Path Connection: (PVPC) 🍓

Definition: A Virtual Path Connection (VPC) is an ATM connection where switching is done on the VPI field only of each cell. A permanent VPC is one that gets provisioned through some network management function and stays up indefinitely. Same energy, different field 💅

Discussion: none.

Specification: AF-UNI3.1

1.2.37. Private Network-Network Interface (PNNI) 🌐

Definition: PNNI is a routing information protocol. It lets extremely scalable, full function, dynamic multi-vendor ATM switches get integrated into the same network. The vendors really said "we can all be friends" ✨

Discussion: PNNI covers signaling and routing between ATM network devices. PNNI signaling is based on UNI 4.0 signaling between two network side interfaces. PNNI routing gives you a way to route ATM cells between two separate, autonomous ATM networks. Teamwork makes the dream work 🫶

Specification: AF-PNNI1.0

1.2.38. Protocol Data Unit (PDU) 📦

Definition: A PDU is a message of a given protocol. It has the payload plus protocol-specific control information, which is typically in a header. PDUs pass over the protocol interfaces that exist between the layers of protocols (per OSI model). Think of it as the outfit a message wears to go out 👗

Discussion: In ATM networks, a PDU can mean an ATM cell, multiple ATM cells, an AAL segment, an IP datagram, and more 🌟

Specification: Common Usage

1.2.39. Segmentation and Reassembly (SAR) 🧩

Definition: SAR is the process the AAL uses in the B-ISDN reference model (see B-ISDN). It fragments higher layer PDUs into ATM cells, then puts them back together. Chop it, then stitch it up ✂️🧵

Discussion: SAR is not a measurement itself, but the speed at which SAR can be completed on a bit stream can be measured. This measurement is not included in this document. Still, the way SAR is performed will greatly effect performance. SAR can be done on the interface card (on board) or in machine central memory (in core). On-board computation should produce only a small, constant delay. In core computation produces variable delay, which will negatively effect TCP RTT computations. It gets messier because of where the CRC-32 calculation lives. With an in core CRC-32 calculation, bus contention may make on board SAR slower than in core SAR. Clearly, on board CRC-32 calculation and SAR give the most favorable performance results 🏆

SAR performance also gets effected by ATM layer impairments. Cell error (CE), cell loss (CL), cell mis-insertion (CM), and cell delay variation (CDV) will all negatively effect SAR. CE will cause an AAL5 PDU to fail the CRC-32 check and be discarded, which discards the packet that PDU contained. CL and CM will both cause an AAL5 PDU to fail the length check and be discarded. CL can have other effects depending on whether the lost cell was the final cell (PTI=1) of the AAL5 PDU. Here's the full breakdown, and yes it's a lot 😭

1. PTI=0 cell is lost.  In this case, re-assembly registers a length
discrepancy and discards the PDU.

2. PTI=1 cell is lost.

2.  A.  The AAL5 re-assembly timer expires before the first cell,
PTI=0, of the next AAL5 PDU arrives.  The AAL5 PDU with the missing
PTI=1 cell is discarded due to re-assembly timeout and one packet is
lost.

2.  B.  The first cell of the next AAL5 PDU arrives before the re-
assembly timer expires.  The AAL5 with the missing PTI=1 cell is
prepended to the next AAL5 PDU in the SAR engine.  This yields two
possibilities:

2. B. i.  The AAL5 re-assembly timer expires before the last cell,
PTI=1, of the next AAL5 PDU arrives.  The AAL5 PDU with the missing
PTI=1 cell and the next AAL5 PDU are discarded due to re-assembly
timeout and two packets are lost.

2. B. ii.  The last cell of the next AAL5 PDU arrives before the re-
assembly timer expires.  In this case, AAL5 registers a length
discrepancy and discards the PDU; therefore, the AAL5 PDU with the
missing PTI=1 cell and the next AAL5 PDU are discarded due to their
concatenation and two packets are lost.

2. C.  Coupled with re-assembly, there exists some mechanism for
identifying the start of a higher layer PDU, e.g., IP, and the cells
associated with the first incomplete AAL5 PDU are discarded,
resulting in the loss of one packet.

Specification: AF-UNI3.1

1.2.40. Sustainable Cell Rate (SCR) 🌙

Definition: SCR is an upper bound on the conforming average rate of an ATM connection over time scales that are long compared to the ones PCR is defined for. If the UPC enforces this bound, the network can allocate sufficient resources. That's less than what PCR-based allocation would need, and the performance objectives (for example, Cell Loss Ratio) can still be achieved. Budget glow-up 💸

Discussion: SCR limits the average data rate on an ATM connection. If a user violates the SCR, cells may be dropped, which causes Cell Loss. This in turn negatively impacts AAL5 PDUs, which may be carrying IP datagrams. See the discussion under SAR 🫠

Specification: AF-TM4.0

1.2.41. Switched Connection 🔀

Definition: A connection that gets established via signaling.

Discussion: none.

Specification: AF-UNI3.1

1.2.42. Switched Virtual Channel Connection (SVCC) 🦄

Definition: A Switched VCC is one that gets established and taken down dynamically through control signaling. A Virtual Channel Connection (VCC) is an ATM connection where switching is done on the VPI/VCI fields of each cell.

Discussion: none.

Specification: AF-UNI3.1

1.2.43. Switched Virtual Circuit (SVC) 📞

Definition: A connection that gets established via signaling. The user defines the endpoints when the call is initiated.

Discussion: SVCs are established using either UNI signaling or PNNI signaling. The signaling state machine implements several timers, and those can effect the time required for call establishment. That will effect TCP round trip time calculation, which then effects TCP throughput. There are two possibilities. If Call Proceeding is not implemented, there is only one timer, T310, with a value of 10 seconds. If Call Proceeding is implemented, there are two timers, T303 and T310, with the values 4 and 10 seconds. Either way, if T303 or T310 expires after a Setup message is sent, the calling party has the option to re-transmit the Setup. In the T303 case, that gives a maximum setup time of 18 seconds. In the T310 case, it's 20 seconds. So the initial TCP RTT calculation will be on the order of 20 seconds. Wait is real 🕰️😭

Specification: AF-UNI3.1, AF-UNI4.0, AF-PNNI1.0

1.2.44. Switched Virtual Path Connection (SVPC) 🌺

Definition: A Switched Virtual Path Connection is one that gets established and taken down dynamically through control signaling. A Virtual Path Connection (VPC) is an ATM connection where switching is done on the VPI field only of each cell.

Discussion: none.

Specification: AF-UNI3.1

1.2.45. Traffic Contract 📜

Definition: A specification of the negotiated traffic characteristics of an ATM connection.

Discussion: See the discussions under BT, CAC, CDV, GCRA, PCR, and SCR. Read the group chat before you sign anything 📖

Specification: AF-TM4.0

1.2.46. Traffic Management (TM) 🚦

Definition: Traffic Management is the aspect of the traffic control and congestion control procedures for ATM. ATM layer traffic control refers to the set of actions the network takes to avoid congestion conditions. ATM layer congestion control refers to the set of actions the network takes to minimize the intensity, spread, and duration of congestion. The following functions form a framework for managing and controlling traffic and congestion in ATM networks, and they may be used in appropriate combinations:

   Connection Admission Control
   Feedback Control
   Usage Parameter Control
   Priority Control
   Traffic Shaping
   Network Resource Management
   Frame Discard
   ABR Flow Control

Discussion: See CAC and traffic shaping.

Specification: AF-TM4.0

1.2.47. Traffic Shaping (TS) 🎨

Definition: Traffic Shaping is a mechanism that alters the traffic characteristics of a stream of cells on a connection. The goal is better network efficiency while still meeting the QoS objectives, or ensuring conformance at a subsequent interface. Traffic shaping must maintain cell sequence integrity on a connection. Shaping changes the traffic characteristics of a cell flow, with the consequence of increasing the mean Cell Transfer Delay. A little delay for a lot of organization 🧘

Discussion: TS should improve TCP throughput by reducing RTT variations. As a result, TCP RTT calculations should be more stable. Stability era 🌷

Specification: AF-UNI3.1

1.2.48. Transmission Convergence (TC) 🌊

Definition: A sub-layer of the physical layer of the B-ISDN model transforms the flow of cells into a steady flow of bits and bytes for transmission over the physical medium. On transmit, the TC sublayer maps the cells to the frame format, generates the Header Error Check (HEC), and sends idle cells when the ATM layer has none to send. On reception, the TC sublayer delineates individual cells in the received bit stream and uses the HEC to detect and correct received errors. It's the unsung hero of the whole stack 🫡

Discussion: TC is not a measurement itself, but the speed at which TC can occur on a bit stream can be measured. This measurement will not be discussed in this document. However, its value should be constant and small with respect to cell inter-arrival at the maximum data rate.

Specification: AF-UNI3.1

1.2.49. Unspecified Bit Rate (UBR) 💖

Definition: okay so UBR is an ATM service category that doesn't promise any traffic-related service guarantees 🫠. There's no per-connection negotiated bandwidth, period. Nobody commits to a cell loss ratio or to how long cells take to cross the connection. It's very "we'll try our best" energy 💅

Discussion: RFC 2331 is where the UBR service class for IP over ATM gets specified 🦋. UBR basically models the "best effort" service type from RFC 791, but it has real drawbacks for TCP 😭. Since UBR doesn't guarantee anything about cell loss (CL), cell delay variation (CDV) or cell mis-insertion (CM), TCP RTT estimates end up super variable. All of that also messes with AAL5 re-assembly, which can then cause packet loss. See the discussions under CDV and SAR 🔥.

Specification: AF-TM4.0

1.2.50. Usage Parameter Control (UPC) 🎀

Definition: Usage Parameter Control is the set of actions the network takes to monitor and control traffic 🧚. It looks at how much traffic is being offered and whether the ATM connection is valid, right at the end-system access. The main goal is protecting network resources from both malicious and accidental misbehavior, because that stuff can wreck the QoS of connections that are already up. It does this by spotting violations of negotiated parameters and then taking appropriate action 👑.

Discussion: See the discussions under BT, CAC, CDV, GCRA, PCR and SCR ✨.

Specification: AF-TM4.0

1.2.51. User-Network Interface (UNI) 🌸

Definition: this is the interface point between ATM end users and a private ATM switch, or between a private ATM switch and the public carrier ATM network 🏠. It's defined by physical and protocol specifications in the ATM Forum UNI documents. Basically it's the standard the ATM Forum adopted for connections between users or end stations and a local switch 🔌.

Discussion: none 🤷‍♀️

Specification: AF-UNI3.1

1.2.52. Variable Bit Rate (VBR) 🦋

Definition: an ATM Forum defined service category that supports variable bit rate data traffic, using average and peak traffic parameters 📈.

Discussion: VBR can potentially hurt TCP throughput because of big RTT variations 😬. That in turn makes the TCP RTT estimates unstable, which is not it 💀.

Specification: AF-TM4.0

1.2.53. Virtual Channel (VC) 🧁

Definition: a communications channel that gives you sequential, unidirectional transport of ATM cells ➡️.

Discussion: none 🙃

Specification: AF-TM3.1

1.2.54. Virtual Channel Connection (VCC) 🌈

Definition: a concatenation of VCIs that stretches between the points where ATM service users access the ATM layer 💫. The places where the ATM cell payload gets handed off to, or received from, the users of the ATM Layer (so a higher layer or an ATM-entity) for processing mark the endpoints of a VCC. VCCs are unidirectional, so they only go one way 💜.

Discussion: none 🫶

Specification: AF-TM3.1

1.2.55. Virtual Channel Identifier (VCI) ⭐

Definition: a unique numerical tag, defined by a 16 bit field in the ATM cell header, that identifies the virtual channel the cell is supposed to travel over 🏷️.

Discussion: none 🌷

Specification: AF-UNI3.1

1.2.56. Virtual Path (VP) 🍓

Definition: a unidirectional logical association or bundle of VCs 🧺.

Discussion: none 🙈

Specification: AF-UNI3.1

1.2.57. Virtual Path Connection (VPC) 🌸

Definition: a concatenation of VPIs between Virtual Path Terminators (VPTs). VPCs are unidirectional 💖.

Discussion: none ✨

Specification: AF-TM3.1

1.2.58. Virtual Path Identifier (VPI) 🦄

Definition: an eight-bit field in the ATM cell header that says which virtual path the cell should get routed over 🗺️.

Discussion: none 💅

Specification: AF-UNI3.1

2. Performance Metrics 📊

2.1. Definition Format (from RFC 1242) 🎀

Okay so this is the template for defining a metric 📝. The first thing you do is state the metric that's being defined.

Definition: the specific definition for the metric 🎯.

Discussion: a brief discussion of the metric, its application, and any restrictions on measurement procedures 🧐.

Measurement units: the intrinsic units used to quantify this metric. That includes subsidiary units too, so for example microseconds are fine if the intrinsic unit is seconds ⏱️.

2.2. Definitions 🫧

2.2.1. Physical Layer - SONET 🌊

2.2.1.1. Pointer Movements

Hmm, I need to keep the formatting level, so here it is as ###:

2.2.1.1. Pointer Movements 👀

Definition: Pointer Movements is the number of changes in a SONET pointer due to clock synchronization slips ⏰.

Discussion: SONET Pointer Movements can cause loss of information in the SONET payload envelop (SPE), which carries IP datagrams either as ATM cells or as PPP delimited PDUs 📦. It's giving data loss 😭.

Measurement Units: Per second.

2.2.1.2. Transport Overhead Error Count 🔢

Definition: SONET Transport Overhead Error Count is the number of SONET transport overhead errors that get detected 🕵️‍♀️.

Discussion: SONET Transport Overhead Errors SONET Transport Overhead Errors cause SONET frames to be lost. Those frames may contain IP datagrams, either in the form of cells or as PPP delimited PDUs 🥺.

Measurement Units: Positive integer

2.2.1.3. Path Overhead Error Count 🧮

Definition: SONET Path Overhead Error Count is the number of SONET path overhead errors that get detected 🔍.

Discussion: SONET Path Overhead Errors cause SONET frames to be lost. Those frames may contain IP datagrams, either in the form of cells or as PPP delimited PDUs 💀.

Measurement Units: Positive integer

2.2.2. ATM Layer ☁️

2.2.2.1. Cell Delay Variation (CDV) 🌪️

Definition: the variation in cell transfer delay (CTD) that goes with a given traffic load, orientation and distribution, plus an integration period 📉.

CDV = max (CTD) - min (CTD)

Where max and min indicate the maximum and minimum over the integration period, respectively 💫.

Discussion: CDV is a component of cell transfer delay, caused by buffering and cell scheduling 🗂️. Peak-to-peak CDV is a QoS delay parameter tied to CBR and VBR services. The peak-to-peak CDV is the ((1-a) quantile of the CTD) minus the fixed CTD that any delivered cell on a connection could experience during the entire connection holding time 🎢. The parameter "a" is the probability of a cell arriving late ⏳.

CDV affects TCP round trip time calculations. Big CDV values will hurt TCP throughput and cause SAR timeout, so see the discussion under SAR 🚨.

Measurement Units: seconds

2.2.2.2. Cell Error Ratio (CER) 🧩

Definition: the ratio of cells with payload errors in a transmission, compared to the total number of cells sent in that transmission, for a given traffic load, orientation and distribution, plus an integration period 📊. Errors in the cell header cause cell loss at the ATM layer, so keep that in mind 👀. Multiple errors in one payload only count as one cell payload error ✌️.

CER = Cells with payload errors / Total Cells Transmitted.

Discussion: the measurement is taken over a time interval, and it's best measured on an in-service circuit 🔌. CER is closely related to the number of corrupted AAL5 PDUs, but there's no direct numerical correlation between the number of errored cells and the number of corrupted AAL5 PDUs. There are two cases to know about 🧠.

  1. Only one cell in an AAL5 PDU contains payload errors. In this case, there's a one-to-one correspondence between cell payload errors and the number of corrupted AAL5 PDUs 🎯.
  2. Multiple cells in the AAL5 PDU contain payload errors. In this case, there's no one-to-one correspondence between cell payload errors and the number of corrupted AAL5 PDUs 🌀.

Measurement Units: dimensionless.

2.2.2.3. Cell Loss Ratio (CLR) 📉

Definition: the ratio of lost cells in a transmission compared to the total cells sent in that transmission, for a given traffic load, orientation and distribution, plus an integration period 🕳️.

CLR = Lost Cells / Total Cells Transmitted.

Discussion: CLR is a negotiated QoS parameter, and acceptable values are network specific 🤝. The objective is to minimize CLR, as long as the end-system adapts its traffic to the changing ATM layer transfer characteristics 🔄. The CLR parameter is the value of CLR that the network agrees to offer as an objective over the lifetime of the connection. It's expressed as an order of magnitude, with a range of 10^-1 to 10^-15 and unspecified 🔢.

CLR shows how many ATM cells got lost compared to the total number sent. It's closely related to the number of corrupted AAL5 PDUs, but there's no direct numerical correlation between the number of cells lost and the number of corrupted AAL5 PDUs. See the discussion under SAR 💖.

Measurement Units: dimensionless.

2.2.2.4. Cell Misinsertion Ratio (CMR) 🫣

Definition: the ratio of cells received at an endpoint that the source end never originally transmitted, compared to the total number of cells properly transmitted, for a given traffic load, orientation and distribution, plus an integration period 🕵️.

CMR = Misinserted Cells / Total Cells Transmitted.

Discussion: the measurement is taken over a time interval, and it's best measured on an in-service circuit 🔌. CMR is closely related to the number of corrupted AAL5 PDUs, but there's no direct numerical correlation between the number of mis-inserted cells and the number of corrupted AAL5 PDUs. Two cases again 👯.

  1. Only one cell is mis-inserted into an AAL5 PDU. In this case, there's a one-to-one correspondence between cell mis-insertion and the number of corrupted AAL5 PDUs 🎯.
  2. Multiple cells are mis-inserted into an AAL5. In this case, there's no one-to-one correspondence between cell mis-insertion and the number of corrupted AAL5 PDUs 🌀.

Measurement Units: dimensionless.

2.2.2.5. Cell Rate Margin (CRM) 🪙

Definition: a measure of the difference between the effective bandwidth allocation and the allocation for sustainable rate, in cells per second 🧮.

Discussion: this measures the amount of provisioned bandwidth that goes unused 🫥. That lack of utilization can be caused by encapsulation overhead, like the AAL5 trailer and padding, or by the protocol itself, like how TCP usually transmits in only one direction ↔️.

Measurement units: Cells per second

2.2.2.6. CRC Error Ratio 🧷

Definition: the ratio of PDUs received at an endpoint that contain an invalid CRC, compared to the total number of cells properly transmitted, for a given traffic load, orientation and distribution, plus an integration period 📏.

Discussion: CRC errors cause ATM cells to be lost 💔. Although that shows up as cell loss at the ATM layer, this measurement can be made in-service using a test probe that measures CRC errors at the TC layer 🧪.

Measurement Units: dimensionless

2.2.2.7. Cell Transfer Delay (CTD) ⏱️

Definition: the elapsed time between a cell exit event at measurement point 1 (for example, at the source UNI) and the corresponding cell entry event at measurement point 2 (for example, the destination UNI) for a particular connection 🛫🛬.

Discussion: the cell transfer delay between two measurement points is the sum of the total inter-ATM node transmission delay and the total ATM node processing delay 🧾. This number is a constant and shouldn't adversely affect performance, but it's still a component in RTT 🫠.

Measurement units: seconds

2.2.3. ATM Adaptation Layer (AAL) Type 5 (AAL5) 🌟

2.2.3.1. AAL5 Re-assembly Errors ✨

Definition: Any error that makes the AAL5 PDU corrupted counts as an AAL5 Re-assembly Error. 💅

Discussion: AAL5 Re-assembly Errors cause AAL5 PDUs to get lost, and those PDUs can be carrying IP datagrams. Bestie, that's a whole vibe check on your data 😭

Measurement Units: Positive Integer

2.2.3.2. AAL5 Reassembly Time ⏱️

Definition: AAL5 Reassembly Time is the gap between the final cell of an AAL5 PDU arriving and the PDU's payload being handed up to the service layer. 🦋

Discussion: AAL5 Reassembly Time directly affects TCP round trip time calculations, so it matters a LOT for how snappy your connection feels 🔥

Measurement Units: seconds

2.2.3.3. AAL5 CRC Error Ratio 🧮

Definition: This is the ratio of PDUs received at an endpoint that contain an invalid CRC, compared to the total number of cells properly transmitted. It's measured against a given traffic load, orientation and distribution, plus an integration period. 💖

Discussion: AAL5 CRC errors lead to AAL5 Re-assembly Errors, so check out the discussion under AAL5 Re-assembly Errors for the full tea 🍵

Measurement Units: dimensionless

2.2.4. ATM Service: Signaling 📞

2.2.4.1. CAC Denial Time 🙅‍♀️

Definition: This is how long CAC takes to decide that a call has to be rejected. ⏳

Discussion: When Call Proceeding is implemented, this number stays under 4 seconds. If it isn't, the number stays under 10 seconds. Big values here hurt performance on systems that have an alternate, non-NBMA, service available, so keep an eye on it 👀

Measurement Units: seconds

2.2.4.2. Connection Establishment Time 🤝

Definition: This is the time between the first Setup message from the calling party and the Connect message going back to the calling party. 💌

Discussion: See the discussion under SVC. Iykyk 💅

Measurement Units: seconds

2.2.4.3. Connection Teardown Time 🧹

Definition: This is the time between the Release message being sent and the Release Complete message being received. 🌙

Discussion: Big values of this measurement hurt performance in systems where the total number of open calls or VCs is limited. Here's the bad part: a new VC can't be set up with the same VPI/VCI until the old one has been released. Not it being stuck in the chat 😭

Measurement Units: seconds

2.2.4.4. Crankback Time 🔙

Definition: This is the time between the switch where the current Designated Transit List (DTL) is blocked sending out its first release or release complete message, and the target switch receiving the SETUP with the updated DTLs. 🧭

Discussion: This measurement doesn't count the time spent on the successful part of the call setup transit, or the time the calling party needs to hear back from the called party. So the call can still fail to complete if the call setup timer on the calling party runs out. Main character drama ⏰

See the discussion under SVC.

Measurement Units: seconds

2.2.4.5. Route Update Response Time 🗺️

Definition: This is the time between a switch receiving a PNNI Topology State Element (PTSE), which is the PNNI routing PDU, with a topology that's different from the current one, and the moment that switch starts generating DTLs that reflect the routing change. 🔄

Discussion: This measurement gives you a lower bound on how long SETUP messages keep getting forwarded along a sub-optimal or blocked path. Not ideal, periodt 🙈

Measurement Units: seconds

2.2.5. ATM Service: ILMI 🌸

2.2.5.1. MIB Alignment Time 📚

Definition: This is the time between the final cold start message being issued and the final get response that comes back from the exchange of static MIB information. 🎀

Discussion: This measurement shows how long the switch and end system need to swap all the info they need to figure out and line up each other's capabilities. It doesn't include address registration. Also, this number depends on how many MIB elements both systems have implemented, so it's not one-size-fits-all 🧚

Measurement Units: seconds

2.2.5.2. Address Registration Time 📍

Definition: This is the time between the initial set request issued by the switch and the final get response issued by the switch. 💜

Discussion: This measurement assumes the switch has checked the network prefix status object, and the end system has checked the ATM address status object. But if the end system only checks the ATM address status object after the switch has already sent a set request for the network prefix status object, this measurement won't show the real time it takes to finish address registration. Plot twist 😭

Measurement Units: seconds

3. Security Considerations 🔐

This document is purely about giving you terminology. It doesn't describe a protocol or an implementation, so there are no security considerations for it. Zero drama here, bestie 💅

4. Notices 📣

The IETF doesn't take a position on whether any intellectual property or other rights claimed around the technology in this document are valid or in scope, or on whether any license under those rights is or isn't available. It also doesn't say it has tried to find any such rights. If you want the IETF's procedures for rights in standards-track and standards-related documents, look at BCP-11. 📜

Copies of rights claims that were made available for publication, plus any assurances of licenses that will be made available, or the outcome of an attempt to get a general license or permission to use such proprietary rights by implementors or users of this specification, can be obtained from the IETF Secretariat. 🗂️

The IETF invites any interested party to tell it about any copyrights, patents or patent applications, or other proprietary rights that may cover technology required to practice this standard. Send that info to the IETF Executive Director. 💌

5. References 📚

  • [AF-ILMI4.0] ATM Forum Integrated Local Management Interface Version 4.0, af-ilmi-0065.000, September 1996. 🌈
  • [AF-TEST-0022] Introduction to ATM Forum Test Specifications, af-test-0022.00, December 1994. 🧪
  • [AF-TM4.0] ATM Forum, Traffic Management Specification Version 4.0, af-tm-0056.00, April 1996. 🚦
  • [AF-TM4.1] ATM Forum, Traffic Management Specification Version 4.1 (final ballot), btd-tm-01.02, July 1998. 🚦
  • [AF-UNI3.1] ATM Forum, User Network Interface Specification Version 3.1, September 1994. 🔌
  • [AF-UNI4.0] ATM Forum, User Network Interface Specification Version 4.0, July 1996. 🔌
  • [I.321] ITU-T, B-ISDN protocol reference model and its application, April 1991. 🧠
  • [I.363] ITU-T, B-ISDN ATM Adaptation Layer Specification series, 1996-1997. 🧩
  • [I.363.5] ITU-T, B-ISDN ATM Adaptation Layer Specification: Type 5 AAL, August 1996. 🧩

6. Editors' Addresses 💌

Jeffrey Dunn Advanced Network Consultants, Inc. 4214 Crest Place Ellicott City, MD 21043 USA

Phone: +1 (410) 750-1700 EMail: Jeffrey.Dunn@worldnet.att.net

Cynthia Martin Advanced Network Consultants, Inc. 11241-B Skilift Court Columbia, MD 21044 USA

Phone: +1 (410) 730-6300 EMail: Cynthia.E.Martin@worldnet.att.net

Copyright (C) The Internet Society (2000). All Rights Reserved.

This document and translations of it may be copied and furnished to others. Derivative works that comment on or explain it, or help with its implementation, may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind. The condition is that the above copyright notice and this paragraph are included on all such copies and derivative works. 🫶

However, this document itself may not be modified in any way, such as by removing the copyright notice or the references to the Internet Society or other Internet organizations. The exception is when it's needed to develop Internet standards, in which case the Internet Standards process copyright procedures must be followed, or when it's required to translate it into languages other than English. 🌍

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. ♾️

This document and the information in it are provided on an "AS IS" basis. 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 provided by the Internet Society. 💖

📦 where this page comes from