]> Consultant

Rue de Rennes Cesson-Sevigne 35510 France anaminaburo@gmail.com

IMT Atlantique

CS 17607, 2 rue de la Chataigneraie Cesson-Sevigne Cedex 35576 France Laurent.Toutain@imt-atlantique.fr

IMT Atlantique

CS 17607, 2 rue de la Chataigneraie Cesson-Sevigne Cedex 35576 France corentin.banier@imt-atlantique.fr

Orange

marion.dumay@orange.com

Internet SCHC Working Group Internet-Draft This document describes how CORECONF management can be applied to SCHC Context.

Introduction{#intro} defines the YANG Data Model for a SCHC context (a.k.a Set of Rules). proposes the architecture for rule management. Some rules must be clearly dedicated to the modification of the context. defines a way to serialize data issued from a YANG DM into a CBOR representation and defines the CoAP interface. This document describes in which condition management can be done, how to manage rules inside an SCHC instance using CORECONF and proposes some compression rules for the protocol headers.

Applicability statement

Architecture SCHC instance management allows the two end-points to modify the common SoR, by:

• modifying rules values (such as TV, MO or CDA) in existing rules,
• adding a new rule,
• removing an existing rule.

The rule management uses the CORECONF interface based on CoAP. The management traffic is carried as SCHC compressed packets tagged to some specific rule IDs. They are identified as M rules in Figure . Management Rules (or M rules) can be either Compression rules or No compression rules. Only M rules can modify the SoR. Management procedures uses their own IPv6 stack, independent of the rest of the system. SCHC Packets using M Rules MUST be encrypted either by the underlying layer (for instance in a QUIC stream dedicated to management inside a QUIC connection) or directly using OSCORE or DTLS.

Inband Management [SoR]| ... | +-[]>[SoR]| | ! [___]| | ! [___]| | ! | | ! | | F/R | | F/R | +------ins_id1----+-----ins_idi-----+------ins_idn----+ . C/D ! M +---+ ___ . . +------------->|Mng|<=>[SoR] . . F/R +---+ [___] . +.................. Discriminator ....................+ ]]>

CoAP Profile Management requests MUST be protected against packet loss. It is RECOMMENDED to use CONfirmable requests and no Token. If the management request is too large regarding the MTU, SCHC Fragmentation SHOULD be used instead of the Block option. As shown in figure fragmentation can be common to Management rules and other rules.

Rule modification SCHC imposes that both ends share exactly the same SoR, therefore, a new or modified rule cannot be used while it remains in candidate status until the other end has validated the modification. A candidate rule cannot be used, either in C/D or F/R. A SCHC PDU MUST NOT be generated with a candidate rule ID and received PDUs containing a candidate rule ID must be dropped.

Modifying a rule | X candidate | /------------ | ---|<======/====================|---- | | / | | Guard | |<----- | | Guard v | | v ---| |---- X valid | | X valid ]]>

illustrates a Rule modification. The left-hand side entity A wants to make rule x evolve. It send an acknowledged CoAP message to the other end. Host A change the status of the rule to "candidate", indicating that the rule can no longer be used for SCHC procedures. The receiving entity B, acknowledges the message and continues to maintain the "candidate" status for a Guard period. At the reception of the acknowledgement, A set also a Guard period before rule x becomes valid again. The Guard period is used to avoid SCHC message with a rule ID to appear at the other end after a rule modification. The Guard period appears only once during the rule management and is depends on the out-of-sequence messages expected between both ends.

Rule creation Rule creation do not require a Guard period, and acknowledgement is RECOMMENDED. Figure gives an example, where the Acknowledgment is lost. Entity A sends a management message to create a new rule. Since its a new rule, the Guard period is not set and the new rule becomes immediately valid on B. The Acknowledgement does not reach A, so the rule stays in the candidate state, but the reception of a SCHC PDU carrying the RulE ID X, informs that the message has been correctly received by B. So X becomes valid in A.

Modifying a rule | X valid | X==================| | | X valid |<---------------------------| | X | | | ]]>

Rule deletion After the rule deletion, a Guard period is established. During that period, a rule with the same ID cannot be created, and SCHC PDU corrying the Rule ID are dropped.

Management messages

YANG Data Model CORECONF proposes an interface to manage data structured with a YANG Data Model. RFC 9363 defines a YANG Data Model for SCHC Rules. SCHC Instance Management MUST use FETCH to read a rule and iPATCH to create, modify or delete a rule. In order to accomplish management, the YANG Data Model has been updated.

Nature Management M Rules have to be marked in a way that allows quickly identifying which rules in a SoR are responsible for management. Therefore, a new "nature-management" type has been defined. This nature is actually a specialization of "nature-compression" for management purposes and compression needs to be available and activated to do management.

