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]