< draft-ietf-6lo-dispatch-iana-registry-01.txt		draft-ietf-6lo-dispatch-iana-registry-02.txt >
	6lo S. Chakrabarti		6lo S. Chakrabarti
	Internet-Draft Ericsson		Internet-Draft Ericsson
	Updates: 4944, 6282 (if approved) G. Montenegro		Updates: 4944, 6282 (if approved) G. Montenegro
	Intended status: Standards Track Microsoft		Intended status: Standards Track Microsoft
	Expires: August 28, 2016 R. Droms		Expires: September 22, 2016 R. Droms
	Cisco		Cisco
	J. Woodyatt		J. Woodyatt
	Nest		Nest
	February 25, 2016		March 21, 2016
	IANA Registry for 6lowpan ESC Dispatch Code points		IANA Registry for 6lowpan ESC Dispatch Code points
	draft-ietf-6lo-dispatch-iana-registry-01		draft-ietf-6lo-dispatch-iana-registry-02
	Abstract		Abstract
	RFC4944 defines ESC dispatch type for additional dispatch bytes in		RFC4944 defines ESC dispatch type for additional dispatch bytes in
	the 6lowpan header. The value of ESC byte has been updated by		the 6lowpan header. The value of ESC byte has been updated by
	RFC6282. However, the usage of ESC extension byte has not been		RFC6282. However, the usage of ESC extension byte has not been
	defined in RFC6282 and RFC4944. The purpose of this document is to		defined in RFC6282 and RFC4944. The purpose of this document is to
	define the ESC extension byte code points and to request		define the ESC extension byte code points and to request
	corresponding IANA actions.		corresponding IANA actions.
	skipping to change at page 1, line 40 ¶		skipping to change at page 1, line 40 ¶
	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 http://datatracker.ietf.org/drafts/current/.		Drafts is at http://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 August 28, 2016.		This Internet-Draft will expire on September 22, 2016.
	Copyright Notice		Copyright Notice
	Copyright (c) 2016 IETF Trust and the persons identified as the		Copyright (c) 2016 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
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://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
	skipping to change at page 2, line 18 ¶		skipping to change at page 2, line 18 ¶
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Usage of ESC dispatch bytes . . . . . . . . . . . . . . . . . . 3		3. Usage of ESC dispatch bytes . . . . . . . . . . . . . . . . . . 3
	3.1. Interaction with other RFC4944 implementations . . . . . . 4		3.1. Interaction with other RFC4944 implementations . . . . . . 4
	3.2. ESC Extension Bytes Typical Sequence . . . . . . . . . . . 5		3.2. ESC Extension Bytes Typical Sequence . . . . . . . . . . . 5
	3.3. Example: ITU-T G.9903 ESC type usage . . . . . . . . . . . 5		3.3. ITU-T G.9903 ESC type usage . . . . . . . . . . . . . . . 5
	3.4. NALP and ESC bytes . . . . . . . . . . . . . . . . . . . . 6		3.4. NALP and ESC bytes . . . . . . . . . . . . . . . . . . . . 6
	4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6		4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
	5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6		5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
	6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7		6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7		7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
	7.1. Normative References . . . . . . . . . . . . . . . . . . . 7		7.1. Normative References . . . . . . . . . . . . . . . . . . . 7
	7.2. Informative References . . . . . . . . . . . . . . . . . . 7		7.2. Informative References . . . . . . . . . . . . . . . . . . 8
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
	1. Introduction		1. Introduction
	[RFC4944] section 5.1 defines the dispatch header and types. The ESC		[RFC4944] section 5.1 defines the dispatch header and types. The ESC
	type is defined for using additional dispatch bytes in the 6lowpan		type is defined for using additional dispatch bytes in the 6lowpan
	header. RFC 6282 modifies the value of the ESC dispatch type and it		header. RFC 6282 modifies the value of the ESC dispatch type and it
	is recorded in IANA registry [6LOWPAN-IANA]. However, the bytes and		is recorded in IANA registry [6LOWPAN-IANA]. However, the bytes and
	usage following the ESC byte are not defined in either [RFC4944] and		usage following the ESC byte are not defined in either [RFC4944] and
	[RFC6282]. However, in recent years with 6lowpan deployments, the		[RFC6282]. However, in recent years with 6lowpan deployments, the
	skipping to change at page 4, line 11 ¶		skipping to change at page 4, line 11 ¶
	Figure 1: Frame Format with ESC Byte		Figure 1: Frame Format with ESC Byte
	ESC: The left-most byte is the ESC dispatch type containing '0100000'		ESC: The left-most byte is the ESC dispatch type containing '0100000'
	ESC Extension Type (EET): It is the first byte following the ESC		ESC Extension Type (EET): It is the first byte following the ESC
	byte. Extension type defines the payload for the additional dispatch		byte. Extension type defines the payload for the additional dispatch
	bytes. The values are from 0 to 255. Value 0 and 255 are reserved		bytes. The values are from 0 to 255. Value 0 and 255 are reserved
	for future use. These values are assigned by IANA. The EET values		for future use. These values are assigned by IANA. The EET values
	are similar to dispatch values in the 6lowpan header except they are		are similar to dispatch values in the 6lowpan header except they are
	preceeded by the ESC byte. Thus, ESC extension types and dispatch		preceeded by the ESC byte. Thus, ESC extension types and dispatch
	values are using orthogonal code spaces. Though not desirable,		values are using orthogonal code spaces. Though not desirable,
	multiple ESC bytes MAY appear in a 6lowpan header. For example, it		multiple ESC bytes MAY appear in a 6lowpan header. Section 3.1
	is possible to form [Mesh-hdr][6lowpan-		describes how to handle unknown ESC dispatch type.
	IPHC][Payload][ESC][EET][Payload][ESC][EET][Payload] as long as it
	follows the same semantics defined in this document and does not
	induce fragmentation. Section 3.1 describes how to handle unknown
	ESC dispatch type.
	Extended Dispatch Payload(EDP): This part of frame format must be		Extended Dispatch Payload(EDP): This part of frame format must be
	defined by the corresponding extension type. A specification is		defined by the corresponding extension type. A specification is
	required to define each usage of extension type and its corresponding		required to define each usage of extension type and its corresponding
	Extension Payload. For the sake of interoperability, specifications		Extension Payload. For the sake of interoperability, specifications
	of extension bytes MUST NOT redefine the existing ESC Extension Type		of extension bytes MUST NOT redefine the existing ESC Extension Type
	codes.		codes.
	Section 5.1 in RFC4944 indicates that the Extension Type field may		Section 5.1 in RFC4944 indicates that the Extension Type field may
	contain additional dispatch values larger than 63, as corrected by		contain additional dispatch values larger than 63, as corrected by
	skipping to change at page 5, line 9 ¶		skipping to change at page 5, line 7 ¶
	bytes may appear in a packet. The ESC bytes can appear as the first,		bytes may appear in a packet. The ESC bytes can appear as the first,
	last or middle dispatch bytes. However, a packet will get dropped by		last or middle dispatch bytes. However, a packet will get dropped by
	any node that does not understand the EET at the beginning of the		any node that does not understand the EET at the beginning of the
	packet. The closer to the end of the packet are the EET's, the		packet. The closer to the end of the packet are the EET's, the
	higher chance there is that a legacy node will recognize and		higher chance there is that a legacy node will recognize and
	successfully process some dispatch type [RFC4944] before the EET and		successfully process some dispatch type [RFC4944] before the EET and
	then ignore the EET instead of dropping the entire packet.		then ignore the EET instead of dropping the entire packet.
	3.2. ESC Extension Bytes Typical Sequence		3.2. ESC Extension Bytes Typical Sequence
	The following diagram provides an example when ESC extension bytes		ESC Extension bytes sequence and order with respect to 6LoWPAN Mesh
	might be used:		header and LoWPAN_IPHC header are described below. When LOWPAN_IPHC
			dispatch type is present, ESC bytes MUST appear before the
			LOWPAN_IPHC dispatch type in order to maintain backward compatibility
			with RFC 8262 section 3.2. The following diagrams provide examples
			of ESC extension byte usages:
	A LoWPAN encapsulated HC1 compressed packet:		A LoWPAN encapsulated IPv6 Header compressed packet:
	+----------+-----------------+---------+-----+-----+--------+
	| Dispatch | LOWPAN_IPHC hdr | Payld |ESC | EET |EPayld |		+-------+------+--------+--------+-----------------+--------+
	+----------------------------+---------+-----+-----+--------+		| ESC | EET | EDP |Dispatch| LOWPAN_IPHC hdr | Payld |
			+-------+------+--------+--------+-----------------+--------+
	A LoWPAN_IPHC Header, Mesh header and an ESC extenstion byte:		A LoWPAN_IPHC Header, Mesh header and an ESC extenstion byte:
	+-------+-------+--------+--------+-------+-----+-----+-------+		+-----+-----+-----+----+------+-------+---------------+------+
	| M Typ | M Hdr | LOWPAN_IPHC Hdr | Payld |ESC | EET | EPayld|		|M typ| Mhdr| ESC | EET|EDP |Disptch|LOWPAN_IPHC hdr| Payld|
	+-------+-------+--------+--------+-------+-----+-----+-------+		+-----+-----+-----+----+------+-------+---------------+------+
			A Mesh header with ESC bytes
			+-------+-------+-----+-----+-------+
			| M Typ | M Hdr | ESC | EET |EDP |
			+-------+-------+-----+-----+-------+
			With Fragment header
			+-------+-------+--------+------+-----+-----+-------+
			| M Typ | M Hdr | F Typ | F hdr|ESC | EET | EDP |
			+-------+-------+--------+------+-----+-----+-------+
			ESC byte as a LowPAN encapsulation
			+--------+--------+--------+
			| ESC | EET | EDP |
			+--------+--------+--------+
	Figure 2: A 6lowpan packet with ESC Bytes		Figure 2: A 6lowpan packet with ESC Bytes
	3.3. Example: ITU-T G.9903 ESC type usage		3.3. ITU-T G.9903 ESC type usage
	[G3-PLC] provides native mesh-under functionalities. The ESC		The ESC dispatch type is used in [G3-PLC] to provide native mesh
	dispatch type is used with the command frames specified in figure		header and bootstrapping functionalities. The ITU-T recommendation
	9-12 and Table 9-35 in [G3-PLC] . The command ID values are 0x01 to		defines command IDs in the [G3-PLC] section 9.4.2.3 which operates
			like ESC Extension type field. The command ID values are 0x01 to
	0x1F.		0x1F.
	The frame format is defined as follows:		The frame format is defined as follows:
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|0 1| ESC | Command ID | Command Payload		|0 1| ESC | Command ID | Command Payload
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 3: G.9903 Frame Format with ESC Byte		Figure 3: G.9903 Frame Format with ESC Byte
	3.4. NALP and ESC bytes		3.4. NALP and ESC bytes
	According to RFC4944 [RFC4944] section 5.1, NALP dispatch bytes are		According to RFC4944 [RFC4944] section 5.1, NALP dispatch bytes are
	used for non-6lowpan packets. Since ESC bytes are part of 6lowpan		reserved for use as a kind of escape code for identification of non-
	dispatch types (extended), they are orthogonal to NALP bytes.		6lowpan payloads. Since ESC bytes are part of 6lowpan dispatch types
			(extended), they are orthogonal to NALP bytes.
			This document clarifies that NALP dispatch codes only provide an
			escape method for non-6LoWPAN payloads when they appear as the
			initial byte of a LoWPAN encapsulation, and that the potential
			meaning of their appearance in any other location is reserved for
			future use.
	4. IANA Considerations		4. IANA Considerations
	This document requests IANA to register the 'ESC Extension Type'		This document requests IANA to register the 'ESC Extension Type'
	values as per the policy 'Specification Required'[RFC5226] as		values as per the policy 'Specification Required'[RFC5226] as
	specified in this document which follows the same policy as in the		specified in this document which follows the same policy as in the
	IANA section of [RFC4944]. For each Extension Type (except the		IANA section of [RFC4944]. For each Extension Type (except the
	Reserved values) the specification MUST define corresponding Extended		Reserved values) the specification MUST define corresponding Extended
	Dispatch Payload frame bytes for the receiver implementation to read		Dispatch Payload frame bytes for the receiver implementation to read
	the ESC bytes with interoperability.		the ESC bytes with interoperability.
	skipping to change at page 8, line 13 ¶		skipping to change at page 8, line 39 ¶
	<http://www.rfc-editor.org/info/rfc5226>.		<http://www.rfc-editor.org/info/rfc5226>.
	Authors' Addresses		Authors' Addresses
	Samita Chakrabarti		Samita Chakrabarti
	Ericsson		Ericsson
	300 Holger Way		300 Holger Way
	San Jose, CA		San Jose, CA
	US		US
	Phone: +1 408 750 5843
	Email: samita.chakrabarti@ericsson.com		Email: samita.chakrabarti@ericsson.com
	Gabriel Montenegro		Gabriel Montenegro
	Microsoft		Microsoft
	Seattle		Seattle
	US		US
	Email: gabriel.montenegro@microsoft.com		Email: gabriel.montenegro@microsoft.com
	Ralph Droms		Ralph Droms
	Cisco		Cisco
	USA		USA
	Email: rdroms@cisco.com		Email: rdroms@cisco.com
	James Woodyatt		James Woodyatt
	Nest		Nest
	Mountain View, CA		Mountain View, CA
	USA		USA
End of changes. 16 change blocks.
	30 lines changed or deleted		54 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/