idnits 2.17.1 draft-svshah-tsvwg-deterministic-forwarding-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC5127]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == 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 (January 08, 2014) is 3758 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2598 (Obsoleted by RFC 3246) Summary: 2 errors (**), 0 flaws (~~), 2 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: July 12, 2014 January 08, 2014 7 Deterministic Forwarding PHB 8 draft-svshah-tsvwg-deterministic-forwarding-00 10 Abstract 12 This document defines a Differentiated Services Per-Hop-Behavior 13 (PHB) Group called Deterministic Forwarding (DF). The document 14 describes the purpose and semantics of this PHB. It also describes 15 creation and forwarding treatment of the service class. The document 16 also describes how the code-point can be mapped into one of the 17 aggregated Diffserv service classes [RFC5127]. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on July 12, 2014. 36 Copyright Notice 38 Copyright (c) 2014 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 This document may contain material from IETF Documents or IETF 52 Contributions published or made publicly available before November 53 10, 2008. The person(s) controlling the copyright in some of this 54 material may not have granted the IETF Trust the right to allow 55 modifications of such material outside the IETF Standards Process. 56 Without obtaining an adequate license from the person(s) controlling 57 the copyright in such materials, this document may not be modified 58 outside the IETF Standards Process, and derivative works of it may 59 not be created outside the IETF Standards Process, except to format 60 it for publication as an RFC or to translate it into languages other 61 than English. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 1.1. Use-cases . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 3. DF code-point Behavior . . . . . . . . . . . . . . . . . . . . 5 69 3.1. Potential implementation of DF scheduling . . . . . . . . . 6 70 3.2. Conditioning DF traffic at Enqueue . . . . . . . . . . . . 8 71 4. Diffserv behavior through non-DF DS domains . . . . . . . . . . 8 72 5. Updates to RFC4594 and RFC5127 . . . . . . . . . . . . . . . . 8 73 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 74 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 9 75 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 76 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 77 9.1. Normative References . . . . . . . . . . . . . . . . . . . 9 78 9.2. Informative References . . . . . . . . . . . . . . . . . . 9 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 81 1. Introduction 83 IP Networks typically implement Diffserv to provide differentiated 84 forwarding behavior to different class of traffic. Networks that 85 implement Diffserv relies on DSCP code-point in the IP header of a 86 packet to select PHB as a specific forwarding treatment for that 87 packet [RFC2474, RFC2475]. This document describes a particular PHB 88 called Deterministic Forwarding (DF). The proposed new code-point 89 defines a service class for the purpose of forwarding treatment of a 90 packet at determined/fixed scheduled time providing no jitter service 91 to the class of traffic (updates RFC4594 with the addition of a new 92 Service Class). 94 DF PHB can be used for the network services that require the 95 capability to ensure a predictable interaction between networked 96 systems and guarantee a very strict time scheduled services. 97 Applications of such networks may be able to absorb a loss but are 98 very sensitive to end to end latency and jitter. Examples of such 99 networks include Machine to Machine (M2M) control and monitoring 100 deployment with IP over varieties of Layer 2 networks. 102 The definition of Expedited Forwarding (EF) [RFC2598] PHB is low 103 latency and thus one can envision use of EF code-point for such 104 service. However, even though EF defines low latency and low jitter, 105 it does not guarantee deterministic/fixed scheduled time service. 106 Depending on co-existence of the other traffic in the network, EF 107 traffic may have more or less variance on jitter and thus not 108 suitable for the deterministic service. DF PHB thus is more suitable 109 for deterministic time sensitive traffic. 111 Typically for an application where end to end deterministic service 112 is important, relevant traffic should be provisioned through DF PHB 113 at every hop in that end to end path. However, in cases where 114 intermediate hops (or DS domains) either do not support DF PHB or 115 supports only aggregated service classes described in RFC5127, DF 116 traffic in those DS domains MUST be mapped to Real Time Treatment 117 class (EF PHB) defined in RFC5127. Traffic in such scenario MUST be 118 conditioned at the Edge before entering and after exiting such DS 119 domains. This is described further in later section. 121 1.1. Use-cases 123 With an introduction of machine to machine networks over IP, a new 124 set of applications are emerging. Traffic types from such 125 applications/networks are some-what different from the traditional 126 traffic types. Though most traffic types have characteristics 127 similar to that of traditional ones [LLN-DIFF], certain control 128 signals for some of the applications are extremely sensitive to 129 latency and jitter. Such control signals demand much stricter 130 latency and jitter, at pretty much decisive time scheduled delivery, 131 end to end. Industrial automation, Smart cities and automobiles/ 132 planes/trains built around such networks are examples of such use- 133 cases. 135 Machine to machine networks may be implemented on varieties of Layer 136 2 protocols. 802.3 and 802.15e [TiSCH] are examples of layer 2 that 137 are enhancing their capabilities to allow time scheduled delivery of 138 packets. 140 In a wireless sensor networks, that are implemented over IP, multiple 141 LLN (Low power and Lossy Networks) may be connected through Backbone. 143 ---+------------------------ 144 | Converged Campus Network 145 | 146 +-----+ 147 | | Gateway 148 | | 149 +-----+ 150 | 151 | Backbone 152 +--------------------+------------------+ 153 | | | 154 +-----+ +-----+ +-----+ 155 | | LLN border | | LLN border | | LLN border 156 o | | router | | router | | router 157 +-----+ +-----+ +-----+ 158 o o o o 159 o o o o o o o o o o o 160 o o o o o o o o o o o o o o o o o o 161 o o o o o o o o o o o o o o o o 162 o o M o o o o o o o o o o o o o 163 o o o o o o o o o 164 o o o o o 166 LLN-1 LLN-2 LLN-3 168 As shown in the diagram, multiple LL Networks are connected to each 169 other via Backbone through LLN Border routers. Each LL Network 170 consist of many nodes. There are different types of traffic 171 forwarded through each LL node and from one LL Network to another. 172 Most LLN traffic types have characteristics similar to that of 173 traditional ones and thus can be supported through existing Diffserv 174 classes except time sensitive control signals. Without segregating 175 such control signals to a specific Diffserv class would require 176 Intserv support for LLN traffic in such networks. All traffic would 177 be subject to flow classification to differentiate time sensitive 178 control signals which can be a big scale concern. Supporting time 179 sensitive control signals via newly proposed DF Diffserv class allows 180 implementation of Diffserv in LLN Networks. 182 2. Terminology 184 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 185 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 186 document are to be interpreted as described in RFC2119. 188 3. DF code-point Behavior 190 The DF PHB is to implement time scheduled forwarding treatment. 191 Provisioning of such a service has two parts, 193 1) Provisioning of the fixed/relative time for scheduling of such 194 service 195 2) Provisioning of the max size of the data to be transmitted at 196 each scheduled time 198 Provisioned scheduled time may be absolute or relative. For example, 199 a DF class may be provisioned to schedule packets (or bytes) at every 200 fixed time. Fixed time can be time of a day or any other absolute 201 definition. In a multi hop forwarding of DF traffic, absolute time 202 service provisioning at each hop may require to be dependent on the 203 clock synchronization (clock synchronization is not in the scope of 204 this specification). In relative time scheduling, packets to be 205 scheduled at every specific interval or it could be relative to any 206 other specific event/trigger. The definition of the time interval or 207 any other event is relevant to that specific provisioned node only. 209 The size of the data, to be transmitted at each scheduled time 210 service, provisioned can be in the unit of bytes or time. Once DF 211 PHB is provisioned and enabled, forwarding treatment MUST service 212 packets (bytes) from this class at the scheduled time for max 213 allowable data. Scheduling MUST pre-empt any other service, 214 including EF, during the schedule time service for the DF class. In 215 order to avoid incurred latency to EF class of traffic, it is 216 expected to carefully provision DF class to limit scheduled time 217 service to as minimal data transmission that would prevent larger 218 than expected delays to EF class of traffic. 220 Provisioning can be done via any of multiple possible methods. It 221 could be via command interface, or could be via external provisioning 222 agents, or could be via some sort of signaling that may dynamically 223 pre-negotiate time window of transmission at each node in a network 224 path. 226 3.1. Potential implementation of DF scheduling 228 Following are examples of potential implementations. They are not 229 any form of guidelines or recommendations. 231 There are at least two ways to implement scheduling for DF traffic 232 class. 234 1) One queue to buffer and schedule all DF traffic (from all flows), 236 2) Multiple sub-queues for DF traffic class, one queue for each DF 237 provisioned flow 239 Flow here represents macro definition, it does not have to be only 240 5-tuple. 242 Any chosen DF scheduling implementation MUST run traffic conditioning 243 at enqueue to decide if packets to be enqueued or discarded. 244 Discussed more in later section. 246 1) One data-plane queue to buffer all DF traffic 248 This one queue maintains, possibly a circular, indexed buffer list. 249 Every time scheduled slot is an index in the buffer list. If enqueue 250 conditioning decides not to discard a packet, packet gets en-queued 251 at the relevant index in the buffer list in such a way that relevant 252 index pointer, and thus buffered relevant packets for that index, at 253 the head of the list is ready to be de-queued at next scheduled time. 254 Subsequent buffer index is scheduled for the subsequent scheduled 255 time slot and so forth. If a specific flow has not received any 256 packet for a scheduled time then buffer index for that flow remains 257 empty. A packet from other flows do not get buffered at that empty 258 index. That means during dequeue, at a schedule time service, an 259 empty index results in no packets to dequeue and thus nothing to be 260 transmitted from the DF queue at that point in time. 262 . 263 |`. 264 EF (Low latency) ----------------||----> `. 265 High | `. 266 . | `. 267 rate queues |`. | `. 268 AF1 ----||---> `. | `. 269 | `. | `. 270 AF3 ----||---> '------------------> '------> 271 | .' Low | .' 272 BE ----||---> .' | .' 273 | .' | .' 274 .' | .' 275 Deterministic| .' 276 DF ----------------||----> .' 277 (scheduled time/interrupt driven de-queue)|.' 279 2) multiple sub-queues for each DF flows 281 If enqueue conditioning decides not to discard a packet, packet gets 282 enqueued in the relevant DF sub-queue designated for that flow. At a 283 scheduled time slot, scheduler dequeues a packet from the respective 284 sub-queue. Every scheduled time service interrupt is mapped to a 285 specific DF sub-queue to dequeue a packet from. 287 . 288 |`. 289 EF (Low latency) ----------------||----> `. 290 High | `. 291 . | `. 292 rate queues |`. | `. 293 AF1 ----||---> `. | `. 294 | `. | `. 295 AF3 ----||---> '------------------> '------> 296 | .' Low | .' 297 BE ----||---> .' | .' 298 | .' | .' 299 .' | .' 300 (DF queues) Deterministic| .' 301 DF (at interval 1, 6, 11 ..) ----||----> .' 302 DF (at interval 3, 8, 13 ..) ----||---->.' 304 3.2. Conditioning DF traffic at Enqueue 306 DF traffic MUST be conditioned at the enqueue. As per PHB 307 definition, packets are required to be scheduled and delivered at a 308 precise absolute or relative time interval. Any packet that has 309 missed the window of its service time MUST be discarded. That would 310 also mean any packet coming from the previous hop MUST be conditioned 311 at the enqueue for validity of its scheduled service. For example if 312 a DF queue is provisioned to serve a packet with less than x ms of 313 jitter and for an arrived packet, if next scheduled time for a packet 314 results in more than x ms of jitter then such packet MUST be 315 discarded. The enqueued packet MUST also be checked against the size 316 of the data. If size of the data to be enqueued in a DF queue is 317 bigger than what scheduled time slot is provisioned for then such 318 packet MUST be discarded. 320 4. Diffserv behavior through non-DF DS domains 322 In cases where DF traffic is forwarded through multiple DS domains, 323 DS domains close to the source and receiver understand application's 324 deterministic service requirement well and so MUST be provisioned for 325 the precise time scheduled forwarding treatment. Intermediate DS 326 domains MAY support DF PHB. Intermediate domains that can not 327 support DF PHB, DF traffic from such domains SHOULD get EF treatment, 328 as defined in RFC5127 for Real Time Service aggregation. Sender and 329 Receiver DS domains, in such cases, MUST condition DF traffic at the 330 respective Edge. If EF service through intermediate DS domains can 331 have a predictable upper bound, receiver DS domain Edge can add a 332 correction to an incurred latency/jitter with its own defined time 333 interval for DF service. 335 5. Updates to RFC4594 and RFC5127 337 This specification updates RFC4594 with an addition of a new Diffserv 338 Class. It also updates RFC5127 to aggregate DF class of traffic to 339 Real Time Aggregation Class. 341 6. IANA Considerations 343 This document defines a new DSCP code-point DF. IANA maintains the 344 list of existing DSCPs. Proposal is to allocate a new one for the DF 345 code-point. 347 7. Security Considerations 349 There is no security considerations required besides ones already 350 understood in the context of Differentiated services architecture 352 8. Acknowledgements 354 Fred Baker and Norm Finn. 356 9. References 358 9.1. Normative References 360 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 361 "Definition of the Differentiated Services Field (DS 362 Field) in the IPv4 and IPv6 Headers", RFC 2474, 363 December 1998. 365 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 366 and W. Weiss, "An Architecture for Differentiated 367 Services", RFC 2475, December 1998. 369 [RFC2598] Jacobson, V., Nichols, K., and K. Poduri, "An Expedited 370 Forwarding PHB", RFC 2598, June 1999. 372 [RFC5127] Chan, K., Babiarz, J., and F. Baker, "Aggregation of 373 Diffserv Service Classes", RFC 5127, February 2008. 375 9.2. Informative References 377 [TiSCH] Thubert, P., Watteyne, T., and R. Assimiti, "An 378 Architecture for IPv6 over the TSCH mode of IEEE 379 802.15.4e, I-D.draft-ietf-6tisch-architecture", Nov 2013. 381 [LLN-DIFF] 382 Shah, S. and P. Thubert, "Differentiated Service Class 383 Recommendations for LLN Traffic, 384 I-D.draft-svshah-tsvwg-lln-diffserv-recommendations", 385 Aug 2013. 387 Authors' Addresses 389 Shitanshu Shah 390 Cisco Systems 391 170 W. Tasman Drive 392 San Jose, CA 95134 393 US 395 Email: svshah@cisco.com 397 Pascal Thubert 398 Cisco Systems 399 Village d'Entreprises Green Side 400 400, Avenue de Roumanille 401 Batiment T3 402 Biot - Sophia Antipolis 06410 403 FRANCE 405 Email: pthubert@cisco.com