Static Context Header Compression (SCHC) Architecture

4.3.1. SCHC Header

SCHC Header carries information to allow the SCHC strata to work correctly. For example, it selects the correct Instance and checks the validity of the datagram. There IS NOT always a RuleID if there is only one Rule for the SCHC Header, whose length is 0. The SCHC Header format is not fixed, and the SoR MUST have one or more Rules describing the formats. SCHC Header contains different fields. For Instance, when the SCHC header may identify the next protocol in the stack, the format of the SCHC header takes the format as Figure 2 shows.¶

Non-compressed SCHC Header Format:
+- - - - - - +- - - - - - -+- - -+
| Session ID | Protocol ID | CRC |
+- - - - - - +- - - - - - -+- - -+

SCHC Header Compressed:
+- - - - -+- - - - - - - - - - +
| Rule ID | Compressed Residue |
+- - - - -+- - - - - - - - - - +

Rule uses to compressed the SCHC Header:
RuleID
+------------+--+---+--+-----+------+-----------+
|     FID    |FL|POS|DI| TV  |  MO  |     CDA   |
+------------+--+---+--+-----+------+-----------+
| SCHC.sesid |10| 1 |Bi|0x00 |MSB(7)| LSB       |
| SCHC.proto | 8| 1 |Bi|value|equal | not-sent  |
| SCHC.CRC   | 8| 1 |Bi|     |ignore| value-sent|
+------------+--+---+--+-----+------+-----------+

In this example the Rule defines:¶

• A SessionID is 10 bits length and it is used to identify the SoR used for this instance of SCHC.¶

• A Protocol ID in 1-byte length giving the value send in the layer below the SCHC packet to identify the uncompressed protocol stack.¶

• And A CRC. The CRC field is 8 bits length and covers the SCHC header and the SCHC packet from error. When it is elided by the compression, the layer-4 checksum MUST be replaced by another validation sequence.¶

4.4.1. SCHC Packet

The SCHC Packet is composed of a RuleID follows by the content described in the Rule. The content may be a C/D packet, a F/R packet, a CORECONF_Management or a Non Compressed packet. As defined in the [rfc8724], the SCHC packet for C/D is composed of the Compressed Header followed by the payload from the original packet. Figure 3 shows the compressed header format that is composed of the RuledID and a Compressed Residue, which is the output of compressing a packet header with a Rule.¶

C/D Compressed Packet:

+------------+----------------------+
|   RuleID   | Compressed Residue   |
+------------+----------------------+

F/R Compressed Packet:

+------------+----------------------+-----
|   RuleID   | Fragmentation Header | Tiles
+------------+----------------------+-----

CORECONF_Management Compressed Packet:

+------------+----------------------+
|   RuleID   | Compressed Residue   |
+------------+----------------------+

4.6.1. SCHC Rules

SCHC Rules are a description of the header protocols fields, into a list of Field Descriptors. The [rfc8724] gives the format of the Rule description for C/D, F/R and non-compression. In the same manner the SCHC Header and SCHc CORECONF_Management will use the [rfc8724] field descriptors to compress the format information.¶

Each type of Rule is identified with a RuleID. There are different types of Rules: C/D, F/R, SCHC Header, CORECONF_Management and No Compression. Notice that each Rule type used an independent range of RuleID to identify its rules.¶

A Rule does not describe how the compressor parses a packet header. Rules only describe the behavior for each header field.¶

SCHC Action. ToDo¶

4.6.2. SoR identification

ToDo¶

4.7.1. SCHC Data Model

A SCHC instance, summarized in the Figure 5, implies C/D and/or F/R and CORECONF_Management and SCHC Instances Rules present in both end and that both ends are provisioned with the same SoR.¶

        -----                                  -----
       [ SoR ]                                [ SoR ]
        -----                                  -----
          .                                      .
          .                                      .
          .                                      .
       +- M ---+                              +- M ---+
   <===| R & D |<===                      <===| C & F |<===
   ===>| C & F |===>                      ===>| R & D |===>
       +-------+                              +-------+