Guard To determine if a rule is considered available or not during the Guard period, a rule needs to have a status which determines if it can be used. Basically, an available rule MUST associate the key "rule-status" with the value "status-active". Conversely, during the Guard period, "rule-status" MUST be set to "status-candidate".

YANG tree representation The YANG tree represents the Rule structure as defined in RFC 9363 with the two updates described above:

Updated YANG Data Model for CORECONF

Set of Rules Editing For clarity reasons, this document will use YANG Identifiers in quotes instead of the SID values. In the YANG tree, all the lines of the tree have a SID number. Each level of the hierarchy is accessible through one or several keys. For example, to access the hierarchy under "rule", "rule-id-value" and "rule-id-length" must be specified. To access the hierarchy describing an entry in a compression rule, "rule-id-value" and "rule-id-length" must be followed by "field-id", "field-position" and "direction-indicator". Since the TV, MO-value and CDA-value are stored as lists, "index" must be added to access a specific element. Therefore, to access a specific element in a hierarchy, the SID of this element has to be specified, followed by the keys needed to access it. For example, ["target-value/value", 5, 3, "fid-ipv6-version", 1, "di-bidirectional", 0] is used to access the first value (0) of TV for the IPv6 Version of Rule 5/3.

Errors in Management There is different level of error detection:

• CORECONF Errors: these errors are directly generated at the CORECONF level. For instance, retrieving a value with a wrong key.
• YANG validation errors: the data model is not conforming with the constraints such as "must" or "mandatory". This check is optional, since it may require a lot of resources on a device.
• SCHC errors: Errors on the Data Model that cannot be detected at the YANG level, for example, the rule numbering does not respect a binary tree.

Methods

FETCH As mentioned in , FETCH request helps to retrieve at least one instance-value. Example : Fetching TV, MO and CDA of the Entry fid-ipv6-version/1/bidirectional from Rule 6/3.

iPATCH To write an iPATCH request, several methods could be used. For instance, in a Rule 7/8, an entry for a field was set to ignore/value-sent and the target-value was not set, the following command specify a new TV and change the MO and CDA. It is possible to set up individually each field, as given in the following example:

• Specified all conserned fields :

But if the changes concerns the same subtree, it is RECOMMENDED to regroup the changes in a unique fetch, as given in the following example: ~~~ iPATCH /c { ["entry", 7, 8, field, 1, "di-bidirectional"] : { delta_target-value : [{delta_index : 0, delta_value : value}], delta_matching-operator : "mo-equal", delta_comp-decomp-action : "cda-not-sent" } } ~~~ The same principle is applied to rules and "leaf-list".

Add If the target object doesn't exist in the context, then it is appended. It supports three main cases: * Adding a new key-value pair to an existing object * Adding a new object to an existing list One important specification is that for every leaf-list, the YANG Data Model describes that every index should be incremental. In CORECONF, we trust the user/system. Example: - Add TV into fid-ipv6-payload-length/1/di-bidirectional in Rule 0/3

Update A request can be considered as an update if the target associated with the various keys is present in the context. Otherwise, it could be consider as an add or an error. Example : - The Entry fid-ipv6-version/1/di-bidirectional is in Rule 6/3.

• The Entry fid-ipv6-version/1/di-bidirectional is in not in Rule 7/8 but Rule 7/8 exist.

• The Entry fid-ipv6-version/1/di-bidirectional is not in Rule 5/8, and Rule 5/8 does not exist. Therefore, Rule 5/8 cannot be added in order to include the Entry fid-ipv6-version/1/di-bidirectional because other fields, which are not keys, cannot be deducted at every depth of the context.

Delete To remove an object we use "null" value. Example: - Delete Rule 7/8 For deletion, we limit the actions and consider a minimal CORECONF representation as {"ietf-schc:schc" : {"rule" : []}}. Therefore, a request trying to delete "ietf-schc:schc" will set the CORECONF representation to the minimal one. Additionally, while updates are authorized, deleting a protected key is forbidden. Example: - Delete rule-id-value of Rule 0/3

Optimization This process imposes to send the full rule in the value part, so an optimization can be done by deriving an existing rule and modify some parameters. augments the data model for universal options. This add to compression rules a new entry format where a field is indexed with: * a space-id, a YANG identifier referring to the protocol containing options (CoAP, QUIC, TCP,...) * the option used in the protocol * the position In the CORECONF representation, even if the name are similar in the structure, the SID values are different. The key for an entry contains 4 elements. (Content-Format: application/yang-identifiers+cbor-seq) ["schc-opt:matching-operator", 8, 3, "schc-opt:space-id-coap", 11, 1, "di-up"] ]]>

