RFC 3337

Title Block 🎀

Okay bestie, this is RFC 3337 from the Network Working Group, dropped in December 2002 under the Standards Track category 💅. It's called Class Extensions for PPP over Asynchronous Transfer Mode Adaptation Layer 2 (AAL2). The authors are B. Thompson and T. Koren from Cisco Systems, plus B. Buffam from Seaway Networks 🫶. The title block doesn't list anything it obsoletes or updates, so it's not replacing or changing any other RFC 🦋.

Status of This Memo ✨

This document is an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 💖. If you want to know where this protocol stands in standardization, check the current edition of the "Internet Official Protocol Standards" (STD 1) 📚. Distribution of this memo is unlimited 🌈.

Copyright Notice 🌸

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

Abstract 🦋

Okay so the Point-to-Point Protocol (PPP) over Asynchronous Transfer Mode (ATM) Adaptation Layer 2 is the encapsulation that lets a PPP session get carried over an ATM virtual circuit using the AAL2 adaptation layer 🧚. This document adds a set of class extensions to PPP over AAL2 that do the same job as Multi Class Multi Link PPP over a single ATM virtual circuit 🔥. The twist is that instead of using Multi Link PPP for fragmentation, it uses the fragmentation powers of the Segmentation and Reassembly Service Specific Convergence Sublayer, which PPP over AAL2 already needs as its basic encapsulation format 💅.

1. Introduction ✨

Using AAL2 as the adaptation layer for PPP over ATM gives you a bandwidth efficient transport for IP apps that send lots of small packets 🍓. A big example is RTP encapsulated voice, aka Voice over IP 🎀.

Bandwidth isn't the only thing that matters, though. Real-time stuff like voice needs low latency too 😭. RFC 2689 [2] describes an architecture for real-time transport services on low bit rate links 💜. Its main parts are: a real-time encapsulation format for asynchronous and synchronous low-bitrate links, a header compression architecture optimized for real-time flows, elements of negotiation protocols used between routers (or between hosts and routers), and announcement protocols that applications use so the negotiation can happen 🌈.

Multi Class Multi Link PPP [3] is the fragment-oriented answer for the real-time encapsulation format part of that architecture [2], meaning the queues-of-fragments type sender 🧚. The architecture document goes into more detail, but the gist is that a real-time encapsulation format has to guarantee low latency even when big non-real-time packets are around 😤. For example, a 1500 byte packet on a 128 kbit/s ATM virtual circuit keeps that link busy for about 100 ms, so real-time traffic can't get through during that time ⏳. That adds a worst-case delay, and real-time apps end up with round-trip delays that are too high for a lot of interactive tasks 💀. Multi Class Multi Link PPP fixes this by defining a set of extensions to Multi Link PPP [4] so the sender can fragment packets of different priorities into multiple classes of fragments. That way high-priority packets can get sent between the fragments of lower-priority ones 👑.

This document defines a set of class extensions to PPP over AAL2 [1] that do the same job as Multi Class Multi Link PPP over a single ATM virtual circuit 🦋. Instead of building on Multi Link PPP for fragmentation, it uses the Service Specific Segmentation and Reassembly Sublayer (SSSAR) [5], which PPP over AAL2 already requires as its basic encapsulation format 🫶.

Beyond fragmenting, the real-time transport service has to let high-priority fragments slip in between lower-priority fragments 🔥. In PPP over AAL2, you can do this by letting one PPP session span multiple AAL2 CPS [6] Channel Identifiers 💖. Once a PPP session spans multiple AAL2 Channel IDs, the Channel ID can tell you which class a fragment belongs to. Fragments from a high-priority class go out on one particular AAL2 Channel ID, and lower-priority fragments go out on different ones. With multiple fragment classes sorted into different AAL2 Channel IDs, the AAL2 CPS layer can then slide high-priority class fragments in between the lower-priority ones 🎀.

These class-based extensions use services that the AAL2 SSCS and CPS layers already offer and that PPP over AAL2 already specifies 🌸. Because of that, the extensions here could be seen as a desirable alternative to Multi Class Multi Link PPP for providing a class-based transport service with PPP over AAL2 🧚.

1.1. Specification Language 💅

The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in [7] 🙈.

2. Requirements ✨

This document assumes the same service requirements as Multi Class Multi Link PPP [3] 🌈. For the general requirements of a multi class fragmentation / preemption service, go check section 2 of Multi Class Multi Link PPP 📚.

3. Class Extensions for PPP over AAL2 🦋

PPP over AAL2 uses the Service Specific Segmentation and Reassembly Sublayer (SSSAR) [5] for AAL type 2 🧚. SSSAR is what chops PPP packets into frames that the AAL2 CPS can carry 🔥. It uses different AAL2 UUI code-points to say whether a segment is the last segment of a packet or not 💖. SSSAR gives basic fragmentation for every packet sent over PPP over AAL2, and it fragments all packets into 64 byte fragments 🍓.

The AAL2 CPS layer defines a Channel ID that identifies multiple streams of packets inside a single ATM Virtual Circuit 💜. In this document, the AAL2 CPS Channel ID is used to identify the preemption class that a packet fragment belongs to 👑. Since the Channel ID tells you the preemption class, packet fragments from each class of traffic MUST be assigned to different Channel IDs 🫶. On top of that, each PPP session MUST have at least as many Channel IDs assigned as there are different classes of preemptible traffic 💅.

To let PPP packets land in different preemption classes, the packets have to be classified into multiple preemption classes as they get fragmented using SSSAR 🎀. There are lots of ways to decide which class a PPP packet belongs to 🌸. The architecture document [2] describes possible alternatives that MAY be used to implement a real-time classification scheme 🧚.

Once packets are classified, each class of traffic gets its own Channel ID 🌈. Because fragments from each traffic class now go out on a separate Channel ID, the AAL2 CPS layer can schedule fragments from the different classes 🔥. The AAL2 CPS specification [6] doesn't specify how to schedule AAL2 CPS payloads from different Channel IDs 😤. Which scheduling method the AAL2 CPS layer needs depends on what real-time requirements the apps using this service have 💀. Some real-time applications MAY require a priority-based CID scheduler 👑. Other applications MAY only require a fair or weighted fair CID scheduler 🦋. Implementations of PPP over AAL2 real-time transport extensions SHOULD implement AAL2 CPS CID schedulers that meet the requirements of multi-class real-time applications 💖.

---

To be continued in part 2 🌸🎀

8. Authors' Addresses ✨

okay bestie, here are the people who wrote this 🫶 three authors, all named Bruce or Tmima, all with their contact details listed right here:

   Bruce Thompson
   Cisco Systems, Inc.
   170 West Tasman Drive
   San Jose, CA 95134
   USA

   Phone: +1 408 527-0446
   EMail: brucet@cisco.com


   Bruce Buffam
   Seaway Networks
   One Chrysalis Way,
   Suite 300,
   Ottawa, Canada
   K2G-6P9

   Phone: +1 613 723-9161
   EMail: bruce@seawaynetworks.com


   Tmima Koren
   Cisco Systems, Inc.
   170 West Tasman Drive
   San Jose, CA 95134
   USA

   Phone: +1 408 527-6169
   EMail: tmima@cisco.com

9. Full Copyright Statement 💅

okay so this part is the legal stuff, and I'm keeping it word for word because it's giving very serious lawyer energy 💀 here's the whole thing:

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

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided 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 references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as 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 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

last bit, and it's a sweet one 🌸 the RFC Editor function is funded right now by the Internet Society. so the people keeping these documents running get a little help from them ✨