Internet-Draft SCHC Sid Allocation July 2023
Minaburo & Toutain Expires 8 January 2024 [Page]
Workgroup:
schc Working Group
Internet-Draft:
draft-toutain-schc-sid-allocation-01
Published:
Intended Status:
Standards Track
Expires:
Authors:
A. Minaburo
Consultant
L. Toutain
Institut MINES TELECOM; IMT Atlantique

SCHC Sid Allocation

Abstract

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.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on 8 January 2024.

Table of Contents

1. Introduction

RFC9363 defines a YANG Data Model for SCHC rules. [I-D.ietf-core-sid] specifies the process for SID allocation and management. This document discuss of the SID allocation for RFC9363 to minimize the rule representation.

2. SCHC YANG Data Model

The version @2023-01-18 of the SCHC YANG Data Model published in the RFC 9363 contains 136 SIDs (92 for identities, 2 for features and 42 for data). [I-D.ietf-core-sid] indicates that the SID range for the YANG Data Model specified in RFC is between 1000 and 59 000 and that the maximum request pool SHOULD NOT exceed 1000. The draft also gives some pre allocated values.

Since SIDs will be used either to represent unique identity contained in the data model and also leaves (data) forming this data model, it could be wise to distinguish between identifiers and data.

Data structures are delta encoded and included as a CBOR element, the size depends on the value. Deltas between -24 and +23 are encoded on a single byte. Deltas between -256 and +255 use 2 bytes and larger values corresponding to the RFC SID range will be encoded into 3 bytes. To optimize the CORECONF representation delta should be smaller as possible for the more frequent leaves.

On the other hand identities are included in the CORECONF representation and for the RFC SID range the size is constant and equal to 3 bytes.

2.1. Example

CORECONF

{5095: {1: [{4:
        [{1: 5015,
          5: 5018,
          6: 5068,
          7: 4,
          8: 1,
          9: 5083,
          13: [{1: 0, 2: h'06'}]},
         {1: 5015,
          5: 5018,
          6: 2000003,
          7: 8,
          8: 1,
          9: 5083,
          13: [{1: 0, 2: h'00'}]}]
    }]}
}


RESTCONF

{"ietf-schc:schc": {"rule": [{"entry":
             [{"comp-decomp-action": "ietf-schc:cda-not-sent",
               "direction-indicator": "ietf-schc:di-bidirectional",
               "field-id": "ietf-schc:fid-ipv6-version",
               "field-length": 4,
               "field-position": 1,
               "matching-operator": "ietf-schc:mo-equal",
               "target-value": [{"index": 0, "value": "Bg=="}]},
              {"comp-decomp-action": "ietf-schc:cda-not-sent",
               "direction-indicator": "ietf-schc:di-bidirectional",
               "field-id": "ietf-schc-oam:fid-icmpv6-type",
               "field-length": 8,
               "field-position": 1,
               "matching-operator": "ietf-schc:mo-equal",
               "target-value": [{"index": 0, "value": "gA=="}]} ]
         }]}
    }

Figure 1

The example in Figure 1 gives a CORECONF structure transposed the CBOR diagnostic notation and its equivalent in RESTCONF with JSON. For readability and compactness, this example is edited and do not encode a full rule as defined in RFC9363.

The default SID numbering produced by pyang is used, starting from 5000 for SCHC Data Model defined in RFC9363 and 2000000 for an experimental module for OAM.

We can see the delta encoding. The first SID 5095 represents "ietf-schc:schc". "/ietf-schc:schc/rule" which is coded with a +1 since SID 5096 has been assigned. "/ietf-schc:schc/rule/entry" is coded with a delta of 4. Then a list of Field Description follows. +1 represents the leaf "ietf-schc:schc/rule/entry/comp-decomp-action" and the value assigned to that key contains the SID of "ietf-schc:cda-not-sent" identity.

Note that the second element contains a "field-id" belonging to the "ietf-schc-oam" module and the associate SID is 2000003.

3. Recommendation for SID values

The SCHC YANG Data Model defined in RFC 9363 will probably be augmented, to include for instance access control data. To keep a compact representation, delta values must be kept as small as possible. The LPWAN working group should not use the automatic SID numbering and provide a more optimal allocation scheme for augmentation of the SCHC YANG Data Model.

A first recommendation is to avoid merging data and identity in order to limit the delta encoding. The distance between these two sections can be 255 SID to allow deltas on 2 bytes.