A common rule representation that expresses the SCHC rules in an interoperable fashion is needed to be able to provision end-points from different vendors to that effect, [rfc9363] defines a rule representation using the YANG [rfc7950] formalism.¶

[rfc9363] defines a YANG data model to represent the rules. This enables the use of several protocols for rule management, such as NETCONF[RFC6241], RESTCONF[RFC8040], and CORECONF[I-D.ietf-core-comi]. NETCONF uses SSH, RESTCONF uses HTTPS, and CORECONF uses CoAP(s) as their respective transport layer protocols. The data is represented in XML under NETCONF, in JSON[RFC8259] under RESTCONF and in CBOR[RFC8949] under CORECONF.¶

               create
        -----  read    +=======+
       [ SoR ]<------->|Rule   |<-----+ NETCONF,
        -----  update  |Manager|      | RESTCONF or
                delete +=======+      | CORECONF
           +--------------------------+ request
           |
           v M
       +---+---+
   <===| R & D |<===
   ===>| C & F |===>
       +-------+

The Rule Manager (RM) is in charge of handling data derived from the YANG Data Model and apply changes to the context and SoR of each SCHC Instance Figure 6.¶

The RM is an Application using the Internet to exchange information, therefore:¶

• for the network-level SCHC, the communication does not require routing. Each of the end-points having an RM and both RMs can be viewed on the same link, therefore wellknown Link Local addresses can be used to identify the Device and the core RM. L2 security MAY be deemed as sufficient, if it provides the necessary level of protection.¶

• for application-level SCHC, routing is involved and global IP addresses SHOULD be used. End-to-end encryption is RECOMMENDED.¶

Management messages can also be carried in the negotiation protocol, for instace, the [I-D.ietf-schc-over-ppp] proposes a solution. The RM traffic may be itself compressed by SCHC: if CORECONF protocol is used, [rfc8824] can be applied.¶

6.1.1. SCHC over PPP

The LPWAN architecture (Figure 14) generalizes the model to any kind of peers. In the case of more capable devices, a SCHC Device may maintain more than one Instance with the same peer, or a set of different peers. Since SCHC does not signal the Instance in its packets, the information must be derived from a lower layer point to point information. For instance, the SCHC instance control can be associated one-to-one with a tunnel, a TLS session, or a TCP or a PPP connection.¶

For instance, [I-D.ietf-schc-over-ppp] describes a type of deployment where the C/D and/or F/R operations are performed between peers of equal capabilities over a PPP [rfc2516] connection. SCHC over PPP illustrates that with SCHC, the protocols that are compressed can be discovered dynamically and the rules can be fetched on-demand using CORECONF messages Rules, ensuring that the peers use the exact same set of rules.¶

    +----------+  Wi-Fi /   +----------+                ....
    |    IP    |  Ethernet  |    IP    |            ..          )
    |   Host   +-----/------+  Router  +----------(   Internet   )
    | SCHC C/D |  Serial    | SCHC C/D |            (         )
    +----------+            +----------+               ...
                <-- SCHC -->
                  over PPP

In that case, the SCHC Instance is derived from the PPP connection. This means that there can be only one Instance per PPP connection, and that all the flow and only the flow of that Instance is exchanged within the PPP connection. As discussed in Section 7, the Uplink direction is from the node that initiated the PPP connection to the node that accepted it.¶

6.1.2. SCHC over Ethernet

Before the SCHC compression takes place, the SCHC header showed in the Figure 11, is virtually inserted before the real protocol header and data that are compressed in the session, e.g. a IPv6 in this figure.¶

                                       |---- SCHC PACKET ----|
 +------------------+------------------+---------+-----------+
 | IEEE 802 Header  | SCHC Header      | Rule ID | Compressed|
 | Ethertype = SCHC | Ethertype = IPv6 |         | Residue   |
 +------------------+------------------+---------+-----------+
                     <-
                       SCHC overhead
                                     ->

6.1.3. SCHC over IPv6

In the case of IPv6, the expectation is that the Upper Layer Protocol (ULP) checksum can be elided in the SCHC compression of the ULP, because the SCHC header may have its own checksum that protects both the SCHC header and the whole ULP, header and payload.¶

