idnits 2.17.1 draft-thubert-intarea-schc-over-ppp-03.txt: -(372): 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 (21 April 2021) is 1098 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 == Outdated reference: A later version (-02) exists of draft-pelov-lpwan-architecture-00 Summary: 1 error (**), 0 flaws (~~), 3 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) 21 April 2021 5 Intended status: Standards Track 6 Expires: 23 October 2021 8 SCHC over PPP 9 draft-thubert-intarea-schc-over-ppp-03 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 23 October 2021. 34 Copyright Notice 36 Copyright (c) 2021 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 . . . . . . . . . . . . . . . . . 8 58 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 59 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 60 7. Normative References . . . . . . . . . . . . . . . . . . . . 9 61 8. Informative References . . . . . . . . . . . . . . . . . . . 9 62 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 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 PPP is not commonly used in Low-Power Wide Area Networks (LPWAN) but 84 the extreme compression techniques that are defined for use in LPWAN 85 may be applicabel to more traditional links where PPP applies. 87 The "Static Context Header Compression (SCHC) and fragmentation for 88 LPWAN, application to UDP/IPv6" [SCHC] is a new technology that can 89 provide an extreme compression performance but requires a same state 90 to be provisionned on both ends before it can be operated. 92 The "SCHC Architecture" [I-D.pelov-lpwan-architecture] enables a peer 93 to peer SCHC operation in addition to the classical device to network 94 LPWAN paradigm, e.g., over a PPP connection. To enable SCHC over PPP 95 and therefore Ethernet and Wi-Fi, this specification extends 96 [RFC5172] to signal SCHC as an additional compression method for use 97 over PPP. 99 An example use case for SCHC over PPP over Ethernet (SCHCoPPPoE) is 100 to apply SCHC to periodic flows and maintain them at a protocol- 101 independant size and rate. The constant size may be too small for a 102 particular flow or protocol. The SCHC fragmentation can then be used 103 to transport a protocol data unit (PDU) as N compressed SCHC 104 fragments, in which case the effective PDU rate is the TSN frame rate 105 divided by N. 107 This can be useful to streamline the frames and simplifies the 108 scheduling of Deterministic Networking [DetNet] and Operational 109 Technology (OT) control flows over IEEE Std 802.1 Time-Sensitive 110 Networking (TSN) [IEEE802.1TSNTG] or one of the RAW Technologies [RAW 111 Technologies]. 113 2. BCP 14 115 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 116 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 117 "OPTIONAL" in this document are to be interpreted as described in BCP 118 14 [RFC2119][RFC8174] when, and only when, they appear in all 119 capitals, as shown here. 121 3. Extending RFC 5172 123 With this specification, a PPP session defines a vitual link where a 124 SCHC context is established with a particular set of Rules, which is 125 indicated at the set up of the PPP session as follows: 127 [RFC5172] defines an IPV6CP option called the IPv6-Compression- 128 Protocol Configuration option with a type of 2. The option contains 129 an IPv6-Compression-Protocol field value that indicates a compression 130 protocol and an optional data field as shown in Figure 1: 132 0 1 2 3 133 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 134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 135 | Type | Length | IPv6-Compression-Protocol | 136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 137 | Data ... 138 +-+-+-+-+ 139 Figure 1: The IPv6-Compression-Protocol Configuration Option 141 This specification indicates a new IPv6-Compression-Protocol field 142 value for [SCHC] (see Section 5), and enables to transport a Uniform 143 Resource Identifier (URI) [RFC3986] of the set of rules in the 144 optional data. The default format for the set of rules is YANG using 145 the "Data Model for SCHC" [SCHC_DATA_MODEL] encoded in JSON as 146 specified in [RFC7951]. The size of the URL is computed based on the 147 Length of the option as Length-4. If the encoding is asymetrical, 148 the initiator of the session is considered downstream, playing the 149 role of the device in an LPWAN network. 151 4. Profiling SCHC for high speed links 153 Appendix D of [SCHC] specifies the profile information that 154 technology specifications such as this must provide. The following 155 section address this requirement. 157 4.1. Mapping the SCHC Architecture 159 This specification leverages SCHC between an end point that is an IP 160 Host and possibly a serial DTE (Data Terminal Equipment), and another 161 that is an IP Node (either another IP Host or a Router) and possibly 162 a serial DCE (Data Control Equipment), or a more modern physical or 163 emulated endpoint, e.g., Ethernet devices that echange IP packets 164 over PPPoE. 166 Both endpoints MUST support the function of SCHC Compressor/ 167 Decompressor (C/D) as shown in Figure 2. 169 +----------+ Wi-Fi / +----------+ .... 170 | IP | Ethernet | IP | .. ) 171 | Host +-----/------+ Router +----------( Internet ) 172 | SCHC C/D | Serial | SCHC C/D | ( ) 173 +----------+ +----------+ ... 174 <-- SCHC --> 175 over PPP 177 Figure 2: Typical Deployment 179 The SCHC Fragmenter/Reassembler (F/R) is generally not needed, 180 because the maximum transmission unit (MTU) is expected to be large 181 enough and SCHC only reduces the frame size vs. native IP. But it 182 may be used to obtain a small protocol-independant frame size for the 183 compressed packets, possibly way smaller than MTU. 185 A context may be generated for a particular upper layer application, 186 such as a control loop using an industrial automation protocol, to 187 protect the particular flow with a DetNet service. The context can 188 be asymetric, e.g., when connecting a primary and a secondary 189 endpoints, a client and a server, or a programmable logic controller 190 with a sensor or an actuator. 192 4.2. SCHC Parameters 194 Compared to typical LPWANs, most serial links and emulations such as 195 PPPoE are very fast and most of the constraints can be alleviated. 196 For this reason, the SCHC profile for PPP is defined as follows: 198 RuleID numbering scheme: The RuleID for a compression rule is 199 expressed as 2 bytes. The first (leftmost) 2 bits of that RuleId 200 MUST be set to 0 This leaves 14 bits to index the rule. A SCHC 201 compressed packet is always in the form: 203 0 1 204 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+----------...--------+~~~~~~~~~~ 206 |0 0 RuleID | Compression Residue | Payload 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+----------...--------+~~~~~~~~~~ 208 |------- Compressed Header (byte aligned) ------------| 210 Figure 3: SCHC Compressed Packet 212 This specification only supports the No-ACK Mode of SCHC 213 fragmentation as specified in section 8.4.1 of [SCHC]. The SCHC 214 Fragment Header is 2 bytes long. 216 The RuleID for a fragmentation rule is expressed as 4 bits. The 217 bits MUST all set to 1 for a fragmentation rule in No-ACK Mode. 218 The DTag field is 11 bits long (T=11) and the FCN field is one bit 219 (N=1), which is set to 1 on the last fragment as illustrated in 220 Appendix B of [SCHC] and to 0 otherwise. There is no W field 221 (M=0). 223 0 1 224 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--------...-------+~~~~~~~~~~~ 226 |1 1 1 1| DTag |F| Fragment Payload | padding 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--------...-------+~~~~~~~~~~~ 228 |--------- T ---------|N| 229 |---- SCHC Fragment Header ----| 230 Figure 4: SCHC Fragment 232 The No-ACK mode has been designed under the assumption that data 233 unit out-of-sequence delivery does not occur between the entity 234 performing fragmentation and the entity performing reassembly and 235 a DetNet PREOF function might be needed to reorder the fragments. 237 Maximum packet size: MAX_PACKET_SIZE is aligned to the PPP Link MTU. 239 Padding: The Compression Residue MUST be aligned to the L2 word. 240 For Ethernet, the L2 word is one byte, so padding is needed up to 241 the next byte boundary. If a compression rule produces a residue 242 that is not byte aligned, then it is implicitly terminated with a 243 statement that indicates padding till the next byte boundary. The 244 padding bit is 0. 246 4.2.1. Resulting Packet Format 248 In the case of PPPoE, the sequence of compression and encapsulation 249 is as follows: 251 A packet (e.g., an IPv6 packet) 252 | ^ (padding bits 253 v | dropped) 254 +------------------+ +--------------------+ 255 | SCHC Compression | | SCHC Decompression | 256 +------------------+ +--------------------+ 257 | ^ 258 +-- No -+ | 259 | fragmentation | +------------------>+ 260 v | | | 261 +--------------------+ | | +-------------------+ 262 | SCHC Fragmentation | | | | SCHC Reassembly | 263 +--------------------+ | | +-------------------+ 264 | | | ^ 265 +<------------------+ | No | 266 | +-- fragmentation -+ 267 v | 268 +--------------------+ +--------------------+ 269 | PPP Session encaps | | PPP Session decaps | 270 +--------------------+ +--------------------+ 271 | ^ 272 | | 273 v | 274 +------------------+ +------------------+ 275 | PPPoE(oE) encaps | | PPPoE(oE) encaps | 276 +------------------+ +------------------+ 277 | ^ 278 | | 279 +-------------------------------------------+ 280 Sender Receiver 282 Figure 5: Stack Operation (no fragment) 284 In the case of PPPoE, a frame that transports an IPv6 packet 285 compressed with SCHC with no fragmentation shows as follows: 287 0 1 2 3 288 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 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 | | 291 + Source MAC Address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 | | | 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Destination MAC Address + 294 | | 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 | Ethernet Frame Type(0x8864) | Ver=1 | Type=1| Code=0 | 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 | Session ID | Length | 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 | PPP Protocol (IPv6) = 0x0057 |0|0| SCHC RuleID | 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 | | 303 ... Compression ... 304 | Residue +-+-+-+ 305 | | Pad | 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 | | 308 | | 309 | Uncompressed | 310 ... Original ... 311 | Payload | 312 | | 313 | | 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 Figure 6: SCHC over PPP over Ethernet Format 318 4.3. Security Considerations 320 This draft enables to use the SCHC compression and fragmentation over 321 PPP and therefore Ethernet and Wi-Fi with PPPoE. It inherits the 322 possible threats against SCHC listed in the "Security considerations" 323 section of [SCHC]. 325 5. IANA Considerations 327 This document requests the allocation of a new value in the registry 328 "IPv6-Compression-Protocol Types" for "SCHC". A suggested value is 329 proposed in Table 1: 331 +=======+==========================================+===============+ 332 | Value | Description | Reference | 333 +=======+==========================================+===============+ 334 | 4 | Static Context Header Compression (SCHC) | This document | 335 +-------+------------------------------------------+---------------+ 337 Table 1: IP Header Compression Configuration Option Suboption Types 339 6. Acknowledgments 341 7. Normative References 343 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 344 Requirement Levels", BCP 14, RFC 2119, 345 DOI 10.17487/RFC2119, March 1997, 346 . 348 [RFC2516] Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D., 349 and R. Wheeler, "A Method for Transmitting PPP Over 350 Ethernet (PPPoE)", RFC 2516, DOI 10.17487/RFC2516, 351 February 1999, . 353 [RFC5072] Varada, S., Ed., Haskins, D., and E. Allen, "IP Version 6 354 over PPP", RFC 5072, DOI 10.17487/RFC5072, September 2007, 355 . 357 [RFC5172] Varada, S., Ed., "Negotiation for IPv6 Datagram 358 Compression Using IPv6 Control Protocol", RFC 5172, 359 DOI 10.17487/RFC5172, March 2008, 360 . 362 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 363 Resource Identifier (URI): Generic Syntax", STD 66, 364 RFC 3986, DOI 10.17487/RFC3986, January 2005, 365 . 367 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 368 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 369 May 2017, . 371 [SCHC] Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and JC. 372 Zúñiga, "SCHC: Generic Framework for Static Context Header 373 Compression and Fragmentation", RFC 8724, 374 DOI 10.17487/RFC8724, April 2020, 375 . 377 8. Informative References 379 [I-D.pelov-lpwan-architecture] 380 Pelov, A., Thubert, P., and A. Minaburo, "Static Context 381 Header Compression (SCHC) Architecture", Work in Progress, 382 Internet-Draft, draft-pelov-lpwan-architecture-00, 19 383 January 2021, . 386 [SCHC_DATA_MODEL] 387 Minaburo, A. and L. Toutain, "Data Model for Static 388 Context Header Compression (SCHC)", Work in Progress, 389 Internet-Draft, draft-ietf-lpwan-schc-yang-data-model-03, 390 10 July 2020, . 393 [RAW Technologies] 394 Thubert, P., Cavalcanti, D., Vilajosana, X., Schmitt, C., 395 and J. Farkas, "Reliable and Available Wireless 396 Technologies", Work in Progress, Internet-Draft, draft- 397 thubert-raw-technologies-05, 18 May 2020, 398 . 401 [RFC7951] Lhotka, L., "JSON Encoding of Data Modeled with YANG", 402 RFC 7951, DOI 10.17487/RFC7951, August 2016, 403 . 405 [DetNet] Finn, N., Thubert, P., Varga, B., and J. Farkas, 406 "Deterministic Networking Architecture", RFC 8655, 407 DOI 10.17487/RFC8655, October 2019, 408 . 410 [IEEE802.1TSNTG] 411 IEEE, "Time-Sensitive Networking (TSN) Task Group", 412 . 414 Author's Address 416 Pascal Thubert (editor) 417 Cisco Systems, Inc 418 Building D 419 45 Allee des Ormes - BP1200 420 06254 Mougins - Sophia Antipolis 421 France 423 Phone: +33 497 23 26 34 424 Email: pthubert@cisco.com