The second recommendation is to leave some unused SID around SCHC rules to allow augmentation.

4. SID value impact

To study the impact of SIDs size and delta size, we will take three scenarii, which cover the original Data Model defined in [RFC9363] and some augmentations, rules regarding these scenarii are listed in the annex:

For this three group of Set of Rule, we applied four different allocation methods for the SIDs:

The following table shows the results:

  +------------+------------+------------+------------+------------+--------+
  |            |   million  |  IETF      |  IETF      |  IESG      |  JSON  |
  |            |            |  separate  |  grouped   |  (dream)   |        |
  +------------+------------+------------+------------+------------+--------+
  | sor-9363   | 2194       | 1740 (-454)| 1721 (-19) | 1586 (-135)| 15388  |
  +------------+------------+------------+------------+------------+--------+
  | sor-oam    | 2841       | 2265 (-576)| 2243 (-22) | 2064 (-179)| 19871  |
  +------------+------------+------------+------------+------------+--------+
  | sor-oam+ac | 2925       | 2321 (-604)| 2271 (-50) | 2092 (-179)| 20686  |’
  +------------+------------+------------+------------+------------+--------+

Figure 2: Size in Bytes SID allocations strategies

The most important result, is the factor 10 between CBOR and JSON (without indentation) size which proves the efficiency of encoding. 2 kilo-byte of information to represent 8 rules (3 compression and 5 fragmentation rules).

The IETF-grouped has a impact on the rule size, even when no augmentation is perform. This is the case for rfc9363 compatible rules and OAM addition. Figure Figure 3 shows the alphabetical order allocation with pyang.

5095       data /ietf-schc:schc
5096       data /ietf-schc:schc/rule
5097       data /ietf-schc:schc/rule/ack-behavior
5098       data /ietf-schc:schc/rule/direction
5099       data /ietf-schc:schc/rule/dtag-size
5100       data /ietf-schc:schc/rule/entry
5101       data /ietf-schc:schc/rule/entry/comp-decomp-action
5102       data /ietf-schc:schc/rule/entry/comp-decomp-action-value
5103       data /ietf-schc:schc/rule/entry/comp-decomp-action-value/index
5104       data /ietf-schc:schc/rule/entry/comp-decomp-action-value/value
5105       data /ietf-schc:schc/rule/entry/direction-indicator
5106       data /ietf-schc:schc/rule/entry/field-id
5107       data /ietf-schc:schc/rule/entry/field-length
5108       data /ietf-schc:schc/rule/entry/field-position
5109       data /ietf-schc:schc/rule/entry/matching-operator
5110       data /ietf-schc:schc/rule/entry/matching-operator-value
5111       data /ietf-schc:schc/rule/entry/matching-operator-value/index
5112       data /ietf-schc:schc/rule/entry/matching-operator-value/value
5113       data /ietf-schc:schc/rule/entry/target-value
5114       data /ietf-schc:schc/rule/entry/target-value/index
5115       data /ietf-schc:schc/rule/entry/target-value/value
5116       data /ietf-schc:schc/rule/fcn-size
5117       data /ietf-schc:schc/rule/fragmentation-mode
5118       data /ietf-schc:schc/rule/inactivity-timer
------ 23 delta limit
5119       data /ietf-schc:schc/rule/inactivity-timer/ticks-duration
5120       data /ietf-schc:schc/rule/inactivity-timer/ticks-numbers
5121       data /ietf-schc:schc/rule/l2-word-size
5122       data /ietf-schc:schc/rule/max-ack-requests
5123       data /ietf-schc:schc/rule/max-interleaved-frames
5124       data /ietf-schc:schc/rule/maximum-packet-size
5125       data /ietf-schc:schc/rule/rcs-algorithm
5126       data /ietf-schc:schc/rule/retransmission-timer
5127       data /ietf-schc:schc/rule/retransmission-timer/ticks-duration
5128       data /ietf-schc:schc/rule/retransmission-timer/ticks-numbers
5129       data /ietf-schc:schc/rule/rule-id-length
5130       data /ietf-schc:schc/rule/rule-id-value
5131       data /ietf-schc:schc/rule/rule-nature
5132       data /ietf-schc:schc/rule/tile-in-all-1
5133       data /ietf-schc:schc/rule/tile-size
5134       data /ietf-schc:schc/rule/w-size
5135       data /ietf-schc:schc/rule/window-size
Figure 3: Alphabetical order of SIDs

