| Internet-Draft | SCHC Sid Allocation | July 2023 |
| Minaburo & Toutain | Expires 8 January 2024 | [Page] |
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.¶
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.¶
Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
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.¶
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.¶
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=="}]} ]
}]}
}
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.¶
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.¶
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 |’ +------------+------------+------------+------------+------------+--------+
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
"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.¶
The allocation process proposed in [I-D.ietf-core-sid] is slightly enhanced:¶
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.¶
{::include sor-9363.json}
{::include sor-oam.json}
{::include sor-oam+ac.json}
{::include Classeur2.csv}