Network Working Group S. Shah Internet-Draft P. Thubert Intended status: Informational Cisco Systems Expires: April 22, 2013 October 19, 2012 Differentiated Service Class Recommendations for LLN Traffic draft-svshah-lln-diffserv-recommendations-01 Abstract Differentiated services architecture is widely deployed in traditional networks. There exist well defined recommendations for the use of appropriate differentiated service classes for different types of traffic (eg. audio, video) in these networks. Per-Hop Behaviors are typically defined based on this recommendations. With emerging Low-power and Lossy Networks (LLNs), it is important to have similar defined differentiated services recommendations for LLN traffic. Defined recommendations are for LLN class of traffic exiting out of LLNs towards high-speed backbones, converged campus network and for the traffic in the reverse direction. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on April 22, 2013. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents Shah & Thubert Expires April 22, 2013 [Page 1] Internet-Draft Diffserv for LLN traffic October 2012 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Shah & Thubert Expires April 22, 2013 [Page 2] Internet-Draft Diffserv for LLN traffic October 2012 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Application Types and Traffic Patterns . . . . . . . . . . . . 6 3.1. Alert signals . . . . . . . . . . . . . . . . . . . . . . 6 3.2. Control signals . . . . . . . . . . . . . . . . . . . . . 7 3.3. Monitoring data . . . . . . . . . . . . . . . . . . . . . 7 3.3.1. Video data . . . . . . . . . . . . . . . . . . . . . . 8 3.3.2. Query based data . . . . . . . . . . . . . . . . . . . 8 3.3.3. Periodic reporting/logging, Software downloads . . . . 8 3.4. Traffic Class Characteristics Table . . . . . . . . . . . 9 4. Differentiated Service recommendations for LLN traffic . . . . 9 4.1. Alert signals . . . . . . . . . . . . . . . . . . . . . . 9 4.2. Control signals . . . . . . . . . . . . . . . . . . . . . 10 4.3. Monitoring Data . . . . . . . . . . . . . . . . . . . . . 10 4.3.1. Video Data . . . . . . . . . . . . . . . . . . . . . . 10 4.3.2. Query based data . . . . . . . . . . . . . . . . . . . 10 4.3.3. Periodic reporting/logging, Software downloads . . . . 10 4.4. Summary of Differentiated Code-points and QoS Mechanics for them . . . . . . . . . . . . . . . . . . . . 11 5. Deployment Scenario . . . . . . . . . . . . . . . . . . . . . 11 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 8.1. Normative References . . . . . . . . . . . . . . . . . . . 13 8.2. Informative References . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 Shah & Thubert Expires April 22, 2013 [Page 3] Internet-Draft Diffserv for LLN traffic October 2012 1. Introduction With emerging LLN applications, it is anticipated that more and more LLNs will be federated by high-speed backbones, possibly supporting deterministic Ethernet service, and be further connected to some converged campus networks for less demanding usages such as supervisory control like traffic originated in a LLN, such as metering, command and control, may transit over a converged campus IP network. ---+------------------------ | Converged Campus Network | +-----+ | | Gateway | | +-----+ | | Backbone +--------------------+------------------+ | | | +-----+ +-----+ +-----+ | | LLN border | | LLN border | | LLN border o | | router | | router | | router +-----+ +-----+ +-----+ o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o M o o o o o o o o o o o o o o o o o o o o o o o o o o o LLN o : stationary wireless field device, seldom acting as an LLN router In an example figure shown above, Per-Hop Behaviors (PHB) and Service Level Agreements (SLAs), for LLN traffic, require to be defined at the LLN Borders as well as Backbone and possibly in the Converged Campus network. In this document, we will first categorize different types of LLN traffic into service classes and then provide recommendations for Differentiated Service Code-Point(DSCP) for those service classes. Mechanisms to be used, like Traffic Conditioning and Active Queue Management, for differentiated services is well defined in RFC4594. Shah & Thubert Expires April 22, 2013 [Page 4] Internet-Draft Diffserv for LLN traffic October 2012 This document does not focus to re-call them again here but the document will call out any specific mechanism that requires particular consideration. This document focuses on Diffserv recommendations for LLN class of traffic in managed IP networks outside of LLNs, that is for the traffic from LLN towards LLN Border, Backbone, Campus Network as well as for the traffic in the reverse direction. It does not focus on Diffserv architecture or any other QoS recommendations within the LLNs itself. Given constraints of LLNs and their unique requirements, it is expected of a focus within a separate efforts. Though nodes inside LLNs MAY use code-points recommended here. In Section 3 we categorize different types of traffic from Different LLNs. Section 4 recommends differentiated services, including DSCPs and QoS mechanics, for categorized classes of traffic. Section 5 evaluates one of the deployment scenario. 1.1. Definitions DSCP: Differentiated Service Code Point. It is a 6-bits value in the TOS and Traffic Class field of the IPv4 and IPv6 header respectively. This 6-bits numerical value defines standard set of behavior to be performed by Differentiated Services capable hops. Diffserv Class: Diffser Class in this document is used to refer to DSCP code- point(s) and associated Per-hop Behaviors for it. LLN: Low-power and lossy Network. Network constructed with sensors, actuators, routers that are low-power and with higher loss/ success transmission ratio, due to transmission medium and nature of dynamics of changing topology, compare to wired and other traditional networks. SLA: Service Level Agreement. It is a collection of Traffic classification rules and set of services associated with each Traffic Class. Traffic classification may be defined based on just DSCP code-points or additionally (or otherwise) based on some other packet attributes. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this Shah & Thubert Expires April 22, 2013 [Page 5] Internet-Draft Diffserv for LLN traffic October 2012 document are to be interpreted as described in RFC2119. 3. Application Types and Traffic Patterns Different types of traffic can be collapsed into following network service classes. - Alert signals - Critical control signals - Monitoring data - Video data - Query-based response data - Periodic reporting/logging, Software downloads 3.1. Alert signals Alerts/alarms reporting fall in this category where such signal is triggered in a rare un-usual circumstances. An alert may be triggered for an example when environmental hazard level goes beyond certain threshold. Such alerts require to be reported with in the human tolerable time. Note that certain critical alert reporting in certain automation systems may be reported via very closely and tightly managed method that is not implemented within LLNs, due to the nature of transmission media of LLNs and due to the stringent latency requirement for those alerts. Such types of signals are not considered here since they are not within the scope of LLN or any other IP networks. Examples : - Environmental hazard level goes beyond certain threshold - Measured blood pressure exceeds the threshold or a person falls to the ground - Instructional triggers like start/stop traffic lights during certain critical event Traffic Pattern: Typically size of such packets is very small. any specific device of LLN is expected to trigger only handful of packets (may be only 1 packet). That too only during an event which is not a common occurrence. In an affected vicinity, only a designated device or each affected devices may send alerts. In certain type of sensor networks, it is predictable and expected to have only a designated device to trigger such an alert while in certain other types scale number of alert flows may be expected. Shah & Thubert Expires April 22, 2013 [Page 6] Internet-Draft Diffserv for LLN traffic October 2012 Latency required for such traffic is not stringent but is to be within human tolerable time bound. 3.2. Control signals Besides alerts, LLNs also trigger and/or receive different types of control signals, to/from control applications outside of LLNs. These control signals are important enough for the operation of sensors, actuators and underneath network. Administrator controlling applications, outside of LLN network, may trigger a control signal in response to alerts/data received from LLN (in some cases control signal trigger may be automated without explicit human interaction in the loop) or administrator may trigger an explicit control signal for a specific function. Examples: - auto [demand] response (e.g. manage peak load, service disconnect, start/stop street lights) - manual remote service disconnect, remote demand reset - open-loop regulatory control - non-critical close-loop regulatory control - trigger to start Video surveillance Traffic Pattern: Variable size packets but typically size of such packets is small. Certain control signals may be regular and so with number of devices in a particular LLN, it is predictable on average, how many such signals to expect. However, certain other control signals are irregular or on-demand. Typically most of the open-loop, that requires manual interaction, signals are tolerant to latency above 1 second. Certain close-loop control signals require low jitter and low latency, latency in the order of 100s of ms. Some of the tightly coupled closed loop control signals are very sensitive to latency and jitter. However they today, just like critical alerts, are implemented via other management methods outside of LLN. 3.3. Monitoring data Reaction to control signals may initiate flow of data-traffic in either direction. Sensors/Actuators in LLNs may also trigger periodic data (eg. monitoring, reporting data). All different types Shah & Thubert Expires April 22, 2013 [Page 7] Internet-Draft Diffserv for LLN traffic October 2012 of data may be categorized in following classes. 3.3.1. Video data A very common example of this type of monitoring data is Video surveillance or Video feed, triggered thru control signals. This Video feed is typically from LLN towards an application outside of LLN. Traffic Pattern: Video frame size is expected to be big with a flow of variable rate. 3.3.2. Query based data Application at the controller, outside the LLN, or user explicitly may launch query for the data. For example, query for an urban environmental data, query for health report etc. Since this data is query based data, it is important to report data with reasonable latency though not stringent. In addition, some periodic logging data also may require timely reporting and so may expect same type of service (eg. at-home health reporting). Traffic Pattern: Size of packets can vary from small to big. While rate may be predictable in some cases, in most of the cases traffic rate for such data is variable. The traffic is bursty in the nature. 3.3.3. Periodic reporting/logging, Software downloads Many sensors/actuator in different LLNs report data periodically. With some exceptions, as mentioned above for healthcare monitoring logs, most of such data do not have any latency requirement and can be forwarded either thru lower priority assured forwarding or with service of store and forward or even best effort. Sensors/actuators may require software/firmware upgrades where software/ firmware may be downloaded on demand bases. These upgrades and so downloads do not have stringent requirement of timely delivery to the accuracy of seconds. This data also can be forwarded thru lower priority assured forwarding. Traffic Pattern: Periodic reporting/logging typically can be predicated as constant rate. Data may be bursty in the nature. Software download data also may be bursty in nature. Such traffic is tolerant to jitter and Shah & Thubert Expires April 22, 2013 [Page 8] Internet-Draft Diffserv for LLN traffic October 2012 latency. 3.4. Traffic Class Characteristics Table ------------------------------------------------------------------- |Traffic Class | | Tolerance to | | Name | Traffic Characteristics | Loss |Delay |Jitter| |===============+==============================+======+======+======| | Alerts/ |Packet size = small | Low |Low | N/A | | alarms |Rate = typically 1-few packets| | | | | |Short lived flow | | | | | |Burst = not bursty | | | | |---------------+------------------------------+------+------+------| | Control |Packet size = variable, | Yes |Low | Yes | | Signals | typically small | | | | | |Rate = few packets | | | | | |Short lived flow | | | | | |Burst = none to some-what | | | | |---------------+------------------------------+------+------+------| | Very low |Packet size = variable, | Low |Very | Low | | latency | typically small | |Low | | | close-loop |Rate = few packets | | | | | Control |Short lived flow | | | | | Signals |Burst = none to some-what | | | | |---------------+------------------------------+------+------+------| | Video |Packet size = big | Low |Low - | Low | |Monitoring/feed|Rate = variable | |Medium| | | |Long lived flow | | | | | |Burst = non-bursty | | | | |---------------+------------------------------+------+------+------| | Query-based |Packet size = variable | Low |Medium| Yes | | Data |Rate = variable | | | | | |Short lived elastic flow | | | | | |Burst = bursty | | | | |---------------+------------------------------+------+------+------| | Periodic |variable packet size, rate | Yes |Medium| Yes | |Reporting/log, |bursty | |- High| | | Software | | | | | | downloads | | | | | ------------------------------------------------------------------- 4. Differentiated Service recommendations for LLN traffic 4.1. Alert signals Alerts/alarms signaling service requires transmission of few packets with low delay, tolerable to human. This requirement is very similar Shah & Thubert Expires April 22, 2013 [Page 9] Internet-Draft Diffserv for LLN traffic October 2012 to signaling traffic in the traditional networks. Alert signals MAY use Diffserv code-point CS5. 4.2. Control signals As described in earlier section, control signals over IP are divided in two categories. Control signals that require very low latency, service inline with EF PHB, and control signals that require low delay but do not mandate lowest latency. Service requirement for later class of control signals is very similar to service for signaling traffic in the traditional networks. Recommendation for this class of control signals is to use Diffserv code-point CS5. Control signals, like some of the closed-loop signals, that require lower delay and jitter compare to CS5 class of control signals, are recommended to use EF Diffserv class. These control signals are expected to be of the small packet size and short-lived flows. Specifically while sharing EF class with voice traffic, any big control packets can cause additional latency to voice packets and so care MUST be taken either to use a different Diffserv class for them or compress such packets to smaller size. 4.3. Monitoring Data 4.3.1. Video Data RFC4594 has well documented recommendations for different types of Video traffic. If there is any Video traffic from/to LLNs to/from outside of LLNs, they should use same recommended dscp from RFC4594. For example, surveillance video feed is recommended to use dscp CS3. 4.3.2. Query based data Low latency data, like query based report and non-critical signals, is recommended to use AF2 assured forwarding service. Also, certain periodic reporting/logging data that are critical to be reported with regular interval with relatively low jitter is recommended to use AF2x service. 4.3.3. Periodic reporting/logging, Software downloads Non-critical periodic reporting/logging and rest all other data MAY use AF1x or BE service class. Shah & Thubert Expires April 22, 2013 [Page 10] Internet-Draft Diffserv for LLN traffic October 2012 4.4. Summary of Differentiated Code-points and QoS Mechanics for them - Alert Signals CS5 - Control Signaling CS5 - Lower latency control-signals EF - Video broadcast/feed CS3 - Query-based data AF2x - Assured monitoring data AF1x high throughput - Best Effort monitoring data BE Reporting (periodic reporting.certain types of periodic monitoring MAY require assured forwarding) ------------------------------------------------------------------ | Service | DSCP | Conditioning at | PHB | Queuing| AQM| | Class | | DS Edge | Used | | | |===============+======+===================+=========+========+====| | lower latency | EF |Police using sr+bs | RFC3246 |Priority| No | |control signals| |Police using sr+bs | | | | |---------------+------+-------------------+---------+--------+----| |Alert signals/| | | | | | |Control signals| CS5 |Police using sr+bs | RFC2474 | Rate | No | |---------------+------+-------------------+---------+--------+----| | Video feed | CS3 |Police using sr+bs | RFC2474 | Rate | No | |---------------+------+-------------------+---------+--------+----| | Query- | AF21 | Using single-rate,| | | Yes| | based | AF22 |three-color marker | RFC2597 | Rate | per| | Data | AF23 | (such as RFC 2697)| | |DSCP| |---------------+------+-------------------+---------+--------+----| | Periodic | AF11 | Using two-rate, | | | Yes| | Reporting/ | AF12 |three-color marker | RFC2597 | Rate | per| | logging | AF13 | (such as RFC 2698)| | |DSCP| ------------------------------------------------------------------ * "sr+bs" represents a policing mechanism that provides single rate with burst size control [RFC4594] 5. Deployment Scenario Industrial Automation, as described in [RFC5673] and [ISA100.11a], classifies different types of traffic in following six classes ranging in complexity from Class 5 to Class 0 where Class 0 is the most time sensitive class. Shah & Thubert Expires April 22, 2013 [Page 11] Internet-Draft Diffserv for LLN traffic October 2012 o Safety * Class 0: Emergency action - Always a critical function o Control * Class 1: Closed-loop regulatory control - Often a critical function * Class 2: Closed-loop supervisory control - Usually a non- critical function * Class 3: Open-loop control - Operator takes action and controls the actuator (human in the loop) o Monitoring * Class 4: Alerting - Short-term operational effect (for example, event-based maintenance) * Class 5: Logging and downloading / uploading - No immediate operational consequence (e.g., history collection, sequence-of- events, preventive maintenance) It might not be appropriate to transport Class 0 traffic over a wireless network or a multihop network, unless tight mechanisms are put in place such as TDM and frequency hopping. Today this class of traffic is expected to use other tightly managed method outside of IP networks. Excluding class 0 traffic, following table maps Class 1 thru Class 5 service classes to Diffserv code-point. ------------------------- | Service | DSCP | | Class | | |===============+=========| | Class 1* | EF | +-------------------------+ | Class 2 | CS5 | +-------------------------+ | Class 3 | CS5 | +-------------------------+ | Class 4 | AF2x | +-------------------------+ | class 5 | AF1x/BE | +-------------------------+ * Any Class 1 traffic that requires very tight control over latency and jitter falls in the same category as Class 0 traffic. Shah & Thubert Expires April 22, 2013 [Page 12] Internet-Draft Diffserv for LLN traffic October 2012 6. Security Considerations A typical trust model, as much is applicable in traditional networks, is applicable with LLN traffic as well. At the border of the LLN, a trust model needs to be established for any traffic coming out of LLN. Without appropriate trust model to accept/mark dscp code-point for LLN traffic, misbehaving flow may attack a specific Diffserv class disrupting expected service for other traffic from the same Diffserv class. Trust models are typically established at the border router by employing rate-limiting and even marking down dscp code- point to Best Effort for non-trusted flows or dropping them as required. 7. Acknowledgements Thanks to Fred Baker, James Polk for their valuable comments and suggestions. 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration Guidelines for DiffServ Service Classes", RFC 4594, August 2006. [RFC5127] Chan, K., Babiarz, J., and F. Baker, "Aggregation of Diffserv Service Classes", RFC 5127, February 2008. [RFC5548] Dohler, M., Watteyne, T., Winter, T., and D. Barthel, "Routing Requirements for Urban Low-Power and Lossy Networks", RFC 5548, May 2009. [RFC5673] Pister, K., Thubert, P., Dwars, S., and T. Phinney, "Industrial Routing Requirements in Low-Power and Lossy Networks", RFC 5673, October 2009. [RFC5826] Brandt, A., Buron, J., and G. Porcu, "Home Automation Routing Requirements in Low-Power and Lossy Networks", RFC 5826, April 2010. [RFC5867] Martocci, J., De Mil, P., Riou, N., and W. Vermeylen, "Building Automation Routing Requirements in Low-Power and Shah & Thubert Expires April 22, 2013 [Page 13] Internet-Draft Diffserv for LLN traffic October 2012 Lossy Networks", RFC 5867, June 2010. 8.2. Informative References [ISA100.11a] ISA, "ISA-100.11a-2011 - Wireless systems for industrial automation: Process control and related applications", May 2011. [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998. [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998. [RFC6272] Baker, F. and D. Meyer, "Internet Protocols for the Smart Grid", RFC 6272, June 2011. Authors' Addresses Shitanshu Shah Cisco Systems 170 W. Tasman Drive San Jose, CA 95134 US Email: svshah@cisco.com Pascal Thubert Cisco Systems Village d'Entreprises Green Side 400, Avenue de Roumanille Batiment T3 Biot - Sophia Antipolis 06410 FRANCE Email: pthubert@cisco.com Shah & Thubert Expires April 22, 2013 [Page 14]