< draft-bergmann-bier-ccast-01.txt		draft-bergmann-bier-ccast-02.txt >
	Network Working Group O. Bergmann		Network Working Group O. Bergmann
	Internet-Draft C. Bormann		Internet-Draft C. Bormann
	Intended status: Standards Track S. Gerdes		Intended status: Standards Track S. Gerdes
	Expires: October 5, 2016 Universitaet Bremen TZI		Expires: April 8, 2017 Universitaet Bremen TZI
	H. Chen		H. Chen
	Huawei Technologies		Huawei Technologies
	April 03, 2016		October 05, 2016
	Constrained-Cast: Source-Routed Multicast for RPL		Constrained-Cast: Source-Routed Multicast for RPL
	draft-bergmann-bier-ccast-01		draft-bergmann-bier-ccast-02
	Abstract		Abstract
	This specification defines a protocol for forwarding multicast		This specification defines a protocol for forwarding multicast
	traffic in a constrained node network employing the RPL routing		traffic in a constrained node network employing the RPL routing
	protocol in non-storing mode.		protocol in non-storing mode.
	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
	skipping to change at page 1, line 35 ¶		skipping to change at page 1, line 35 ¶
	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 October 5, 2016.		This Internet-Draft will expire on April 8, 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 2, line 13 ¶		skipping to change at page 2, line 13 ¶
	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
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3		1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
	2. The BIER Approach . . . . . . . . . . . . . . . . . . . . . . 3		2. The BIER Approach . . . . . . . . . . . . . . . . . . . . . . 3
	3. The Constrained-Cast Approach . . . . . . . . . . . . . . . . 3		3. The Constrained-Cast Approach . . . . . . . . . . . . . . . . 3
	4. False Positives . . . . . . . . . . . . . . . . . . . . . . . 3		4. False Positives . . . . . . . . . . . . . . . . . . . . . . . 4
	5. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . 4		5. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . 4
	5.1. Multicast Listener Advertisement Object (MLAO) . . . . . 4		5.1. Multicast Listener Advertisement Object (MLAO) . . . . . 4
	5.2. Routing Header . . . . . . . . . . . . . . . . . . . . . 5		5.2. Routing Header . . . . . . . . . . . . . . . . . . . . . 5
	6. Implementation . . . . . . . . . . . . . . . . . . . . . . . 6		6. Implementation . . . . . . . . . . . . . . . . . . . . . . . 6
	7. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . 7		7. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . 7
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
	8.1. ICMPv6 Parameter Registration . . . . . . . . . . . . . . 7		8.1. ICMPv6 Parameter Registration . . . . . . . . . . . . . . 7
	8.2. IPv6 Routing Type Registration . . . . . . . . . . . . . 7		8.2. IPv6 Routing Type Registration . . . . . . . . . . . . . 7
	9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8		9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
	skipping to change at page 2, line 43 ¶		skipping to change at page 2, line 43 ¶
	up and create bread-crumbs. This specification, although part of RFC		up and create bread-crumbs. This specification, although part of RFC
	6550, appears to be incomplete and untested. More importantly,		6550, appears to be incomplete and untested. More importantly,
	Storing Mode is not in use in constrained node networks outside		Storing Mode is not in use in constrained node networks outside
	research operating environments.		research operating environments.
	The present specification addresses multicast forwarding for RPL		The present specification addresses multicast forwarding for RPL
	networks in the much more common Non-Storing Mode. Non-Storing is		networks in the much more common Non-Storing Mode. Non-Storing is
	based on the root node adding source-routing information to downward		based on the root node adding source-routing information to downward
	packets. Evidently, to make this work, RPL multicast needs to		packets. Evidently, to make this work, RPL multicast needs to
	source-route multicast packets. A source route here is a list of		source-route multicast packets. A source route here is a list of
	outgoing interfaces, which subsets the whole set of potential		identifiers to instruct forwarders to relay the respective IP
	forwarders available in the RPL DODAG to those that need to forward		datagram.
	in order to reach known multicast listeners.
			As every forwarder in an IP-based constrained node network has at
			least one network interface, it is straight-forward to use the
			address of an outgoing interface as identifiers in this source-route.
			(Typically, this is a globally unique public address of the node's
			only network adapter.)
			The source-route subsets the whole set of potential forwarders
			available in the RPL DODAG to those that need to forward in order to
			reach known multicast listeners.
	Including an actual list of outgoing interfaces is rarely applicable,		Including an actual list of outgoing interfaces is rarely applicable,
	as this is likely to be a large list of 16-byte IPv6 addresses. Even		as this is likely to be a large list of 16-byte IPv6 addresses. Even
	with [RFC6554] style compression, the size of the list becomes		with [RFC6554] style compression, the size of the list becomes
	prohibitively quickly.		prohibitively quickly.
	1.1. Terminology		1.1. Terminology
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	skipping to change at page 4, line 38 ¶		skipping to change at page 4, line 49 ¶
	yes, it then forwards the packet to all outgoing interfaces that		yes, it then forwards the packet to all outgoing interfaces that
	match the bloom filter in the packet.		match the bloom filter in the packet.
	5.1. Multicast Listener Advertisement Object (MLAO)		5.1. Multicast Listener Advertisement Object (MLAO)
	The header format of the MLAO is depicted in Figure 1. The basic		The header format of the MLAO is depicted in Figure 1. The basic
	structure of the MLAO message is similar to the RPL Destination		structure of the MLAO message is similar to the RPL Destination
	Advertisement Object (DAO). In particular, it starts with RPL ICMP		Advertisement Object (DAO). In particular, it starts with RPL ICMP
	base header with a type value of 155 and the code {IANA TBD1} (MLAO),		base header with a type value of 155 and the code {IANA TBD1} (MLAO),
	followed by the Checksum, RPLInstanceID, parameters and flags as in a		followed by the Checksum, RPLInstanceID, parameters and flags as in a
	DAO. A sequence number allows ordering of MLAOs generated by a		DAO.
	sender.
	0 1 2 3		0 1 2 3
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type = 0x05 | Option Length | Reserved | Prefix Length |		| Type = 0x05 | Option Length | Reserved | Prefix Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	+ +		+ +
	| Group Address |		| Group Address |
	. .		. .
	. .		. .
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 1: RPL Target Option for MLAO		Figure 1: RPL Target Option for MLAO
	The next header field indicates the group that the sender is		The group address field indicates the group that the sender of the
	interested in. This field usually contains a 128 bit IPv6 multicast		MLAO is interested in. This field usually contains a 128 bit IPv6
	group address. Shorter group identifiers could be used together with		multicast group address. Shorter group identifiers could be used
	a protocol for explicit creation of groups. The MLAO message must		together with a protocol for explicit creation of groups. The MLAO
	have at least one RPL target option to specify the address of the		message must have at least one RPL target option to specify the
	listener that has generated the MLAO. As the MLAO message is		address of the listener that has generated the MLAO. The message is
	forwarded hop-by-hop upwards the routing tree using link-local		directed to the global unicast address of the DODAG root and travels
	addresses only, the target option is the only way to communicate the		upwards the routing tree.
	interface address to be used for group subscription.
			Note: It has been suggested to use the RPL Transit Option (Type
			0x06) instead as it is used in Non-Storing mode to inform the
			DODAG root of path attributes. Specifically, this option can be
			used to limit the subscription by providing a proper Path
			Lifetime.
	5.2. Routing Header		5.2. Routing Header
	0 1 2 3		0 1 2 3
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Next Header | Hdr Ext Len | Routing Type | Segments Left |		| Next Header | Hdr Ext Len | Routing Type | Segments Left |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Sequence Number | Func set | Modulus |		| Sequence Number | Func set | Modulus |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	skipping to change at page 5, line 48 ¶		skipping to change at page 6, line 4 ¶
	| |		| |
	. .		. .
	. Filter data .		. Filter data .
	. .		. .
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 2: Routing header		Figure 2: Routing header
	Routing Type: {IANA TBD2} 253		Routing Type: {IANA TBD2} 253
	Segments Left: This value is always 0, so network nodes that do not		Segments Left: This value is always 0, so network nodes that do not
	support this routing header do not generate ICMP6 error messages.		support this routing header do not generate ICMP6 error messages.
	Sequence Number: 16 bits sequence number. The number space is		Sequence Number: 16 bits sequence number. The number space is
	unique for a sequence of multicast datagrams for a specific group		unique for a sequence of multicast datagrams for a specific group
	that arrive at the DAG root on their way up. The DAG root		that arrive at the DAG root on their way up. The DAG root
	increments the number for each datagram it sends down the		increments the number for each datagram it sends down the
	respective DODAG.		respective DODAG.
	Func set: The set of hash functions used to generate the Filter data		Func set: The set of hash functions used to generate the Filter data
	value.		value.
	Note: As the function set contains a combination of several distinct		Note: As the function set contains a combination of several distinct
	hash functions, it is currently unclear if 8 bits number space is		hash functions, it is currently unclear if 8 bits number space is
	large enough.		large enough.
	Modulus: The modulus that is used by the hash functions, minus 64		Modulus: The modulus that is used by the hash functions, minus 64
	(the minimum filter data size that can be used). The sender		(the minimum filter data size that can be used). The DAG root
	chooses the modulus (and thus the filter data size) to achieve its		chooses the modulus (and thus the filter data size) to achieve its
	objectives for false positive rates (Section 4).		objectives for false positive rates (Section 4).
	Filter data: A bit field that indicates which nodes should relay		Filter data: A bit field that indicates which nodes should relay
	this multicast datagram. The length of this field is a multiple		this multicast datagram. The length of this field is a multiple
	of 8 bytes. The actual length is derived from the contents of the		of 8 bytes. The actual length is derived from the contents of the
	field Header Ext Length.		field Header Ext Length.
	Note: The modulus could be derived from the length of the filter data		Note: The modulus could be derived from the length of the filter data
	which is known from the extension header size. On the other hand,		which is known from the extension header size. On the other hand,
	keeping a separate record of the modulus means that the sender could		keeping a separate record of the modulus means that the DAG root
	leave out 8-byte multiples of trailing zero bits if they happen to		could leave out 8-byte multiples of trailing zero bits if they happen
	occur. But then, a modulus that leaves 8-byte sequences of zero bits		to occur. But then, a modulus that leaves 8-byte sequences of zero
	in the filter is probably too large.		bits in the filter is probably too large.
	6. Implementation		6. Implementation
	In 2013, Constrained-Cast was implemented in Contiki. It turns out		In 2013, Constrained-Cast was implemented in Contiki. It turns out
	that forwarders can compute the hash functions once for their		that forwarders can compute the hash functions once for their
	outgoing interfaces and then cache them, simply bit-matching their		outgoing interfaces and then cache them, simply bit-matching their
	outgoing interface hash bits against the bloom filter in the packet		outgoing interface hash bits against the bloom filter in the packet
	(a match is indicated when all bits in the outgoing interface hash		(a match is indicated when all bits in the outgoing interface hash
	are set in the bloom filter).		are set in the bloom filter).
	skipping to change at page 8, line 7 ¶		skipping to change at page 8, line 7 ¶
	Types registry:		Types registry:
	+-------+----------------------+------------+		+-------+----------------------+------------+
	| Value | Name | Reference |		| Value | Name | Reference |
	+-------+----------------------+------------+		+-------+----------------------+------------+
	| TBD2 | CCast Routing Header | [RFC-XXXX] |		| TBD2 | CCast Routing Header | [RFC-XXXX] |
	+-------+----------------------+------------+		+-------+----------------------+------------+
	9. Acknowledgments		9. Acknowledgments
			Thanks to Yasuyuki Tanaka for valuable comments.
	This work has been supported by Siemens Corporate Technology.		This work has been supported by Siemens Corporate Technology.
	10. References		10. References
	10.1. Normative References		10.1. Normative References
	[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,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<http://www.rfc-editor.org/info/rfc2119>.		<http://www.rfc-editor.org/info/rfc2119>.
	skipping to change at page 8, line 33 ¶		skipping to change at page 8, line 35 ¶
	<http://www.rfc-editor.org/info/rfc6550>.		<http://www.rfc-editor.org/info/rfc6550>.
	10.2. Informative References		10.2. Informative References
	[BLOOM] Bloom, B., "Space/time trade-offs in hash coding with		[BLOOM] Bloom, B., "Space/time trade-offs in hash coding with
	allowable errors", ISSN 0001-0782, ACM		allowable errors", ISSN 0001-0782, ACM
	Press Communications of the ACM vol 13 no 7 pp 422-426,		Press Communications of the ACM vol 13 no 7 pp 422-426,
	1970, <http://doi.acm.org/10.1145/362686.362692>.		1970, <http://doi.acm.org/10.1145/362686.362692>.
	[I-D.ietf-bier-architecture]		[I-D.ietf-bier-architecture]
	Wijnands, I., Rosen, E., Dolganow, A., P, T., and S.		Wijnands, I., Rosen, E., Dolganow, A., Przygienda, T., and
	Aldrin, "Multicast using Bit Index Explicit Replication",		S. Aldrin, "Multicast using Bit Index Explicit
	draft-ietf-bier-architecture-03 (work in progress),		Replication", draft-ietf-bier-architecture-04 (work in
	January 2016.		progress), July 2016.
	[RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6		[RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6
	Routing Header for Source Routes with the Routing Protocol		Routing Header for Source Routes with the Routing Protocol
	for Low-Power and Lossy Networks (RPL)", RFC 6554,		for Low-Power and Lossy Networks (RPL)", RFC 6554,
	DOI 10.17487/RFC6554, March 2012,		DOI 10.17487/RFC6554, March 2012,
	<http://www.rfc-editor.org/info/rfc6554>.		<http://www.rfc-editor.org/info/rfc6554>.
	[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type		[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type
	Specifications and Registration Procedures", BCP 13,		Specifications and Registration Procedures", BCP 13,
	RFC 6838, DOI 10.17487/RFC6838, January 2013,		RFC 6838, DOI 10.17487/RFC6838, January 2013,
End of changes. 13 change blocks.
	29 lines changed or deleted		42 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/