ROLL Working Group N. Dejean Internet-Draft Elster SAS Intended status: Standards Track D. Barthel Expires: September 8, 2011 France Telecom Orange March 7, 2011 Selective DIS for RPL draft-dejean-roll-selective-dis-00 Abstract This document specifies DIS options that enrich the potential behavior of the Routing Protocol for Low Power and Lossy Networks (RPL) specified in [I-D.ietf-roll-rpl]. The goal is to enable new leaf nodes to quickly discover and attach to the routing structure, without having to wait for spontaneous DIO transmissions by neighbour routers and without causing them to reset their DIO timers. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Status of this Memo This Internet-Draft is submitted 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 September 8, 2011. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. Dejean & Barthel Expires September 8, 2011 [Page 1] Internet-Draft draft-dejean-roll-selective-dis-00 March 2011 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 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 2. Leaf Node bit . . . . . . . . . . . . . . . . . . . . . . . . 4 3. DIS Options . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Metric Container . . . . . . . . . . . . . . . . . . . . . 5 3.2. Response Spreading . . . . . . . . . . . . . . . . . . . . 5 4. Example of use . . . . . . . . . . . . . . . . . . . . . . . . 6 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 5.1. DIS Flag Field . . . . . . . . . . . . . . . . . . . . . . 9 5.2. RPL Control Message Options . . . . . . . . . . . . . . . 9 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 8.1. Normative references . . . . . . . . . . . . . . . . . . . 9 8.2. Informative references . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 Dejean & Barthel Expires September 8, 2011 [Page 2] Internet-Draft draft-dejean-roll-selective-dis-00 March 2011 1. Introduction This document makes use of the terminology defined in [I-D.ietf-roll-terminology]. Low power and Lossy Networks (LLNs) have specific routing characteristics compared with traditional wired or ad-hoc networks that have been spelled out in [RFC5548], [RFC5673], [RFC5826] and [RFC5867]. [I-D.ietf-roll-rpl] has specified the minimally viable core of mechanisms for a routing protocol, called Routing Protocol for Low Power and Lossy Networks (RPL), specifically designed for LLNs. This document specifies DIS options that enrich the behavior of RPL and that were left out of [I-D.ietf-roll-rpl] in the interest of time. The goal is to enable new leaf nodes to quickly discover and attach to the routing structure, without having to wait for spontaneous DIO transmissions by neighbour routers and without causing them to reset their DIO timers. Indeed, with RPL as defined in [I-D.ietf-roll-rpl], a leaf node that wants to join an already deployed LLN is confronted with the following dilemna: o It can either wait for DIOs to be sent by neighbor routers. These transmissions may happen after a very long time, since the Trickle timers of the neighbor routers may have increased their period to a very large value, in order to save energy in a stable network. Furthermore, the transmission of a DIO packet by a neighbor router is not even guaranteed to happen during a Trickle timer period, since transmission suppression may happen (see [I-D.ietf-roll-trickle]). o Or it elects to proactively send a DIS (DODAG Information Sollicitation). This DIS can only be sent in broadcast, since the new node does know which router to ask for. Under the specification of [I-D.ietf-roll-rpl], all routers that receive a broadcast DIS packet will reset their Trickle timer. The time to their next spontaneous DIO transmission will indeed be dramatically shortened, which is desirable, although it will not prevent potential transmission suppression. But an undesired effect is that this will induce a large energy consumption in the network for two compounding reasons: first, all neighbour routeurs will respond, irrespective of their relevance to the new node, and second, each neighbor router will send frequent DIOs until its Dejean & Barthel Expires September 8, 2011 [Page 3] Internet-Draft draft-dejean-roll-selective-dis-00 March 2011 Trickle timer relaxes to the maximum period, even though only the first DIO is useful. None of the choices above matches the requirements of [RFC5548]. This document defines a way to broadcast a DIS message that includes selective options and a flag in order to query responses by neighbor routers such that: o responses are sent promptly, reducing the time the technician has to sit waiting at the customer premises to check the result of the joining process o responses are DIOs sent using unicast, reducing the overhearing energy cost in the router neighborhood when modern MAC technologies are used o each neighbor router only responds with a single DIO for each DIS, reducing the reception cost at the destination o the DIO is only sent if the neighbor router matches the criteria specified in the DIS selective options, reducing the reception, collision and overhearing energy costs Admitedly, requesting an unknown population of neighbor routers to promptly send even a single DIO may be a cause for multiple collisions. This risk is mitigated by the use of good access contention methods at the link layer and by the wise use of the DIS options. However, both conditions are beyond the control of this specification. This document therefore specifies an optional collision mitigation mechanism of its own. 2. Leaf Node bit In the format of the DIS base object, bit 0 of the Flag field is defined as the "Leaf Node" bit. Dejean & Barthel Expires September 8, 2011 [Page 4] Internet-Draft draft-dejean-roll-selective-dis-00 March 2011 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |L| Flags | Reserved | Option(s)... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: The DIS Base Object A node that receives a DIS with the "Leaf Node" bit set MUST NOT reset its DIO Trickle timer, even if it matches the options carried by the DIS. A node that receives a DIS message with the "Leaf Node" bit set and that matches the options carried in the DIS MUST reply with a unicast DIO, using the mechanism described in Section 3.2. 3. DIS Options 3.1. Metric Container In addition to those already listed in [I-D.ietf-roll-rpl], the following option is declared valid for a DIS message: 0x02 Metric Container A node that receives a DIS with a Metric Container option MUST ignore any Metric object in it, and MUST parse the Contraint objects in it, if any. The constraint values are compared to the values of the corresponding metrics known to the node. If both a Solicited Information option and a Metric Container option are present in a DIS message, they combine in a logical AND fashion, i.e. all predicates MUST match for the DIS to globally match. If a Constraint objects carries a constraint for a metric the value of which is unknown to the node, it is RECOMMENDED that the node considers the constraint a match. 3.2. Response Spreading With a wise use of the DIS options, our experience is that the population of responding routers is small enough for modern medium access techniques to efficiently resolve contention at the link layer. However, for those systems in which either above-mentioned postulate can't be met, an optional DIO response spreading mechanism is specified here. A new RPL control message option is defined, called "Response Dejean & Barthel Expires September 8, 2011 [Page 5] Internet-Draft draft-dejean-roll-selective-dis-00 March 2011 Spreading", with a recommended Type value of 0x0A (to be confirmed by IANA). Its format complies with the general format of RPL options, and is described in Figure 2. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 0x0A | Length | Spread. Inter.| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: The Response Spreading option A node that responds to a broadcast DIS in observance of Section 2 MUST, if that DIS includes a Response Spreading option, wait for a time uniformely drawn in the interval [O..2^SpreadingInterval], expressed in ms, before attempting to transmit its DIO. If the DIS does not include a Response Spreading option, the node is free to transmit the DIO as it otherwise would. 4. Example of use A new leaf node that joins an established network runs an iterative algorithm by which it requests (using broadcast) network information from routers belonging to the desired network ID and which match some constraint values passed as parameters of the request. At each unsuccessful iteration, the requirements are relaxed, until one or several answers are received, or until the maximum number of iterations is reached. The answers from the routers can advantageously contain the values for other metrics than those by which the request was qualified, so that the router selection takes place based on more metrics. The following example shows requests iterating on two constraint values (on Hop Count and Link Quality Level) and makes use of a third metric value (Node Energy) provided into the answers. With Hop Count iterating through four different values (0-3) and Link Quality Level iterating through three possible values (2,4,6), a maximum of twelve DIS packets can be broadcast per joining node, in the following order: o Soliciting info from routers with max Hop Count 0 and max LQL 2 o Soliciting info from routers with max Hop Count 0 and max LQL 4 Dejean & Barthel Expires September 8, 2011 [Page 6] Internet-Draft draft-dejean-roll-selective-dis-00 March 2011 o Soliciting info from routers with max Hop Count 0 and max LQL 6 o Soliciting info from routers with max Hop Count 1 and max LQL 2 o Soliciting info from routers with max Hop Count 1 and max LQL 4 o Soliciting info from routers with max Hop Count 1 and max LQL 6 o Soliciting info from routers with max Hop Count 2 and max LQL 2 o Soliciting info from routers with max Hop Count 2 and max LQL 4 o Soliciting info from routers with max Hop Count 2 and max LQL 6 o Soliciting info from routers with max Hop Count 3 and max LQL 2 o Soliciting info from routers with max Hop Count 3 and max LQL 4 o Soliciting info from routers with max Hop Count 3 and max LQL 6 Receiving any answer stops the iteration. Per our example, the new node then selects its parent router, based on the Node Energy and the Link Quality Level, according to the following algorithm: o Reject router(s) with asymmetric connectivity (LQL seen from new node does not match the constraint value issued in the DIS request) o Retain the router(s) that advertise the best Node Energy level o In case of equality, select the router that boasts the best Link Quality Level. Dejean & Barthel Expires September 8, 2011 [Page 7] Internet-Draft draft-dejean-roll-selective-dis-00 March 2011 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 155 | 0x00 | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DIS BASE | Solicited Information | |L| Flags | Reserved | Type | Opt Length | |1| 0 | 0x00 | 7 | 19 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Solicited Information | | RPLInstanceID |V|I|D| Flags | DODAG ID | | =0x66 |0|1|0| 0 | 0x0000 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Solicited Information | | DODAG ID | | 0x00000000 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Solicited Information | | DODAG ID | | 0x00000000 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Solicited Information | | DODAG ID | | 0x00000000 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Solicited Information |MetricContainer| | DODAG ID |Version Number | Type | | 0x0000 | 0x00 | 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Metric Container | | Opt Length |Routing-MC-Type|Res Flags|P|C|O|R| A | Prec | | 12 | 3 (HC) | 0 |0|1|0|0| 000 | 000 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Metric Container | | Length (bytes)| Res | Flags | Hop Count |Routing-MC-Type| | 2 | 0 | 0 | 0 | 6 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Metric Container | |Res Flags|P|C|O|R| A | Prec | Length (bytes)| Res | | 0 |0|1|0|0| 000 | 000 | 2 | 0x00 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |MetricContainer| | Val | Counter | | 2 | 0 | +-+-+-+-+-+-+-+-+ Packet dump of DIS with Hop Count = 0, LQL <= 2 Dejean & Barthel Expires September 8, 2011 [Page 8] Internet-Draft draft-dejean-roll-selective-dis-00 March 2011 5. IANA Considerations 5.1. DIS Flag Field IANA is requested to allocate bit O of the DIS Flag Field to become the "Leaf Node" bit, the functionality of which is described in Section 2 of this document. Value Meaning Reference 0 Leaf Node This document 5.2. RPL Control Message Options IANA is requested to allocate a new code point in the "RPL Control Message Options" registry for the "Response Spreading" option, the behavior of which is described in Section 3.2. +-------+-----------------------+---------------+ | Value | Meaning | Reference | +-------+-----------------------+---------------+ | 0x0A | Response Spreading | This document | +-------+-----------------------+---------------+ RPL Control Message Options 6. Security Considerations 7. Acknowledgements 8. References 8.1. Normative references [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-18 (work in progress), February 2011. [I-D.ietf-roll-trickle] Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko, "The Trickle Algorithm", draft-ietf-roll-trickle-08 (work Dejean & Barthel Expires September 8, 2011 [Page 9] Internet-Draft draft-dejean-roll-selective-dis-00 March 2011 in progress), January 2011. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. 8.2. Informative references [I-D.ietf-roll-terminology] Vasseur, J., "Terminology in Low power And Lossy Networks", draft-ietf-roll-terminology-04 (work in progress), September 2010. [RFC5548] Dohler, M., Watteyne, T., Winter, T., and D. Barthel, "Routing Requirements for Urban Low-Power and Lossy Networks", RFC 5548, May 2009. [RFC5673] Pister, K., Thubert, P., Dwars, S., and T. Phinney, "Industrial Routing Requirements in Low-Power and Lossy Networks", RFC 5673, October 2009. [RFC5826] Brandt, A., Buron, J., and G. Porcu, "Home Automation Routing Requirements in Low-Power and Lossy Networks", RFC 5826, April 2010. [RFC5867] Martocci, J., De Mil, P., Riou, N., and W. Vermeylen, "Building Automation Routing Requirements in Low-Power and Lossy Networks", RFC 5867, June 2010. Authors' Addresses Nicolas Dejean Elster SAS Espace Concorde, 120 impasse JB Say Perols, 34470 France Email: nicolas.dejean@coronis.com Dejean & Barthel Expires September 8, 2011 [Page 10] Internet-Draft draft-dejean-roll-selective-dis-00 March 2011 Dominique Barthel France Telecom Orange 28 chemin du Vieux Chene, BP 98 Meylan, 38243 France Email: dominique.barthel@orange-ftgroup.com Dejean & Barthel Expires September 8, 2011 [Page 11]