The SCHC Header between IPv6 and the ULP is not needed because of the Next Header field on the IPv6 header format.¶

                             |---- SCHC Packet -----|
 +-------------+-------------+---------+------------+
 | IPv6 Header | SCHC Header | Rule ID | Compressed |
 |  NH=SCHC    | NH = ULP    |         | Residue    |
 +-------------+-------------+---------+------------+
                <-
                SCHC overhead
                           ->

In the air, both the SCHC header and the ULP are compressed. The session endpoints are typically identified by the source and destination IP addresses. If the roles are well-known, then the endpoint information can be elided and deduced from the IP header. If there is only one session, it can be elided as well, otherwise a rule and residue are needed to extract the session ID.¶

6.1.4. SCHC over UDP

When SCHC operates over the Internet, middleboxes may block packets with a next header that is SCHC. To avoid that issue, it would be desirable to prepend a UDP header before the SCHC header as shown in figure Figure 13.¶

                                           |---- SCHC Packet -----|
 +-------------+-------------+-------------+---------+------------+
 | IPv6 Header | UDP Header  | SCHC Header | Rule ID | Compressed |
 |  NH=UDP     | Port = SCHC | NH = ULP    |         | Residue    |
 +-------------+-------------+-------------+---------+------------+
                <-
                       SCHC overhead
                                          ->
~

In that case, the destination port can indicate SCHC as in an header chain, and the source port can indicate the SCHC session in which case it can be elided in the compressed form of the SCHC header. The UDP checksum protects both the SCHC header and the whole ULP, so the SCHC and the ULP checksums can both be elided. In other words, in the SCHC over UDP case, the SCHC header can be fully elided, but the packet must carry the overhead of a full UDP header.¶

7.1.1. Device Development

The expectation for the development cycle is that message formats are documented as a data model that is used to generate rules. Several models are possible:¶

1. In the application model, an interface definition language and binary communication protocol such as Apache Thrift is used, and the parser code includes the SCHC operation. This model imposes that both ends are compiled with the generated structures and linked with generated code that represents the rule operation.¶

2. In the device model, the rules are generated separately. Only the device-side code is linked with generated code. The Rules are published separately to be used by a generic SCHC engine that operates in a middle box such as a SCHC gateway.¶

3. In the protocol model, both endpoint generate a packet format that is imposed by a protocol. In that case, the protocol itself is the source to generate the Rules. Both ends of the SCHC compression are operated in middle boxes, and special attention must be taken to ensure that they operate on the compatible SoR, basically the same major version of the same SoR.¶

Depending on the deployment, the tools that generate the Rules should provide knobs to optimize the SoR, e.g., more rules vs. larger residue.¶

7.1.2. Rules Publication

In the device model and in the protocol model, at least one of the endpoints must obtain the SoR dynamically. The expectation is that the SoR are published to a reachable repository and versionned (minor, major). Each SoR should have its own Uniform Resource Names (URN) [RFC8141] and a version.¶

The SoR should be authenticated to ensure that it is genuine, or obtained from a trusted app store. A corrupted SoR may be used for multiple forms of attacks, more in Section 8.¶

7.1.3. SCHC Device Deployment

The device and the network should mutually authenticate themselves. The autonomic approach [RFC8993] provides a model to achieve this at scale with zero touch, in networks where enough bandwidth and compute are available. In highly constrained networks, one touch is usually necessary to program keys in the devices.¶

The initial handshake between the SCHC endpoints should comprise a capability exchange whereby URN and the version of the SoR are obtained or compared. SCHC may not be used if both ends can not agree on an URN and a major version.
Manufacturer Usage Descriptions (MUD) [RFC8520] may be used for that purpose in the device model.¶

Upon the handshake, both ends can agree on a SoR, their role when the rules are asymmetrical, and fetch the SoR if necessary. Optionally, a node that fetched a SoR may inform the other end that it is reacy from transmission.¶

7.1.4. SCHC Device Maintenance

URN update without device update (bug fix) FUOTA => new URN => reprovisioning¶

7.1.5. SCHC Device Decommissionning

Signal from device/vendor/network admin¶