OpenSCHC Rule Manager Module¶
## Base format
A context and rule is written in JSON.
A context contains an identifier, AND one or three rules. One of rules must specify the SCHC Compression/Decompression (CD). Two specify SCHC Fragmentation/Reassembly (FR) if needed.
Therefore, a context has to be formed to either below structures.
- {
- “devL2Addr”: …, “dstIID”: …, “comp”: { … }, “fragSender”: { … }, “fragReceiver”: { … }
}
“comp”: compression rule. “fragSender”: fragmentation rule for inbound. “fragReceiver”: fragmentation rule for outbound.
Or,
- {
- “devL2Addr”: …, “dstIID”: …, “profile”: { … }, “comp”: { … }
}
XXX Q. “profile” should be in the context ?
## Context
A context is uniquely identified by devL2Addr specifying the L2 address of a SCHC device.
dstIID matches the IP address assigned to the interface of the communication peer. In the context of the SCHC device, dstIID indicates the IP address of the interface at the SCHC Translator, which is dedicated between the device and the application. In the context of the other side, dstIID indicates the IP address of the SCHC device.
+——–+ +————+ +—–+ | SCHC | | SCHC |---------| App | | Device | | Translator | | | +——–+ +————+ +—–+
In the above example, the context of each side is like below:
at the device:
- {
- “devL2Addr”: “L”, “dstIID”: “M”
}
at the translator:
- {
- “devL2Addr”: “L”, “dstIID”: “D”
}
“*” and “/” can be used for a wild-card match. (XXX should be implemented.)
## Rule
XXX is it true that both ruleID and ruleLength is unique key ? XXX is the deivce L2 address the real key ?
A rule is uniquely identified by the rule ID of variable length. Each rule must contain the following information:
- {
- “ruleID” : 2, “ruleLength” : 3
}
where ruleID contains the rule ID value aligned on the right and ruleLength gives the size in bits of the ruleID. In the previous example, this corresponds to the binary value 0b010. if ruleLength is not specified the value is set to 1 byte.
The rule is either a compression/decompression rule or a fragmentation/reassembly rule. For C/D rules, the keyword “compression” must be defined. For F/R rules, the keyword “fragmentation” and “fragmentation” must be defined.
## Compression Rule
A compression rule is bidirectionnal.
## Fragmentation Rule
A fragmentation rule is uni directionnal.
The “fragmentation” keyword is used to give fragmentation mode and profile: - one fragmentation mode keywork “noAck”, “ackAlways” or “ackOnError”. - FRModeProfile parameters. Default values are automaticaly added. - dtagSize, WSize and FCNSize are used to define the SCHC fragmentation header - windowSize can be added if not 2^FCNSize - 1
For “ackOnError” the following parameter is defined: - “ackBehavior” defined the ack behavior, i.e. when the Ack must be spontaneously sent
by the receiver and therefore when the sender must listen for Ack. - “afterAll0” means that the sender waits for ack after sending an All-0 - “afterAll1” means that the sender waits only after sending the last fragment - other behaviors may be defined in the future.
## data model of DB
- db = [
- {
“devL2Addr”: .., “dstIID”: .., “comp”: {
“ruleID”: .., “ruleLength”: .., “compression”: { …}},
- “fragSender”: {
}
- “fragReceiver”: {
}
}, …
]
## method
add_context(context, comp=None, fragSender=None, fragReceiver=None)
It adds the context. If it exists, raise ValueError.
add_rules(context, comp=None, fragSender=None, fragReceiver=None)
It adds the list of rules into the context specified. If it exists, raise ValueError. If context is not specified, the rule will be added into the default context.
## Rule to add a new key
Each key must be unique through a rule. For example, below the keys of “profile” are not allowed.
- {
- “profile”: { … }, “compression”: { “profile”: … }
}
## Examples
Example 1:
- {
- “ruleID” : 14, “ruleLength” : 4 # rule 0b1110 “compression”: { … }
}
Example 2:
- {
“ruleID” : 15, “ruleLength” : 4 # rule 0b1110 “fragmentationOut”: {
“FRMode” : “noAck” # or “ackAlways”, “ackOnError” “FRModeProfile” : {
“dtagSize” : 1, “WSize”: 3, “FCNSize” : 3, “windowSize”, 7, “ackBehavior”: “afterAll1”}
}
}
-
class
rulemanager.RuleManager¶ RuleManager class is used to manage Compression/Decompression and Fragmentation/ Reassembly rules.
-
add_context(context, comp=None, fragSender=None, fragReceiver=None)¶ add context into the db.
-
add_rule(context, key, rule)¶ Check rule integrity and uniqueless and add it to the db
-
add_rules(context, comp=None, fragSender=None, fragReceiver=None)¶ add rules into the context specified.
-
check_rule_compression(rule)¶ compression rule check
-
check_rule_fragmentation(rule)¶ fragmentation rule check
-
find_context_bydevL2addr(dev_L2addr)¶ find a context with dev_L2addr.
-
find_context_bydstiid(dst_iid)¶ find a context with dst_iid, which can be a wild card.
-
find_context_exact(dev_L2addr, dst_iid)¶ find a context by both devL2Addr and dstIID. This is mainly for internal use.
-
find_rule_bypacket(context, packet_bbuf)¶ returns a compression rule or an fragmentation rule in the context matching with the field value of rule id in the packet.
-