idnits 2.17.1 draft-svshah-lln-diffserv-recommendations-01.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 448 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 (October 19, 2012) is 4201 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 542, but no explicit reference was found in the text == Unused Reference: 'RFC5127' is defined on line 549, but no explicit reference was found in the text == Unused Reference: 'RFC5548' is defined on line 552, but no explicit reference was found in the text == Unused Reference: 'RFC5826' is defined on line 560, but no explicit reference was found in the text == Unused Reference: 'RFC5867' is defined on line 564, but no explicit reference was found in the text == Unused Reference: 'RFC2474' is defined on line 575, but no explicit reference was found in the text == Unused Reference: 'RFC2475' is defined on line 580, but no explicit reference was found in the text == Unused Reference: 'RFC6272' is defined on line 584, 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: April 22, 2013 October 19, 2012 7 Differentiated Service Class Recommendations for LLN Traffic 8 draft-svshah-lln-diffserv-recommendations-01 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 April 22, 2013. 40 Copyright Notice 42 Copyright (c) 2012 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.3. Monitoring data . . . . . . . . . . . . . . . . . . . . . 7 76 3.3.1. Video data . . . . . . . . . . . . . . . . . . . . . . 8 77 3.3.2. Query based data . . . . . . . . . . . . . . . . . . . 8 78 3.3.3. Periodic reporting/logging, Software downloads . . . . 8 79 3.4. Traffic Class Characteristics Table . . . . . . . . . . . 9 80 4. Differentiated Service recommendations for LLN traffic . . . . 9 81 4.1. Alert signals . . . . . . . . . . . . . . . . . . . . . . 9 82 4.2. Control signals . . . . . . . . . . . . . . . . . . . . . 10 83 4.3. Monitoring Data . . . . . . . . . . . . . . . . . . . . . 10 84 4.3.1. Video Data . . . . . . . . . . . . . . . . . . . . . . 10 85 4.3.2. Query based data . . . . . . . . . . . . . . . . . . . 10 86 4.3.3. Periodic reporting/logging, Software downloads . . . . 10 87 4.4. Summary of Differentiated Code-points and QoS 88 Mechanics for them . . . . . . . . . . . . . . . . . . . . 11 89 5. Deployment Scenario . . . . . . . . . . . . . . . . . . . . . 11 90 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 91 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 92 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 93 8.1. Normative References . . . . . . . . . . . . . . . . . . . 13 94 8.2. Informative References . . . . . . . . . . . . . . . . . . 14 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 97 1. Introduction 99 With emerging LLN applications, it is anticipated that more and more 100 LLNs will be federated by high-speed backbones, possibly supporting 101 deterministic Ethernet service, and be further connected to some 102 converged campus networks for less demanding usages such as 103 supervisory control like traffic originated in a LLN, such as 104 metering, command and control, may transit over a converged campus IP 105 network. 107 ---+------------------------ 108 | Converged Campus Network 109 | 110 +-----+ 111 | | Gateway 112 | | 113 +-----+ 114 | 115 | Backbone 116 +--------------------+------------------+ 117 | | | 118 +-----+ +-----+ +-----+ 119 | | LLN border | | LLN border | | LLN border 120 o | | router | | router | | router 121 +-----+ +-----+ +-----+ 122 o o o o 123 o o o o o o o o o o o 124 o o o o o o o o o o o o o o o o o o 125 o o o o o o o o o o o o o o o o 126 o o M o o o o o o o o o o o o o 127 o o o o o o o o o 128 o o o o o 129 LLN 130 o : stationary wireless field device, seldom acting as an LLN router 132 In an example figure shown above, Per-Hop Behaviors (PHB) and Service 133 Level Agreements (SLAs), for LLN traffic, require to be defined at 134 the LLN Borders as well as Backbone and possibly in the Converged 135 Campus network. 137 In this document, we will first categorize different types of LLN 138 traffic into service classes and then provide recommendations for 139 Differentiated Service Code-Point(DSCP) for those service classes. 140 Mechanisms to be used, like Traffic Conditioning and Active Queue 141 Management, for differentiated services is well defined in RFC4594. 143 This document does not focus to re-call them again here but the 144 document will call out any specific mechanism that requires 145 particular consideration. 147 This document focuses on Diffserv recommendations for LLN class of 148 traffic in managed IP networks outside of LLNs, that is for the 149 traffic from LLN towards LLN Border, Backbone, Campus Network as well 150 as for the traffic in the reverse direction. It does not focus on 151 Diffserv architecture or any other QoS recommendations within the 152 LLNs itself. Given constraints of LLNs and their unique 153 requirements, it is expected of a focus within a separate efforts. 154 Though nodes inside LLNs MAY use code-points recommended here. 156 In Section 3 we categorize different types of traffic from Different 157 LLNs. Section 4 recommends differentiated services, including DSCPs 158 and QoS mechanics, for categorized classes of traffic. Section 5 159 evaluates one of the deployment scenario. 161 1.1. Definitions 163 DSCP: Differentiated Service Code Point. It is a 6-bits value in the 164 TOS and Traffic Class field of the IPv4 and IPv6 header 165 respectively. This 6-bits numerical value defines standard set 166 of behavior to be performed by Differentiated Services capable 167 hops. 169 Diffserv 170 Class: Diffser Class in this document is used to refer to DSCP code- 171 point(s) and associated Per-hop Behaviors for it. 173 LLN: Low-power and lossy Network. Network constructed with sensors, 174 actuators, routers that are low-power and with higher loss/ 175 success transmission ratio, due to transmission medium and 176 nature of dynamics of changing topology, compare to wired and 177 other traditional networks. 179 SLA: Service Level Agreement. It is a collection of Traffic 180 classification rules and set of services associated with each 181 Traffic Class. Traffic classification may be defined based 182 on just DSCP code-points or additionally (or otherwise) 183 based on some other packet attributes. 185 2. Terminology 187 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 188 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 189 document are to be interpreted as described in RFC2119. 191 3. Application Types and Traffic Patterns 193 Different types of traffic can be collapsed into following network 194 service classes. 196 - Alert signals 197 - Critical control signals 198 - Monitoring data 199 - Video data 200 - Query-based response data 201 - Periodic reporting/logging, Software downloads 203 3.1. Alert signals 205 Alerts/alarms reporting fall in this category where such signal is 206 triggered in a rare un-usual circumstances. An alert may be 207 triggered for an example when environmental hazard level goes beyond 208 certain threshold. Such alerts require to be reported with in the 209 human tolerable time. Note that certain critical alert reporting in 210 certain automation systems may be reported via very closely and 211 tightly managed method that is not implemented within LLNs, due to 212 the nature of transmission media of LLNs and due to the stringent 213 latency requirement for those alerts. Such types of signals are not 214 considered here since they are not within the scope of LLN or any 215 other IP networks. 217 Examples : 218 - Environmental hazard level goes beyond certain threshold 219 - Measured blood pressure exceeds the threshold or a person falls to 220 the ground 221 - Instructional triggers like start/stop traffic lights during 222 certain critical event 224 Traffic Pattern: 226 Typically size of such packets is very small. any specific device of 227 LLN is expected to trigger only handful of packets (may be only 1 228 packet). That too only during an event which is not a common 229 occurrence. 231 In an affected vicinity, only a designated device or each affected 232 devices may send alerts. In certain type of sensor networks, it is 233 predictable and expected to have only a designated device to trigger 234 such an alert while in certain other types scale number of alert 235 flows may be expected. 237 Latency required for such traffic is not stringent but is to be 238 within human tolerable time bound. 240 3.2. Control signals 242 Besides alerts, LLNs also trigger and/or receive different types of 243 control signals, to/from control applications outside of LLNs. These 244 control signals are important enough for the operation of sensors, 245 actuators and underneath network. Administrator controlling 246 applications, outside of LLN network, may trigger a control signal in 247 response to alerts/data received from LLN (in some cases control 248 signal trigger may be automated without explicit human interaction in 249 the loop) or administrator may trigger an explicit control signal for 250 a specific function. 252 Examples: 253 - auto [demand] response (e.g. manage peak load, service 254 disconnect, start/stop street lights) 255 - manual remote service disconnect, remote demand reset 257 - open-loop regulatory control 258 - non-critical close-loop regulatory control 259 - trigger to start Video surveillance 261 Traffic Pattern: 263 Variable size packets but typically size of such packets is small. 264 Certain control signals may be regular and so with number of devices 265 in a particular LLN, it is predictable on average, how many such 266 signals to expect. However, certain other control signals are 267 irregular or on-demand. 269 Typically most of the open-loop, that requires manual interaction, 270 signals are tolerant to latency above 1 second. Certain close-loop 271 control signals require low jitter and low latency, latency in the 272 order of 100s of ms. 274 Some of the tightly coupled closed loop control signals are very 275 sensitive to latency and jitter. However they today, just like 276 critical alerts, are implemented via other management methods outside 277 of LLN. 279 3.3. Monitoring data 281 Reaction to control signals may initiate flow of data-traffic in 282 either direction. Sensors/Actuators in LLNs may also trigger 283 periodic data (eg. monitoring, reporting data). All different types 284 of data may be categorized in following classes. 286 3.3.1. Video data 288 A very common example of this type of monitoring data is Video 289 surveillance or Video feed, triggered thru control signals. This 290 Video feed is typically from LLN towards an application outside of 291 LLN. 293 Traffic Pattern: 295 Video frame size is expected to be big with a flow of variable rate. 297 3.3.2. Query based data 299 Application at the controller, outside the LLN, or user explicitly 300 may launch query for the data. For example, query for an urban 301 environmental data, query for health report etc. Since this data is 302 query based data, it is important to report data with reasonable 303 latency though not stringent. In addition, some periodic logging 304 data also may require timely reporting and so may expect same type of 305 service (eg. at-home health reporting). 307 Traffic Pattern: 309 Size of packets can vary from small to big. While rate may be 310 predictable in some cases, in most of the cases traffic rate for such 311 data is variable. The traffic is bursty in the nature. 313 3.3.3. Periodic reporting/logging, Software downloads 315 Many sensors/actuator in different LLNs report data periodically. 316 With some exceptions, as mentioned above for healthcare monitoring 317 logs, most of such data do not have any latency requirement and can 318 be forwarded either thru lower priority assured forwarding or with 319 service of store and forward or even best effort. 321 Sensors/actuators may require software/firmware upgrades where 322 software/ firmware may be downloaded on demand bases. These upgrades 323 and so downloads do not have stringent requirement of timely delivery 324 to the accuracy of seconds. This data also can be forwarded thru 325 lower priority assured forwarding. 327 Traffic Pattern: 329 Periodic reporting/logging typically can be predicated as constant 330 rate. Data may be bursty in the nature. Software download data also 331 may be bursty in nature. Such traffic is tolerant to jitter and 332 latency. 334 3.4. Traffic Class Characteristics Table 336 ------------------------------------------------------------------- 337 |Traffic Class | | Tolerance to | 338 | Name | Traffic Characteristics | Loss |Delay |Jitter| 339 |===============+==============================+======+======+======| 340 | Alerts/ |Packet size = small | Low |Low | N/A | 341 | alarms |Rate = typically 1-few packets| | | | 342 | |Short lived flow | | | | 343 | |Burst = not bursty | | | | 344 |---------------+------------------------------+------+------+------| 345 | Control |Packet size = variable, | Yes |Low | Yes | 346 | Signals | typically small | | | | 347 | |Rate = few packets | | | | 348 | |Short lived flow | | | | 349 | |Burst = none to some-what | | | | 350 |---------------+------------------------------+------+------+------| 351 | Very low |Packet size = variable, | Low |Very | Low | 352 | latency | typically small | |Low | | 353 | close-loop |Rate = few packets | | | | 354 | Control |Short lived flow | | | | 355 | Signals |Burst = none to some-what | | | | 356 |---------------+------------------------------+------+------+------| 357 | Video |Packet size = big | Low |Low - | Low | 358 |Monitoring/feed|Rate = variable | |Medium| | 359 | |Long lived flow | | | | 360 | |Burst = non-bursty | | | | 361 |---------------+------------------------------+------+------+------| 362 | Query-based |Packet size = variable | Low |Medium| Yes | 363 | Data |Rate = variable | | | | 364 | |Short lived elastic flow | | | | 365 | |Burst = bursty | | | | 366 |---------------+------------------------------+------+------+------| 367 | Periodic |variable packet size, rate | Yes |Medium| Yes | 368 |Reporting/log, |bursty | |- High| | 369 | Software | | | | | 370 | downloads | | | | | 371 ------------------------------------------------------------------- 373 4. Differentiated Service recommendations for LLN traffic 375 4.1. Alert signals 377 Alerts/alarms signaling service requires transmission of few packets 378 with low delay, tolerable to human. This requirement is very similar 379 to signaling traffic in the traditional networks. Alert signals MAY 380 use Diffserv code-point CS5. 382 4.2. Control signals 384 As described in earlier section, control signals over IP are divided 385 in two categories. Control signals that require very low latency, 386 service inline with EF PHB, and control signals that require low 387 delay but do not mandate lowest latency. Service requirement for 388 later class of control signals is very similar to service for 389 signaling traffic in the traditional networks. Recommendation for 390 this class of control signals is to use Diffserv code-point CS5. 392 Control signals, like some of the closed-loop signals, that require 393 lower delay and jitter compare to CS5 class of control signals, are 394 recommended to use EF Diffserv class. These control signals are 395 expected to be of the small packet size and short-lived flows. 396 Specifically while sharing EF class with voice traffic, any big 397 control packets can cause additional latency to voice packets and so 398 care MUST be taken either to use a different Diffserv class for them 399 or compress such packets to smaller size. 401 4.3. Monitoring Data 403 4.3.1. Video Data 405 RFC4594 has well documented recommendations for different types of 406 Video traffic. If there is any Video traffic from/to LLNs to/from 407 outside of LLNs, they should use same recommended dscp from RFC4594. 408 For example, surveillance video feed is recommended to use dscp CS3. 410 4.3.2. Query based data 412 Low latency data, like query based report and non-critical signals, 413 is recommended to use AF2 assured forwarding service. Also, certain 414 periodic reporting/logging data that are critical to be reported with 415 regular interval with relatively low jitter is recommended to use 416 AF2x service. 418 4.3.3. Periodic reporting/logging, Software downloads 420 Non-critical periodic reporting/logging and rest all other data MAY 421 use AF1x or BE service class. 423 4.4. Summary of Differentiated Code-points and QoS Mechanics for them 425 - Alert Signals CS5 427 - Control Signaling CS5 429 - Lower latency control-signals EF 431 - Video broadcast/feed CS3 433 - Query-based data AF2x 435 - Assured monitoring data AF1x 436 high throughput 438 - Best Effort monitoring data BE 439 Reporting (periodic reporting.certain types of periodic monitoring 440 MAY require assured forwarding) 441 ------------------------------------------------------------------ 442 | Service | DSCP | Conditioning at | PHB | Queuing| AQM| 443 | Class | | DS Edge | Used | | | 444 |===============+======+===================+=========+========+====| 445 | lower latency | EF |Police using sr+bs | RFC3246 |Priority| No | 446 |control signals| |Police using sr+bs | | | | 447 |---------------+------+-------------------+---------+--------+----| 448 |Alert signals/| | | | | | 449 |Control signals| CS5 |Police using sr+bs | RFC2474 | Rate | No | 450 |---------------+------+-------------------+---------+--------+----| 451 | Video feed | CS3 |Police using sr+bs | RFC2474 | Rate | No | 452 |---------------+------+-------------------+---------+--------+----| 453 | Query- | AF21 | Using single-rate,| | | Yes| 454 | based | AF22 |three-color marker | RFC2597 | Rate | per| 455 | Data | AF23 | (such as RFC 2697)| | |DSCP| 456 |---------------+------+-------------------+---------+--------+----| 457 | Periodic | AF11 | Using two-rate, | | | Yes| 458 | Reporting/ | AF12 |three-color marker | RFC2597 | Rate | per| 459 | logging | AF13 | (such as RFC 2698)| | |DSCP| 460 ------------------------------------------------------------------ 461 * "sr+bs" represents a policing mechanism that provides single rate 462 with burst size control [RFC4594] 464 5. Deployment Scenario 466 Industrial Automation, as described in [RFC5673] and [ISA100.11a], 467 classifies different types of traffic in following six classes 468 ranging in complexity from Class 5 to Class 0 where Class 0 is the 469 most time sensitive class. 471 o Safety 473 * Class 0: Emergency action - Always a critical function 475 o Control 477 * Class 1: Closed-loop regulatory control - Often a critical 478 function 480 * Class 2: Closed-loop supervisory control - Usually a non- 481 critical function 483 * Class 3: Open-loop control - Operator takes action and controls 484 the actuator (human in the loop) 486 o Monitoring 488 * Class 4: Alerting - Short-term operational effect (for example, 489 event-based maintenance) 491 * Class 5: Logging and downloading / uploading - No immediate 492 operational consequence (e.g., history collection, sequence-of- 493 events, preventive maintenance) 495 It might not be appropriate to transport Class 0 traffic over a 496 wireless network or a multihop network, unless tight mechanisms are 497 put in place such as TDM and frequency hopping. Today this class of 498 traffic is expected to use other tightly managed method outside of 499 IP networks. Excluding class 0 traffic, following table maps Class 1 500 thru Class 5 service classes to Diffserv code-point. 502 ------------------------- 503 | Service | DSCP | 504 | Class | | 505 |===============+=========| 506 | Class 1* | EF | 507 +-------------------------+ 508 | Class 2 | CS5 | 509 +-------------------------+ 510 | Class 3 | CS5 | 511 +-------------------------+ 512 | Class 4 | AF2x | 513 +-------------------------+ 514 | class 5 | AF1x/BE | 515 +-------------------------+ 517 * Any Class 1 traffic that requires very tight control over latency 518 and jitter falls in the same category as Class 0 traffic. 520 6. Security Considerations 522 A typical trust model, as much is applicable in traditional networks, 523 is applicable with LLN traffic as well. At the border of the LLN, a 524 trust model needs to be established for any traffic coming out of 525 LLN. Without appropriate trust model to accept/mark dscp code-point 526 for LLN traffic, misbehaving flow may attack a specific Diffserv 527 class disrupting expected service for other traffic from the same 528 Diffserv class. Trust models are typically established at the border 529 router by employing rate-limiting and even marking down dscp code- 530 point to Best Effort for non-trusted flows or dropping them as 531 required. 533 7. Acknowledgements 535 Thanks to Fred Baker, James Polk for their valuable comments and 536 suggestions. 538 8. References 540 8.1. Normative References 542 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 543 Requirement Levels", BCP 14, RFC 2119, March 1997. 545 [RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration 546 Guidelines for DiffServ Service Classes", RFC 4594, 547 August 2006. 549 [RFC5127] Chan, K., Babiarz, J., and F. Baker, "Aggregation of 550 Diffserv Service Classes", RFC 5127, February 2008. 552 [RFC5548] Dohler, M., Watteyne, T., Winter, T., and D. Barthel, 553 "Routing Requirements for Urban Low-Power and Lossy 554 Networks", RFC 5548, May 2009. 556 [RFC5673] Pister, K., Thubert, P., Dwars, S., and T. Phinney, 557 "Industrial Routing Requirements in Low-Power and Lossy 558 Networks", RFC 5673, October 2009. 560 [RFC5826] Brandt, A., Buron, J., and G. Porcu, "Home Automation 561 Routing Requirements in Low-Power and Lossy Networks", 562 RFC 5826, April 2010. 564 [RFC5867] Martocci, J., De Mil, P., Riou, N., and W. Vermeylen, 565 "Building Automation Routing Requirements in Low-Power and 566 Lossy Networks", RFC 5867, June 2010. 568 8.2. Informative References 570 [ISA100.11a] 571 ISA, "ISA-100.11a-2011 - Wireless systems for industrial 572 automation: Process control and related applications", 573 May 2011. 575 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 576 "Definition of the Differentiated Services Field (DS 577 Field) in the IPv4 and IPv6 Headers", RFC 2474, 578 December 1998. 580 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 581 and W. Weiss, "An Architecture for Differentiated 582 Services", RFC 2475, December 1998. 584 [RFC6272] Baker, F. and D. Meyer, "Internet Protocols for the Smart 585 Grid", RFC 6272, June 2011. 587 Authors' Addresses 589 Shitanshu Shah 590 Cisco Systems 591 170 W. Tasman Drive 592 San Jose, CA 95134 593 US 595 Email: svshah@cisco.com 597 Pascal Thubert 598 Cisco Systems 599 Village d'Entreprises Green Side 600 400, Avenue de Roumanille 601 Batiment T3 602 Biot - Sophia Antipolis 06410 603 FRANCE 605 Email: pthubert@cisco.com