RPC Represented as a tree: After duplication, the new rule stays in a candidate state until the new values are set.

Protocol Stack The management inside the instance has its own IPv6 stack totally independent of the rest of the system. The goal is to implement IPv6/UDP/CoAP to allow the implementation of the CORECONF interface. No other kind of traffic is allowed. The end-point acting as a Device has the IPv6 address fe80::1/64 and the other end fe80::2/64. Both implements CoAP client and server capabilities. The server uses port 5683 and the client 3865.

Compression Rules Two rules are required for management functionality. The first rule (RuleID M1) defines packets containing application payloads that include a CoAP Content-Format field. Depending on the direction (Up or Down), this rule manages Confirmable FETCH/iPATCH requests or Non-Confirmable Content responses accordingly. Therefore, the second rule (RuleID M2) is used to compress packets which do not include application payload, basically response packets in downlink.

Management Rule 1

Management Rule 2

OSCORE

Compression Rules

DTLS

Compression Rules

Example CORECONF usage in Python

Deletion cases

• Delete root element:
• Delete a specific rule:
• Delete a specific entry:
• Delete a basic key:
• Delete a leaf-list single:
• Delete a leaf-list several:
• Delete an unknown entry:
• Delete a protected key:

Update cases

• Update protected key:
• Update basic key:

Addition cases

• Add a new entry:
• Add leaf-list incremental:
• Add leaf-list non-incremental:
• Add new key:value:
• Add new rule:
• Add entry into unknown rule:

Normative References This document defines the Static Context Header Compression and fragmentation (SCHC) framework, which provides both a header compression mechanism and an optional fragmentation mechanism. SCHC has been designed with Low-Power Wide Area Networks (LPWANs) in mind. SCHC compression is based on a common static context stored both in the LPWAN device and in the network infrastructure side. This document defines a generic header compression mechanism and its application to compress IPv6/UDP headers. This document also specifies an optional fragmentation and reassembly mechanism. It can be used to support the IPv6 MTU requirement over the LPWAN technologies. Fragmentation is needed for IPv6 datagrams that, after SCHC compression or when such compression was not possible, still exceed the Layer 2 maximum payload size. The SCHC header compression and fragmentation mechanisms are independent of the specific LPWAN technology over which they are used. This document defines generic functionalities and offers flexibility with regard to parameter settings and mechanism choices. This document standardizes the exchange over the LPWAN between two SCHC entities. Settings and choices specific to a technology or a product are expected to be grouped into profiles, which are specified in other documents. Data models for the context and profiles are out of scope. This document describes a YANG data model for the Static Context Header Compression (SCHC) compression and fragmentation Rules. This document formalizes the description of the Rules for better interoperability between SCHC instances either to exchange a set of Rules or to modify the parameters of some Rules. YANG (RFC 7950) is a data modeling language used to model configuration data, state data, parameters and results of Remote Procedure Call (RPC) operations or actions, and notifications. This document defines encoding rules for YANG in the Concise Binary Object Representation (CBOR) (RFC 8949). Trilliant Networks Inc. consultant IMT Atlantique YumaWorks Universität Bremen TZI This document describes a network management interface for constrained devices and networks, called CoAP Management Interface (CORECONF). The Constrained Application Protocol (CoAP) is used to access datastore and data node resources specified in YANG, or SMIv2 converted to YANG. CORECONF uses the YANG to CBOR mapping and converts YANG identifier strings to numeric identifiers for payload size reduction. CORECONF extends the set of YANG based protocols, NETCONF and RESTCONF, with the capability to manage constrained devices and networks. Acklio Cisco Systems Acklio This document defines the LPWAN SCHC architecture. Orange Consultant RISE AB IMT Atlantique The idea of keeping option identifiers in SCHC Rules simplifies the interoperability and the evolution of SCHC compression, when the protocol introduces new options, that can be unknown from the current SCHC implementation. This document discuss the augmentation of the current YANG Data Model, in order to add in the Rule options identifiers used by the protocol. Consultant Institut MINES TELECOM; IMT Atlantique YANG SID (Schema Item iDentifier) is a method to identify YANG items in constrained environments. The YANG Data Model for SCHC needs to use smaller values and reduce the distance between two sections to minimize deltas' size and assure header compression performance. Keeping compact values for SCHC can be done when data and identity are differentiated.

YANG DM rpc duplicate-rule { input { container from { uses ietf-schc:rule-id-type; } container to { uses ietf-schc:rule-id-type; } } output { leaf status { type string; } } }

Acknowledgments The authors sincerely thank This work was supported by the Sweden's Innovation Agency VINNOVA within the EUREKA CELTIC-NEXT project CYPRESS.