< draft-ietf-6lo-dispatch-iana-registry-00.txt		draft-ietf-6lo-dispatch-iana-registry-01.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 7, 2016 R. Droms		Expires: August 28, 2016 R. Droms
	Cisco		Cisco
	J. Woodyatt		J. Woodyatt
	Nest		Nest
	February 4, 2016		February 25, 2016
	IANA Registry for 6lowpan ESC Dispatch Code points		IANA Registry for 6lowpan ESC Dispatch Code points
	draft-ietf-6lo-dispatch-iana-registry-00		draft-ietf-6lo-dispatch-iana-registry-01
	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 7, 2016.		This Internet-Draft will expire on August 28, 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 19 ¶		skipping to change at page 2, line 19 ¶
	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. Example: ITU-T G.9903 ESC type usage . . . . . . . . . . . 5
	3.4. NALP Usage . . . . . . . . . . . . . . . . . . . . . . . . 6		3.4. NALP and ESC bytes . . . . . . . . . . . . . . . . . . . . 6
	4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6		4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
	5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7		5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
	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 . . . . . . . . . . . . . . . . . . 7
	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
	skipping to change at page 3, line 36 ¶		skipping to change at page 3, line 36 ¶
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119].		document are to be interpreted as described in [RFC2119].
	3. Usage of ESC dispatch bytes		3. Usage of ESC dispatch bytes
	RFC 4944 [RFC4944] first introduces this "ESC" dispatch header type		RFC 4944 [RFC4944] first introduces this "ESC" dispatch header type
	for extension of dispatch bytes. RFC 6282 [RFC6282] subsequently		for extension of dispatch bytes. RFC 6282 [RFC6282] subsequently
	modified its value to [01 000000].		modified its value to [01 000000].
	This document specifies that the first octet following the ESC byte		This document specifies that the first octet following the ESC byte
	be used for extension type(extended dispatch values). Subsequent		be used for extension type (extended dispatch values). Subsequent
	octets are left unstructured for the specific use of the extension		octets are left unstructured for the specific use of the extension
	type:		type:
	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 | ESC EXT Type | Extended Dispatch Payload		|0 1| ESC | ESC EXT Type | Extended Dispatch Payload
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	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 byte.		ESC Extension Type (EET): It is the first byte following the ESC
	Extension type defines the payload for the additional dispatch bytes.		byte. Extension type defines the payload for the additional dispatch
	The values are from 0 to 255. Value 0 and 255 are reserved for		bytes. The values are from 0 to 255. Value 0 and 255 are reserved
	future use. These values are assigned by IANA. The EET values are		for future use. These values are assigned by IANA. The EET values
	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. Section 3.1		multiple ESC bytes MAY appear in a 6lowpan header. For example, it
	describes how to handle unknown ESC dispatch type.		is possible to form [Mesh-hdr][6lowpan-
			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.		Extension Payload. For the sake of interoperability, specifications
			of extension bytes MUST NOT redefine the existing ESC Extension Type
			codes.
	Note that section 5.1 in RFC4944 indicates that the Extension Type		Section 5.1 in RFC4944 indicates that the Extension Type field may
	field may contain additional dispatch values larger than 63		contain additional dispatch values larger than 63, as corrected by
	[4944-ERRATA]. Note that the new dispatch type MUST NOT modify the		[4944-ERRATA]. For the sake of interoperability, the new dispatch
	behavior of existing dispatch types for the sake of interoperability.		type (EET) MUST NOT modify the behavior of existing dispatch types
			[RFC4944].
	3.1. Interaction with other RFC4944 implementations		3.1. Interaction with other RFC4944 implementations
	It is expected that RFC4944 existing implementations are not capable		It is expected that RFC4944 existing implementations are not capable
	of processing ESC extension data bytes as defined in this document.		of processing ESC extension data bytes as defined in this document.
	However, implementors have to assume that existing implementation		However, implementors have to assume that existing implementation
	that attempt to process an EET unknown to them will simply drop the		that attempt to process an EET unknown to them will simply drop the
	packet or ignore the ESC dispatch bytes.		packet or ignore the ESC dispatch bytes.
	If an implementation following this document, during processing of		If an implementation following this document, during processing of
	the received packet reaches the ESC byte for which it does not		the received packet reaches the ESC byte for which it does not
	understand the extension bytes (EET), it MUST drop that packet.		understand the extension bytes (EET), it MUST drop that packet.
	However, it is important to clarify that a router node SHOULD forward		However, it is important to clarify that a router node SHOULD forward
	a 6lowpan packet with the EET bytes as long as it does not attempt to		a 6lowpan packet with the EET bytes as long as it does not attempt to
	process any ESC extension bytes.		process any unknown ESC extension bytes.
	Sequence Of dispatch bytes and ESC bytes: Multiple ESC extension		Sequence Of dispatch bytes and ESC bytes: Multiple ESC extension
	bytes may appear in a packet. Could a 6lowpan packet start with a		bytes may appear in a packet. The ESC bytes can appear as the first,
	ESC dispatch type? In another word, should ESC extension always be		last or middle dispatch bytes. However, a packet will get dropped by
	preceeded by non-ESC dispatch bytes?		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
	gab: I think the answer is no. But per the previous sentence, you		higher chance there is that a legacy node will recognize and
	have to assume that your packet will get dropped immediately by any		successfully process some dispatch type [RFC4944] before the EET and
	node that does not understand the EET at the beginning of the packet.		then ignore the EET instead of dropping the entire 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 successfully process
	some dispatch type before the EET and then ignore the EET instead of
	dropping the entire packet. Unless you know for sure that all nodes
	in your network understand a given EET (by definition a private and
	non-standard deployment), placing it at the beginning is a good way
	to guarantee that the packet will get dropped.
	3.2. ESC Extension Bytes Typical Sequence		3.2. ESC Extension Bytes Typical Sequence
	The following diagram provides an example when ESC extension bytes		The following diagram provides an example when ESC extension bytes
	might be used:		might be used:
	A LoWPAN encapsulated HC1 compressed packet:		A LoWPAN encapsulated HC1 compressed packet:
	+----------+-----------------+---------+-----+-----+--------+		+----------+-----------------+---------+-----+-----+--------+
	| Dispatch | LOWPAN_IPHC hdr | Payld |ESC | EET |EPayld |		| Dispatch | LOWPAN_IPHC hdr | Payld |ESC | EET |EPayld |
	+----------------------------+---------+-----+-----+--------+		+----------------------------+---------+-----+-----+--------+
	skipping to change at page 6, line 5 ¶		skipping to change at page 6, line 5 ¶
	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 Usage		3.4. NALP and ESC bytes
	There were several comments on 00 draft -- that this draft should
	provide guidance on NALP usage as there was no clear distinction
	between ITU-T command mode usage and NALP usage. In order to avaoid
	such confusion, a NALP usage guidance should be provided. This is a
	space holder section in order to decide whether NALP usage indeed
	should belong here.
	gab: I don't think we need to say anything beyond what we already say		According to RFC4944 [RFC4944] section 5.1, NALP dispatch bytes are
	in 4944: it is not a 6lowpan frame. This was done recognizing that		used for non-6lowpan packets. Since ESC bytes are part of 6lowpan
	some SDO's would also define their own frame structure, in		dispatch types (extended), they are orthogonal to NALP bytes.
	particular, Zigbee. There was some effort to agree with them on some
	way for our definitions to not collide. So prescribing usage of
	NALP, beyond saying it is not 6lowpan nor the subject of any IETF
	document, would defeat the purpose.
	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.
	The initial values for the 'ESC Extension Type' fields are:		The initial values for the 'ESC Extension Type' fields are:
	+-------+---------------------------------+---------------+		+-------+---------------------------------+---------------+
	| Value | Description | Reference |		| Value | Description | Reference |
	+-------+---------------------------------+---------------+		+-------+---------------------------------+---------------+
	| 0 | Reserved for future use | This document |		| 0 | Reserved for future use | This document |
	| | | |		| | | |
End of changes. 16 change blocks.
	51 lines changed or deleted		40 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/