< draft-ietf-lpwan-ipv6-static-context-hc-19.txt   draft-ietf-lpwan-ipv6-static-context-hc-20.txt >
lpwan Working Group A. Minaburo lpwan Working Group A. Minaburo
Internet-Draft Acklio Internet-Draft Acklio
Intended status: Standards Track L. Toutain Intended status: Standards Track L. Toutain
Expires: January 5, 2020 IMT-Atlantique Expires: January 23, 2020 IMT-Atlantique
C. Gomez C. Gomez
Universitat Politecnica de Catalunya Universitat Politecnica de Catalunya
D. Barthel D. Barthel
Orange Labs Orange Labs
JC. Zuniga JC. Zuniga
SIGFOX SIGFOX
July 04, 2019 July 22, 2019
Static Context Header Compression (SCHC) and fragmentation for LPWAN, Static Context Header Compression (SCHC) and fragmentation for LPWAN,
application to UDP/IPv6 application to UDP/IPv6
draft-ietf-lpwan-ipv6-static-context-hc-19 draft-ietf-lpwan-ipv6-static-context-hc-20
Abstract Abstract
This document defines the Static Context Header Compression (SCHC) This document defines the Static Context Header Compression (SCHC)
framework, which provides both header compression and fragmentation framework, which provides both header compression and fragmentation
functionalities. SCHC has been designed for Low Power Wide Area functionalities. SCHC has been designed for Low Power Wide Area
Networks (LPWAN). Networks (LPWAN).
SCHC compression is based on a common static context stored in both SCHC compression is based on a common static context stored in both
the LPWAN device and the network side. This document defines a the LPWAN device and the network side. This document defines a
skipping to change at page 2, line 20 skipping to change at page 2, line 20
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 5, 2020. This Internet-Draft will expire on January 23, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 51 skipping to change at page 2, line 51
3. LPWAN Architecture . . . . . . . . . . . . . . . . . . . . . 5 3. LPWAN Architecture . . . . . . . . . . . . . . . . . . . . . 5
4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. SCHC overview . . . . . . . . . . . . . . . . . . . . . . . . 8 5. SCHC overview . . . . . . . . . . . . . . . . . . . . . . . . 8
5.1. SCHC Packet format . . . . . . . . . . . . . . . . . . . 10 5.1. SCHC Packet format . . . . . . . . . . . . . . . . . . . 10
5.2. Functional mapping . . . . . . . . . . . . . . . . . . . 10 5.2. Functional mapping . . . . . . . . . . . . . . . . . . . 10
6. Rule ID . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 6. Rule ID . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
7. Compression/Decompression . . . . . . . . . . . . . . . . . . 12 7. Compression/Decompression . . . . . . . . . . . . . . . . . . 12
7.1. SCHC C/D Rules . . . . . . . . . . . . . . . . . . . . . 12 7.1. SCHC C/D Rules . . . . . . . . . . . . . . . . . . . . . 12
7.2. Rule ID for SCHC C/D . . . . . . . . . . . . . . . . . . 14 7.2. Rule ID for SCHC C/D . . . . . . . . . . . . . . . . . . 14
7.3. Packet processing . . . . . . . . . . . . . . . . . . . . 15 7.3. Packet processing . . . . . . . . . . . . . . . . . . . . 15
7.4. Matching operators . . . . . . . . . . . . . . . . . . . 16 7.4. Matching operators . . . . . . . . . . . . . . . . . . . 17
7.5. Compression Decompression Actions (CDA) . . . . . . . . . 17 7.5. Compression Decompression Actions (CDA) . . . . . . . . . 17
7.5.1. processing fixed-length fields . . . . . . . . . . . 17 7.5.1. processing fixed-length fields . . . . . . . . . . . 18
7.5.2. processing variable-length fields . . . . . . . . . . 18 7.5.2. processing variable-length fields . . . . . . . . . . 18
7.5.3. not-sent CDA . . . . . . . . . . . . . . . . . . . . 18 7.5.3. not-sent CDA . . . . . . . . . . . . . . . . . . . . 19
7.5.4. value-sent CDA . . . . . . . . . . . . . . . . . . . 19 7.5.4. value-sent CDA . . . . . . . . . . . . . . . . . . . 19
7.5.5. mapping-sent CDA . . . . . . . . . . . . . . . . . . 19 7.5.5. mapping-sent CDA . . . . . . . . . . . . . . . . . . 19
7.5.6. LSB CDA . . . . . . . . . . . . . . . . . . . . . . . 19 7.5.6. LSB CDA . . . . . . . . . . . . . . . . . . . . . . . 20
7.5.7. DevIID, AppIID CDA . . . . . . . . . . . . . . . . . 20 7.5.7. DevIID, AppIID CDA . . . . . . . . . . . . . . . . . 20
7.5.8. Compute-* . . . . . . . . . . . . . . . . . . . . . . 20 7.5.8. Compute-* . . . . . . . . . . . . . . . . . . . . . . 20
8. Fragmentation/Reassembly . . . . . . . . . . . . . . . . . . 20 8. Fragmentation/Reassembly . . . . . . . . . . . . . . . . . . 21
8.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 20 8.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 21
8.2. SCHC F/R Protocol Elements . . . . . . . . . . . . . . . 21 8.2. SCHC F/R Protocol Elements . . . . . . . . . . . . . . . 21
8.2.1. Messages . . . . . . . . . . . . . . . . . . . . . . 21 8.2.1. Messages . . . . . . . . . . . . . . . . . . . . . . 21
8.2.2. Tiles, Windows, Bitmaps, Timers, Counters . . . . . . 22 8.2.2. Tiles, Windows, Bitmaps, Timers, Counters . . . . . . 22
8.2.3. Integrity Checking . . . . . . . . . . . . . . . . . 24 8.2.3. Integrity Checking . . . . . . . . . . . . . . . . . 24
8.2.4. Header Fields . . . . . . . . . . . . . . . . . . . . 24 8.2.4. Header Fields . . . . . . . . . . . . . . . . . . . . 25
8.3. SCHC F/R Message Formats . . . . . . . . . . . . . . . . 27 8.3. SCHC F/R Message Formats . . . . . . . . . . . . . . . . 27
8.3.1. SCHC Fragment format . . . . . . . . . . . . . . . . 27 8.3.1. SCHC Fragment format . . . . . . . . . . . . . . . . 27
8.3.2. SCHC ACK format . . . . . . . . . . . . . . . . . . . 28 8.3.2. SCHC ACK format . . . . . . . . . . . . . . . . . . . 28
8.3.3. SCHC ACK REQ format . . . . . . . . . . . . . . . . . 31 8.3.3. SCHC ACK REQ format . . . . . . . . . . . . . . . . . 31
8.3.4. SCHC Sender-Abort format . . . . . . . . . . . . . . 31 8.3.4. SCHC Sender-Abort format . . . . . . . . . . . . . . 31
8.3.5. SCHC Receiver-Abort format . . . . . . . . . . . . . 31 8.3.5. SCHC Receiver-Abort format . . . . . . . . . . . . . 32
8.4. SCHC F/R modes . . . . . . . . . . . . . . . . . . . . . 32 8.4. SCHC F/R modes . . . . . . . . . . . . . . . . . . . . . 33
8.4.1. No-ACK mode . . . . . . . . . . . . . . . . . . . . . 33 8.4.1. No-ACK mode . . . . . . . . . . . . . . . . . . . . . 33
8.4.2. ACK-Always mode . . . . . . . . . . . . . . . . . . . 35 8.4.2. ACK-Always mode . . . . . . . . . . . . . . . . . . . 35
8.4.3. ACK-on-Error mode . . . . . . . . . . . . . . . . . . 41 8.4.3. ACK-on-Error mode . . . . . . . . . . . . . . . . . . 41
9. Padding management . . . . . . . . . . . . . . . . . . . . . 48 9. Padding management . . . . . . . . . . . . . . . . . . . . . 48
10. SCHC Compression for IPv6 and UDP headers . . . . . . . . . . 49 10. SCHC Compression for IPv6 and UDP headers . . . . . . . . . . 49
10.1. IPv6 version field . . . . . . . . . . . . . . . . . . . 49 10.1. IPv6 version field . . . . . . . . . . . . . . . . . . . 49
10.2. IPv6 Traffic class field . . . . . . . . . . . . . . . . 49 10.2. IPv6 Traffic class field . . . . . . . . . . . . . . . . 50
10.3. Flow label field . . . . . . . . . . . . . . . . . . . . 49 10.3. Flow label field . . . . . . . . . . . . . . . . . . . . 50
10.4. Payload Length field . . . . . . . . . . . . . . . . . . 50 10.4. Payload Length field . . . . . . . . . . . . . . . . . . 50
10.5. Next Header field . . . . . . . . . . . . . . . . . . . 50 10.5. Next Header field . . . . . . . . . . . . . . . . . . . 50
10.6. Hop Limit field . . . . . . . . . . . . . . . . . . . . 50 10.6. Hop Limit field . . . . . . . . . . . . . . . . . . . . 51
10.7. IPv6 addresses fields . . . . . . . . . . . . . . . . . 50 10.7. IPv6 addresses fields . . . . . . . . . . . . . . . . . 51
10.7.1. IPv6 source and destination prefixes . . . . . . . . 51 10.7.1. IPv6 source and destination prefixes . . . . . . . . 51
10.7.2. IPv6 source and destination IID . . . . . . . . . . 51 10.7.2. IPv6 source and destination IID . . . . . . . . . . 52
10.8. IPv6 extensions . . . . . . . . . . . . . . . . . . . . 51 10.8. IPv6 extensions . . . . . . . . . . . . . . . . . . . . 52
10.9. UDP source and destination port . . . . . . . . . . . . 52 10.9. UDP source and destination port . . . . . . . . . . . . 52
10.10. UDP length field . . . . . . . . . . . . . . . . . . . . 52 10.10. UDP length field . . . . . . . . . . . . . . . . . . . . 53
10.11. UDP Checksum field . . . . . . . . . . . . . . . . . . . 52 10.11. UDP Checksum field . . . . . . . . . . . . . . . . . . . 53
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 53 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 54
12. Security considerations . . . . . . . . . . . . . . . . . . . 53 12. Security considerations . . . . . . . . . . . . . . . . . . . 54
12.1. Security considerations for SCHC 12.1. Security considerations for SCHC
Compression/Decompression . . . . . . . . . . . . . . . 53 Compression/Decompression . . . . . . . . . . . . . . . 54
12.2. Security considerations for SCHC 12.2. Security considerations for SCHC
Fragmentation/Reassembly . . . . . . . . . . . . . . . . 54 Fragmentation/Reassembly . . . . . . . . . . . . . . . . 55
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 55 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 56
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 55 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 56
14.1. Normative References . . . . . . . . . . . . . . . . . . 55 14.1. Normative References . . . . . . . . . . . . . . . . . . 56
14.2. Informative References . . . . . . . . . . . . . . . . . 56 14.2. Informative References . . . . . . . . . . . . . . . . . 56
Appendix A. Compression Examples . . . . . . . . . . . . . . . . 57 Appendix A. Compression Examples . . . . . . . . . . . . . . . . 57
Appendix B. Fragmentation Examples . . . . . . . . . . . . . . . 59 Appendix B. Fragmentation Examples . . . . . . . . . . . . . . . 60
Appendix C. Fragmentation State Machines . . . . . . . . . . . . 67 Appendix C. Fragmentation State Machines . . . . . . . . . . . . 67
Appendix D. SCHC Parameters . . . . . . . . . . . . . . . . . . 73 Appendix D. SCHC Parameters . . . . . . . . . . . . . . . . . . 73
Appendix E. Supporting multiple window sizes for fragmentation . 75 Appendix E. Supporting multiple window sizes for fragmentation . 75
Appendix F. Downlink SCHC Fragment transmission . . . . . . . . 75 Appendix F. Downlink SCHC Fragment transmission . . . . . . . . 75
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 76
1. Introduction 1. Introduction
This document defines the Static Context Header Compression (SCHC) This document defines the Static Context Header Compression (SCHC)
framework, which provides both header compression and fragmentation framework, which provides both header compression and fragmentation
skipping to change at page 7, line 28 skipping to change at page 7, line 28
o FL: Field Length is the length of the packet header field. It is o FL: Field Length is the length of the packet header field. It is
expressed in bits for header fields of fixed lengths or as a type expressed in bits for header fields of fixed lengths or as a type
(e.g. variable, token length, ...) for field lengths that are (e.g. variable, token length, ...) for field lengths that are
unknown at the time of Rule creation. The length of a header unknown at the time of Rule creation. The length of a header
field is defined in the corresponding protocol specification (such field is defined in the corresponding protocol specification (such
as IPv6 or UDP). as IPv6 or UDP).
o FP: when a Field is expected to appear multiple times in a header, o FP: when a Field is expected to appear multiple times in a header,
Field Position specifies the occurence this Field Description Field Position specifies the occurence this Field Description
applies to (for example, first uri-path option, second uri-path, applies to (for example, first uri-path option, second uri-path,
etc. in a CoAP header). The value 1 designates the first etc. in a CoAP header).
occurence. The default value is 1.
o IID: Interface Identifier. See the IPv6 addressing architecture o IID: Interface Identifier. See the IPv6 addressing architecture
[RFC7136] [RFC7136]
o L2: Layer two. The immediate lower layer SCHC interfaces with. o L2: Layer two. The immediate lower layer SCHC interfaces with.
It is provided by an underlying LPWAN technology. It does not It is provided by an underlying LPWAN technology. It does not
necessarily correspond to the OSI model definition of Layer 2. necessarily correspond to the OSI model definition of Layer 2.
o L2 Word: this is the minimum subdivision of payload data that the o L2 Word: this is the minimum subdivision of payload data that the
L2 will carry. In most L2 technologies, the L2 Word is an octet. L2 will carry. In most L2 technologies, the L2 Word is an octet.
skipping to change at page 13, line 51 skipping to change at page 13, line 51
Field ID also identifies the nesting. Field ID also identifies the nesting.
o Field Length (FL) represents the length of the field. It can be o Field Length (FL) represents the length of the field. It can be
either a fixed value (in bits) if the length is known when the either a fixed value (in bits) if the length is known when the
Rule is created or a type if the length is variable. The length Rule is created or a type if the length is variable. The length
of a header field is defined by its own protocol specification of a header field is defined by its own protocol specification
(e.g. IPv6 or UDP). If the length is variable, the type defines (e.g. IPv6 or UDP). If the length is variable, the type defines
the process to compute the length and its unit (bits, bytes...). the process to compute the length and its unit (bits, bytes...).
o Field Position (FP): most often, a field only occurs once in a o Field Position (FP): most often, a field only occurs once in a
packet header. Some fields may occur multiple times in a header. packet header. However, some fields may occur multiple times. An
example is the uri-path of CoAP. FP indicates which occurrence
FP indicates which occurrence this Field Description applies to. this Field Description applies to. If FP is not specified in the
The default value is 1 (first occurrence). Field Description, it takes the default value of 1. The value 1
designates the first occurence. The value 0 is special. It means
"don't care", see Section 7.3.
o A Direction Indicator (DI) indicates the packet direction(s) this o A Direction Indicator (DI) indicates the packet direction(s) this
Field Description applies to. Three values are possible: Field Description applies to. Three values are possible:
* UPLINK (Up): this Field Description is only applicable to * UPLINK (Up): this Field Description is only applicable to
packets sent by the Dev to the App, packets sent by the Dev to the App,
* DOWNLINK (Dw): this Field Description is only applicable to * DOWNLINK (Dw): this Field Description is only applicable to
packets sent from the App to the Dev, packets sent from the App to the Dev,
skipping to change at page 15, line 31 skipping to change at page 15, line 33
* The next step is to match the Field Descriptions by their * The next step is to match the Field Descriptions by their
direction, using the Direction Indicator (DI). If any field of direction, using the Direction Indicator (DI). If any field of
the packet header cannot be matched with a Field Description the packet header cannot be matched with a Field Description
with the correct FID and DI, the Rule MUST be disregarded. with the correct FID and DI, the Rule MUST be disregarded.
* Then the Field Descriptions are further selected according to * Then the Field Descriptions are further selected according to
Field Position (FP). If any field of the packet header cannot Field Position (FP). If any field of the packet header cannot
be matched with a Field Description with the correct FID, DI be matched with a Field Description with the correct FID, DI
and FP, the Rule MUST be disregarded. and FP, the Rule MUST be disregarded.
The value 0 for FP means "don't care", i.e. the comparison of
this Field Description's FP with the position of the field of
the packet header being compressed returns True, whatever that
position. FP=0 can be useful to build compression Rules for
protocols headers in which some fields order is irrelevant. An
example could be uri-queries in CoAP. Care needs to be
exercised when writing Rules containing FP=0 values. Inded, it
may result in decompressed packets having fields ordered
differently compared to the original packet.
* Once each header field has been associated with a Field * Once each header field has been associated with a Field
Description with matching FID, DI and FP, each packet field's Description with matching FID, DI and FP, each packet field's
value is then compared to the corresponding Target Value (TV) value is then compared to the corresponding Target Value (TV)
stored in the Rule for that specific field, using the matching stored in the Rule for that specific field, using the matching
operator (MO). If every field in the packet header satisfies operator (MO). If every field in the packet header satisfies
the corresponding matching operators (MO) of a Rule (i.e. all the corresponding matching operators (MO) of a Rule (i.e. all
MO results are True), that Rule is used for compressing the MO results are True), that Rule is used for compressing the
header. Otherwise, the Rule MUST be disregarded. header. Otherwise, the Rule MUST be disregarded.
* If no eligible compression Rule is found, then the header MUST * If no eligible compression Rule is found, then the header MUST
 End of changes. 21 change blocks. 
35 lines changed or deleted 46 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/