"Rule-id-value", "rule-id-length", "rule-nature" present in all rules have a delta higher than 23. On the other hand, other elements such are matching-operator-value or comp-decomp-action-value which are not present in all rules have a smaller delta. Figure {#Allocation} gives the manual SID allocation used in this document. This lead to a reduction of about 20 bytes (a mean of 5 bytes for the 8 rules in the example) when no augmentation is perform. In case of augmentation with the last example including access control, this leads to 50 bytes.

Manual allocation allows also to use some other space, the last scenario takes 10 values (1%) from the IESG space for the most frequent identity.

4.1. Administrative process

The allocation process proposed in [I-D.ietf-core-sid] is slightly enhanced:

  • the SCHC WG requests IANA for a larger pool of SIDs than originally needed for a single Data Model (for instance 500 SIDs)
  • the SCHC WG MAY request IESG review for a small amount of SIDs
  • the WG manages the space as presented in Appendix B.
  • If a module is validated by the WG and request a WG allocation, the SID are allocated in the space and a sid file is issue for this module.

The result is a better allocation of the space, [I-D.ietf-core-sid] proposes a minimum of 50 SIDs per module, but looking at the existing models, the effective number is smaller. Using a common pool, allows a better utilization.

5. Normative References

[I-D.ietf-core-sid]
Veillette, M., Pelov, A., Petrov, I., Bormann, C., and M. Richardson, "YANG Schema Item iDentifier (YANG SID)", Work in Progress, Internet-Draft, draft-ietf-core-sid-20, , <https://datatracker.ietf.org/doc/html/draft-ietf-core-sid-20>.
[I-D.ietf-lpwan-schc-compound-ack]
Zúñiga, J. C., Gomez, C., Aguilar, S., Toutain, L., Cespedes, S., and D. S. W. L. Torre, "SCHC Compound ACK", Work in Progress, Internet-Draft, draft-ietf-lpwan-schc-compound-ack-17, , <https://datatracker.ietf.org/doc/html/draft-ietf-lpwan-schc-compound-ack-17>.
[I-D.ietf-lpwan-schc-yang-data-model]
Minaburo, A. and L. Toutain, "A YANG Data Model for Static Context Header Compression (SCHC)", Work in Progress, Internet-Draft, draft-ietf-lpwan-schc-yang-data-model-21, , <https://datatracker.ietf.org/doc/html/draft-ietf-lpwan-schc-yang-data-model-21>.
[I-D.toutain-lpwan-access-control]
Minaburo, A., Toutain, L., and I. Martinez, "SCHC Rule Access Control", Work in Progress, Internet-Draft, draft-toutain-lpwan-access-control-01, , <https://datatracker.ietf.org/doc/html/draft-toutain-lpwan-access-control-01>.
[RFC8341]
Bierman, A. and M. Bjorklund, "Network Configuration Access Control Model", STD 91, RFC 8341, DOI 10.17487/RFC8341, , <https://www.rfc-editor.org/rfc/rfc8341>.
[RFC8824]
Minaburo, A., Toutain, L., and R. Andreasen, "Static Context Header Compression (SCHC) for the Constrained Application Protocol (CoAP)", RFC 8824, DOI 10.17487/RFC8824, , <https://www.rfc-editor.org/rfc/rfc8824>.
[RFC9363]
Minaburo, A. and L. Toutain, "A YANG Data Model for Static Context Header Compression (SCHC)", RFC 9363, DOI 10.17487/RFC9363, , <https://www.rfc-editor.org/rfc/rfc9363>.

Appendix A. Set of Rules

{::include sor-9363.json}
Figure 4: SoR only referenced by RFC9363
{::include sor-oam.json}
Figure 5: SoR including OAM compression
{::include sor-oam+ac.json}
Figure 6: SoR including Access Control

Appendix B. SID Allocation

{::include Classeur2.csv}
Figure 7: Manual SID allocation

Appendix C. Security Considerations

TBD

Appendix D. IANA Considerations

TBD

Authors' Addresses

Ana Minaburo
Consultant
Rue de Rennes
35510 Cesson-Sevigne
France
Laurent Toutain
Institut MINES TELECOM; IMT Atlantique
2 rue de la Chataigneraie
CS 17607
35576 Cesson-Sevigne Cedex
France