idnits 2.17.1 draft-ietf-pppext-pppmux-00.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. == 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 7) being 59 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. ** 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 85: '...ame. The PFF bit MUST be set for the f...' RFC 2119 keyword, line 120: '...f each PPP multiplexed frame MUST have...' RFC 2119 keyword, line 138: '... The receiver MUST support Protocol...' RFC 2119 keyword, line 140: '...two bytes long. The transmitter SHOULD...' RFC 2119 keyword, line 152: '...enegotiated then PPP Multiplexing MUST...' (3 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 81 has weird spacing: '...defined part ...' -- 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 (January 5, 2000) is 8871 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) == Unused Reference: '1' is defined on line 255, but no explicit reference was found in the text Summary: 7 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force PPPext Working Group 2 Internet Draft R. Pazhyannur, 3 I. Ali 4 Motorola 5 Craig Fox 6 Cisco Systems 7 Document: 8 Expires: June 5, 2000 January 5, 2000 10 PPP Multiplexed Frame Option 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. Internet-Drafts are working 16 documents of the Internet Engineering Task Force (IETF), its areas, 17 and its working groups. Note that other groups may also distribute 18 working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other documents 22 at any time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 1. Abstract 33 This draft describes a method to reduce the PPP framing overhead 34 used to transport small packets over slow links. The method, PPP 35 Multiplexing, sends multiple PPP encapsulated packets in a single 36 PPP frame. As a result, the PPP overhead per packet is reduced. 38 2. Description 40 At a minimum, PPP encapsulating a packet adds several bytes of 41 overhead, including an HDLC flag character (at least one to separate 42 adjacent packets), the Address (0xFF) and Control (0x03) field 43 bytes, a two byte PPP Protocol ID, and the two byte CRC field. Even 44 if the Address and Control Fields are negotiated off and the PPP 45 Protocol ID is compressed, each PPP encapsulated frame will include 46 four bytes of overhead. This overhead can be reduced to one or two 47 bytes. 49 The key idea is to concatenate multiple PPP encapsulated frames into 50 a single PPP multiplexed frame by inserting a length field before 51 the beginning of each frame. Each PPP encapsulated frame is called a 52 PPP subframe. Removing the PPP framing characters can save several 53 bytes per packet, reducing overhead. The PPP Protocol ID field can 54 PPP Mux January, 2000 56 also be removed for those subframes which have the same PPP Protocol 57 ID as the preceding subframe. 59 For the sake of efficiency, the maximum size of a subframe is 127 60 bytes. This size includes the PPP Protocol ID, unless it is removed 61 during the multiplexing process. This size limitation should not be 62 significant since the impact of the PPP overhead is reduced as the 63 packet size is increased. 65 During the LCP negotiation phase of PPP, a receiver can offer to 66 receive multiplexed frames using an LCP Option, described in Section 67 4. Once LCP has been negotiated, the transmitter may choose which 68 PPP frames to multiplex. Frames should not be re-ordered by either 69 the transmitter or receiver regardless of whether they arrive as 70 part of the PPP multiplexed frame or by themselves. 72 As with any concatenation scheme, the implementor has to consider 73 the the tradeoff between increased delay for 74 multiplexing/demultiplexing and reduced packet overhead as the 75 length of the multiplexed frame increases. 77 2.1. Protocol Field Elimination 79 The PPP Protocol ID field of a subframe can be removed if the PPP 80 Protocol ID of that subframe is the same as that for the preceding 81 subframe. A Protocol Field Flag (PFF) bit is defined part of the 82 length field (thus reducing the length field from an 8-bit to a 7- 83 bit field). The PFF bit is set if the PPP Protocol ID is included in 84 the subframe. The PFF bit is cleared if the PPP Protocol ID has been 85 removed from the subframe. The PFF bit MUST be set for the first 86 subframe in a PPP multiplexed Frame. The transmitter is not 87 obligated to remove the PPP Protocol ID for any subframe. 89 2.2. Payload Format 91 The format of the complete PPP frame along with multiple subframes 92 is shown in Figure 2. Note that regardless of the order in which 93 individual bits are transmitted, i.e. LSB first or MSB first, the 94 PFF bit will be seen to be the MSB of a byte that contains both the 95 PFF and the subframe length field. 97 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 98 | +P| + + + +P| + + + | 99 | PPP +F| Len1 + PPP + + +F| LenN + PPP + + | 100 |Header +F| + Prot. +Info1+ ~ +F| + Prot. +InfoN+ CRC | 101 | + |(7bits)+ Field1+ + + |(7bits)+FieldN + + | 102 | (2-5) +(1 byte )+ (0-2) + + +(1 byte) + (0-2) + + (2) | 103 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 105 Figure 2. Multiplexing subframes in a PPP frame. 107 PPP Mux January, 2000 109 PPP Header: 110 The PPP header contains the PPP Protocol Field for a PPP 111 Multiplexed Frame (0x59). The PPP header compression 112 options (ACFC and PFC) may be negotiated during LCP and 113 could thus affect the format of this header. 115 Protocol Field Flag (PFF): 116 This one bit field indicates whether the PPP Protocol ID of the 117 subframe follows the subframe length field. PFF = 1 indicates 118 that the protocol field is present for this subframe. PFF = 0 119 indicates that the protocol field is absent for this subframe. 120 The first subframe of each PPP multiplexed frame MUST have 121 PFF = 1. If PFF = 0 then the PPP Protocol ID is the same as 122 that of the preceding subframe with PFF = 1. 124 Length Field: 125 Each subframe has a seven bit subframe length field. This 126 length does not include the byte containing the PFF and length 127 field but does include the PPP Protocol ID if present (i.e. if 128 PFF = 1). The maximum length of a subframe is 127 bytes. PPP 129 packets larger than 127 bytes will need to be sent in their 130 own PPP frame. 132 Protocol Field: 133 This field contains the Protocol Field value for the subframe. 134 This field is optional. If PFF = 1 for a subframe, the 135 protocol field is present in the subframe, otherwise it is 136 inferred at the receiver. 138 The receiver MUST support Protocol-Field-Compression (PFC) 139 [2] for PPP Protocol IDs in this field. Thus the 140 field may be one or two bytes long. The transmitter SHOULD 141 compress PPP Protocol IDs in this field that have an upper 142 byte of zero (i.e. Protocol IDs from 0x21 thru 0xFD). This 143 Protocol Field Compression is not related to the negotiation 144 of PFC during LCP negotiation. 146 Information Field: 147 This field contains the actual packet being encapsulated. 148 The maximum length of this field is 127 bytes, if the Protocol 149 Field is eliminated from the subframe. Any frame 150 may be included here with the exception of LCP Configure 151 Request, ACK, NAK and Reject frames and PPP multiplexed 152 frames. If LCP is renegotiated then PPP Multiplexing MUST 153 be disabled. 155 2.2 Transmitter procedure 157 A simple implementation of the transmitter is provided. During the 158 transmission of a multiplexed PPP frame, the transmitter has a state 159 variable, Last_PID, which is used to hold the most recent value of 160 PPP Mux January, 2000 162 protocol field in a subframe with PFF=1. This variable is only valid 163 during the transmission of a multiplexed frame and no history is 164 maintained from the transmission of one multiplexed PPP frame to the 165 next one. This is because the first subframe in every multiplexed 166 subframe MUST contain the protocol field. 168 After transmitting a PPP frame (multiplexed or not) on the channel, 169 the PPP multiplexing logic looks at the buffers which hold the PPP 170 frames to be transmitted. In case there are multiple frames, the PPP 171 multiplexing logic checks if either the length of the first frame or 172 the second frame in the buffer is greater than 127 bytes. If either 173 of these two conditions are met, the first and second frame are 174 transmitted as non-multiplexed frames. The above logic ensures that 175 small frames separated by large frames will not be transmitted as 176 multiplexed frames with only one subframe. If both conditions are 177 not true, i.e., the length of the first PPP frame and that of the 178 second PPP frame are less than or equal to 127 bytes, the 179 transmitter starts compiling a multiplexed PPP frame with the 180 protocol field value corresponding to PPP_Multiplexed_Frame (0x59). 181 It sets PFF=1 and then prepends the length of the first PPP 182 subframe, after compressing the Protocol field. The protocol field 183 is included in the first subframe. For subsequent subframes, the 184 test for deciding to prepend the protocol field to a subframe is to 185 compare the protocol field value of the subframe to Last_PID. If 186 they are equal, PFF is set to 0 and the protocol field is deleted. 187 If not, PFF is set to 1, the protocol field is included in the 188 subframe and Last_PID is set to the protocol field value of the 189 current subframe. The stopping criteria in the concatenation process 190 are (i) when the length of the next subframe is greater than 127 191 bytes or (ii)the length of the entire PPP frame by including the new 192 subframe exceeds the maximum receive unit (MRU) parameter negotiated 193 during LCP [2], or (iii) there are no more subframes to concatenate. 195 2.3 Receiver procedure 197 If a multiplexed frame, i.e. a frame with Protocol field value equal 198 to PPP_Multiplexed_Frame (0x59), is received, the frame is 199 demultiplexed in order using the following input demultiplexing 200 logic. Similar to a transmitter, the receiver has a state variable 201 called Last_rcvd_ID, which is the value of the protocol field in the 202 most recently demultiplexed subframe with PFF=1. No history is 203 preserved in going from one multiplexed PPP frame to the next. From 204 the first subframe the protocol field value is copied to 205 Last_rcvd_PID. The length of the first subframe is determined, and 206 the subframe is passed to be processed as a PPP frame. The remainder 207 of the frame is returned to the demultiplexor. 209 Each succeeding subframe is processed similarly. If PFF=0 for a 210 subframe, Last_rcvd_PID is appended to the beginning of the subframe 211 before handing the subframe to the PPP logic. If PFF=1 for a 212 subframe, Last_rcvd_PID is set to this value and the subframe is 213 passed to PPP logic. This processing is complete when the remainder 214 of the frame is empty, or when the size field of a subframe exceeds 215 PPP Mux January, 2000 217 the amount of data remaining in a packet. In the latter case, there 218 is an error either in the length field of the last subframe or in 219 the length field of one of the previous subframes. In either case 220 the last subframe must be dropped by the demultiplexing logic. 222 It is illegal to put a multiplexed frame within a multiplexed frame. 224 3. PPP Link Control Protocol Extension 226 A receiver will offer its ability to received multiplexed frames by 227 negotiating LCP Option 30. A transmitter may not send a multiplexed 228 unless the peer has offered to receive multiplexed frames. Support 229 of multiplexed frame reception is negotiated in each direction 230 independently. Acknowledgement of the multiplexed Frame LCP Option 231 (30) does not obligate a peer to transmit Multiplexed frames. 233 LCP frames MUST NOT be sent in Multiplexed frames. 235 A summary of the PPP multiplexed frame option is shown below 237 0 1 238 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 | Type = 30 | Length = 2 | 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 Figure 3. PPP Multiplexed Frame LCP Option 245 The size of a multiplexed PPP frame MUST NOT exceed the maximum 246 receive unit (MRU) size negotiated during LCP [2]. 248 4. Security Considerations 250 This draft does not impose additional security considerations beyond 251 those that apply to PPP and header-compression schemes over PPP. 253 5. References 255 [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 256 9, RFC 2026, October 1996. 258 [2] Simpson, W., Ed., "The Point-To-Point Protocol (PPP)", STD 51, 259 RFC 1661, July 1994. 261 11. Author's Addresses 263 Rajesh Pazhyannur 264 Motorola, Network Solutions Sector 265 1501, W. Shure Drive 266 Arlington Heights, IL 60004 267 Phone: (847) 632-4524 268 PPP Mux January, 2000 270 Email: pazhynnr@cig.mot.com 272 Irfan Ali 273 Motorola, Network Solutions Sector 274 2A8, 1421 Shure Drive 275 Arlington Heights, IL 60004 276 Phone: (847) 632-3281 277 Email: fia225@email.mot.com 279 Craig Fox 280 Cisco Systems 281 170 W. Tasman Street 282 San Jose, CA 95134 283 Phone: (408) 526-6296 284 E-mail: fox@cisco.com 285 PPP Mux January, 2000 287 Full Copyright Statement 289 "Copyright (C) The Internet Society (date). All Rights Reserved. 290 This document and translations of it may be copied and furnished to 291 others, and derivative works that comment on or otherwise explain it 292 or assist in its implementation may be prepared, copied, published 293 and distributed, in whole or in part, without restriction of any 294 kind, provided that the above copyright notice and this paragraph 295 are included on all such copies and derivative works. However, this 296 document itself may not be modified in any way, such as by removing 297 the copyright notice or references to the Internet Society or other 298 Internet organizations, except as needed for the purpose of 299 developing Internet standards in which case the procedures for 300 copyrights defined in the Internet Standards process must be 301 followed, or as required to translate it into