idnits 2.17.1 draft-ietf-pppext-ppp-over-aal2-class-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 277 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 74 instances of too long lines in the document, the longest one being 7 characters in excess of 72. ** There is 1 instance of lines with control characters in the document. ** The abstract seems to contain references ([2], [3], [4], [5], [6], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 106: '...The keywords MUST, MUST NOT, REQUIRED,...' RFC 2119 keyword, line 107: '...RECOMMENDED, MAY, and OPTIONAL, when t...' RFC 2119 keyword, line 140: '...[2] describes possible alternatives that MAY be used to implement a real...' RFC 2119 keyword, line 150: '...ime applications MAY require the use o...' RFC 2119 keyword, line 151: '...her applications MAY only require a fa...' (1 more instance...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. '1' ** Downref: Normative reference to an Informational RFC: RFC 2689 (ref. '2') -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' Summary: 12 errors (**), 0 flaws (~~), 3 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Point-to-Point Protocol Extensions Working Group Bruce Thompson 2 Internet Draft Tmima Koren 3 February 4, 2002 Cisco Systems 4 Expires July 2002 Bruce Buffam 5 draft-ietf-pppext-ppp-over-aal2-class-02.txt Camelot Content 7 Class Extensions for PPP over ATM Adaptation Layer 2 9 Status of this memo 11 This document is an Internet Draft and is in full conformance with all 12 provisions of Section 10 of RFC 2026. Internet Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its Areas, and 14 its Working Groups. Note that other groups may also distribute working 15 documents as Internet Drafts. 17 Internet Drafts are draft documents valid for a maximum of six months. 18 Internet Drafts may be updated, replaced, or obsolete by other 19 documents at any time. It is not appropriate to use Internet Drafts as 20 reference material or to cite them other than as "work in progress". 22 The list of current Internet-Drafts can be accessed at: 23 http://www.ietf.org/ietf/1id-abstracts.txt 25 The list of Internet-Draft Shadow Directories can be accessed at: 26 http://www.ietf.org/shadow.txt 28 This draft is being submitted as a possible work item to the IETF 29 Audio/Video Transport working group. To subscribe to the mailing list 30 send a message to rem-conf-request@es.net with the line "subscribe" in 31 the body of the message. Archives are available from: 32 ftp://ftp.es.net/pub/mail-archive/rem-conf 34 Copyright Notice 36 Copyright (C) The Internet Society (1999-2001). All Rights Reserved. 38 Abstract 40 PPP over ATM Adaptation Layer 2 defines the encapsulation that allows a PPP 41 session to be transported over an ATM virtual circuit using the AAL2 adaptation 42 layer. This document defines a set of class extensions to PPP over AAL2 that 43 implement equivalent functionality to Multi Class Multi Link PPP over a single 44 ATM virtual circuit. Instead of using Multi Link PPP as the basis for 45 fragmentation functionality, this document uses the functionality of the 46 Segmentation and Reassembly Service Specific Convergence Sublayer that is 47 already required as the basic encapsulation format of PPP over AAL2. 49 1. Introduction 51 Using AAL2 as an adaptation layer for PPP transport over ATM provides a 52 bandwidth efficient transport for IP applications that generate small 53 packets. An example IP application that generates small packets is RTP 54 encapsulated voice (Voice over IP). 56 In addition to bandwidth efficiency, real-time applications such as voice 57 require low latency. RFC 2689 [2] describes an architecture for providing 58 transport services for real time applications on low bit rate links. The 59 main components of the architecture are: a real-time encapsulation format 60 for asynchronous and synchronous low-bitrate links, a header compression 61 architecture optimized for real-time flows, elements of negotiation 62 protocols used between routers (or between hosts and routers), and 63 announcement protocols used by applications to allow this negotiation to 64 take place. 66 Multi Class Multi Link PPP [3] defines a fragment-oriented solution for the 67 real-time encapsulation format part of the architecture defined in [2], i.e. 68 for the queues-of-fragments type sender. As described in more detail in the 69 architecture document, a real-time encapsulation format is required as, 70 e.g., a 1500 byte packet on a 128 kbit/s ATM virtual circuit makes this link 71 unavailable for the transmission of real-time information for about 100 ms. 72 This adds a worst-case delay that causes real-time applications to operate 73 with round-trip delays that are too high for many interactive tasks. Multi 74 Class Multi Link PPP defines a set of extensions of Multi Link PPP [4] that 75 enable the sender to fragment the packets of various priorities into 76 multiple classes of fragments, allowing high-priority packets to be sent 77 between fragments of lower priorities. 79 This document defines a set of class extensions to PPP over AAL2 [1] that 80 implement equivalent functionality to Multi Class Multi Link PPP over a 81 single ATM virtual circuit. Instead of using Multi Link PPP as the basis for 82 fragmentation functionality, this document uses the functionality of the 83 Segmentation and Reassembly Service Specific Convergence Sublayer (SSSAR)[5] 84 that is already required as the basic encapsulation format of PPP over AAL2. 86 In addition to providing fragmentation, the real time transport service must 87 allow high priority fragments to be sent between fragments of lower 88 priorities. This can be accomplished in PPP over AAL2 by allowing a single 89 PPP session to span multiple AAL2 CPS [6] Channel Identifiers. Once a PPP 90 session spans multiple AAL2 Channel IDs, the Channel ID can be used to 91 identify the class that a fragment belongs to. Fragments belonging to a high 92 priority class can be sent using a particular AAL2 Channel ID. Fragments of 93 lower priority classes can be sent using different AAL2 Channel IDs. Once 94 multiple fragment classes are identified using different AAL2 Channel IDs, 95 the AAL2 CPS layer can be used to send fragments belonging to a high 96 priority class between fragments of lower priorities. 98 The class based extensions to PPP over AAL2 use existing services of the 99 AAL2 SSCS and CPS layers already specified in PPP over AAL2. Because of 100 this, the extensions described in this draft may be viewed as a desirable 101 alternative to Multi Class Multi Link PPP in providing a class based 102 transport service with PPP over AAL2. 104 1.1. Specification Language 106 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, 107 RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be 108 interpreted as described in [6]. 110 2. Requirements 112 This document assumes the same service requirements as defined in Multi 113 Class Multi Link PPP [3]. The reader is referred to section 2 of Multi Class 114 Multi Link PPP for the general requirements of a multi class fragmentation / 115 preemption service. 117 3. Class Extensions for PPP over AAL2 119 PPP over AAL2 uses the Segmentation and Reassembly Service Specific 120 Convergence Sublayer (SSSAR) [5] for the AAL type 2. The SSSAR sublayer is 121 used to segment PPP packets into frames that can be transported using the 122 AAL2 CPS. The SSSAR sublayer uses different AAL2 UUI code-points to indicate 123 whether a segment is the last segment of a packet or not. SSSAR provides 124 basic fragmentation functionality for all packets encapsulated using PPP 125 over AAL2. The SSSAR layer fragments all packets into 64 byte fragments. 127 The AAL2 CPS layer defines a Channel ID that is used to identify multiple 128 streams of packets within a single ATM Virtual Circuit. In this document, 129 the AAL2 CPS Channel ID is used to identify the preemption class that a 130 packet fragment belongs to. Since the Channel ID is used to identify 131 different preemption classes, packet fragments from each class of traffic 132 MUST be assigned to different Channel IDs. In addition, each PPP session 133 MUST have at least as many Channel IDs assigned as there are different 134 classes of preemptible traffic. 136 To allow PPP packets to be assigned to different preemption classes, PPP 137 packets must be classified into multiple preemption classes as they are 138 fragmented using SSSAR. Many classification methods may be used to determine 139 the class that a particular PPP packet belongs to. The architecture document 140 [2] describes possible alternatives that MAY be used to implement a real 141 time classification scheme. 143 Once packets have been classified into different premption classes, each 144 class of traffic is then assigned a different Channel ID. Since fragments 145 from each traffic class are now transmitted using separate Channel ID, the 146 AAL2 CPS layer can be used to schedule fragments from the different classes. 147 The AAL2 CPS specification [6] does not specify a method for scheduling AAL2 148 CPS payloads from different Channel IDs. The scheduling method required at 149 the AAL2 CPS layer depends upon the real time requirements of applications 150 using this service. Some real-time applications MAY require the use of a 151 priority based CID scheduler. Other applications MAY only require a fair or 152 weighted fair CID scheduler. Implementations of PPP over AAL2 real time 153 transport extensions SHOULD implement AAL2 CPS CID schedulers that meet the 154 requirements of multi-class real time applications. 156 4. Example Implementation: Class Based Extensions for Voice Service 158 When PPP over AAL2 is used to transport both voice and non-voice packets over 159 low bandwidth ATM virtual circuits, it may be necessary to preempt the 160 transmission of a large data packet in order to transmit a voice packet with 161 minimal delay. The example implementation described below shows an example of 162 how the class extensions for PPP over AAL2 can be used to support a real time 163 voice transport service over low bandwidth AAL2 virtual circuits. To 164 guarantee low latency and loss for voice transport, the ATM virtual circuit 165 in this example must be provisioned using a real time traffic class such as 166 VBRnrt or VBRrt. 168 For the simple voice service described above, 2 classes are sufficient to 169 guarantee low latency for voice packets. The PPP over AAL2 session in this 170 case can be configured to run across 2 AAL2 CPS Channel IDs. One channel ID 171 is used to transport large data packets while the other channel ID is used to 172 transport real time voice packets. 174 Packets that arrive at the PPP interface must first be classified as either 175 belonging to the real time class or belonging to the data class. A simple 176 classifier that can be used to classify packets at this layer is packet size. 177 Large packets are assigned to the non-real time (or data) traffic class and 178 small packets are assigned to the real time traffic class. The packet size 179 used to discriminate between real time and non real time packets may vary 180 based on the application and transmission rate of the virtual circuit. 182 Once packets have been classified, they are now fragmented using the SSSAR 183 layer of PPP over AAL2. Separate instances of the SSSAR fragmentation 184 function run on each of the 2 Channel IDs assigned to the PPP session. 185 Fragments coming from the SSSAR functions are now scheduled into the AAL2 186 virtual circuit using the AAL2 CPS layer. Most AAL2 SAR implementations 187 currently implement fair scheduling across multiple AAL2 Channel IDs. Since 188 the AAL2 CPS scheduler implements fair scheduling, real time fragments will 189 wait for at most one non-real time fragment to be transmitted on the AAL2 190 virtual circuit before being scheduled. 192 7. Security Considerations 194 Operation of this protocol is believed to be no more and no less secure than 195 operation of PPP over AAL2 [1]. 197 8. Acknowledgements 199 The authors would like to thank James Carlson for his contributions to this 200 proposal. 202 9. References 204 [1] B. Thompson, T. Koren, B. Buffam, PPP over AAL2, January 2002 206 [2] Bormann, C., "Providing Integrated Services over Low-bitrate 207 Links", RFC 2689, September 1999. 209 [3] Bormann, C., "The Multi-Class Extension to Multi-Link PPP", RFC 2686, 210 September 1999. 212 [4] Sklower, K., Lloyd, B., McGregor, G., Carr, D. and T. Coradetti, 213 "The PPP Multilink Protocol (MP)", RFC 1990, August 1996. 215 [5] ITU-T, "Segmentation and Reassembly Service Specific Convergence 216 Sublayer for the AAL type 2", June 1998. 218 [6] ITU-T, "BISDN ATM Adaptation layer specification: 219 Type 2 AAL(AAL2)", September 1997. 221 10. Authors' Addresses 223 Bruce Thompson 224 Cisco Systems, Inc. 225 170 West Tasman Drive 226 San Jose, CA 95134 227 USA 228 Phone: +1 408 527-0446 229 Email: brucet@cisco.com 231 Bruce Buffam 232 Camelot Content Technologies 233 133 Centre Point Dr 234 Ottawa, Ontario, 235 Canada, K2G-5X3 236 Phone: +1 613 723-9161 X4017 237 Email: bruce@camelotcontent.com 239 Tmima Koren 240 Cisco Systems, Inc. 241 170 West Tasman Drive 242 San Jose, CA 95134 243 USA 244 Phone: +1 408 527-6169 245 Email: tmima@cisco.com 247 11. Full Copyright Statement 249 Copyright (C) The Internet Society (2001). All Rights Reserved. 251 This document and translations of it may be copied and furnished to 252 others, and derivative works that comment on or otherwise explain it 253 or assist in its implementation may be prepared, copied, published 254 and distributed, in whole or in part, without restriction of any 255 kind, provided that the above copyright notice and this paragraph 256 are included on all such copies and derivative works. However, this 257 document itself may not be modified in any way, such as by removing 258 the copyright notice or references to the Internet Society or other 259 Internet organizations, except as needed for the purpose of 260 developing Internet standards in which case the procedures for 261 copyrights defined in the Internet Standards process must be 262 followed, or as required to translate it into languages other than 263 English. 265 The limited permissions granted above are perpetual and will not be 266 revoked by the Internet Society or its successors or assigns. 268 This document and the information contained herein is provided on an 269 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 270 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 271 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 272 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 273 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.