Internet Engineering Task Force M. Goyal, Ed.
Internet-Draft University of Wisconsin
Intended status: Standards Track Milwaukee
Expires: November 29, 2011 E. Baccelli
M. Philipp
INRIA
A. Brandt
Sigma Designs
J. Martocci
Johnson Controls
May 28, 2011
A Compression Format for RPL Control Messages
draft-goyal-roll-rpl-compression-00
Abstract
This document specifies a compression format for RPL ICMPv6 RPL
control messages.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 29, 2011.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
Goyal, et al. Expires November 29, 2011 [Page 1]
Internet-Draft draft-goyal-roll-rpl-compression-00 May 2011
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. RPL ICMPv6 Message Compression . . . . . . . . . . . . . . . . 3
3. RPL Base Object Compression . . . . . . . . . . . . . . . . . 4
3.1. Compressing the DODAG Information Object . . . . . . . . . 4
4. Compressing the RPL Options . . . . . . . . . . . . . . . . . 6
4.1. DODAG Configuration Option . . . . . . . . . . . . . . . . 6
4.2. Metric/Constraint Objects . . . . . . . . . . . . . . . . 8
4.2.1. Compressed Node State and Attributes Object . . . . . 9
4.2.2. Compressed Node Energy Object . . . . . . . . . . . . 9
4.2.3. Compressed Hop Count Object . . . . . . . . . . . . . 10
4.2.4. Compressed Throughput Object . . . . . . . . . . . . . 10
4.2.5. Compressed Latency Object . . . . . . . . . . . . . . 10
4.2.6. Compressed ETX Object . . . . . . . . . . . . . . . . 10
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.1. A DIO With A Configuration Option, A Route Information
Option and A Metric Container . . . . . . . . . . . . . . 11
5.2. A DIO With A Configuration Option, A Route Discovery
Option and A Metric Container . . . . . . . . . . . . . . 12
6. Security Considerations . . . . . . . . . . . . . . . . . . . 14
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
8.1. Normative References . . . . . . . . . . . . . . . . . . . 14
8.2. Informative References . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
Goyal, et al. Expires November 29, 2011 [Page 2]
Internet-Draft draft-goyal-roll-rpl-compression-00 May 2011
1. Introduction
RPL [I-D.ietf-roll-rpl] is an IPv6 routing protocol for low power and
lossy networks. It defines a number of ICMPv6 control messages for
its operation. These messages are susceptible to fragmentation when
RPL is deployed over a link layer with a small payload (e.g. IEEE
802.15.4, where the MAC payload can be as small as 81 bytes). This
document specifies a compression format for ICMPv6 RPL control
messages to minimize such fragmentation. This document currently
defines the compression format for RPL's DODAG Information Object
(DIO) base object, DODAG Configuration Option and some of the Routing
Metric/Constraint objects. Later versions of this document may
include the compression formats for other RPL messages and options.
1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
[RFC2119].
Additionally, this document uses terminology from
[I-D.ietf-roll-rpl], [I-D.ietf-roll-routing-metrics],
[I-D.ietf-roll-p2p-rpl] and [I-D.ietf-6lowpan-hc].
2. RPL ICMPv6 Message Compression
Various fields of a compressed ICMPv6 messages are as follows:
o Type: 155, as specified in [I-D.ietf-roll-rpl];
o Code: The Code value of the compressed version of an RPL ICMPv6
message is obtained by setting the 7th bit in the Code value
associated with the corresponding uncompressed message. For
example, the Code associated with a compressed DODAG Information
Object is 0x40.
o Checksum: The 16-bit Checksum for a compressed RPL message is
calculated in the same manner as for the uncompressed message.
o Base: The Base object carried in the message is compressed in the
manner described in Section 3.
o Option(s): An option carried in a compressed RPL ICMPv6 message
MAY be compressed as described in Section 4 or it MAY be carried
uncompressed as in an uncompressed message.
Goyal, et al. Expires November 29, 2011 [Page 3]
Internet-Draft draft-goyal-roll-rpl-compression-00 May 2011
3. RPL Base Object Compression
This section defines the compression format for various Base objects
associated with RPL ICMPv6 messages.
3.1. Compressing the DODAG Information Object
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - - - - - -
|C|I|L|V|R|G|T|F| Ra | Compr | Inline Fields
+---+---+---+---+---+---+---+---+- - - - - - - - - - - - - -
Figure 1: The Compression Format for DODAG Information Object
The format of a compressed DODAG Information Object (DIO) base object
is shown in Figure 1 and consists of the following fields:
o C: This flag is set to 1 if the 3rd byte of the DIO contains an
8-bit identifier of the "context" that provides values of all
elided fields in the DIO base object and the options it contains.
Otherwise, this flag is set to 0. The description of the contexts
in use in an LLN and how RPL nodes come to know of these contexts
is out of scope for this document.
o I: This flag indicates whether the RPLInstanceID field is elided
or not. This flag is set to 1 if the RPLInstanceID field is
present inline in the compressed DIO. This flag is set to 0 if
the RPLInstanceID field is elided. In this case, the implicit
value of the RPLInstanceID depends on the context if present. In
the absence of the context, the implicit value of the
RPLInstanceID depends on the value of the L flag as discussed
next.
o L: This flag is meaningful only when both C and I flags are 0,
i.e. the RPLInstanceID field is elided but no context is
identified. In this case, the L flag is set to 1 if the elided
RPLInstanceID is local and has implicit value 128. The L flag is
set to 0 if the elided RPLInstanceID field is global and has
implicit value 0. If either of C and I flag is set to 1, the L
flag MUST be set to 0 on transmission and ignored on reception.
o V: This flag is set to 1 if the Version Number is carried inline
in the DIO message. The flag is set to 0 if the Version Number is
elided. In this case, the implicit value of the Version Number
depends on the context if present. If no context is present, the
implicit value of the Version Number is assumed to be zero.
Goyal, et al. Expires November 29, 2011 [Page 4]
Internet-Draft draft-goyal-roll-rpl-compression-00 May 2011
o R: This flag indicates whether the Rank field in the DIO is
shortened or not. This flag is set to 1 if the full 16-bit Rank
is present inline in the compressed DIO. The flag is set to 0 if
the 4-bit long Ra field contains the rank value.
o G: This flag indicates whether the byte containing the Grounded,
Mode of Operation and DODAG Preference fields is elided or not.
This flag is set to 1 if the above-mentioned byte is carried
inline. The flag is set to 0, if this byte is elided. In this
case, the implicit values of Grounded, Mode of Operation and
DODAGPreference fields depend on the context if present. If no
context is present, the implicit values of these fields are as
follows:
* The Grounded flag has implicit value 0, i.e., the DODAG is not
grounded.
* The Mode of Operation field has implicit value 0, i.e., the
DODAG does not maintain any downward routes.
* The DODAG Preference field has implicit value 0, i.e., least
preferred.
o T: This flag is set to 1 if the DTSN field is carried inline. The
flag is set to 0, if the DTSN field is elided. In this case, the
implicit value of the DTSN field depends on the context if
present. If no context is present, the implicit value of this
field is assumed to be zero.
o F: This flag indicates whether the Flags and Reserved fields in
the DIO are elided or not. This flag is set to 1 if these fields
are carried inline. The flag is set to 0, if these fields are
elided. In this case, the values of these fields depend on the
context if present. If no context is present, both fields are
assumed to be zero.
o Ra: This field contains the 4-bit rank value if the R flag is set
to 0.
o Compr: This field contains the number of prefix octets that are
elided from the DODAGID field. For example, the Compr value will
be zero if full 16-octet DODAGID field is carried inline in the
compressed DIO.
o Inline Fields: The context identifier, if present, occupies the
3rd byte of the compressed DIO base object. Any inline fields in
the compressed DIO appear in the same order as in the uncompressed
format defined in [I-D.ietf-roll-rpl].
Goyal, et al. Expires November 29, 2011 [Page 5]
Internet-Draft draft-goyal-roll-rpl-compression-00 May 2011
4. Compressing the RPL Options
This section defines the compression format for some of the RPL
options that may be carried inside an RPL control message. These RPL
options SHOULD be compressed when carried inside an RPL control
message compressed in the manner described in this document. The
other RPL options, for which a compression format is not specified in
this document, MUST follow the format in which they are defined when
carried inside an RPL control message compressed as described in this
document.
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+----------------
| Option Type | Option Length | Option Data
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+----------------
Figure 2: Format of a Compressed RPL Option
The compression format of an RPL option is shown in Figure 2. It
consists of:
o Option Type: The Option Type value for a compressed RPL option is
same as that of the uncompressed option with the most significant
bit (MSB) set to 1.
o Option Length: The Option Length is 8 bits long as in case of an
uncompressed RPL option.
4.1. DODAG Configuration Option
0 1 2 3 4 5 6 7 8
+---+---+---+---+---+---+---+---+- - - - - - - -
| F | T1| T2| I1| I2| O | R | L | Inline Fields
+---+---+---+---+---+---+---+---+- - - - - - - -
Figure 3: Format of a Compressed DODAG Configuration Option
The format of the compressed DODAG Configuration Option is shown in
Figure 3. The compressed DODAG Configuration option begins with an
octet consisting of flags that specify whether the individual fields
in the option are elided or not. The implicit value of an elided
field depends on the context identified in the DIO base object. If
DIO base object does not identify a context, the implicit value of an
elided field is as specified below:
Goyal, et al. Expires November 29, 2011 [Page 6]
Internet-Draft draft-goyal-roll-rpl-compression-00 May 2011
o F: This flag indicates whether the byte in the uncompressed DODAG
Configuration option, consisting of the Flags, A and PCS fields,
is elided or not. This flag is set to 1 if this byte is carried
inline. The flag is set to 0, if this byte is elided. If the DIO
base object does not contain a context, the implicit values of
elided A and PCS fields are zero and DEFAULT_PATH_CONTROL_SIZE (as
defined in [I-D.ietf-roll-rpl]) respectively.
o T1: This flag indicates whether the DIOIntervalDoublings and
DIOIntervalMin fields are elided or not. This flag is set to 1 if
these fields are carried inline. The flag is set to 0, if these
fields are elided. If DIO base object does not contain a context
identifier, these fields, if elided, assume their default values
as defined in [I-D.ietf-roll-rpl].
o T2: This flag indicates whether the DIORedundancyConstant field is
elided or not. This flag is set to 1 if DIORedundancyConstant is
carried inline. The flag is set to 0, if this field is elided.
In this case, the field assumes its default value as defined in
[I-D.ietf-roll-rpl] if the DIO base object does not identify a
context.
o I1: This flag indicates whether the MaxRankIncrease field is
elided or not. This flag is set to 1 if this field is carried
inline. The flag is set to 0 if this field is elided. In this
case, the MaxRankIncrease field assumes its default value (as
defined in [I-D.ietf-roll-rpl]) if the DIO base object does not
identify a context.
o I2: This flag indicates whether the MinHopRankInc field is elided
or not. This flag is set to 1 if this field is carried inline.
The flag is set to 0 if this field is elided. In this case, the
MinHopRankInc field assumes its default value (as defined in
[I-D.ietf-roll-rpl]) if the DIO base object does not identify a
context.
o O: This flag indicates whether the OCP field is elided or not.
This flag is set to 1 if this field is carried inline. The flag
is set to 0 if this field is elided. In this case, if the DIO
base object does not identify a context, RPL Objective Function 0
[I-D.ietf-roll-of0] is the OCP in effect.
o R: This flag indicates whether the byte marked as Reserved in the
uncompressed format is elided or not. This flag is set to 1 if
this byte is carried inline. The flag is set to 0 if this byte is
elided. In this case, the Reserved byte is assumed to have value
0.
Goyal, et al. Expires November 29, 2011 [Page 7]
Internet-Draft draft-goyal-roll-rpl-compression-00 May 2011
o L: This flag indicates whether the Default Lifetime and Lifetime
Unit fields are elided or not. This flag is set to 1 if these
fields are carried inline. The flag is set to 0 if these fields
are elided. In this case, the life time of the routes associates
with this DODAG is infinity unless another value is specified in
the context identified in the DIO base object.
o Inline fields: Any inline fields in the compressed DODAG
Configuration option appear in the same order as in the
uncompressed format.
Note that a compressed DODAG Configuration Option can be as small as
3 bytes, whereas an uncompressed DODAG Configuration Option is 16
bytes long.
4.2. Metric/Constraint Objects
0 1 2 3 4 5 6 7 8
+---+---+---+---+---+---+---+---+- - - - - - - -
| Type | C |O/P| P2| A | Object Body
+---+---+---+---+---+---+---+---+- - - - - - - -
Figure 4: Generic Format of a Compressed Routing Metric/Constraint
Object
A compressed Metric Container Option contains compressed Routing
Metric/Constraint objects as defined in this document. A compressed
Metric Container Option MUST NOT contain uncompressed Routing Metric/
Constraint objects defined in [I-D.ietf-roll-routing-metrics]. The
generic format of a compressed Routing Metric/Constraint Object is
shown in Figure 4. A compressed Routing Metric/Constraint Object
always has a fixed size as defined in this document. Thus,
"recorded" metrics and sub-objects/TLV options within a metric object
are not allowed. Various fields inside a compressed Routing Metric/
Container Object header are as follows:
o Type: The type of the routing metric/constraint object.
o C: This flag is set to one if the object represents a constraint.
This flag is set to zero if the object represents a metric.
o O/P: If the object represents a constraint, this flag is set to
one if the constraint is optional. Otherwise, the flag is set to
zero. If the object represents a metric, this bit represents,
along with P2 bit, a 2-bit "precedence" field.
o P2: This bit is relevant only when the object represents a metric.
Along with the O/P bit, this bit forms a 2-bit "precendence" field
Goyal, et al. Expires November 29, 2011 [Page 8]
Internet-Draft draft-goyal-roll-rpl-compression-00 May 2011
to indicate the precedence of this metric relative to other
metrics in the container. The precedence values range from 0 to
3, 0 being the highest precedence.
o A: This field is relevant only for metrics and indicates the
manner in which the routing metric must be aggregated:
* A=0x00: The routing metric is additive
* A=0x01: The routing metric reports a maximum
* A=0x02: The routing metric reports a minimum
* A=0x03: The routing metric is multiplicative
4.2.1. Compressed Node State and Attributes Object
0 1 2 3 4 5 6 7 8
+---+---+---+---+---+---+---+---+
| Reserved | A | O |
+---+---+---+---+---+---+---+---+
Figure 5: Compressed Node State and Attributes Object
The compressed Node State and Attributes object has Type value 0 and
is shown in Figure 5. The A and O flags in the object have same
meaning and function as the corresponding flags in the uncompressed
object defined in [I-D.ietf-roll-routing-metrics].
4.2.2. Compressed Node Energy Object
0 1 2 3 4 5 6 7 8
+---+---+---+---+---+---+---+---+
| I | T | E | E-E |
+---+---+---+---+---+---+---+---+
Figure 6: Compressed Node Energy Object
The compressed Node Energy object has Type value 1 and is shown in
Figure 6. Various fields in the object have same meaning and
function as the corresponding fields in Node Energy sub-object
defined in [I-D.ietf-roll-routing-metrics]. Node that the E-E field
has been reduced from 8 bits to 4 bits.
Goyal, et al. Expires November 29, 2011 [Page 9]
Internet-Draft draft-goyal-roll-rpl-compression-00 May 2011
4.2.3. Compressed Hop Count Object
0 1 2 3 4 5 6 7 8
+---+---+---+---+---+---+---+---+
| Hop Count |
+---+---+---+---+---+---+---+---+
Figure 7: Compressed Hop Count Object
The compressed Hop Count object has Type value 2 and is shown in
Figure 7. It consists of a 8-bit hop count value.
4.2.4. Compressed Throughput Object
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| Throughput |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
Figure 8: Compressed Throughput Object
The compressed Throughput object has Type value 3 and is shown in
Figure 8. It consists of a 16-bit value expresed in units of kilo
bytes per second.
4.2.5. Compressed Latency Object
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| Latency |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
Figure 9: Compressed Latency Object
The compressed Latency object has Type value 4 and is shown in
Figure 9. It consists of a 16-bit value expresed in units of
milliseconds.
4.2.6. Compressed ETX Object
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| ETX |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
Goyal, et al. Expires November 29, 2011 [Page 10]
Internet-Draft draft-goyal-roll-rpl-compression-00 May 2011
Figure 10: Compressed ETX Object
The compressed ETX object has Type value 5 and is shown in Figure 10.
It consists of a 16-bit value, which has the same meaning and
function as the ETX field inside ETX sub-object inside ETX object
defined in [I-D.ietf-roll-routing-metrics].
5. Examples
In this section, we compare the sizes of RPL control messages with
and without the compression mechanism specified in this document.
5.1. A DIO With A Configuration Option, A Route Information Option and
A Metric Container
Consider an uncompressed multicast DIO message that has a
Configuration Option, a Route Information Option and a Metric
Container with one ETX metric object and one ETX constraint object.
This message consists of the following components:
o IPv6 header: A typical IPv6 header, compressed as per
[I-D.ietf-6lowpan-hc], for a multicast DIO message consists of 5
bytes as follows:
* 2 byte LOWPAN_IPHC Base Encoding
* 1 byte Context Identifier Extension
* 1 byte Next Header
* 1 byte Group ID to identify all-RPL-nodes multicast address.
o 4 bytes for ICMP Type, Code and Checksum fields;
o 24 bytes for DIO Base Object;
o 16 bytes for DODAG Configuration Option;
o 24 byte Route Information Option;
o 14 bytes for Metric Container consisting of:
* 2 bytes for Type and Option Length fields;
* 6 bytes for ETX metric object (4 bytes header + 2 bytes body);
Goyal, et al. Expires November 29, 2011 [Page 11]
Internet-Draft draft-goyal-roll-rpl-compression-00 May 2011
* 6 bytes for ETX constraint object (4 bytes header + 2 bytes
body).
Thus, the total length of such a DIO is 87 bytes.
The same message, when compressed in the manner described in this
document, consists of:
o 5 bytes of IPv6 header compressed as per [I-D.ietf-6lowpan-hc] in
the manner described in the previous paragraph;
o 4 bytes for ICMP Type, Code and Checksum fields;
o 4 bytes of compressed DIO Base Object consisting of 2 bytes of
header and 2 bytes for DODAGID (the best case scenario);
o 3 bytes of compressed DODAG Configuration Option, including 2
bytes for Type and Option Length fields;
o 24 bytes of Route Information Option;
o 8 bytes for Metric Container consisting of:
* 2 bytes for Type and Option Length fields;
* 3 bytes for ETX metric object (1 byte header + 2 bytes body);
* 3 bytes for ETX constraint object (1 byte header + 2 bytes
body).
Thus, the total length of the compressed DIO is 48 bytes.
5.2. A DIO With A Configuration Option, A Route Discovery Option and A
Metric Container
Consider an uncompressed multicast DIO message that has a
Configuration Option, a Route Discovery Option (defined in
[I-D.ietf-roll-p2p-rpl]) and a Metric Container with one ETX metric
object and one ETX constraint object. This message consists of the
following components:
o 5 bytes of IPv6 header compressed as per [I-D.ietf-6lowpan-hc] in
the manner described in the previous section;
o 4 bytes for ICMP Type, Code and Checksum fields;
o 24 bytes for DIO Base Object;
Goyal, et al. Expires November 29, 2011 [Page 12]
Internet-Draft draft-goyal-roll-rpl-compression-00 May 2011
o 16 bytes for DODAG Configuration Option;
o 26 bytes for Route Discovery Option consisting of:
* 4 bytes for Type, Option Length and other fixed length fields;
* 2 bytes for the Target address field;
* 20 bytes for the Address vector (assuming 10 2-byte long
elements).
o 14 bytes for Metric Container consisting of:
* 2 bytes for Type and Option Length fields;
* 6 bytes for ETX metric object (4 bytes header + 2 bytes body);
* 6 bytes for ETX constraint object (4 bytes header + 2 bytes
body).
Thus, the total length of such a DIO is 89 bytes.
The same message, when compressed in the manner described in this
document, consists of:
o 5 bytes of IPv6 header compressed as per [I-D.ietf-6lowpan-hc];
o 4 bytes for ICMP Type, Code and Checksum fields;
o 4 bytes of compressed DIO Base Object consisting of 2 bytes of
header and 2 bytes for DODAGID (the best case scenario);
o 3 bytes of compressed DODAG Configuration Option, including 2
bytes for Type and Option Length fields;
o 26 bytes of Route Information Option;
o 8 bytes for Metric Container consisting of:
* 2 bytes for Type and Option Length fields;
* 3 bytes for ETX metric object (1 byte header + 2 bytes body);
* 3 bytes for ETX constraint object (1 byte header + 2 bytes
body).
Thus, the total length of the compressed DIO is 50 bytes.
Goyal, et al. Expires November 29, 2011 [Page 13]
Internet-Draft draft-goyal-roll-rpl-compression-00 May 2011
6. Security Considerations
TBA
7. IANA Considerations
TBA
8. References
8.1. Normative References
[I-D.ietf-roll-routing-metrics]
Vasseur, J., Kim, M., Pister, K., Dejean, N., and D.
Barthel, "Routing Metrics used for Path Calculation in Low
Power and Lossy Networks",
draft-ietf-roll-routing-metrics-19 (work in progress),
March 2011.
[I-D.ietf-roll-rpl]
Winter, T., Thubert, P., Brandt, A., Clausen, T., Hui, J.,
Kelsey, R., Levis, P., Pister, K., Struik, R., and J.
Vasseur, "RPL: IPv6 Routing Protocol for Low power and
Lossy Networks", draft-ietf-roll-rpl-19 (work in
progress), March 2011.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
8.2. Informative References
[I-D.ietf-6lowpan-hc]
Hui, J. and P. Thubert, "Compression Format for IPv6
Datagrams in Low Power and Lossy Networks (6LoWPAN)",
draft-ietf-6lowpan-hc-15 (work in progress),
February 2011.
[I-D.ietf-roll-of0]
Thubert, P., "RPL Objective Function 0",
draft-ietf-roll-of0-12 (work in progress), May 2011.
[I-D.ietf-roll-p2p-rpl]
Goyal, M., Baccelli, E., Brandt, A., Cragie, R., and J.
Martocci, "Reactive Discovery of Point-to-Point Routes in
Low Power and Lossy Networks", draft-ietf-roll-p2p-rpl-03
(work in progress), May 2011.
Goyal, et al. Expires November 29, 2011 [Page 14]
Internet-Draft draft-goyal-roll-rpl-compression-00 May 2011
[I-D.ietf-roll-terminology]
Vasseur, J., "Terminology in Low power And Lossy
Networks", draft-ietf-roll-terminology-05 (work in
progress), March 2011.
Authors' Addresses
Mukul Goyal (editor)
University of Wisconsin Milwaukee
3200 N Cramer St
Milwaukee, WI 53211
USA
Phone: +1 414 2295001
Email: mukul@uwm.edu
Emmanuel Baccelli
INRIA
Phone: +33-169-335-511
Email: Emmanuel.Baccelli@inria.fr
URI: http://www.emmanuelbaccelli.org/
Matthias Philipp
INRIA
Email: matthias.philipp@inria.fr
Anders Brandt
Sigma Designs
Phone: +45-29609501
Email: abr@sdesigns.dk
Jerald Martocci
Johnson Controls
Phone: +1-414-524-4010
Email: jerald.p.martocci@jci.com
Goyal, et al. Expires November 29, 2011 [Page 15]