idnits 2.17.1 draft-svshah-tsvwg-deterministic-forwarding-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The 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 01, 2015) is 3316 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2474' is defined on line 291, but no explicit reference was found in the text == Unused Reference: 'RFC2475' is defined on line 296, but no explicit reference was found in the text == Unused Reference: 'RFC2598' is defined on line 300, but no explicit reference was found in the text == Unused Reference: 'RFC4594' is defined on line 303, but no explicit reference was found in the text == Unused Reference: 'TiSCH' is defined on line 312, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2598 (Obsoleted by RFC 3246) Summary: 2 errors (**), 0 flaws (~~), 7 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 2, 2015 March 01, 2015 7 Deterministic Forwarding PHB 8 draft-svshah-tsvwg-deterministic-forwarding-03 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 2, 2015. 36 Copyright Notice 38 Copyright (c) 2015 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 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 3. DF Per Hop Behavior . . . . . . . . . . . . . . . . . . . . . . 4 68 4. Traffic Conditioning . . . . . . . . . . . . . . . . . . . . . 4 69 5. Diffserv behavior through non-DF DS domain . . . . . . . . . . 5 70 6. Potential implementation of DF scheduling . . . . . . . . . . . 5 71 7. Updates to RFC4594 and RFC5127 . . . . . . . . . . . . . . . . 7 72 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 73 9. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 74 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 75 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 76 11.1. Normative References . . . . . . . . . . . . . . . . . . . 8 77 11.2. Informative References . . . . . . . . . . . . . . . . . . 8 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 80 1. Introduction 82 There is a demand to provide deterministic forwarding to certain type 83 of traffic in machine to machine networks over IP. With an 84 introduction of machine to machine networks over IP, a new set of IP 85 applications are emerging. Traffic types from such applications/ 86 networks are some-what different from the traditional traffic types. 87 Though most traffic types have characteristics similar to that of 88 traditional ones [LLN-DIFF], certain control signals for some of the 89 applications are extremely sensitive to latency and jitter and thus 90 timely scheduled delivery. End to end deterministic path for such 91 traffic may be through one or more administered inter-connected 92 machine to machine networks. 94 Deterministic Forwarding (DF) PHB group is a means for each node in 95 machine to machine networks, in an end to end path, to deliver 96 required deterministic behavior. DF class in each DS node is 97 allocated with a scheduled transmission time. DS node may be 98 allocated one scheduled time for the whole aggregate DF traffic, or 99 may be allocated with different schedule time for each micro-flow or 100 set of micro-flows in a DF class. IP packets that wish to use 101 deterministic service are assigned DF code-point, typically at the 102 originator of such traffic. 104 In a DS node, the level of forwarding determinism of an IP packet 105 depends on scheduled time, at which packet then serviced independent 106 of existence and load of any other type of traffic. For example when 107 a DF packet arrives at the DS node, it is queued until its 108 provisioned scheduled time of service. At the trigger of that 109 scheduled time, service to all other traffic is pre-empted to service 110 DF traffic. 112 This document describes the DF PHB group. DF capability is not a 113 required function for a DS-compliant node, but a DS-compliant node 114 that implements DF PHB group MUST conform to the specification in 115 this document. 117 Typically for an application where end to end deterministic service 118 is important, relevant traffic can be serviced through DF PHB at 119 every hop in the path. However, in cases where intermediate hops (or 120 DS domains) either do not support DF PHB or supports only aggregated 121 service classes described in RFC5127, DF traffic in those DS domains 122 MUST be mapped to Real Time Treatment class (EF PHB) defined in 123 RFC5127. Traffic in such scenario MUST be conditioned at the Edge 124 before entering and after exiting such DS domains. This is described 125 further in later section. 127 2. Terminology 129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 130 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 131 document are to be interpreted as described in RFC2119. 133 3. DF Per Hop Behavior 135 The DF PHB is to implement deterministic scheduled, deterministic in 136 terms of a time, forwarding treatment. DF traffic MUST be serviced 137 in a manner to meet configurable scheduled time. A DS node may pre- 138 allocate dedicated resources available at configured scheduled time 139 for optionally configurable maximum size of data. Every conforming 140 packet, belonging to DF class, gets deterministic service 141 irrespective of traffic in other Diffserv class and current load on 142 the system. A DS node MAY allow though its dedicated scheduled 143 resources available to other Differentiated service classes when DF 144 class does not have any packets to serve during its service time. 146 A DS node MAY be configured with the same parameters for the entire 147 DF traffic class or different parameters for each micro-flow in a DF 148 class. For the later case, DF traffic MUST be serviced in a manner 149 to meet scheduled service time for each individual micro-flow. Per- 150 flow DF parameters may be provisioned dynamically thru a signaling 151 protocol. Use of any signaling protocol is agnostic to the DF PHB 152 and thus out of scope of this specification [An example of such 153 signaling protocol referred in 6TisCH]. What signaling protocol 154 requires to convey, at minimum to each DS node in the end to end 155 path, is request for DF service along with the flow classification 156 and associated DF parameters, parameters like intended time of a 157 service and size of data to be transmitted during time of service. 158 In a packet path, packet first is classified if it belongs to DF PHB. 159 Once classified for DF PHB, it gets deterministic treatment if 160 provisioned for per-flow DF parameters or else gets aggregate DF 161 treatment. 163 4. Traffic Conditioning 165 A DF supported DS Domain MAY condition traffic at the ingress Edge of 166 the domain. Traffic conditioning MUST discard any incoming packet 167 that does not conform to the configured DF service. As per PHB 168 definition, packets are required to be scheduled and delivered at a 169 precise absolute or relative time interval. Any packet that has 170 missed the window of its service time MUST be discarded. For example 171 if a DF queue is provisioned to serve a packet with less than x ms of 172 jitter and for an arrived packet, if next scheduled time for a packet 173 results in more than x ms of jitter then such packet MUST be 174 discarded. The packet MUST also be checked against the size of the 175 data. If size of the packet is bigger than max size of the data a 176 scheduled time is provisioned to service then such packet MUST be 177 discarded. In addition to DS node at the ingress Edge of the domain, 178 other DS nodes in the path MAY implement Traffic Conditioning. 180 5. Diffserv behavior through non-DF DS domain 182 In deployments if two DF domains are connected through a domain that 183 does not support DF PHB, traffic from such intermediate domain MUST 184 be forwarded with low latency. DF traffic at the egress Edge of the 185 sender DF domain MUST be mapped to EF PHB aggregate service, defined 186 as Real Time Service aggregation in RFC5127. Such traffic when 187 entered in the receiving DF domain MUST be conditioned, as described 188 in earlier section, at the ingress Edge of that receiving domain. 190 6. Potential implementation of DF scheduling 192 Following are examples of potential implementations. They are not 193 any form of guidelines or recommendations but simply a reference to 194 potential implementations. 196 There are at least two ways to implement scheduling for DF traffic 197 class. 199 1) One queue to buffer and schedule all DF traffic (from all flows), 201 2) Multiple sub-queues for DF traffic class, one queue for each DF 202 provisioned flow 204 Any chosen DF scheduling implementation MUST run traffic conditioning 205 at enqueue to decide if packets to be enqueued or discarded. 206 Discussed more in later section. 208 1) Single queue to buffer all DF traffic 210 This single queue maintains, possibly a circular, indexed buffer 211 list. Each index logically maps to each scheduled time service. If 212 conditioning results in not to discard a packet, packet gets en- 213 queued at a relevant index in the buffer list that maps to a relevant 214 scheduled time slot. If there is no packet(s) received for a 215 specific scheduled time service then buffer index for that scheduled 216 service remains empty. This also means that during dequeue, at a 217 schedule time service, an empty index results in no dequeued packets 218 from the DF queue and thus nothing to be transmitted from the DF 219 queue at that point in time. Queuing system may de-queue packets 220 from non-DF queues when an index in DF buffer list found to be an 221 empty during a specific scheduled time service. 223 . 224 |`. 225 EF (Low latency) ----------------||----> `. 226 High | `. 227 . | `. 228 rate queues |`. | `. 229 AF1 ----||---> `. | `. 230 | `. | `. 231 AF3 ----||---> '------------------> '------> 232 | .' Low | .' 233 BE ----||---> .' | .' 234 | .' | .' 235 .' | .' 236 Deterministic| .' 237 DF ----------------||----> .' 238 (scheduled time/interrupt driven de-queue)|.' 240 2) multiple queues to buffer each DF traffic flows 242 If conditioning results in not to discard a packet, packet gets 243 enqueued in the relevant DF queue designated for that flow. At a 244 scheduled time slot, scheduler dequeues a packet from the respective 245 queue for that flow. Every scheduled time service interrupt is 246 mapped to a flow specific DF queue to dequeue a packet from. 248 . 249 |`. 250 EF (Low latency) ----------------||----> `. 251 High | `. 252 . | `. 253 rate queues |`. | `. 254 AF1 ----||---> `. | `. 255 | `. | `. 256 AF3 ----||---> '------------------> '------> 257 | .' Low | .' 258 BE ----||---> .' | .' 259 | .' | .' 260 .' | .' 261 (DF queues) Deterministic| .' 262 DF (at interval 1, 6, 11 ..) ----||----> .' 263 DF (at interval 3, 8, 13 ..) ----||---->.' 264 (scheduled time/interrupt driven de-queue)| 266 7. Updates to RFC4594 and RFC5127 268 This specification updates RFC4594 with an addition of a new Diffserv 269 Class. It also updates RFC5127 to aggregate DF class of traffic to 270 Real Time Aggregation Class. 272 8. IANA Considerations 274 This document defines a new DSCP code-point DF. IANA maintains the 275 list of existing DSCPs. Proposal is to allocate a new one for the DF 276 code-point. 278 9. Security Considerations 280 There is no security considerations required besides ones already 281 understood in the context of Differentiated services architecture 283 10. Acknowledgements 285 Fred Baker, Norm Finn, David Black, Brian Carpenter for their 286 comments and feed-back. 288 11. References 289 11.1. Normative References 291 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 292 "Definition of the Differentiated Services Field (DS 293 Field) in the IPv4 and IPv6 Headers", RFC 2474, 294 December 1998. 296 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 297 and W. Weiss, "An Architecture for Differentiated 298 Services", RFC 2475, December 1998. 300 [RFC2598] Jacobson, V., Nichols, K., and K. Poduri, "An Expedited 301 Forwarding PHB", RFC 2598, June 1999. 303 [RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration 304 Guidelines for DiffServ Service Classes", RFC 4594, 305 August 2006. 307 [RFC5127] Chan, K., Babiarz, J., and F. Baker, "Aggregation of 308 Diffserv Service Classes", RFC 5127, February 2008. 310 11.2. Informative References 312 [TiSCH] Thubert, P., Watteyne, T., and R. Assimiti, "An 313 Architecture for IPv6 over the TSCH mode of IEEE 314 802.15.4e, I-D.draft-ietf-6tisch-architecture", Nov 2013. 316 [LLN-DIFF] 317 Shah, S. and P. Thubert, "Differentiated Service Class 318 Recommendations for LLN Traffic, 319 I-D.draft-svshah-tsvwg-lln-diffserv-recommendations", 320 Aug 2013. 322 Authors' Addresses 324 Shitanshu Shah 325 Cisco Systems 326 170 W. Tasman Drive 327 San Jose, CA 95134 328 US 330 Email: svshah@cisco.com 331 Pascal Thubert 332 Cisco Systems 333 Village d'Entreprises Green Side 334 400, Avenue de Roumanille 335 Batiment T3 336 Biot - Sophia Antipolis 06410 337 FRANCE 339 Email: pthubert@cisco.com