idnits 2.17.1 draft-ietf-pppext-pppmux-02.txt: ** The Abstract section seems to be numbered 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. == There is 1 instance of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 8 pages 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. ** 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 154: '... The receiver MUST support Protocol...' RFC 2119 keyword, line 156: '...two bytes long. The transmitter SHOULD...' RFC 2119 keyword, line 171: '... Multiplexing MUST be disabled unti...' RFC 2119 keyword, line 260: '... LCP frames MUST NOT be sent in Mult...' RFC 2119 keyword, line 284: '... MUST be outside of a PPPmux header ...' (1 more instance...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 45 has weird spacing: '... with the A...' -- 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.) -- The document date (February 15, 2001) is 8470 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 7 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PPPext Working Group R. Pazhyannur, 3 I. Ali 4 Internet Engineering Task Force Motorola 5 Internet Draft C. Fox 6 Cisco Systems 8 Expires: August 15, 2001 February 15, 2001 10 PPP Multiplexing 11 draft-ietf-pppext-pppmux-02.txt 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026. Internet-Drafts are working 17 documents of the Internet Engineering Task Force (IETF), its areas, 18 and its working groups. Note that other groups may also distribute 19 working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other documents 23 at any time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 1. Abstract 34 This draft describes a method to reduce the PPP framing overhead 35 used to transport small packets over slow links. The method, PPP 36 Multiplexing, sends multiple PPP encapsulated packets in a single 37 PPP frame. As a result, the PPP overhead per packet is reduced. 39 2. Description 41 PPP encapsulation (for example with PPP in HDLC framing) adds 42 several bytes of overhead: a HDLC flag (at least one to separate 43 adjacent packets), the Address (0xFF) and Control (0x03) field 44 bytes, a two byte PPP Protocol ID, and the two byte CRC field. Even 45 with the Address and Control Fields negotiated off and the PPP 46 Protocol ID compressed, each PPP encapsulated frame will include 47 four bytes of overhead. When PPP frames are tunneled, as in L2TP 48 [1], the L2TP overhead per PPP frame is significant. 50 The key idea is to concatenate multiple PPP encapsulated frames into 51 a single PPP multiplexed frame by inserting a delimiter before the 52 beginning of each frame. The description of the delimiters is 53 provided in Subsection 2.1. The delimiters are used by the 55 PPP Mux February, 2001 57 demultiplexor to separate the PPP frames within the multiplexed 58 frame. Each PPP encapsulated frame within the multiplexed frame is 59 called a PPP subframe. 61 During the NCP negotiation phase of PPP, a receiver can offer to 62 receive multiplexed frames using the PPP Mux Control Protocol 63 (PPPMuxCP), as described in Section 3. Once PPPMuxCP has been 64 negotiated, the transmitter may choose which PPP frames to 65 multiplex. Frames should not be re-ordered by either the transmitter 66 or receiver regardless of whether they arrive as part of the PPP 67 multiplexed frame or by themselves. 69 The scheme proposed is similar to the concatenated framing option 70 [2]. The key differences are that PPP multiplexing is more efficient 71 and that it allows concatenation of variable sized frames. This is 72 unlike concatenated framing which restricts all frames to be of 73 fixed length. 75 As with any concatenation scheme, the implementer has to consider 76 the tradeoff between increased delay for multiplexing/demultiplexing 77 and reduced packet overhead as the length of the multiplexed frame 78 increases. 80 2.1. Payload Format 82 The format of the complete PPP frame along with multiple subframes 83 for PPP in HDLC-like framing [3] is shown in Figure 1. Note that 84 regardless of the order in which individual bits are transmitted, 85 i.e. LSB first or MSB first, the PFF bit will be seen to be the MSB 86 of a byte that contains both the PFF and the subframe length field. 88 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 89 | +P|L| + + + +P|L| + + + | 90 | PPP/ +F|X|Len1 + PPP + + +F|X|LenN + PPP + + | 91 | HDLC +F|T| + Prot. +Info1+ ~ +F|T| + Prot. +InfoN+ CRC | 92 | Header+ | | + Field1+ + + | | +FieldN + + | 93 | (2-5) + (1-2 ) + (0-2) + + + (1�2) + (0-2) + + (2) | 94 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 96 Figure 1. Multiplexing subframes in a PPP frame. 98 PPP Header: 99 The PPP header contains the PPP Protocol Field for a PPP 100 Multiplexed Frame (0x0059). The PPP header compression 101 options (ACFC and PFC) may be negotiated during LCP and 102 could thus affect the format of this header. 104 Length Field: 106 PPP Mux February, 2001 108 The length field consists of three subfields: 110 1. Protocol Field Flag (PFF): 111 The PFF refers to the most significant bit of the first byte of 112 each subframe. This one bit field indicates whether the PPP 113 Protocol ID of the subframe follows the subframe length field. 114 For the first subframe, the PFF bit could be set to zero if the 115 PPP protocol ID of the first subframe is equal to the default 116 PID value negotiated in PPPMuxCP. PFF = 1 indicates that the 117 protocol field is present (and follows the length field) for 118 this subframe. PFF = 0 indicates that the protocol field is 119 absent for this subframe. If PFF = 0 then the PPP Protocol ID 120 is the same as that of the preceding subframe with PFF = 1, or 121 it is equal to default PID value of the PPPMuxCP Option for the 122 first subframe. The transmitter is not obligated to remove the 123 PPP Protocol ID for any subframe. 125 2. Length Extension (LXT) 126 This one bit field indicates whether the length field is one 127 byte or two bytes long. If the LXT bit is set, then the 128 length field is two bytes long (a PFF bit, a length extension 129 bit, and 14 bits of sub-frame length). If the LXT bit is 130 cleared, then the length field is one byte long(a PFF bit, a 131 length extension bit, and 6 bits of sub-frame length). 133 3. Sub-frame Length (LEN): 134 This is the length of the subframe in bytes not including the 135 length field. However, it does include the PPP Protocol ID if 136 present (i.e. if PFF = 1). If the length of the subframe is 137 less than 64 bytes (less than or equal to 63 bytes), LXT is set 138 to zero and the last six bits of the length field is 139 the subframe length. If the length of the subframe is greater 140 than 63 bytes, LXT is set to one and the last 14 bits of the 141 length field is the length of the subframe. The maximum 142 length of a subframe is 16,383 bytes. PPP packets larger than 143 16,383 bytes will need to be sent in their own PPP frame. A 144 transmitter is not required to multiplex all frames smaller 145 than 16,383 bytes. It may chose to only multiplex frames 146 smaller than a configurable size into a PPP multiplexed frame. 148 Protocol Field: 149 This field contains the Protocol Field value for the subframe. 150 This field is optional. If PFF = 1 for a subframe, the 151 protocol field is present in the subframe, otherwise it is 152 inferred at the receiver. 154 The receiver MUST support Protocol-Field-Compression (PFC) 155 [4] for subframe PPP Protocol IDs. Thus the field may be 156 one or two bytes long. The transmitter SHOULD 157 compress PPP Protocol IDs in this field that have an upper 158 byte of zero (i.e. Protocol IDs from 0x21 thru 0xFD). This 160 PPP Mux February, 2001 162 Protocol Field Compression in each PPP subframe is not related 163 to the negotiation of PFC during LCP negotiation which affects 164 the length of PPP Multiplexed Frame Protocol ID. 166 Information Field: 167 This field contains the actual packet being encapsulated. 168 Any frame may be included here with the exception of LCP 169 Configure Request, ACK, NAK and Reject frames and PPP 170 Multiplexed frames. If LCP is renegotiated then PPP 171 Multiplexing MUST be disabled until the PPP Mux Control 172 Protocol is negotiated. 174 2.2 Transmitter procedure 176 A simple implementation of the transmitter is provided. During the 177 transmission of a multiplexed PPP frame, the transmitter has a state 178 variable, Last_PID, which is used to hold the most recent value of 179 protocol field in a subframe with PFF=1. At the start of the 180 multiplexing process, Last_PID is set equal to the default PID value 181 negotiated in PPPMuxCP. Also, a user configurable parameter, maximum 182 subframe length (MAX_SF_LEN), is used to determine the maximum size 183 of a PPP frame which can be multiplexed. The value of MAX_SF_LEN 184 should be less or equal to the minimum of MRU-2(maximum size of 185 length field) and 16,383 (14 bits). 187 After transmitting a PPP frame (multiplexed or not) on the channel, 188 the PPP multiplexing logic looks at the buffers that hold the PPP 189 frames to be transmitted. In case there are multiple frames, the PPP 190 multiplexing logic checks if the length of the first frame in the 191 buffer is less than or equal to MAX_SF_LEN bytes. If so, the 192 transmitter starts compiling a multiplexed PPP frame with the 193 protocol field value corresponding to PPP Multiplexed Frame (0x59). 194 For each subframe, the test for deciding to prepend the protocol 195 field to a subframe is to compare the protocol field value of the 196 subframe to Last_PID. If they are equal, PFF is set to 0 and the 197 protocol field is deleted. If not, PFF is set to 1, the protocol 198 field is included, after PFC, in the subframe and Last_PID is set to 199 the protocol field value of the current subframe. The stopping 200 criteria in the concatenation process are (i) when the length of the 201 next subframe is greater than MAX_SF_LEN bytes or (ii) the length of 202 the entire PPP frame by including the new subframe exceeds the 203 maximum receive unit (MRU) parameter negotiated during LCP [4], or 204 (iii) there are no more subframes to concatenate. 206 Implementers may choose additionally to implement using timers. In 207 such a case a timeout in addition to the conditions stated above is 208 used as a stopping criteria of the multiplexing process. Moreover, 209 it may be desirable to limit the maximum size of a multiplexed 210 packet to be considerably smaller than MRU for reasons of 211 multiplexing latency and packet error considerations. 213 PPP Mux February, 2001 215 2.3 Receiver procedure 217 If a multiplexed frame, i.e. a frame with Protocol field value equal 218 to PPP Multiplexed Frame (0x0059), is received, the frame is 219 demultiplexed in order using the following input demultiplexing 220 logic. Similar to a transmitter, the receiver has a state variable 221 called Last_rcvd_PID, which is the value of the protocol field in 222 the most recently demultiplexed subframe with PFF=1. Last_rcvd_PID 223 is initialized to default PID value negotiated by PPPMuxCP. If PFF=0 224 for a subframe, Last_rcvd_PID is appended to the beginning of the 225 subframe before handing the subframe, as determined by the length 226 field, to the PPP logic. If PFF=1 for a subframe, Last_rcvd_PID is 227 set to this value and the subframe, as determined by the length 228 field, is passed to PPP logic. The remainder of the frame is 229 returned to the demultiplexor. Each succeeding subframe is processed 230 similarly. This processing is complete when the remainder of the 231 frame is empty, or when the size field of a subframe exceeds the 232 amount of data remaining in a packet. In the latter case, there is 233 an error either in the length field of the last subframe or in the 234 length field of one of the previous subframes. In either case the 235 last subframe must be dropped by the demultiplexing logic. 237 It is illegal to put a multiplexed frame within a multiplexed frame. 239 3. PPP Network Control Protocol for PPP Multiplexing (PPPMuxCP) 241 A receiver will offer its ability to received multiplexed frames by 242 negotiating NCP for PPP multiplexing, PPPMuxCP. The protocol field 243 value for a PPPMuxCP frames is 0x8059. PPPMuxCP is similar to other 244 NCPs such as IPCP [6]. A transmitter may not send a multiplexed 245 frame unless the peer has offered to receive multiplexed frames. 246 Support of multiplexed frame reception is negotiated in each 247 direction independently. Successful negotiation of PPPMuxCP does not 248 obligate a peer to transmit multiplexed frames. 250 As part of the PPPMuxCP negotiation, a 'default PID' option is 251 always negotiated. This enables the transmitter to transmit the 252 first subframe of a PPP multiplexed frame without a PID (PFF=0), 253 thus resulting in a saving of one or two bytes. Note that the 254 negotiation of default PID does not require the transmitter to send 255 the first subframe with PFF=0 even if doing so would optimize the 256 transmission. And, as always, the option (and thus the default PID) 257 is negotiated by the receiver, i.e. the receiver will interpret a 258 received PPPmux packet using the default PID it offered. 260 LCP frames MUST NOT be sent in Multiplexed frames. 262 PPP Mux February, 2001 264 The only option in PPPMuxCP is the negotiation of Default PID and is 265 shown below 267 0 1 2 3 268 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 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 | Type = 1 | Length = 4 | Default PID | 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 Figure 2. Default PID option for PPPMuxCP 275 4. Interaction with PPP Multilink (MP) Protocol 277 PPP multiplexed frame option is negotiated by an NCP. LCP is 278 negotiated over each member link of a multilink bundle and not on 279 the bundle itself [5]. Thus in case of MP, PPPmux cannot be 280 negotiated for individual links, but only for the bundle. 282 Hence, on the transmitter side PPP multiplexing always occurs before 283 multilink PPP encapsulation. On a link, an MP header (if present) 284 MUST be outside of a PPPmux header (if present). Multilink frames 285 must not be sent in Multiplexed frames. 287 5. Interaction with CCP and ECP 289 PPP multiplexing must be performed below (after) any bundle-level 290 CCP and/or ECP, and above (before) MP and any per-link CCP and/or 291 ECP. Thus, to negotiate the hypothetical transmit path sequence 292 CCP -> PPPMux -> ECP, the bundle-level version of CCP (80fd) and the 293 per-link version of ECP (8055) are negotiated along with the PPPMux 294 Option. 296 An implementation that cannot perform PPPMux above CCP or ECP MUST 297 issue Protocol-Reject for the per-link forms of CCP and ECP if 298 PPPMux has been negotiated. 300 6. Security Considerations 302 This draft does not impose additional security considerations beyond 303 those that apply to PPP and header-compression schemes over PPP. 305 7. Acknowledgements 307 The authors would like to thank contributors on the PPPext mailing 308 list, especially James Carlson, for valuable inputs to this draft. 310 8. References 312 PPP Mux February, 2001 314 [1] Townsley, M., et al, "Layer Two Tunneling Protocol "L2TP"", RFC 315 2661, August 1999. 317 [2] Simpson, W., Ed., "PPP LCP extensions", RFC 1570, January, 1994. 319 [3] Simpson, W., Ed., "PPP in HDLC-like Framing", STD 51, RFC 1662, 320 July 1994. 322 [4] Simpson, W., Ed., "The Point-To-Point Protocol (PPP)", STD 51, 323 RFC 1661, July 1994. 325 [5] Sklower, K., et al, "The PPP Multilink Protocol (MP)", RFC 1990, 326 August 1996. 328 [6] McGregor, G., "The PPP Internet Protocol Control Protocol 329 (IPCP)", RFC 1332, May 1992. 331 7. Author's Addresses 333 Rajesh Pazhyannur 334 Motorola, Network Solutions Sector 335 1501, W. Shure Drive 336 Arlington Heights, IL 60004 337 Phone: (847) 632-4524 338 Email: pazhynnr@cig.mot.com 340 Irfan Ali 341 Motorola, Network Solutions Sector 342 1501, W. Shure Drive 343 Arlington Heights, IL 60004 344 Phone: (847) 632-3281 345 Email: fia225@email.mot.com 347 Craig Fox 348 Cisco Systems 349 170 W. Tasman Street 350 San Jose, CA 95134 351 Phone: (408) 526-6296 352 E-mail: fox@cisco.com 354 PPP Mux February, 2001 356 Full Copyright Statement 358 Copyright (C) The Internet Society (2000). All Rights Reserved. 360 This document and translations of it may be copied and furnished to 361 others, and derivative works that comment on or otherwise explain it 362 or assist in its implementation may be prepared, copied, published 363 and distributed, in whole or in part, without restriction of any 364 kind, provided that the above copyright notice and this paragraph 365 are included on all such copies and derivative works. However, this 366 document itself may not be modified in any way, such as by removing 367 the copyright notice or references to the Internet Society or other 368 Internet organizations, except as needed for the purpose of 369 developing Internet standards in which case the procedures for 370 copyrights defined in the Internet Standards process must be 371 followed, or as required to translate it into languages other than 372 English. 374 The limited permissions granted above are perpetual and will not be 375 revoked by the Internet Society or its successors or assigns. This 376 document and the information contained herein is provided on an 377 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 378 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 379 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 380 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 381 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.