idnits 2.17.1 draft-ietf-pppext-pppmux-01.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 261: '... LCP frames MUST NOT be sent in Mult...' RFC 2119 keyword, line 285: '... 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 (October 2, 2000) is 8600 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 Internet Engineering Task Force I. Ali 4 Internet Draft Motorola 5 C. Fox 6 Cisco Systems 8 Expires: April 2, 2000 October 2, 2000 10 PPP Multiplexing 11 draft-ietf-pppext-pppmux-01.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 is 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 October, 2000 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 October, 2000 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 October, 2000 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 maximum packet 182 length for multiplexing, MAX_SF_LEN, could be set which is less than 183 MRU and 16,384. 185 After transmitting a PPP frame (multiplexed or not) on the channel, 186 the PPP multiplexing logic looks at the buffers that hold the PPP 187 frames to be transmitted. In case there are multiple frames, the PPP 188 multiplexing logic checks if either the length of the first frame or 189 the second frame in the buffer is greater than MAX_SF_LEN bytes. If 190 either of these two conditions are met, the first and second frame 191 are transmitted as non-multiplexed frames. The above logic ensures 192 that small frames separated by large frames will not be transmitted 193 as multiplexed frames with only one subframe. If both conditions are 194 not true, i.e., the length of the first PPP frame and that of the 195 second PPP frame are less than or equal to MAX_SF_LEN bytes, the 196 transmitter starts compiling a multiplexed PPP frame with the 197 protocol field value corresponding to PPP Multiplexed Frame (0x59). 198 For each subframe, the test for deciding to prepend the protocol 199 field to a subframe is to compare the protocol field value of the 200 subframe to Last_PID. If they are equal, PFF is set to 0 and the 201 protocol field is deleted. If not, PFF is set to 1, the protocol 202 field is included, after PFC, in the subframe and Last_PID is set to 203 the protocol field value of the current subframe. The stopping 204 criteria in the concatenation process are (i) when the length of the 205 next subframe is greater than MAX_SF_LEN bytes or (ii) the length of 206 the entire PPP frame by including the new subframe exceeds the 207 maximum receive unit (MRU) parameter negotiated during LCP [4], or 208 (iii) there are no more subframes to concatenate. 210 Implementers may choose alternately to implement using timers. In 211 such a case a timeout in addition to the conditions stated above is 212 used for the stopping criteria of the multiplexing process. 214 PPP Mux October, 2000 216 2.3 Receiver procedure 218 If a multiplexed frame, i.e. a frame with Protocol field value equal 219 to PPP Multiplexed Frame (0x0059), is received, the frame is 220 demultiplexed in order using the following input demultiplexing 221 logic. Similar to a transmitter, the receiver has a state variable 222 called Last_rcvd_PID, which is the value of the protocol field in 223 the most recently demultiplexed subframe with PFF=1. Last_rcvd_PID 224 is initialized to default PID value negotiated by PPPMuxCP. If PFF=0 225 for a subframe, Last_rcvd_PID is appended to the beginning of the 226 subframe before handing the subframe, as determined by the length 227 field, to the PPP logic. If PFF=1 for a subframe, Last_rcvd_PID is 228 set to this value and the subframe, as determined by the length 229 field, is passed to PPP logic. The remainder of the frame is 230 returned to the demultiplexor. Each succeeding subframe is processed 231 similarly. This processing is complete when the remainder of the 232 frame is empty, or when the size field of a subframe exceeds the 233 amount of data remaining in a packet. In the latter case, there is 234 an error either in the length field of the last subframe or in the 235 length field of one of the previous subframes. In either case the 236 last subframe must be dropped by the demultiplexing logic. 238 It is illegal to put a multiplexed frame within a multiplexed frame. 240 3. PPP Network Control Protocol for PPP Multiplexing (PPPMuxCP) 242 A receiver will offer its ability to received multiplexed frames by 243 negotiating NCP for PPP multiplexing, PPPMuxCP. The protocol field 244 value for a PPPMuxCP frames is 0x8059. PPPMuxCP is similar to other 245 NCPs like IPCP [6]. A transmitter may not send a multiplexed frame 246 unless the peer has offered to receive multiplexed frames. Support 247 of multiplexed frame reception is negotiated in each direction 248 independently. Successful negotiation of PPPMuxCP does not obligate 249 a peer to transmit multiplexed frames. 251 As part of the PPPMuxCP negotiation, a 'default PID' option is 252 always negotiated. This enables the transmitter to transmit the 253 first subframe of a PPP multiplexed frame without a PID (PFF=0), 254 thus resulting in a saving of one or two bytes. Note that the 255 negotiation of default PID does not require the transmitter to send 256 the first subframe with PFF=0 even if doing so would optimize the 257 transmission. And, as always, the option (and thus the default PID) 258 is negotiated by the receiver, i.e. the receiver will interpret a 259 received PPPmux packet using the default PID it offered. 261 LCP frames MUST NOT be sent in Multiplexed frames. 263 PPP Mux October, 2000 265 The only option in PPPMuxCP is the negotiation of Default PID and is 266 shown below 268 0 1 2 3 269 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 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 | Type = 1 | Length = 4 | Default PID | 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 Figure 2. Default PID option for PPPMuxCP 276 4. Interaction with PPP Multilink (MP) Protocol 278 PPP multiplexed frame option is negotiated by an NCP. LCP is 279 negotiated over each member link of a multilink bundle and not on 280 the bundle itself [5]. Thus in case of MP, PPPmux cannot be 281 negotiated for individual links, but only for the bundle. 283 Hence, on the transmitter side PPP multiplexing always occurs before 284 multilink PPP encapsulation. On a link, an MP header (if present) 285 MUST be outside of a PPPmux header (if present). Multilink frames 286 must not be sent in Multiplexed frames. 288 5. Interaction with CCP and ECP 290 Though PPP multiplexing in itself does not place any requirements on 291 the sequence in which it is performed with respect to compression 292 and encryption, in order to simplify implementation and ensure 293 interoperability, PPPmux header MUST always be outside CCP and ECP 294 header. 296 6. Security Considerations 298 This draft does not impose additional security considerations beyond 299 those that apply to PPP and header-compression schemes over PPP. 301 7. Acknowledgements 303 The authors would like to thank contributors on the PPPext mailing 304 list, especially James Carlson, for valuable inputs to this draft. 306 8. References 308 [1] Townsley, M., et al, "Layer Two Tunneling Protocol "L2TP"", RFC 309 2661, August 1999. 311 PPP Mux October, 2000 313 [2] Simpson, W., Ed., "PPP LCP extensions", RFC 1570, January, 1994. 315 [3] Simpson, W., Ed., "PPP in HDLC-like Framing", STD 51, RFC 1662, 316 July 1994. 318 [4] Simpson, W., Ed., "The Point-To-Point Protocol (PPP)", STD 51, 319 RFC 1661, July 1994. 321 [5] Sklower, K., et al, "The PPP Multilink Protocol (MP)", RFC 1990, 322 August 1996. 324 [6] McGregor, G., "The PPP Internet Protocol Control Protocol 325 (IPCP)", RFC 1332, May 1992. 327 7. Author's Addresses 329 Rajesh Pazhyannur 330 Motorola, Network Solutions Sector 331 1501, W. Shure Drive 332 Arlington Heights, IL 60004 333 Phone: (847) 632-4524 334 Email: pazhynnr@cig.mot.com 336 Irfan Ali 337 Motorola, Network Solutions Sector 338 1501, W. Shure Drive 339 Arlington Heights, IL 60004 340 Phone: (847) 632-3281 341 Email: fia225@email.mot.com 343 Craig Fox 344 Cisco Systems 345 170 W. Tasman Street 346 San Jose, CA 95134 347 Phone: (408) 526-6296 348 E-mail: fox@cisco.com 350 PPP Mux October, 2000 352 Full Copyright Statement 354 Copyright (C) The Internet Society (2000). All Rights Reserved. 356 This document and translations of it may be copied and furnished to 357 others, and derivative works that comment on or otherwise explain it 358 or assist in its implementation may be prepared, copied, published 359 and distributed, in whole or in part, without restriction of any 360 kind, provided that the above copyright notice and this paragraph 361 are included on all such copies and derivative works. However, this 362 document itself may not be modified in any way, such as by removing 363 the copyright notice or references to the Internet Society or other 364 Internet organizations, except as needed for the purpose of 365 developing Internet standards in which case the procedures for 366 copyrights defined in the Internet Standards process must be 367 followed, or as required to translate it into languages other than 368 English. 370 The limited permissions granted above are perpetual and will not be 371 revoked by the Internet Society or its successors or assigns. This 372 document and the information contained herein is provided on an 373 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 374 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 375 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 376 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 377 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.