idnits 2.17.1 draft-thubert-intarea-schc-over-ppp-02.txt: -(365): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC5172, but the abstract doesn't seem to directly say this. It does mention RFC5172 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC5172, updated by this document, for RFC5378 checks: 2007-05-17) -- 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 (22 September 2020) is 1312 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) ** Downref: Normative reference to an Informational RFC: RFC 2516 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 LPWAN P. Thubert, Ed. 3 Internet-Draft Cisco Systems 4 Updates: 5172 (if approved) 22 September 2020 5 Intended status: Standards Track 6 Expires: 26 March 2021 8 SCHC over PPP 9 draft-thubert-intarea-schc-over-ppp-02 11 Abstract 13 This document extends RFC 5172 to signal the use of SCHC as the 14 compression method between a pair of nodes over PPP. Combined with 15 RFC 2516, this enables the use of SCHC over Ethernet and Wi-Fi. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at https://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on 26 March 2021. 34 Copyright Notice 36 Copyright (c) 2020 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 41 license-info) in effect on the date of publication of this document. 42 Please review these documents carefully, as they describe your rights 43 and restrictions with respect to this document. Code Components 44 extracted from this document must include Simplified BSD License text 45 as described in Section 4.e of the Trust Legal Provisions and are 46 provided without warranty as described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 2. BCP 14 . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 3. Extending RFC 5172 . . . . . . . . . . . . . . . . . . . . . 3 53 4. Profiling SCHC for high speed links . . . . . . . . . . . . . 4 54 4.1. Mapping the SCHC Architecture . . . . . . . . . . . . . . 4 55 4.2. SCHC Parameters . . . . . . . . . . . . . . . . . . . . . 5 56 4.2.1. Resulting Packet Format . . . . . . . . . . . . . . . 6 57 4.3. Security Considerations . . . . . . . . . . . . . . . . . 7 58 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 59 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 60 7. Normative References . . . . . . . . . . . . . . . . . . . . 8 61 8. Informative References . . . . . . . . . . . . . . . . . . . 8 62 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 64 1. Introduction 66 The Point-to-Point Protocol (PPP) [RFC5172] provides a standard 67 method of encapsulating network-layer protocol information over 68 serial (point-to-point and bus) links. "A Method for Transmitting 69 PPP Over Ethernet (PPPoE)" [RFC2516] transports PPP over Ethernet 70 between a pair of nodes. It is compatible with a translating bridge 71 to Wi-Fi, and therefore enables PPP over Wi-Fi as well. 73 PPP also proposes an extensible Link Control Protocol and a family of 74 Network Control Protocols (NCPs) for establishing and configuring 75 different network-layer protocols. "IP Version 6 over PPP" [RFC5072] 76 specifies the IPv6 Control Protocol (IPV6CP), which is an NCP for a 77 PPP link, and allows for the negotiation of desirable parameters for 78 an IPv6 interface over PPP. "Negotiation for IPv6 Datagram 79 Compression Using IPv6 Control Protocol" [RFC5172] defines the IPv6 80 datagram compression option that can be negotiated by a node on the 81 link through the IPV6CP. 83 The "Static Context Header Compression (SCHC) and fragmentation for 84 LPWAN, application to UDP/IPv6" [SCHC] is a new technology that can 85 provide an extreme compression performance but requires a same state 86 to be provisionned on both ends before it can be operated. To enable 87 SCHC over PPP and therefore Ethernet and Wi-Fi, this specification 88 extends [RFC5172] to signal SCHC as an additional compression method 89 for use over PPP. 91 An example use case for SCHC over PPP over Ethernet (SCHCoPPPoE) is 92 to apply SCHC to periodic flows and maintain them at a protocol- 93 independant size and rate. The constant size may be too small for a 94 particular flow or protocol. The SCHC fragmentation can then be used 95 to transport a protocol data unit (PDU) as N compressed SCHC 96 fragments, in which case the effective PDU rate is the TSN frame rate 97 divided by N. 99 This can be useful to streamline the frames and simplifies the 100 scheduling of Deterministic Networking [DetNet] and Operational 101 Technology (OT) control flows over IEEE Std 802.1 Time-Sensitive 102 Networking (TSN) [IEEE802.1TSNTG] or one of the [RAW Technologies]. 104 2. BCP 14 106 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 107 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 108 "OPTIONAL" in this document are to be interpreted as described in BCP 109 14 [RFC2119][RFC8174] when, and only when, they appear in all 110 capitals, as shown here. 112 3. Extending RFC 5172 114 With this specification, a PPP session defines a vitual link where a 115 SCHC context is established with a particular set of Rules, which is 116 indicated at the set up of the PPP session as follows: 118 [RFC5172] defines an IPV6CP option called the IPv6-Compression- 119 Protocol Configuration option with a type of 2. The option contains 120 an IPv6-Compression-Protocol field value that indicates a compression 121 protocol and an optional data field as shown in Figure 1: 123 0 1 2 3 124 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 125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 126 | Type | Length | IPv6-Compression-Protocol | 127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 128 | Data ... 129 +-+-+-+-+ 131 Figure 1: The IPv6-Compression-Protocol Configuration Option 133 This specification indicates a new IPv6-Compression-Protocol field 134 value for [SCHC] (see Section 5), and enables to transport a Uniform 135 Resource Identifier (URI) [RFC3986] of the set of rules in the 136 optional data. The default format for the set of rules is YANG using 137 the "Data Model for SCHC" [SCHC_DATA_MODEL] encoded in JSON as 138 specified in [RFC7951]. The size of the URL is computed based on the 139 Length of the option as Length-4. If the encoding is asymetrical, 140 the initiator of the session is considered downstream, playing the 141 role of the device in an LPWAN network. 143 4. Profiling SCHC for high speed links 145 Appendix D of [SCHC] specifies the profile information that 146 technology specifications such as this must provide. The following 147 section address this requirement. 149 4.1. Mapping the SCHC Architecture 151 This specification leverages SCHC between an end point that is an IP 152 Host and possibly a serial DTE (Data Terminal Equipment), and another 153 that is an IP Node (either another IP Host or a Router) and possibly 154 a serial DCE (Data Control Equipment), or a more modern physical or 155 emulated endpoint, e.g., Ethernet devices that echange IP packets 156 over PPPoE. 158 Both endpoints MUST support the function of SCHC Compressor/ 159 Decompressor (C/D) as shown in Figure 2. 161 +----------+ Wi-Fi / +----------+ .... 162 | IP | Ethernet | IP | .. ) 163 | Host +-----/------+ Router +----------( Internet ) 164 | SCHC C/D | Serial | SCHC C/D | ( ) 165 +----------+ +----------+ ... 166 <-- SCHC --> 167 over PPP 169 Figure 2: Typical Deployment 171 The SCHC Fragmenter/Reassembler (F/R) is generally not needed, 172 because the maximum transmission unit (MTU) is expected to be large 173 enough and SCHC only reduces the frame size vs. native IP. But it 174 may be used to obtain a small protocol-independant frame size for the 175 compressed packets, possibly way smaller than MTU. 177 A context may be generated for a particular upper layer application, 178 such as a control loop using an industrial automation protocol, to 179 protect the particular flow with a DetNet service. The context can 180 be asymetric, e.g., when connecting a primary and a secondary 181 endpoints, a client and a server, or a programmable logic controller 182 with a sensor or an actuator. 184 4.2. SCHC Parameters 186 Compared to typical LPWANs, most serial links and emulations such as 187 PPPoE are very fast and most of the constraints can be alleviated. 188 For this reason, the SCHC profile for PPP is defined as follows: 190 RuleID numbering scheme: The RuleID for a compression rule is 191 expressed as 2 bytes. The first (leftmost) 2 bits of that RuleId 192 MUST be set to 0 This leaves 14 bits to index the rule. A SCHC 193 compressed packet is always in the form: 195 0 1 196 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+----------...--------+~~~~~~~~~~ 198 |0 0 RuleID | Compression Residue | Payload 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+----------...--------+~~~~~~~~~~ 200 |------- Compressed Header (byte aligned) ------------| 202 Figure 3: SCHC Compressed Packet 204 This specification only supports the No-ACK Mode of SCHC 205 fragmentation as specified in section 8.4.1 of [SCHC]. The SCHC 206 Fragment Header is 2 bytes long. 208 The RuleID for a fragmenation rule is expressed as 4 bits. The 209 bits MUST all set to 1 for a fragmentation rule in No-ACK Mode. 210 The DTag field is 11 bits long (T=11) and the FCN field is one bit 211 (N=1), which is set to 1 on the last fragment as illustrated in 212 Appendix B of [SCHC] and to 0 otherwise. There is no W field 213 (M=0). 215 0 1 216 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--------...-------+~~~~~~~~~~~ 218 |1 1 1 1| DTag |F| Fragment Payload | padding 219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--------...-------+~~~~~~~~~~~ 220 |--------- T ---------|N| 221 |---- SCHC Fragment Header ----| 223 Figure 4: SCHC Fragment 225 The No-ACK mode has been designed under the assumption that data 226 unit out-of-sequence delivery does not occur between the entity 227 performing fragmentation and the entity performing reassembly and 228 a DetNet PREOF function might be needed to reorder the fragments. 230 Maximum packet size: MAX_PACKET_SIZE is aligned to the PPP Link MTU. 232 Padding: The Compression Residue MUST be aligned to the L2 word. 233 For Ethernet, the L2 word is one byte, so padding is needed up to 234 the next byte boundary. If a compression rule produces a residue 235 that is not byte aligned, then it is implicitly terminated with a 236 statement that indicates padding till the next byte boundary. The 237 padding bit is 0. 239 4.2.1. Resulting Packet Format 241 In the case of PPPoE, the sequence of compression and encapsulation 242 is as follows: 244 A packet (e.g., an IPv6 packet) 245 | ^ (padding bits 246 v | dropped) 247 +------------------+ +--------------------+ 248 | SCHC Compression | | SCHC Decompression | 249 +------------------+ +--------------------+ 250 | ^ 251 +-- No -+ | 252 | fragmentation | +------------------>+ 253 v | | | 254 +--------------------+ | | +-------------------+ 255 | SCHC Fragmentation | | | | SCHC Reassembly | 256 +--------------------+ | | +-------------------+ 257 | | | ^ 258 +<------------------+ | No | 259 | +-- fragmentation -+ 260 v | 261 +--------------------+ +--------------------+ 262 | PPP Session encaps | | PPP Session decaps | 263 +--------------------+ +--------------------+ 264 | ^ 265 | | 266 v | 267 +------------------+ +------------------+ 268 | PPPoE(oE) encaps | | PPPoE(oE) encaps | 269 +------------------+ +------------------+ 270 | ^ 271 | | 272 +-------------------------------------------+ 273 Sender Receiver 275 Figure 5: Stack Operation (no fragment) 277 In the case of PPPoE, a frame that transports an IPv6 packet 278 compressed with SCHC with no fragmentation shows as follows: 280 0 1 2 3 281 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 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 | | 284 + Source MAC Address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 | | | 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Destination MAC Address + 287 | | 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 | Ethernet Frame Type(0x8864) | Ver=1 | Type=1| Code=0 | 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 | Session ID | Length | 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 | PPP Protocol (IPv6) = 0x0057 |0|0| SCHC RuleID | 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 | | 296 ... Compression ... 297 | Residue +-+-+-+ 298 | | Pad | 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 | | 301 | | 302 | Uncompressed | 303 ... Original ... 304 | Payload | 305 | | 306 | | 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 Figure 6: SCHC over PPP over Ethernet Format 311 4.3. Security Considerations 313 This draft enables to use the SCHC compression and fragmentation over 314 PPP and therefore Ethernet and Wi-Fi with PPPoE. It inherits the 315 possible threats against SCHC listed in the "Security considerations" 316 section of [SCHC]. 318 5. IANA Considerations 320 This document requests the allocation of a new value in the registry 321 "IPv6-Compression-Protocol Types" for "SCHC". A suggested value is 322 proposed in Table 1: 324 +=======+==========================================+===============+ 325 | Value | Description | Reference | 326 +=======+==========================================+===============+ 327 | 4 | Static Context Header Compression (SCHC) | This document | 328 +-------+------------------------------------------+---------------+ 330 Table 1: IP Header Compression Configuration Option Suboption Types 332 6. Acknowledgments 334 7. Normative References 336 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 337 Requirement Levels", BCP 14, RFC 2119, 338 DOI 10.17487/RFC2119, March 1997, 339 . 341 [RFC2516] Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D., 342 and R. Wheeler, "A Method for Transmitting PPP Over 343 Ethernet (PPPoE)", RFC 2516, DOI 10.17487/RFC2516, 344 February 1999, . 346 [RFC5072] Varada, S., Ed., Haskins, D., and E. Allen, "IP Version 6 347 over PPP", RFC 5072, DOI 10.17487/RFC5072, September 2007, 348 . 350 [RFC5172] Varada, S., Ed., "Negotiation for IPv6 Datagram 351 Compression Using IPv6 Control Protocol", RFC 5172, 352 DOI 10.17487/RFC5172, March 2008, 353 . 355 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 356 Resource Identifier (URI): Generic Syntax", STD 66, 357 RFC 3986, DOI 10.17487/RFC3986, January 2005, 358 . 360 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 361 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 362 May 2017, . 364 [SCHC] Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and JC. 365 Zúñiga, "SCHC: Generic Framework for Static Context Header 366 Compression and Fragmentation", RFC 8724, 367 DOI 10.17487/RFC8724, April 2020, 368 . 370 8. Informative References 372 [SCHC_DATA_MODEL] 373 Minaburo, A. and L. Toutain, "Data Model for Static 374 Context Header Compression (SCHC)", Work in Progress, 375 Internet-Draft, draft-ietf-lpwan-schc-yang-data-model-03, 376 10 July 2020, . 379 [RAW Technologies] 380 Thubert, P., Cavalcanti, D., Vilajosana, X., Schmitt, C., 381 and J. Farkas, "Reliable and Available Wireless 382 Technologies", Work in Progress, Internet-Draft, draft- 383 thubert-raw-technologies-05, 18 May 2020, 384 . 387 [RFC7951] Lhotka, L., "JSON Encoding of Data Modeled with YANG", 388 RFC 7951, DOI 10.17487/RFC7951, August 2016, 389 . 391 [DetNet] Finn, N., Thubert, P., Varga, B., and J. Farkas, 392 "Deterministic Networking Architecture", RFC 8655, 393 DOI 10.17487/RFC8655, October 2019, 394 . 396 [IEEE802.1TSNTG] 397 IEEE, "Time-Sensitive Networking (TSN) Task Group", 398 . 400 Author's Address 402 Pascal Thubert (editor) 403 Cisco Systems, Inc 404 Building D 405 45 Allee des Ormes - BP1200 406 06254 Mougins - Sophia Antipolis 407 France 409 Phone: +33 497 23 26 34 410 Email: pthubert@cisco.com