< draft-ietf-lpwan-schc-yang-data-model-03.txt		draft-ietf-lpwan-schc-yang-data-model-04.txt >
	lpwan Working Group A. Minaburo		lpwan Working Group A. Minaburo
	Internet-Draft Acklio		Internet-Draft Acklio
	Intended status: Standards Track L. Toutain		Intended status: Standards Track L. Toutain
	Expires: January 11, 2021 Institut MINES TELECOM; IMT Atlantique		Expires: August 6, 2021 Institut MINES TELECOM; IMT Atlantique
	July 10, 2020		February 02, 2021
	Data Model for Static Context Header Compression (SCHC)		Data Model for Static Context Header Compression (SCHC)
	draft-ietf-lpwan-schc-yang-data-model-03		draft-ietf-lpwan-schc-yang-data-model-04
	Abstract		Abstract
	This document describes a YANG data model for the SCHC (Static		This document describes a YANG data model for the SCHC (Static
	Context Header Compression) compression and fragmentation rules.		Context Header Compression) compression and fragmentation rules.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	skipping to change at page 1, line 32 ¶		skipping to change at page 1, line 32 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on January 11, 2021.		This Internet-Draft will expire on August 6, 2021.
	Copyright Notice		Copyright Notice
	Copyright (c) 2020 IETF Trust and the persons identified as the		Copyright (c) 2021 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	skipping to change at page 2, line 38 ¶		skipping to change at page 2, line 38 ¶
	8. Normative References . . . . . . . . . . . . . . . . . . . . 41		8. Normative References . . . . . . . . . . . . . . . . . . . . 41
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42
	1. Introduction		1. Introduction
	2. SCHC rules		2. SCHC rules
	SCHC is a compression and fragmentation mechanism for constrained		SCHC is a compression and fragmentation mechanism for constrained
	networks defined in [RFC8724]. It is based on a static context		networks defined in [RFC8724]. It is based on a static context
	shared by two entities at the boundary this constrained network.		shared by two entities at the boundary this constrained network.
	Draft [RFC8724] provides an abstract representation of the rules used		Draft [RFC8724] provides an non formal representation of the rules
	either for compression/decompression (or C/D) or fragmentation/		used either for compression/decompression (or C/D) or fragmentation/
	reassembly (or F/R). The goal of this document is to formalize the		reassembly (or F/R). The goal of this document is to formalize the
	description of the rules to offer:		description of the rules to offer:
	o the same definition on both ends, even if the internal		o the same definition on both ends, even if the internal
	representation is different.		representation is different.
	o an update the other end to set up some specific values (e.g. IPv6		o an update the other end to set up some specific values (e.g. IPv6
	prefix, Destination address,...)		prefix, Destination address,...)
	o ...		o ...
	This document defines a YANG module to represent both compression and		This document defines a YANG module to represent both compression and
	fragmentation rules, which leads to common representation for values		fragmentation rules, which leads to common representation for values
	for all the rules elements.		for all the rules elements.
	SCHC compression is generic, the main mechanism do no refers to a		SCHC compression is generic, the main mechanism do no refers to a
	specific fields. A field is abstracted through an ID, a position, a		specific protocol. Any header field is abstracted through an ID, a
	direction and a value that can be a numerical value or a string.		position, a direction and a value that can be a numerical value or a
	[RFC8724] and [I-D.ietf-lpwan-coap-static-context-hc] specifies		string. [RFC8724] and [I-D.ietf-lpwan-coap-static-context-hc]
	fields for IPv6, UDP, CoAP and OSCORE.		specifies fields for IPv6, UDP, CoAP and OSCORE.
			[I-D.barthel-lpwan-oam-schc] decribes ICMPv6 header compression.
	SCHC fragmentation requires a set of common parameters that are		SCHC fragmentation requires a set of common parameters that are
	included in a rule. These parameters are defined in [RFC8724].		included in a rule. These parameters are defined in [RFC8724].
	2.1. Compression Rules		2.1. Compression Rules
	[RFC8724] proposes an abstract representation of the compression		[RFC8724] proposes an non formal representation of the compression
	rule. A compression context for a device is composed of a set of		rule. A compression context for a device is composed of a set of
	rules. Each rule contains information to describe a specific field		rules. Each rule contains information to describe a specific field
	in the header to be compressed.		in the header to be compressed.
	+-----------------------------------------------------------------+		+-----------------------------------------------------------------+
	| Rule N |		| Rule N |
	+-----------------------------------------------------------------+|		+-----------------------------------------------------------------+|
	| Rule i ||		| Rule i ||
	+-----------------------------------------------------------------+||		+-----------------------------------------------------------------+||
	| (FID) Rule 1 |||		| (FID) Rule 1 |||
	skipping to change at page 4, line 4 ¶		skipping to change at page 4, line 5 ¶
	Figure 1: Compression Decompression Context		Figure 1: Compression Decompression Context
	2.2. Field Identifier		2.2. Field Identifier
	In the process of compression, the headers of the original packet are		In the process of compression, the headers of the original packet are
	first parsed to create a list of fields. This list of fields is		first parsed to create a list of fields. This list of fields is
	matched against the rules to find the appropriate one and apply		matched against the rules to find the appropriate one and apply
	compression. The link between the list given by the parsed fields		compression. The link between the list given by the parsed fields
	and the rules is done through a field ID. [RFC8724] do not state how		and the rules is done through a field ID. [RFC8724] do not state how
	the field ID value can be constructed. In the examples, it was given		the field ID value can be constructed. In examples, identification
	through a string indexed by the protocol name (e.g. IPv6.version,		is done through a string indexed by the protocol name (e.g.
	CoAP.version,...).		IPv6.version, CoAP.version,...).
	Using the YANG model, each field MUST be identified through a global		Using the YANG model, each field MUST be identified through a global
	YANG identityref. A YANG field ID derives from the field-id-base-		YANG identityref. A YANG field ID derives from the field-id-base-
	type. Figure 2 gives some field ID definitions. Note that some		type. Figure 2 gives some field ID definitions. Note that some
	field IDs can be splitted is smaller pieces. This is the case for		field IDs can be splitted is smaller pieces. This is the case for
	"fid-ipv6-trafficclass-ds" and "fid-ipv6-trafficclass-ecn" which are		"fid-ipv6-trafficclass-ds" and "fid-ipv6-trafficclass-ecn" which are
	a subset of "fid-ipv6-trafficclass-ds".		a subset of "fid-ipv6-trafficclass-ds".
	identity field-id-base-type {		identity field-id-base-type {
	description "Field ID with SID";		description "Field ID with SID";
	skipping to change at page 4, line 45 ¶		skipping to change at page 4, line 46 ¶
	identity fid-ipv6-trafficclass-ecn {		identity fid-ipv6-trafficclass-ecn {
	base field-id-base-type;		base field-id-base-type;
	description "IPv6 Traffic Class field from RFC8200,		description "IPv6 Traffic Class field from RFC8200,
	ECN field from RFC3168";		ECN field from RFC3168";
	}		}
	...		...
	Figure 2: Definition of identityref for field IDs		Figure 2: Definition of identityref for field IDs
	Figure 2 gives an example of field ID identityref definitions. The		Figure 2 gives some examples of field ID identityref definitions.
	base identity is field-id-base-type, and field id are derived for it.		The base identity is field-id-base-type, and field id are derived for
			it.
	The naming convention is "fid" followed by the protocol name and the		The naming convention is "fid" followed by the protocol name and the
	field name.		field name.
	The yang model in annex (see Section 7) gives the full definition of		The yang model in annex (see Section 7) gives the full definition of
	the field ID for [RFC8724], [I-D.ietf-lpwan-coap-static-context-hc],		the field ID for [RFC8724], [I-D.ietf-lpwan-coap-static-context-hc],
	and [I-D.barthel-lpwan-oam-schc].		and [I-D.barthel-lpwan-oam-schc].
	The type associated to this identity is field-id-type (cf. Figure 3)		The type associated to this identity is field-id-type (cf. Figure 3)
	typedef field-id-type {		typedef field-id-type {
	description "Field ID generic type.";		description "Field ID generic type.";
	type identityref {		type identityref {
	base field-id-base-type;		base field-id-base-type;
	skipping to change at page 13, line 47 ¶		skipping to change at page 13, line 47 ¶
	}		}
	}		}
	}		}
	}		}
	Figure 13: Definition of a SCHC Context		Figure 13: Definition of a SCHC Context
	To access to a specific rule, rule-id and its specific length is used		To access to a specific rule, rule-id and its specific length is used
	as a key. The rule is either a compression or a fragmentation rule.		as a key. The rule is either a compression or a fragmentation rule.
	Each context can be identify though a version id.		Each context can be identified though a version id.
	3.1. Compression rule		3.1. Compression rule
	A compression rule is composed of entries describing its processing		A compression rule is composed of entries describing its processing
	(cf. Figure 14). An entry contains all the information defined in		(cf. Figure 14). An entry contains all the information defined in
	Figure 1 with the types defined above.		Figure 1 with the types defined above.
	3.1.1. Compression context representation.		3.1.1. Compression context representation.
	The compression rule described Figure 1 is associated to a rule ID.		The compression rule described Figure 1 is associated to a rule ID.
	skipping to change at page 16, line 23 ¶		skipping to change at page 16, line 23 ¶
	Figure 15: Definition of a compression rule		Figure 15: Definition of a compression rule
	To identify a specific entry Field ID, position and direction are		To identify a specific entry Field ID, position and direction are
	needed.		needed.
	3.2. Fragmentation rule		3.2. Fragmentation rule
	Parameters for fragmentation are defined in Annex D of [RFC8724].		Parameters for fragmentation are defined in Annex D of [RFC8724].
	Figure 16 gives the first elements found in this structure. It		Figure 16 gives the first elements found in this structure. It
	starts with a direction. Since fragmentation rules are		starts with a direction. Since fragmentation rules work for a
	unidirectional, they contain a mandatory direction. The type is the		specific direction, they contain a mandatory direction. The type is
	same as the one used in compression entries, but the use of		the same as the one used in compression entries, but the use of
	bidirectionnal is forbidden.		bidirectionnal is forbidden.
	The next elements describe size of SCHC fragmentation header fields.		The next elements describe size of SCHC fragmentation header fields.
	Only the FCN size is mandatory and value must be higher or equal to		Only the FCN size is mandatory and value must be higher or equal to
	1.		1.
	grouping fragmentation-content {		grouping fragmentation-content {
	description "This grouping defines the fragmentation parameters for		description "This grouping defines the fragmentation parameters for
	all the modes (No Ack, Ack Always and Ack on Error) specified in		all the modes (No Ack, Ack Always and Ack on Error) specified in
	RFC 8724.";		RFC 8724.";
	skipping to change at page 19, line 48 ¶		skipping to change at page 19, line 48 ¶
	Figure 20 gives information related to a specific compression mode:		Figure 20 gives information related to a specific compression mode:
	fragmentation-mode MUST be set with a specific behavior. Identityref		fragmentation-mode MUST be set with a specific behavior. Identityref
	are given Figure 21.		are given Figure 21.
	For Ack on Error some specific information may be provided:		For Ack on Error some specific information may be provided:
	o tile-size gives in bits the size of the tile; If set to 0 a single		o tile-size gives in bits the size of the tile; If set to 0 a single
	tile is inserted inside a fragment.		tile is inserted inside a fragment.
	o tile-in All1 indicates if All1 contains only the RCS (all1-data-		o tile-in-All1 indicates if All1 contains only the RCS (all1-data-
	no) or may contain a single tile (all1-data-yes). Since the		no) or may contain a single tile (all1-data-yes). Since the
	reassembly process may detect this behavior, the choice can be		reassembly process may detect this behavior, the choice can be
	left to the fragmentation process. In that case identityref all1-		left to the fragmentation process. In that case identityref all1-
	data-sender-choice as to be specified. All possible values are		data-sender-choice as to be specified. All possible values are
	given Figure 21.		given Figure 21.
	o ack-behavior tells when the fragmentation process may send		o ack-behavior tells when the fragmentation process may send
	acknowledgments. When ack-behavior-after-All0 is specified, the		acknowledgments. When ack-behavior-after-All0 is specified, the
	ack may be sent after the reception of All-0 fragment. When ack-		ack may be sent after the reception of All-0 fragment. When ack-
	behavior-after-All1 is specified, the ack may be sent after the		behavior-after-All1 is specified, the ack may be sent after the
	skipping to change at page 41, line 31 ¶		skipping to change at page 41, line 31 ¶
	<code ends>		<code ends>
	Figure 23		Figure 23
	8. Normative References		8. Normative References
	[I-D.barthel-lpwan-oam-schc]		[I-D.barthel-lpwan-oam-schc]
	Barthel, D., Toutain, L., Kandasamy, A., Dujovne, D., and		Barthel, D., Toutain, L., Kandasamy, A., Dujovne, D., and
	J. Zuniga, "OAM for LPWAN using Static Context Header		J. Zuniga, "OAM for LPWAN using Static Context Header
	Compression (SCHC)", draft-barthel-lpwan-oam-schc-01 (work		Compression (SCHC)", draft-barthel-lpwan-oam-schc-02 (work
	in progress), March 2020.		in progress), November 2020.
	[I-D.ietf-lpwan-coap-static-context-hc]		[I-D.ietf-lpwan-coap-static-context-hc]
	Minaburo, A., Toutain, L., and R. Andreasen, "LPWAN Static		Minaburo, A., Toutain, L., and R. Andreasen, "LPWAN Static
	Context Header Compression (SCHC) for CoAP", draft-ietf-		Context Header Compression (SCHC) for CoAP", draft-ietf-
	lpwan-coap-static-context-hc-15 (work in progress), July		lpwan-coap-static-context-hc-18 (work in progress),
	2020.		January 2021.
	[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained		[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
	Application Protocol (CoAP)", RFC 7252,		Application Protocol (CoAP)", RFC 7252,
	DOI 10.17487/RFC7252, June 2014,		DOI 10.17487/RFC7252, June 2014,
	<https://www.rfc-editor.org/info/rfc7252>.		<https://www.rfc-editor.org/info/rfc7252>.
	[RFC8724] Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and JC.		[RFC8724] Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and JC.
	Zuniga, "SCHC: Generic Framework for Static Context Header		Zuniga, "SCHC: Generic Framework for Static Context Header
	Compression and Fragmentation", RFC 8724,		Compression and Fragmentation", RFC 8724,
	DOI 10.17487/RFC8724, April 2020,		DOI 10.17487/RFC8724, April 2020,
End of changes. 15 change blocks.
	27 lines changed or deleted		29 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/