idnits 2.17.00 (12 Aug 2021) /tmp/idnits24225/draft-svshah-tsvwg-lln-diffserv-recommendations-04.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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 468 has weird spacing: '... |Alert signa...' == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 03, 2015) is 2657 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 559, but no explicit reference was found in the text == Unused Reference: 'RFC5127' is defined on line 566, but no explicit reference was found in the text == Unused Reference: 'RFC5548' is defined on line 569, but no explicit reference was found in the text == Unused Reference: 'RFC5826' is defined on line 577, but no explicit reference was found in the text == Unused Reference: 'RFC5867' is defined on line 581, but no explicit reference was found in the text == Unused Reference: 'RFC2474' is defined on line 592, but no explicit reference was found in the text == Unused Reference: 'RFC2475' is defined on line 597, but no explicit reference was found in the text == Unused Reference: 'RFC6272' is defined on line 601, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 11 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Shah 3 Internet-Draft P. Thubert 4 Intended status: Informational Cisco Systems 5 Expires: August 7, 2015 February 03, 2015 7 Differentiated Service Class Recommendations for LLN Traffic 8 draft-svshah-tsvwg-lln-diffserv-recommendations-04 10 Abstract 12 Differentiated services architecture is widely deployed in 13 traditional networks. There exist well defined recommendations for 14 the use of appropriate differentiated service classes for different 15 types of traffic (eg. audio, video) in these networks. Per-Hop 16 Behaviors are typically defined based on this recommendations. With 17 emerging Low-power and Lossy Networks (LLNs), it is important to have 18 similar defined differentiated services recommendations for LLN 19 traffic. Defined recommendations are for LLN class of traffic 20 exiting out of LLNs towards high-speed backbones, converged campus 21 network and for the traffic in the reverse direction. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on August 7, 2015. 40 Copyright Notice 42 Copyright (c) 2015 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 This document may contain material from IETF Documents or IETF 56 Contributions published or made publicly available before November 57 10, 2008. The person(s) controlling the copyright in some of this 58 material may not have granted the IETF Trust the right to allow 59 modifications of such material outside the IETF Standards Process. 60 Without obtaining an adequate license from the person(s) controlling 61 the copyright in such materials, this document may not be modified 62 outside the IETF Standards Process, and derivative works of it may 63 not be created outside the IETF Standards Process, except to format 64 it for publication as an RFC or to translate it into languages other 65 than English. 67 Table of Contents 69 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 1.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5 71 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 72 3. Application Types and Traffic Patterns . . . . . . . . . . . . 6 73 3.1. Alert signals . . . . . . . . . . . . . . . . . . . . . . 6 74 3.2. Control signals . . . . . . . . . . . . . . . . . . . . . 7 75 3.2.1. Deterministic control signals . . . . . . . . . . . . 7 76 3.3. Monitoring data . . . . . . . . . . . . . . . . . . . . . 8 77 3.3.1. Video data . . . . . . . . . . . . . . . . . . . . . . 8 78 3.3.2. Query based data . . . . . . . . . . . . . . . . . . . 8 79 3.3.3. Periodic reporting/logging, Software downloads . . . . 8 80 3.4. Traffic Class Characteristics Table . . . . . . . . . . . 10 81 4. Differentiated Service recommendations for LLN traffic . . . . 10 82 4.1. Alert signals . . . . . . . . . . . . . . . . . . . . . . 10 83 4.2. Control signals . . . . . . . . . . . . . . . . . . . . . 11 84 4.2.1. Deterministic Control Signals . . . . . . . . . . . . 11 85 4.3. Monitoring Data . . . . . . . . . . . . . . . . . . . . . 11 86 4.3.1. Video Data . . . . . . . . . . . . . . . . . . . . . . 11 87 4.3.2. Query based data . . . . . . . . . . . . . . . . . . . 11 88 4.3.3. Periodic reporting/logging, Software downloads . . . . 11 89 4.4. Summary of Differentiated Code-points and QoS 90 Mechanics for them . . . . . . . . . . . . . . . . . . . . 12 91 5. Deployment Scenario . . . . . . . . . . . . . . . . . . . . . 12 92 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 93 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 94 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 95 8.1. Normative References . . . . . . . . . . . . . . . . . . . 14 96 8.2. Informative References . . . . . . . . . . . . . . . . . . 15 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 99 1. Introduction 101 With emerging LLN applications, it is anticipated that more and more 102 LLNs will be federated by high-speed backbones, possibly supporting 103 deterministic Ethernet service, and be further connected to some 104 converged campus networks for less demanding usages such as 105 supervisory control like traffic originated in a LLN, such as 106 metering, command and control, may transit over a converged campus IP 107 network. 109 ---+------------------------ 110 | Converged Campus Network 111 | 112 +-----+ 113 | | Gateway 114 | | 115 +-----+ 116 | 117 | Backbone 118 +--------------------+------------------+ 119 | | | 120 +-----+ +-----+ +-----+ 121 | | LLN border | | LLN border | | LLN border 122 o | | router | | router | | router 123 +-----+ +-----+ +-----+ 124 o o o o 125 o o o o o o o o o o o 126 o o o o o o o o o o o o o o o o o o 127 o o o o o o o o o o o o o o o o 128 o o M o o o o o o o o o o o o o 129 o o o o o o o o o 130 o o o o o 131 LLN 132 o : stationary wireless field device, seldom acting as an LLN router 134 In an example figure shown above, Per-Hop Behaviors (PHB) and Service 135 Level Agreements (SLAs), for LLN traffic, require to be defined at 136 the LLN Borders as well as Backbone and possibly in the Converged 137 Campus network. 139 In this document, we will first categorize different types of LLN 140 traffic into service classes and then provide recommendations for 141 Differentiated Service Code-Point(DSCP) for those service classes. 142 Mechanisms to be used, like Traffic Conditioning and Active Queue 143 Management, for differentiated services is well defined in RFC4594. 145 This document does not focus to re-call them again here but the 146 document will call out any specific mechanism that requires 147 particular consideration. 149 This document focuses on Diffserv recommendations for LLN class of 150 traffic in managed IP networks outside of LLNs, that is for the 151 traffic from LLN towards LLN Border, Backbone, Campus Network as well 152 as for the traffic in the reverse direction. It does not focus on 153 Diffserv architecture or any other QoS recommendations within the 154 LLNs itself. Given constraints of LLNs and their unique 155 requirements, it is expected of a focus within a separate efforts. 156 Though nodes inside LLNs MAY use code-points recommended here. 158 In Section 3 we categorize different types of traffic from Different 159 LLNs. Section 4 recommends differentiated services, including DSCPs 160 and QoS mechanics, for categorized classes of traffic. Section 5 161 evaluates one of the deployment scenario. 163 1.1. Definitions 165 DSCP: Differentiated Service Code Point. It is a 6-bits value in the 166 TOS and Traffic Class field of the IPv4 and IPv6 header 167 respectively. This 6-bits numerical value defines standard set 168 of behavior to be performed by Differentiated Services capable 169 hops. 171 Diffserv 172 Class: Diffser Class in this document is used to refer to DSCP code- 173 point(s) and associated Per-hop Behaviors for it. 175 LLN: Low-power and lossy Network. Network constructed with sensors, 176 actuators, routers that are low-power and with higher loss/ 177 success transmission ratio, due to transmission medium and 178 nature of dynamics of changing topology, compare to wired and 179 other traditional networks. 181 SLA: Service Level Agreement. It is a collection of Traffic 182 classification rules and set of services associated with each 183 Traffic Class. Traffic classification may be defined based 184 on just DSCP code-points or additionally (or otherwise) 185 based on some other packet attributes. 187 2. Terminology 189 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 190 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 191 document are to be interpreted as described in RFC2119. 193 3. Application Types and Traffic Patterns 195 Different types of traffic can be collapsed into following network 196 service classes. 198 - Alert signals 199 - Control signals 200 - Monitoring data 201 - Video data 202 - Query-based response data 203 - Periodic reporting/logging, Software downloads 205 3.1. Alert signals 207 Alerts/alarms reporting fall in this category where such signal is 208 triggered in a rare un-usual circumstances. An alert may be 209 triggered for an example when environmental hazard level goes beyond 210 certain threshold. Such alerts require to be reported with in the 211 human tolerable time. Note that certain critical alert reporting in 212 certain automation systems may be reported via very closely and 213 tightly managed method that is not implemented within LLNs, due to 214 the nature of transmission media of LLNs and due to the stringent 215 latency requirement for those alerts. Such types of signals are not 216 considered here since they are not within the scope of LLN or any 217 other IP networks. 219 Examples : 220 - Environmental hazard level goes beyond certain threshold 221 - Measured blood pressure exceeds the threshold or a person falls to 222 the ground 223 - Instructional triggers like start/stop traffic lights during 224 certain critical event 226 Traffic Pattern: 228 Typically size of such packets is very small. any specific device of 229 LLN is expected to trigger only handful of packets (may be only 1 230 packet). That too only during an event which is not a common 231 occurrence. 233 In an affected vicinity, only a designated device or each affected 234 devices may send alerts. In certain type of sensor networks, it is 235 predictable and expected to have only a designated device to trigger 236 such an alert while in certain other types scale number of alert 237 flows may be expected. 239 Latency required for such traffic is not stringent but is to be 240 within human tolerable time bound. 242 3.2. Control signals 244 Besides alerts, LLNs also trigger and/or receive different types of 245 control signals, to/from control applications outside of LLNs. These 246 control signals are important enough for the operation of sensors, 247 actuators and underneath network. Administrator controlling 248 applications, outside of LLN network, may trigger a control signal in 249 response to alerts/data received from LLN (in some cases control 250 signal trigger may be automated without explicit human interaction in 251 the loop) or administrator may trigger an explicit control signal for 252 a specific function. 254 Examples: 255 - auto [demand] response (e.g. manage peak load, service 256 disconnect, start/stop street lights) 257 - manual remote service disconnect, remote demand reset 259 - open-loop regulatory control 260 - non-critical close-loop regulatory control 261 - critical closed-loop control signals 262 - trigger to start Video surveillance 264 Traffic Pattern: 266 Variable size packets but typically size of such packets is small. 267 Certain control signals may be regular and so with number of devices 268 in a particular LLN, it is predictable on average, how many such 269 signals to expect. However, certain other control signals are 270 irregular or on-demand. 272 Typically most of the open-loop, that requires manual interaction, 273 signals are tolerant to latency above 1 second. Certain close-loop 274 control signals require low jitter and low latency, latency in the 275 order of 100s of ms. 277 3.2.1. Deterministic control signals 279 Some of the LLN applications, like Industrial automation, have class 280 of control signals that require very strict time scheduled service. 281 This traffic is very sensitive to jitter. Applications may be able 282 to handle a loss of packet or two but are very sensitive to jitter 283 and any delivery outside of the deterministic time schedule can have 284 expensive effects on the Network. Critical closed-loop control 285 signals example falls in this category. 287 Deterministic control signals are very sensitive to jitter. Scope of 288 such traffic is contained to LL Network and to the IP backbone 289 connecting to two or more such networks. This traffic is not 290 expected to be transmitted over Campus, WAN and Internet. 292 3.3. Monitoring data 294 Reaction to control signals may initiate flow of data-traffic in 295 either direction. Sensors/Actuators in LLNs may also trigger 296 periodic data (eg. monitoring, reporting data). All different types 297 of data may be categorized in following classes. 299 3.3.1. Video data 301 A very common example of this type of monitoring data is Video 302 surveillance or Video feed, triggered thru control signals. This 303 Video feed is typically from LLN towards an application outside of 304 LLN. 306 Traffic Pattern: 308 Video frame size is expected to be big with a flow of variable rate. 310 3.3.2. Query based data 312 Application at the controller, outside the LLN, or user explicitly 313 may launch query for the data. For example, query for an urban 314 environmental data, query for health report etc. Since this data is 315 query based data, it is important to report data with reasonable 316 latency though not stringent. In addition, some periodic logging 317 data also may require timely reporting and so may expect same type of 318 service (eg. at-home health reporting). 320 Traffic Pattern: 322 Size of packets can vary from small to big. While rate may be 323 predictable in some cases, in most of the cases traffic rate for such 324 data is variable. The traffic is bursty in the nature. 326 3.3.3. Periodic reporting/logging, Software downloads 328 Many sensors/actuator in different LLNs report data periodically. 329 With some exceptions, as mentioned above for healthcare monitoring 330 logs, most of such data do not have any latency requirement and can 331 be forwarded either thru lower priority assured forwarding or with 332 service of store and forward or even best effort. 334 Sensors/actuators may require software/firmware upgrades where 335 software/ firmware may be downloaded on demand bases. These upgrades 336 and so downloads do not have stringent requirement of timely delivery 337 to the accuracy of seconds. This data also can be forwarded thru 338 lower priority assured forwarding. 340 Traffic Pattern: 342 Periodic reporting/logging typically can be predicated as constant 343 rate. Data may be bursty in the nature. Software download data also 344 may be bursty in nature. Such traffic is tolerant to jitter and 345 latency. 347 3.4. Traffic Class Characteristics Table 349 ------------------------------------------------------------------- 350 |Traffic Class | | Tolerance to | 351 | Name | Traffic Characteristics | Loss |Delay |Jitter| 352 |===============+==============================+======+======+======| 353 | Alerts/ |Packet size = small | Low |Low | N/A | 354 | alarms |Rate = typically 1-few packets| | | | 355 | |Short lived flow | | | | 356 | |Burst = none to some-what | | | | 357 |---------------+------------------------------+------+------+------| 358 | Control |Packet size = variable, | Yes |Low | Yes | 359 | Signals | typically small | | | | 360 | |Rate = few packets | | | | 361 | |Short lived flow | | | | 362 | |Burst = none to some-what | | | | 363 |---------------+------------------------------+------+------+------| 364 | Deterministic |Packet size = variable, | Low |Very | Very | 365 | Control | typically small | |Low | Low | 366 | Signals |Rate = few packets | | | | 367 | |Short lived flow | | | | 368 | |Burst = none to some-what | | | | 369 |---------------+------------------------------+------+------+------| 370 | Video |Packet size = big | Low |Low - | Low | 371 |Monitoring/feed|Rate = variable | |Medium| | 372 | |Long lived flow | | | | 373 | |Burst = non-bursty | | | | 374 |---------------+------------------------------+------+------+------| 375 | Query-based |Packet size = variable | Low |Medium| Yes | 376 | Data |Rate = variable | | | | 377 | |Short lived elastic flow | | | | 378 | |Burst = bursty | | | | 379 |---------------+------------------------------+------+------+------| 380 | Periodic |variable packet size, rate | Yes |Medium| Yes | 381 |Reporting/log, |bursty | |- High| | 382 | Software | | | | | 383 | downloads | | | | | 384 ------------------------------------------------------------------- 386 4. Differentiated Service recommendations for LLN traffic 388 4.1. Alert signals 390 Alerts/alarms signaling service requires transmission of few packets 391 with low delay, tolerable to human. This requirement is very similar 392 to signaling traffic in the traditional networks. Alert signals MAY 393 use Diffserv code-point CS5. 395 4.2. Control signals 397 As described in earlier section, control signals over IP are divided 398 in two categories. Control signals that require deterministic 399 forwarding service, and control signals that require relatively low 400 delay. Service requirement for later class of control signals is 401 very similar to service for signaling traffic in the traditional 402 networks. Recommendation for this class of control signals is to use 403 Diffserv code-point CS5. 405 4.2.1. Deterministic Control Signals 407 PHB for this class of traffic is defined as forwarding of a packet at 408 determined/scheduled time providing no jitter service. 410 Recommended DSCP code-point for this class of traffic is EF. Since 411 this class of traffic is not expected to co-exist with voice like 412 traffic, that implements EF code-point as used in traditional Campus 413 and WAN networks, the same code-point is re-used here for the purpose 414 of deterministic control signals. However, a note to be made for 415 defined PHB for this code-point as deterministic forwarding behavior 416 as defined in this document. 418 Scheduling MUST pre-empt service of any other class of traffic during 419 the scheduled time for this class of traffic. 421 4.3. Monitoring Data 423 4.3.1. Video Data 425 RFC4594 has well documented recommendations for different types of 426 Video traffic. If there is any Video traffic from/to LLNs to/from 427 outside of LLNs, they should use same recommended dscp from RFC4594. 428 For example, surveillance video feed is recommended to use dscp CS3. 430 4.3.2. Query based data 432 Low latency data, like query based report and non-critical signals, 433 is recommended to use AF2 assured forwarding service. Also, certain 434 periodic reporting/logging data that are critical to be reported with 435 regular interval with relatively low jitter is recommended to use 436 AF2x service. 438 4.3.3. Periodic reporting/logging, Software downloads 440 Non-critical periodic reporting/logging and rest all other data MAY 441 use AF1x or BE service class. 443 4.4. Summary of Differentiated Code-points and QoS Mechanics for them 445 - Alert Signals CS5 447 - Control Signaling CS5 449 - Deterministic Control Signals EF 451 - Video broadcast/feed CS3 453 - Query-based data AF2x 455 - Assured monitoring data AF1x 456 high throughput 458 - Best Effort monitoring data BE 459 Reporting (periodic reporting.certain types of periodic monitoring 460 MAY require assured forwarding) 461 ------------------------------------------------------------------ 462 | Service | DSCP | Conditioning at | PHB | Queuing| AQM| 463 | Class | | DS Edge | Used | | | 464 |===============+======+===================+=========+========+====| 465 | Deterministic | EF | | |Time | No | 466 |control signals| |Police using sr+bs | |Schedule| | 467 |---------------+------+-------------------+---------+--------+----| 468 |Alert signals/| | | | | | 469 |Control signals| CS5 |Police using sr+bs | RFC2474 | Rate | No | 470 |---------------+------+-------------------+---------+--------+----| 471 | Video feed | CS3 |Police using sr+bs | RFC2474 | Rate | No | 472 |---------------+------+-------------------+---------+--------+----| 473 | Query- | AF21 | Using single-rate,| | | Yes| 474 | based | AF22 |three-color marker | RFC2597 | Rate | per| 475 | Data | AF23 | (such as RFC 2697)| | |DSCP| 476 |---------------+------+-------------------+---------+--------+----| 477 | Periodic | AF11 | Using two-rate, | | | Yes| 478 | Reporting/ | AF12 |three-color marker | RFC2597 | Rate | per| 479 | logging | AF13 | (such as RFC 2698)| | |DSCP| 480 ------------------------------------------------------------------ 481 * "sr+bs" represents a policing mechanism that provides single rate 482 with burst size control [RFC4594] 484 5. Deployment Scenario 486 Industrial Automation, as described in [RFC5673] and [ISA100.11a], 487 classifies different types of traffic in following six classes 488 ranging in complexity from Class 5 to Class 0 where Class 0 is the 489 most time sensitive class. 491 o Safety 493 * Class 0: Emergency action - Always a critical function 495 o Control 497 * Class 1: Closed-loop regulatory control - Often a critical 498 function 500 * Class 2: Closed-loop supervisory control - Usually a non- 501 critical function 503 * Class 3: Open-loop control - Operator takes action and controls 504 the actuator (human in the loop) 506 o Monitoring 508 * Class 4: Alerting - Short-term operational effect (for example, 509 event-based maintenance) 511 * Class 5: Logging and downloading / uploading - No immediate 512 operational consequence (e.g., history collection, sequence-of- 513 events, preventive maintenance) 515 It might not be appropriate to transport Class 0 traffic over a 516 wireless network or a multihop network, unless tight mechanisms are 517 put in place such as TDM and frequency hopping. Today this class of 518 traffic is expected to use other tightly managed method outside of 519 IP networks. Excluding class 0 traffic, following table maps Class 1 520 thru Class 5 service classes to Diffserv code-point. 522 ------------------------- 523 | Service | DSCP | 524 | Class | | 525 |===============+=========| 526 | Class 1 | EF | 527 +-------------------------+ 528 | Class 2 | CS5 | 529 +-------------------------+ 530 | Class 3 | CS5 | 531 +-------------------------+ 532 | Class 4 | AF2x | 533 +-------------------------+ 534 | class 5 | AF1x/BE | 535 +-------------------------+ 537 6. Security Considerations 539 A typical trust model, as much is applicable in traditional networks, 540 is applicable with LLN traffic as well. At the border of the LLN, a 541 trust model needs to be established for any traffic coming out of 542 LLN. Without appropriate trust model to accept/mark dscp code-point 543 for LLN traffic, misbehaving flow may attack a specific Diffserv 544 class disrupting expected service for other traffic from the same 545 Diffserv class. Trust models are typically established at the border 546 router by employing rate-limiting and even marking down dscp code- 547 point to Best Effort for non-trusted flows or dropping them as 548 required. 550 7. Acknowledgements 552 Thanks to Fred Baker, James Polk for their valuable comments and 553 suggestions. 555 8. References 557 8.1. Normative References 559 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 560 Requirement Levels", BCP 14, RFC 2119, March 1997. 562 [RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration 563 Guidelines for DiffServ Service Classes", RFC 4594, 564 August 2006. 566 [RFC5127] Chan, K., Babiarz, J., and F. Baker, "Aggregation of 567 Diffserv Service Classes", RFC 5127, February 2008. 569 [RFC5548] Dohler, M., Watteyne, T., Winter, T., and D. Barthel, 570 "Routing Requirements for Urban Low-Power and Lossy 571 Networks", RFC 5548, May 2009. 573 [RFC5673] Pister, K., Thubert, P., Dwars, S., and T. Phinney, 574 "Industrial Routing Requirements in Low-Power and Lossy 575 Networks", RFC 5673, October 2009. 577 [RFC5826] Brandt, A., Buron, J., and G. Porcu, "Home Automation 578 Routing Requirements in Low-Power and Lossy Networks", 579 RFC 5826, April 2010. 581 [RFC5867] Martocci, J., De Mil, P., Riou, N., and W. Vermeylen, 582 "Building Automation Routing Requirements in Low-Power and 583 Lossy Networks", RFC 5867, June 2010. 585 8.2. Informative References 587 [ISA100.11a] 588 ISA, "ISA-100.11a-2011 - Wireless systems for industrial 589 automation: Process control and related applications", 590 May 2011. 592 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 593 "Definition of the Differentiated Services Field (DS 594 Field) in the IPv4 and IPv6 Headers", RFC 2474, 595 December 1998. 597 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 598 and W. Weiss, "An Architecture for Differentiated 599 Services", RFC 2475, December 1998. 601 [RFC6272] Baker, F. and D. Meyer, "Internet Protocols for the Smart 602 Grid", RFC 6272, June 2011. 604 Authors' Addresses 606 Shitanshu Shah 607 Cisco Systems 608 170 W. Tasman Drive 609 San Jose, CA 95134 610 US 612 Email: svshah@cisco.com 614 Pascal Thubert 615 Cisco Systems 616 Village d'Entreprises Green Side 617 400, Avenue de Roumanille 618 Batiment T3 619 Biot - Sophia Antipolis 06410 620 FRANCE 622 Email: pthubert@cisco.com