====================================================================
The memo documents the interfaces, components, and semantics used by
-collection protocol in TinyOS 2.x. Collection provides best-effort,
-multihop delivery of packets to one of a set of collection points.
-There may be multiple collection points in a network, and in this
-case the semantics are *anycast* delivery to at least one of the
-collection points. A node sending a packet does not specify which of
-the collection points the packet is destined to. The union of the
-paths from each node to one or more of the collection points forms a
-set of trees, and in this document assume that collection points are
-the roots of these trees.
+the collection protocols in TinyOS 2.x. Collection provides
+best-effort, multihop delivery of packets to one of a set of
+collection points. There may be multiple collection points in a
+network, and in this case the semantics are *anycast* delivery to at
+least one of the collection points. A node sending a packet does not
+specify which of the collection points the packet is destined to. The
+union of the paths from each node to one or more of the collection
+points forms a set of trees, and in this document we assume that
+collection points are the roots of these trees.
1. Introduction
interact with the collection component.
The collection infrastructure can be multiplexed among independent
-applications, by means of a collection identifier. While data traffic
-in the protocol is multiplexed through these identifiers, control
-traffic is not: all data traffic uses the same routing topology.
+applications, by means of a collection identifier. The collection
+identifier is used to identify different data traffic at the sender,
+intermediate-nodes, or the receiver, much like port number in TCP. All
+data traffic, regardless of the collection identifier, use the same
+routing topology.
The nodes that generate data to be sent to the root are *senders*.
Senders use the Send interface [1_] to send data to the root of
collection. The collection identifier is specified as a parameter to
Receive during instantiation.
-The set of all roots and the paths that
-lead to them form the collection routing infrastructure in the network.
-For any connected set of nodes implementing the collection protocol
-there is only one collection infrastructure, *i.e.*, all roots in this
-set active at the same time are part of the same infrastructure.
+The set of all roots and the paths that lead to them form the
+collection routing infrastructure in the network. For any connected
+set of nodes implementing the collection protocol there is only one
+collection infrastructure, *i.e.*, all roots in this set active at the
+same time are part of the same infrastructure.
The RootControl interface configures whether a node is a
root::
}
-CollectionC MAY have additional interfaces. These additional
-interfaces MUST have default functions on all outgoing invocations
-(commands for uses, events for provides) of those interfaces so that
-it can operate properly if they are not wired.
+CollectionC MAY have additional interfaces. All outgoing invocations
+(commands for uses, events for provides) of those interfaces MUST have
+default functions. Those default functions enable CollectionC to
+operate properly even when the additional interfaces are not wired.
Components SHOULD NOT wire to CollectionC.Send. The generic
component CollectionSenderC (described in section 3.1) provides
protocol operating on top of collection, in the same way that
different am_id_t values represent different protocols operating on
top of active messages. All packets sent with a particular
-collection_id_t generally have the same payload format, so that
+collection_id_t generally SHOULD have the same payload format, so that
snoopers, intercepters, and receivers can parse them properly.
ColletionC MUST NOT signal Receive.receive on non-root