< draft-ietf-6lo-dispatch-iana-registry-04.txt		draft-ietf-6lo-dispatch-iana-registry-05.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: February 9, 2017 R. Droms		Expires: March 20, 2017 R. Droms
	Cisco		Cisco
	J. Woodyatt		J. Woodyatt
	Nest		Nest
	August 8, 2016		September 16, 2016
	6lowpan ESC Dispatch Code Points and Guidelines		6lowpan ESC Dispatch Code Points and Guidelines
	draft-ietf-6lo-dispatch-iana-registry-04		draft-ietf-6lo-dispatch-iana-registry-05
	Abstract		Abstract
	RFC4944 defines ESC dispatch type for additional dispatch bytes in		RFC4944 defines the ESC dispatch type to allow for additional
	the 6lowpan header. The value of ESC byte has been updated by		dispatch bytes in the 6lowpan header. The value of the ESC byte was
	RFC6282. However, the usage of ESC extension byte has not been		updated by RFC6282, however, its usage was not defined either in
	defined in RFC6282 and RFC4944. This document updates RFC4944 and		RFC6282 or in RFC4944. This document updates RFC4944 and RFC6282 by
	RFC6282 by defining the ESC extension byte code points including		defining the ESC extension byte code points including registration of
	registration of entries for known use-cases at the time of writing of		entries for known use cases at the time of writing of this document.
	this document.
	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.
	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 February 9, 2017.		This Internet-Draft will expire on March 20, 2017.
	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 3, line 12 ¶		skipping to change at page 3, line 12 ¶
	7.2. Informative References . . . . . . . . . . . . . . . . . . 8		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,
	implementations and Standards organizations have started using the		implementations and standards organizations have started using the
	ESC extension bytes and a co-ordination between the respective		ESC extension bytes and co-ordination between the respective
	organizations and IETF/IANA are needed.		organizations and IETF/IANA is needed.
	The following sections record the ITU-T specification for ESC		The following sections record the ITU-T specification for ESC
	dispatch byte code points as an existing known usage and propose the		dispatch byte code points as an existing known usage and propose the
	definition of ESC extension bytes for future applications. The		definition of ESC extension bytes for future applications. The
	document also requests IANA actions for the first extension byte		document also requests IANA actions for the first extension byte
	following the ESC byte.		following the ESC byte.
	2. Terminology		2. Terminology
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	skipping to change at page 4, line 6 ¶		skipping to change at page 4, line 6 ¶
	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		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. Values 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
	preceded by the ESC byte. Thus, ESC extension types and dispatch		preceded 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. Section 3.1
	describes how to handle unknown ESC dispatch type.		describes how to handle an unknown ESC dispatch type.
	Extended Dispatch Payload(EDP): This part of frame format must be		Extended Dispatch Payload(EDP): This part of the 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
	[4944-ERRATA]. For the sake of interoperability, the new dispatch		[4944-ERRATA]. For the sake of interoperability, the new dispatch
	type (EET) MUST NOT modify the behavior of existing dispatch types		type (EET) MUST NOT modify the behavior of existing dispatch types
	skipping to change at page 4, line 36 ¶		skipping to change at page 4, line 36 ¶
	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, implementers have to assume that existing implementation		However, implementers 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 an 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 unknown 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. 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
	skipping to change at page 6, line 32 ¶		skipping to change at page 6, line 32 ¶
	This document clarifies that NALP dispatch codes only provide an		This document clarifies that NALP dispatch codes only provide an
	escape method for non-6LoWPAN payloads when they appear as the		escape method for non-6LoWPAN payloads when they appear as the
	initial byte of a LoWPAN encapsulation, and that the potential		initial byte of a LoWPAN encapsulation, and that the potential
	meaning of their appearance in any other location is reserved for		meaning of their appearance in any other location is reserved for
	future use.		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 per the policy 'Specification Required' [RFC5226], following
	specified in this document which follows the same policy as in the		the same policy as in the IANA section of [RFC4944]. For each
	IANA section of [RFC4944]. For each Extension Type (except the		Extension Type (except the Reserved values) the specification MUST
	Reserved values) the specification MUST define corresponding Extended		define corresponding Extended Dispatch Payload frame bytes for the
	Dispatch Payload frame bytes for the receiver implementation to read		receiver implementation to read the ESC bytes in an interoperable
	the ESC bytes with interoperability.		fashion.
	[RFC5226] section 4.1 also indicates that "Specification Srequired"		[RFC5226] section 4.1 also indicates that "Specification Required"
	implies a Designated expert review of the public specification which		implies a Designated Expert review of the public specification
	is requesting registry for the ESC Extenstion Type values.		requesting registration of the ESC Extension Type values.
	The allocation of code-points should follow the guidelines on "Usage		The allocation of code points should follow the guidelines on "Usage
	Of ESC Dispatch Bytes" and the typical example sections. ESC		Of ESC Dispatch Bytes" and the typical example sections. ESC
	Extension type code points MUST be used in conjunction with 6lo		Extension type code points MUST be used in conjunction with 6lo
	protocols following [RFC4944] or its derivatives. The requesting		protocols following [RFC4944] or its derivatives. The requesting
	document MUST specify how the ESC dispatch bytes will be used along		document MUST specify how the ESC dispatch bytes will be used along
	with 6LOWPAN headers in their use-cases.		with 6LOWPAN headers in their use cases.
	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 |
	| | | |		| | | |
	| 1-31 | Used by ITU-T G.9903 and G.9905 | ITU-T G.9903 &|		| 1-31 | Used by ITU-T G.9903 and G.9905 | ITU-T G.9903 &|
	| | Command IDs | ITU-T G.9905 |		| | Command IDs | ITU-T G.9905 |
	skipping to change at page 7, line 27 ¶		skipping to change at page 7, line 27 ¶
	| |(Reserved for future IANA | |		| |(Reserved for future IANA | |
	| | Assignment-- Spec Required) | |		| | Assignment-- Spec Required) | |
	| | | |		| | | |
	| 255 | Reserved for future use | This document |		| 255 | Reserved for future use | This document |
	+-------+---------------------------------+---------------+		+-------+---------------------------------+---------------+
	Figure 4: Initial Values for IANA Registry		Figure 4: Initial Values for IANA Registry
	5. Security Considerations		5. Security Considerations
	There is no additional security threats due to the assignments of ESC		There are no additional security threats due to the assignments of
	byte usage described in this document. However, this document		ESC byte usage described in this document. Furthermore, this
	forbids defining any extended dispatch values or extension types that		document forbids defining any extended dispatch values or extension
	modifies the behavior of existing Dispatch types.		types that modify the behavior of existing Dispatch types.
	6. Acknowledgements		6. Acknowledgements
	The authors would like to thank the members of the 6lo WG members for		The authors would like to thank the members of the 6lo WG for their
	the comments in the mailing list. Many thanks to Carsten Bormann,		comments. Many thanks to Carsten Bormann, Ralph Droms, Thierry Lys,
	Ralph Droms, Thierry Lys, Cedric Lavenu, Pascal Thubert for their		Cedric Lavenu, Pascal Thubert for discussions regarding the bits
	discussions regarding resolving the bits allocation issues which led		allocation issues, which led to this document. Jonathan Hui and
	to this document. Jonathan Hui and Robert Cregie provided extensive		Robert Cragie provided extensive reviews and guidance for
	reviews and guidance for interoperability. The authors acknowledges		interoperability. The authors acknowledge the comments from the
	the comments from the following people for shaping this document:		following people that helped shape this document: Paul Duffy, Don
	Paul Duffy, Don Sturek, Michael Richardson, Xavier Vilajosana and		Sturek, Michael Richardson, Xavier Vilajosana and Scott Mansfield.
	Scott Mansfield. Brian Haberman, our document shepherd helped us		Thanks to Brian Haberman, our document shepherd, for guidance in the
	modify the IANA section for guideline.		IANA section.
	7. References		7. References
	7.1. Normative References		7.1. Normative References
	[4944-ERRATA]		[4944-ERRATA]
	"https://www.rfc-editor.org/errata_search.php?rfc=4944".		"https://www.rfc-editor.org/errata_search.php?rfc=4944".
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/		Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
	RFC2119, March 1997,		RFC2119, March 1997,
	skipping to change at page 8, line 46 ¶		skipping to change at page 8, line 46 ¶
	IANA Considerations Section in RFCs", BCP 26, RFC 5226,		IANA Considerations Section in RFCs", BCP 26, RFC 5226,
	DOI 10.17487/RFC5226, May 2008,		DOI 10.17487/RFC5226, May 2008,
	<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		USA
	Email: samita.chakrabarti@ericsson.com		Email: samitac.ietf@gmail.com
	Gabriel Montenegro		Gabriel Montenegro
	Microsoft		Microsoft
	Seattle		USA
	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.ietf@gmail.com
	James Woodyatt		James Woodyatt
	Nest		Nest
	Mountain View, CA		Mountain View, CA
	USA		USA
	Email: jhw@netstlabs.com		Email: jhw@netstlabs.com
End of changes. 21 change blocks.
	50 lines changed or deleted		47 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/