idnits 2.17.1 draft-svshah-tsvwg-deterministic-forwarding-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 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 (March 03, 2014) is 3699 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC4594' is defined on line 374, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2598 (Obsoleted by RFC 3246) Summary: 2 errors (**), 0 flaws (~~), 3 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: September 4, 2014 March 03, 2014 7 Deterministic Forwarding PHB 8 draft-svshah-tsvwg-deterministic-forwarding-01 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 September 4, 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 . . . . . . . . . . . . . . . . . . . . . . . . 10 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 timely(deterministic) delivery. 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, as defined in this 109 document, thus is more suitable for deterministic time sensitive 110 traffic. 112 Typically for an application where end to end deterministic service 113 is important, relevant traffic should be provisioned through DF PHB 114 at every hop in that end to end path. However, in cases where 115 intermediate hops (or DS domains) either do not support DF PHB or 116 supports only aggregated service classes described in RFC5127, DF 117 traffic in those DS domains MUST be mapped to Real Time Treatment 118 class (EF PHB) defined in RFC5127. Traffic in such scenario MUST be 119 conditioned at the Edge before entering and after exiting such DS 120 domains. This is described further in later section. 122 1.1. Use-cases 124 With an introduction of machine to machine networks over IP, a new 125 set of applications are emerging. Traffic types from such 126 applications/networks are some-what different from the traditional 127 traffic types. Though most traffic types have characteristics 128 similar to that of traditional ones [LLN-DIFF], certain control 129 signals for some of the applications are extremely sensitive to 130 latency and jitter thus deterministic service. Such control signals 131 demand much stricter latency and jitter, at pretty much decisive time 132 scheduled delivery, end to end. Industrial automation, Smart cities 133 and automobiles/planes/trains built around such networks are examples 134 of such use-cases. 136 Machine to machine networks may be implemented on varieties of Layer 137 2 protocols. 802.15e [TiSCH] and 802.1 are examples of layer 2 that 138 are enhancing their capabilities to allow time scheduled delivery of 139 packets. 141 ---+------------------------ 142 | Converged Campus Network 143 | 144 +-----+ 145 | | Gateway 146 | | 147 +-----+ 148 | 149 | Backbone 150 +--------------------+------------------+ 151 | | | 152 +-----+ +-----+ +-----+ 153 | | LLN border | | LLN border | | LLN border 154 o | | router | | router | | router 155 +-----+ +-----+ +-----+ 156 o o o o 157 o o o o o o o o o o o 158 o o o o o o o o o o o o o o o o o o 159 o o o o o o o o o o o o o o o o 160 o o M o o o o o o o o o o o o o 161 o o o o o o o o o 162 o o o o o 164 LLN-1 LLN-2 LLN-3 166 Taking use-case example from [TiSCH], as shown in the diagram, 167 multiple LL Networks are connected to each other via Backbone through 168 LLN Border routers. Each LL Network consist of many nodes. There is 169 different types of traffic forwarded through each LL node and from 170 one LL Network to another. Most LLN traffic types have 171 characteristics similar to that of traditional ones and thus can be 172 supported through existing Diffserv classes except time sensitive 173 control signals. Without segregating such control signals to a 174 specific Diffserv class would require Intserv support for LLN traffic 175 in such networks. All traffic would be subject to flow 176 classification to differentiate time sensitive control signals which 177 can be a big scale concern. Supporting time sensitive control 178 signals via newly proposed DF Diffserv class allows implementation of 179 Diffserv in LLN Networks. 181 2. Terminology 183 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 184 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 185 document are to be interpreted as described in RFC2119. 187 3. DF code-point Behavior 189 The DF PHB is to implement time scheduled forwarding treatment. 190 Provisioning of such a service has two parts, 192 1) Provisioning of the fixed/relative time for scheduling of such 193 service 194 2) Provisioning of the max size of the data to be transmitted at 195 each scheduled time. 197 Provisioned scheduled time may be absolute or relative. For example, 198 a DF class may be provisioned to schedule packets (or bytes) at every 199 fixed time. Fixed time can be time of a day or any other absolute 200 definition. In a multi hop forwarding of DF traffic, absolute time 201 service provisioning at each hop may require to be dependent on the 202 clock synchronization (clock synchronization is not in the scope of 203 this specification). In relative time scheduling, packets to be 204 scheduled at every specific interval or it could be relative to any 205 other specific event/trigger. The definition of the time interval or 206 any other event is relevant to that specific provisioned node only. 208 The size of the data to be transmitted, at each scheduled time 209 service, may be provisioned in the unit of bytes or time. The data 210 defined here is raw data transmitted over transmission media, 211 including Layer 2 header and any other overhead. Once DF PHB is 212 provisioned and enabled, forwarding treatment MUST service packets 213 (bytes) from this class at the scheduled time for max allowable size. 214 Scheduling MUST pre-empt any other service, including EF, during the 215 schedule time service for the DF class. In order to avoid incurred 216 latency to EF class of traffic, it is expected to carefully provision 217 DF class to limit scheduled time service to as minimal data 218 transmission that would prevent larger than expected delays to EF 219 class of traffic. 221 Provisioning can be done via any of multiple possible methods. It 222 could be via command interface, or could be via external provisioning 223 agents, or could be via some sort of signaling that may dynamically 224 pre-negotiate time window of transmission at each node in a network 225 path. 227 3.1. Potential implementation of DF scheduling 229 Following are examples of potential implementations. They are not 230 any form of guidelines or recommendations but simply a reference to 231 potential implementations. 233 There are at least two ways to implement scheduling for DF traffic 234 class. 236 1) One queue to buffer and schedule all DF traffic (from all flows), 238 2) Multiple sub-queues for DF traffic class, one queue for each DF 239 provisioned flow 241 Flow here represents macro definition, it does not have to be only 242 5-tuple. 244 Any chosen DF scheduling implementation MUST run traffic conditioning 245 at enqueue to decide if packets to be enqueued or discarded. 246 Discussed more in later section. 248 1) Single queue to buffer all DF traffic 250 This one queue maintains, possibly a circular, indexed buffer list. 251 Each index logically maps to each scheduled time service. If enqueue 252 conditioning not to discard a packet, packet gets en-queued at a 253 relevant index in the buffer list that maps to a relevant scheduled 254 time slot. If there is no packet(s) received for a specific 255 scheduled time service then then buffer index for that scheduled 256 service remains empty. This also means that during dequeue, at a 257 schedule time service, an empty index results in no dequeued packets 258 from the DF queue and thus nothing to be transmitted from the DF 259 queue at that point in time. Queuing system may de-queue packets 260 from non-DF queues when an index in DF buffer list found to be an 261 empty during a specific scheduled time service. 263 . 264 |`. 265 EF (Low latency) ----------------||----> `. 266 High | `. 267 . | `. 268 rate queues |`. | `. 269 AF1 ----||---> `. | `. 270 | `. | `. 271 AF3 ----||---> '------------------> '------> 272 | .' Low | .' 273 BE ----||---> .' | .' 274 | .' | .' 275 .' | .' 276 Deterministic| .' 277 DF ----------------||----> .' 278 (scheduled time/interrupt driven de-queue)|.' 280 2) multiple queues to buffer each DF traffic flows 282 If enqueue conditioning decides not to discard a packet, packet gets 283 enqueued in the relevant DF sub-queue designated for that flow. At a 284 scheduled time slot, scheduler dequeues a packet from the respective 285 sub-queue. Every scheduled time service interrupt is mapped to a 286 specific DF sub-queue to dequeue a packet from. 288 . 289 |`. 290 EF (Low latency) ----------------||----> `. 291 High | `. 292 . | `. 293 rate queues |`. | `. 294 AF1 ----||---> `. | `. 295 | `. | `. 296 AF3 ----||---> '------------------> '------> 297 | .' Low | .' 298 BE ----||---> .' | .' 299 | .' | .' 300 .' | .' 301 (DF queues) Deterministic| .' 302 DF (at interval 1, 6, 11 ..) ----||----> .' 303 DF (at interval 3, 8, 13 ..) ----||---->.' 304 (scheduled time/interrupt driven de-queue)| 306 3.2. Conditioning DF traffic at Enqueue 308 DF traffic MUST be conditioned at the enqueue. As per PHB 309 definition, packets are required to be scheduled and delivered at a 310 precise absolute or relative time interval. Any packet that has 311 missed the window of its service time MUST be discarded. That would 312 also mean any packet coming from the previous hop MUST be conditioned 313 at the enqueue for validity of its scheduled service. For example if 314 a DF queue is provisioned to serve a packet with less than x ms of 315 jitter and for an arrived packet, if next scheduled time for a packet 316 results in more than x ms of jitter then such packet MUST be 317 discarded. The enqueued packet MUST also be checked against the size 318 of the data. If size of the data to be enqueued in a DF queue is 319 bigger than what scheduled time slot is provisioned for then such 320 packet MUST be discarded. 322 4. Diffserv behavior through non-DF DS domains 324 In cases where DF traffic is forwarded through multiple DS domains, 325 DS domains close to the source and receiver understand application's 326 deterministic service requirement well and so MUST be provisioned for 327 the precise time scheduled forwarding treatment. Intermediate DS 328 domains MAY support DF PHB. Intermediate domains that can not 329 support DF PHB, DF traffic from such domains SHOULD get EF treatment, 330 as defined in RFC5127 for Real Time Service aggregation. Sender and 331 Receiver DS domains, in such cases, MUST condition DF traffic at the 332 respective Edge. If EF service through intermediate DS domains can 333 have a predictable upper bound, receiver DS domain Edge can add a 334 correction to an incurred latency/jitter with its own defined time 335 interval for DF service. 337 5. Updates to RFC4594 and RFC5127 339 This specification updates RFC4594 with an addition of a new Diffserv 340 Class. It also updates RFC5127 to aggregate DF class of traffic to 341 Real Time Aggregation Class. 343 6. IANA Considerations 345 This document defines a new DSCP code-point DF. IANA maintains the 346 list of existing DSCPs. Proposal is to allocate a new one for the DF 347 code-point. 349 7. Security Considerations 351 There is no security considerations required besides ones already 352 understood in the context of Differentiated services architecture 354 8. Acknowledgements 356 Fred Baker and Norm Finn. 358 9. References 360 9.1. Normative References 362 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 363 "Definition of the Differentiated Services Field (DS 364 Field) in the IPv4 and IPv6 Headers", RFC 2474, 365 December 1998. 367 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 368 and W. Weiss, "An Architecture for Differentiated 369 Services", RFC 2475, December 1998. 371 [RFC2598] Jacobson, V., Nichols, K., and K. Poduri, "An Expedited 372 Forwarding PHB", RFC 2598, June 1999. 374 [RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration 375 Guidelines for DiffServ Service Classes", RFC 4594, 376 August 2006. 378 [RFC5127] Chan, K., Babiarz, J., and F. Baker, "Aggregation of 379 Diffserv Service Classes", RFC 5127, February 2008. 381 9.2. Informative References 383 [TiSCH] Thubert, P., Watteyne, T., and R. Assimiti, "An 384 Architecture for IPv6 over the TSCH mode of IEEE 385 802.15.4e, I-D.draft-ietf-6tisch-architecture", Nov 2013. 387 [LLN-DIFF] 388 Shah, S. and P. Thubert, "Differentiated Service Class 389 Recommendations for LLN Traffic, 390 I-D.draft-svshah-tsvwg-lln-diffserv-recommendations", 391 Aug 2013. 393 Authors' Addresses 395 Shitanshu Shah 396 Cisco Systems 397 170 W. Tasman Drive 398 San Jose, CA 95134 399 US 401 Email: svshah@cisco.com 403 Pascal Thubert 404 Cisco Systems 405 Village d'Entreprises Green Side 406 400, Avenue de Roumanille 407 Batiment T3 408 Biot - Sophia Antipolis 06410 409 FRANCE 411 Email: pthubert@cisco.com