idnits 2.17.00 (12 Aug 2021) /tmp/idnits3244/draft-svshah-tsvwg-lln-diffserv-recommendations-03.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 460 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 (August 14, 2014) is 2837 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'DF-PHB' is mentioned on line 410, but not defined == Unused Reference: 'RFC2119' is defined on line 551, but no explicit reference was found in the text == Unused Reference: 'RFC5127' is defined on line 558, but no explicit reference was found in the text == Unused Reference: 'RFC5548' is defined on line 561, but no explicit reference was found in the text == Unused Reference: 'RFC5826' is defined on line 569, but no explicit reference was found in the text == Unused Reference: 'RFC5867' is defined on line 573, but no explicit reference was found in the text == Unused Reference: 'DFPHB' is defined on line 577, but no explicit reference was found in the text == Unused Reference: 'RFC2474' is defined on line 588, but no explicit reference was found in the text == Unused Reference: 'RFC2475' is defined on line 593, but no explicit reference was found in the text == Unused Reference: 'RFC6272' is defined on line 597, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 13 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: February 15, 2015 August 14, 2014 7 Differentiated Service Class Recommendations for LLN Traffic 8 draft-svshah-tsvwg-lln-diffserv-recommendations-03 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 February 15, 2015. 40 Copyright Notice 42 Copyright (c) 2014 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 70 1.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4 71 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 72 3. Application Types and Traffic Patterns . . . . . . . . . . . 5 73 3.1. Alert signals . . . . . . . . . . . . . . . . . . . . . . 5 74 3.2. Control signals . . . . . . . . . . . . . . . . . . . . . 6 75 3.2.1. Deterministic control signals . . . . . . . . . . . . 6 76 3.3. Monitoring data . . . . . . . . . . . . . . . . . . . . . 7 77 3.3.1. Video data . . . . . . . . . . . . . . . . . . . . . 7 78 3.3.2. Query based data . . . . . . . . . . . . . . . . . . 7 79 3.3.3. Periodic reporting/logging, Software downloads . . . 8 80 3.4. Traffic Class Characteristics Table . . . . . . . . . . . 8 81 4. Differentiated Service recommendations for LLN traffic . . . 9 82 4.1. Alert signals . . . . . . . . . . . . . . . . . . . . . . 9 83 4.2. Control signals . . . . . . . . . . . . . . . . . . . . . 10 84 4.2.1. Deterministic Control Signals . . . . . . . . . . . . 10 85 4.3. Monitoring Data . . . . . . . . . . . . . . . . . . . . . 10 86 4.3.1. Video Data . . . . . . . . . . . . . . . . . . . . . 10 87 4.3.2. Query based data . . . . . . . . . . . . . . . . . . 10 88 4.3.3. Periodic reporting/logging, Software downloads . . . 10 89 4.4. Summary of Differentiated Code-points and QoS Mechanics 90 for them . . . . . . . . . . . . . . . . . . . . . . . . 10 91 5. Deployment Scenario . . . . . . . . . . . . . . . . . . . . . 11 92 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 93 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 94 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 95 8.1. Normative References . . . . . . . . . . . . . . . . . . 13 96 8.2. Informative References . . . . . . . . . . . . . . . . . 14 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 100 1. Introduction 102 With emerging LLN applications, it is anticipated that more and more 103 LLNs will be federated by high-speed backbones, possibly supporting 104 deterministic Ethernet service, and be further connected to some 105 converged campus networks for less demanding usages such as 106 supervisory control like traffic originated in a LLN, such as 107 metering, command and control, may transit over a converged campus IP 108 network. 110 ---+------------------------ 111 | Converged Campus Network 112 | 113 +-----+ 114 | | Gateway 115 | | 116 +-----+ 117 | 118 | Backbone 119 +--------------------+------------------+ 120 | | | 121 +-----+ +-----+ +-----+ 122 | | LLN border | | LLN border | | LLN border 123 o | | router | | router | | router 124 +-----+ +-----+ +-----+ 125 o o o o 126 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 o o 128 o o o o o o o o o o o o o o o o 129 o o M o o o o o o o o o o o o o 130 o o o o o o o o o 131 o o o o o 132 LLN 133 o : stationary wireless field device, seldom acting as an LLN router 135 In an example figure shown above, Per-Hop Behaviors (PHB) and Service 136 Level Agreements (SLAs), for LLN traffic, require to be defined at 137 the LLN Borders as well as Backbone and possibly in the Converged 138 Campus network. 140 In this document, we will first categorize different types of LLN 141 traffic into service classes and then provide recommendations for 142 Differentiated Service Code-Point(DSCP) for those service classes. 144 Mechanisms to be used, like Traffic Conditioning and Active Queue 145 Management, for differentiated services is well defined in RFC4594. 146 This document does not focus to re-call them again here but the 147 document will call out any specific mechanism that requires 148 particular consideration. 150 This document focuses on Diffserv recommendations for LLN class of 151 traffic in managed IP networks outside of LLNs, that is for the 152 traffic from LLN towards LLN Border, Backbone, Campus Network as well 153 as for the traffic in the reverse direction. It does not focus on 154 Diffserv architecture or any other QoS recommendations within the 155 LLNs itself. Given constraints of LLNs and their unique 156 requirements, it is expected of a focus within a separate efforts. 157 Though nodes inside LLNs MAY use code-points recommended here. 159 In Section 3 we categorize different types of traffic from Different 160 LLNs. Section 4 recommends differentiated services, including DSCPs 161 and QoS mechanics, for categorized classes of traffic. Section 5 162 evaluates one of the deployment scenario. 164 1.1. Definitions 166 DSCP: Differentiated Service Code Point. It is a 6-bits value in the 167 TOS and Traffic Class field of the IPv4 and IPv6 header 168 respectively. This 6-bits numerical value defines standard set 169 of behavior to be performed by Differentiated Services capable 170 hops. 172 Diffserv 173 Class: Diffser Class in this document is used to refer to DSCP code- 174 point(s) and associated Per-hop Behaviors for it. 176 LLN: Low-power and lossy Network. Network constructed with sensors, 177 actuators, routers that are low-power and with higher loss/ 178 success transmission ratio, due to transmission medium and 179 nature of dynamics of changing topology, compare to wired and 180 other traditional networks. 182 SLA: Service Level Agreement. It is a collection of Traffic 183 classification rules and set of services associated with each 184 Traffic Class. Traffic classification may be defined based 185 on just DSCP code-points or additionally (or otherwise) 186 based on some other packet attributes. 188 2. Terminology 190 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 191 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 192 document are to be interpreted as described in RFC2119. 194 3. Application Types and Traffic Patterns 196 Different types of traffic can be collapsed into following network 197 service classes. 199 - Alert signals 200 - Control signals 201 - Monitoring data 202 - Video data 203 - Query-based response data 204 - Periodic reporting/logging, Software downloads 206 3.1. Alert signals 208 Alerts/alarms reporting fall in this category where such signal is 209 triggered in a rare un-usual circumstances. An alert may be 210 triggered for an example when environmental hazard level goes beyond 211 certain threshold. Such alerts require to be reported with in the 212 human tolerable time. Note that certain critical alert reporting in 213 certain automation systems may be reported via very closely and 214 tightly managed method that is not implemented within LLNs, due to 215 the nature of transmission media of LLNs and due to the stringent 216 latency requirement for those alerts. Such types of signals are not 217 considered here since they are not within the scope of LLN or any 218 other IP networks. 220 Examples : 221 - Environmental hazard level goes beyond certain threshold 222 - Measured blood pressure exceeds the threshold or a person falls to 223 the ground 224 - Instructional triggers like start/stop traffic lights during 225 certain critical event 227 Traffic Pattern: 229 Typically size of such packets is very small. any specific device of 230 LLN is expected to trigger only handful of packets (may be only 1 231 packet). That too only during an event which is not a common 232 occurrence. 234 In an affected vicinity, only a designated device or each affected 235 devices may send alerts. In certain type of sensor networks, it is 236 predictable and expected to have only a designated device to trigger 237 such an alert while in certain other types scale number of alert 238 flows may be expected. 240 Latency required for such traffic is not stringent but is to be 241 within human tolerable time bound. 243 3.2. Control signals 245 Besides alerts, LLNs also trigger and/or receive different types of 246 control signals, to/from control applications outside of LLNs. These 247 control signals are important enough for the operation of sensors, 248 actuators and underneath network. Administrator controlling 249 applications, outside of LLN network, may trigger a control signal in 250 response to alerts/data received from LLN (in some cases control 251 signal trigger may be automated without explicit human interaction in 252 the loop) or administrator may trigger an explicit control signal for 253 a specific function. 255 Examples: 256 - auto [demand] response (e.g. manage peak load, service 257 disconnect, start/stop street lights) 258 - manual remote service disconnect, remote demand reset 260 - open-loop regulatory control 261 - non-critical close-loop regulatory control 262 - critical closed-loop control signals 263 - trigger to start Video surveillance 265 Traffic Pattern: 267 Variable size packets but typically size of such packets is small. 268 Certain control signals may be regular and so with number of devices 269 in a particular LLN, it is predictable on average, how many such 270 signals to expect. However, certain other control signals are 271 irregular or on-demand. 273 Typically most of the open-loop, that requires manual interaction, 274 signals are tolerant to latency above 1 second. Certain close-loop 275 control signals require low jitter and low latency, latency in the 276 order of 100s of ms. 278 3.2.1. Deterministic control signals 280 Some of the LLN applications, like Industrial automation, have class 281 of control signals that require very strict time scheduled service. 282 This traffic is very sensitive to jitter. Applications may be able 283 to handle a loss of packet or two but are very sensitive to jitter 284 and any delivery outside of the deterministic time schedule can have 285 expensive effects on the Network. Critical closed-loop control 286 signals example falls in this category. 288 Deterministic control signals are very sensitive to jitter. Scope of 289 such traffic is contained to LL Network and to the IP backbone 290 connecting to two or more such networks. This traffic is not 291 expected to be transmitted over Campus, WAN and Internet. 293 3.3. Monitoring data 295 Reaction to control signals may initiate flow of data-traffic in 296 either direction. Sensors/Actuators in LLNs may also trigger 297 periodic data (eg. monitoring, reporting data). All different types 298 of data may be categorized in following classes. 300 3.3.1. Video data 302 A very common example of this type of monitoring data is Video 303 surveillance or Video feed, triggered thru control signals. This 304 Video feed is typically from LLN towards an application outside of 305 LLN. 307 Traffic Pattern: 309 Video frame size is expected to be big with a flow of variable rate. 311 3.3.2. Query based data 313 Application at the controller, outside the LLN, or user explicitly 314 may launch query for the data. For example, query for an urban 315 environmental data, query for health report etc. Since this data is 316 query based data, it is important to report data with reasonable 317 latency though not stringent. In addition, some periodic logging 318 data also may require timely reporting and so may expect same type of 319 service (eg. at-home health reporting). 321 Traffic Pattern: 323 Size of packets can vary from small to big. While rate may be 324 predictable in some cases, in most of the cases traffic rate for such 325 data is variable. The traffic is bursty in the nature. 327 3.3.3. Periodic reporting/logging, Software downloads 329 Many sensors/actuator in different LLNs report data periodically. 330 With some exceptions, as mentioned above for healthcare monitoring 331 logs, most of such data do not have any latency requirement and can 332 be forwarded either thru lower priority assured forwarding or with 333 service of store and forward or even best effort. 335 Sensors/actuators may require software/firmware upgrades where 336 software/ firmware may be downloaded on demand bases. These upgrades 337 and so downloads do not have stringent requirement of timely delivery 338 to the accuracy of seconds. This data also can be forwarded thru 339 lower priority assured forwarding. 341 Traffic Pattern: 343 Periodic reporting/logging typically can be predicated as constant 344 rate. Data may be bursty in the nature. Software download data also 345 may be bursty in nature. Such traffic is tolerant to jitter and 346 latency. 348 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 DF [DF-PHB]. 411 Scheduling MUST pre-empt service of any other class of traffic during 412 the scheduled time for this class of traffic. 414 4.3. Monitoring Data 416 4.3.1. Video Data 418 RFC4594 has well documented recommendations for different types of 419 Video traffic. If there is any Video traffic from/to LLNs to/from 420 outside of LLNs, they should use same recommended dscp from RFC4594. 421 For example, surveillance video feed is recommended to use dscp CS3. 423 4.3.2. Query based data 425 Low latency data, like query based report and non-critical signals, 426 is recommended to use AF2 assured forwarding service. Also, certain 427 periodic reporting/logging data that are critical to be reported with 428 regular interval with relatively low jitter is recommended to use 429 AF2x service. 431 4.3.3. Periodic reporting/logging, Software downloads 433 Non-critical periodic reporting/logging and rest all other data MAY 434 use AF1x or BE service class. 436 4.4. Summary of Differentiated Code-points and QoS Mechanics for them 437 - Alert Signals CS5 439 - Control Signaling CS5 441 - Deterministic Control Signals DF 443 - Video broadcast/feed CS3 445 - Query-based data AF2x 447 - Assured monitoring data AF1x 448 high throughput 450 - Best Effort monitoring data BE 451 Reporting (periodic reporting.certain types of periodic monitoring 452 MAY require assured forwarding) 453 ------------------------------------------------------------------ 454 | Service | DSCP | Conditioning at | PHB | Queuing| AQM| 455 | Class | | DS Edge | Used | | | 456 |===============+======+===================+=========+========+====| 457 | Deterministic | DF | | |Time | No | 458 |control signals| |Police using sr+bs | |Schedule| | 459 |---------------+------+-------------------+---------+--------+----| 460 |Alert signals/| | | | | | 461 |Control signals| CS5 |Police using sr+bs | RFC2474 | Rate | No | 462 |---------------+------+-------------------+---------+--------+----| 463 | Video feed | CS3 |Police using sr+bs | RFC2474 | Rate | No | 464 |---------------+------+-------------------+---------+--------+----| 465 | Query- | AF21 | Using single-rate,| | | Yes| 466 | based | AF22 |three-color marker | RFC2597 | Rate | per| 467 | Data | AF23 | (such as RFC 2697)| | |DSCP| 468 |---------------+------+-------------------+---------+--------+----| 469 | Periodic | AF11 | Using two-rate, | | | Yes| 470 | Reporting/ | AF12 |three-color marker | RFC2597 | Rate | per| 471 | logging | AF13 | (such as RFC 2698)| | |DSCP| 472 ------------------------------------------------------------------ 473 * "sr+bs" represents a policing mechanism that provides single rate 474 with burst size control [RFC4594] 476 5. Deployment Scenario 478 Industrial Automation, as described in [RFC5673] and [ISA100.11a], 479 classifies different types of traffic in following six classes 480 ranging in complexity from Class 5 to Class 0 where Class 0 is the 481 most time sensitive class. 483 o Safety 485 * Class 0: Emergency action - Always a critical function 487 o Control 489 * Class 1: Closed-loop regulatory control - Often a critical 490 function 492 * Class 2: Closed-loop supervisory control - Usually a non- 493 critical function 495 * Class 3: Open-loop control - Operator takes action and controls 496 the actuator (human in the loop) 498 o Monitoring 500 * Class 4: Alerting - Short-term operational effect (for example, 501 event-based maintenance) 503 * Class 5: Logging and downloading / uploading - No immediate 504 operational consequence (e.g., history collection, sequence-of- 505 events, preventive maintenance) 507 It might not be appropriate to transport Class 0 traffic over a 508 wireless network or a multihop network, unless tight mechanisms are 509 put in place such as TDM and frequency hopping. Today this class of 510 traffic is expected to use other tightly managed method outside of 511 IP networks. Excluding class 0 traffic, following table maps Class 1 512 thru Class 5 service classes to Diffserv code-point. 514 ------------------------- 515 | Service | DSCP | 516 | Class | | 517 |===============+=========| 518 | Class 1 | DF | 519 +-------------------------+ 520 | Class 2 | CS5 | 521 +-------------------------+ 522 | Class 3 | CS5 | 523 +-------------------------+ 524 | Class 4 | AF2x | 525 +-------------------------+ 526 | class 5 | AF1x/BE | 527 +-------------------------+ 529 6. Security Considerations 531 A typical trust model, as much is applicable in traditional networks, 532 is applicable with LLN traffic as well. At the border of the LLN, a 533 trust model needs to be established for any traffic coming out of 534 LLN. Without appropriate trust model to accept/mark dscp code-point 535 for LLN traffic, misbehaving flow may attack a specific Diffserv 536 class disrupting expected service for other traffic from the same 537 Diffserv class. Trust models are typically established at the border 538 router by employing rate-limiting and even marking down dscp code- 539 point to Best Effort for non-trusted flows or dropping them as 540 required. 542 7. Acknowledgements 544 Thanks to Fred Baker, James Polk for their valuable comments and 545 suggestions. 547 8. References 549 8.1. Normative References 551 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 552 Requirement Levels", BCP 14, RFC 2119, March 1997. 554 [RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration 555 Guidelines for DiffServ Service Classes", RFC 4594, August 556 2006. 558 [RFC5127] Chan, K., Babiarz, J., and F. Baker, "Aggregation of 559 Diffserv Service Classes", RFC 5127, February 2008. 561 [RFC5548] Dohler, M., Watteyne, T., Winter, T., and D. Barthel, 562 "Routing Requirements for Urban Low-Power and Lossy 563 Networks", RFC 5548, May 2009. 565 [RFC5673] Pister, K., Thubert, P., Dwars, S., and T. Phinney, 566 "Industrial Routing Requirements in Low-Power and Lossy 567 Networks", RFC 5673, October 2009. 569 [RFC5826] Brandt, A., Buron, J., and G. Porcu, "Home Automation 570 Routing Requirements in Low-Power and Lossy Networks", RFC 571 5826, April 2010. 573 [RFC5867] Martocci, J., De Mil, P., Riou, N., and W. Vermeylen, 574 "Building Automation Routing Requirements in Low-Power and 575 Lossy Networks", RFC 5867, June 2010. 577 [DFPHB] Shah, S. and P. Thubert, "Deterministic Forwarding Per Hop 578 Behavior, I-D.svshah-tsvwg-deterministic-forwarding", 579 March 2014. 581 8.2. Informative References 583 [ISA100.11a] 584 ISA, "ISA-100.11a-2011 - Wireless systems for industrial 585 automation: Process control and related applications", May 586 2011. 588 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 589 "Definition of the Differentiated Services Field (DS 590 Field) in the IPv4 and IPv6 Headers", RFC 2474, December 591 1998. 593 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 594 and W. Weiss, "An Architecture for Differentiated 595 Services", RFC 2475, December 1998. 597 [RFC6272] Baker, F. and D. Meyer, "Internet Protocols for the Smart 598 Grid", RFC 6272, June 2011. 600 Authors' Addresses 602 Shitanshu Shah 603 Cisco Systems 604 170 W. Tasman Drive 605 San Jose, CA 95134 606 US 608 Email: svshah@cisco.com 610 Pascal Thubert 611 Cisco Systems 612 Village d'Entreprises Green Side 613 400, Avenue de Roumanille 614 Batiment T3 615 Biot - Sophia Antipolis 06410 616 FRANCE 618 Email: pthubert@cisco.com