idnits 2.17.1 draft-goyal-roll-metrics-direction-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 23, 2011) is 4811 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-19) exists of draft-ietf-roll-routing-metrics-17 == Outdated reference: A later version (-19) exists of draft-ietf-roll-rpl-18 == Outdated reference: A later version (-17) exists of draft-ietf-roll-p2p-rpl-02 == Outdated reference: A later version (-13) exists of draft-ietf-roll-terminology-04 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force M. Goyal, Ed. 3 Internet-Draft University of Wisconsin Milwaukee 4 Intended status: Experimental E. Baccelli 5 Expires: August 27, 2011 INRIA 6 J. Martocci 7 Johnson Controls 8 February 23, 2011 10 The Direction Field in Routing Metric/Constraint Objects Used in RPL 11 draft-goyal-roll-metrics-direction-00 13 Abstract 15 This document specifies a Direction field in the Routing Metric/ 16 Constraint objects used in RPL operation in low power and lossy 17 networks. 19 Status of this Memo 21 This Internet-Draft is submitted to IETF in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on August 27, 2011. 36 Copyright Notice 38 Copyright (c) 2011 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. The Direction Field . . . . . . . . . . . . . . . . . . . . . . 4 56 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 57 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 58 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 6.1. Normative References . . . . . . . . . . . . . . . . . . . 5 60 6.2. Informative References . . . . . . . . . . . . . . . . . . 5 61 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 63 1. Introduction 65 Asymmetric links are a common observation in low power and lossy 66 networks (LLNs) [sang_2010]. Many link-level routing metrics have a 67 directional aspect. Although such routing metrics can be defined in 68 a bidirectional manner so as to account for the link properties in 69 both directions, this is not always desirable. In the context of RPL 70 [I-D.ietf-roll-rpl], the IPv6 routing protocol for LLNs, it may be 71 necessary to measure a link-level routing metric in a particular 72 direction. For example, if the intent is to build a directional 73 acyclic graph (DAG) specifically for the purpose of low latency 74 communication to the DAG root, the routing metric must measure the 75 link latency in Up direction, i.e., towards the DAG root, as defined 76 in [I-D.ietf-roll-rpl]. Similarly, if a temporary DAG is being 77 constructed to discover a point-to-point route towards a destination 78 [I-D.ietf-roll-p2p-rpl], the routing metric must calculate the 79 relevant link characteristic in Down direction, i.e., away from the 80 DAG root, as defined in [I-D.ietf-roll-rpl]. Thus, there is a need 81 to specify the directional aspect of a link-level routing metric. 83 Accordingly, this document defines a Direction field inside the 84 Routing Metric/Constraint object header, defined in 85 [I-D.ietf-roll-routing-metrics]. The Direction field is defined in 86 two previously reserved bits inside the Routing Metric/Constraint 87 object header. The modified Routing Metric/Constraint object header 88 is backward compatible with its definition in 89 [I-D.ietf-roll-routing-metrics]. 91 2. Terminology 93 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 94 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 95 "OPTIONAL" in this document are to be interpreted as described in 96 [RFC2119]. 98 Additionally, this document uses terminology from 99 [I-D.ietf-roll-terminology] and [I-D.ietf-roll-rpl]. Specifically, 100 the term RPL node refers to an RPL router or an RPL host as defined 101 in [I-D.ietf-roll-rpl]. 103 3. The Direction Field 105 0 1 2 3 106 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 107 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 108 |Routing-MC-Type| Res | D |P|C|O|R| A | Prec | Length | 109 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 110 | | 111 // (object body) | 112 | | 113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 115 Figure 1: Routing Metric/Constraint object generic format 117 The modified Routing Metric/Constraint object header is illustrated 118 in Figure 1. The Direction (or D) field is a 2-bit field that 119 indicates the direction associated with the routing metric/ 120 constraint: 122 o D = 0x00: undefined; 124 o D = 0x01: Up; 126 o D = 0x02: Down; 128 o D = 0x03: Bidirectional. 130 If the D field has value 0x00, the direction associated with the 131 routing metric/constraint is undefined as in 132 [I-D.ietf-roll-routing-metrics]. A value 0x00 for the D field may be 133 suitable for node-level routing metrics/constraints defined in 134 [I-D.ietf-roll-routing-metrics]. The D field value in link-level 135 routing metrics/constraints SHOULD NOT be set to 0x00. 137 This document does not specify how to measure/evaluate a routing 138 metric/constraint object in the direction specified by the D field. 139 The measurement/evaluation methodology for specific routing metrics/ 140 constraints, taking in account the D field, may be specified in a 141 separate document. 143 A routing metric/constraint object MUST be measured/evaluated in 144 accordance with its D field value if defined. In case, an RPL node 145 can not measure/evaluate the routing metric/constraint object in the 146 specified direction, the following rules MUST be applied: 148 o If the object is a recorded metric, i.e., has C=0 and R=1 fields, 149 the RPL node MUST set the P flag inside the object, thereby 150 indicating the partial nature of the recorded metric. 152 o If the object is an aggregated metric, i.e., has C=0 and R=0 153 fields, the RPL node MUST drop the DIO containing the object. 155 o If the object is a mandatory constraint, i.e., has C=1 and O=0 156 fields, the RPL node MUST drop the DIO containing the object. 158 o If the object is an optional constraint, i.e., has C=1 and O=1 159 fields, the RPL node MAY drop the DIO containing the object or it 160 MAY continue processing rest of the DIO ignoring this object. 162 4. Security Considerations 164 TBA 166 5. IANA Considerations 168 This document does not have any IANA considerations. 170 6. References 172 6.1. Normative References 174 [I-D.ietf-roll-routing-metrics] 175 Vasseur, J., Kim, M., Pister, K., Dejean, N., and D. 176 Barthel, "Routing Metrics used for Path Calculation in Low 177 Power and Lossy Networks", 178 draft-ietf-roll-routing-metrics-17 (work in progress), 179 January 2011. 181 [I-D.ietf-roll-rpl] 182 Winter, T., Thubert, P., Brandt, A., Clausen, T., Hui, J., 183 Kelsey, R., Levis, P., Pister, K., Struik, R., and J. 184 Vasseur, "RPL: IPv6 Routing Protocol for Low power and 185 Lossy Networks", draft-ietf-roll-rpl-18 (work in 186 progress), February 2011. 188 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 189 Requirement Levels", BCP 14, RFC 2119, March 1997. 191 6.2. Informative References 193 [I-D.ietf-roll-p2p-rpl] 194 Goyal, M., Baccelli, E., Brandt, A., Cragie, R., Martocci, 195 J., and C. Perkins, "Reactive Discovery of Point-to-Point 196 Routes in Low Power and Lossy Networks", 197 draft-ietf-roll-p2p-rpl-02 (work in progress), 198 February 2011. 200 [I-D.ietf-roll-terminology] 201 Vasseur, J., "Terminology in Low power And Lossy 202 Networks", draft-ietf-roll-terminology-04 (work in 203 progress), September 2010. 205 [sang_2010] 206 Sang, L., Arora, A., and H. Zhang, "On Link Asymmetry and 207 One-way Estimation in Wireless Sensor Networks", ACM 208 Transactions on Sensor Networks Volume 6, Number 2, 209 February 2010. 211 Authors' Addresses 213 Mukul Goyal (editor) 214 University of Wisconsin Milwaukee 215 3200 N Cramer St 216 Milwaukee, WI 53201 217 USA 219 Phone: +1 414 2295001 220 Email: mukul@uwm.edu 222 Emmanuel Baccelli 223 INRIA 225 Phone: +33-169-335-511 226 Email: Emmanuel.Baccelli@inria.fr 227 URI: http://www.emmanuelbaccelli.org/ 229 Jerald Martocci 230 Johnson Controls 231 507 E Michigan St 232 Milwaukee, WI 53202 233 USA 235 Phone: +1 414-524-4010 236 Email: jerald.p.martocci@jci.com