idnits 2.17.1 draft-zha-detnet-flow-info-model-02.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (March 13, 2017) is 2600 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC3198' is mentioned on line 165, but not defined == Missing Reference: 'RFC 3290' is mentioned on line 395, but not defined == Unused Reference: 'RFC3290' is defined on line 560, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Y. Zha 2 Internet Draft Y. Jiang 3 Intended status: Informational Huawei Technologies 4 Expires: September 2017 L. Geng 5 China Mobile 7 March 13, 2017 9 Deterministic Networking Flow Information Model 10 draft-zha-detnet-flow-info-model-02 12 Abstract 14 Deterministic Networking (DetNet) provides end-to-end absolute 15 delay and loss guarantee to serve real-time applications. DetNet 16 is focused on a general approach that use techniques such as 1) 17 data plane resources reservation for DetNet flows; 2) providing 18 fixed path for DetNet flows; 3)sequentializng, replicating, and 19 eliminating duplicate packets transmission [draft-ietf-detnet- 20 architecture-00] to guarantee the worst case delay of DetNet flow 21 while allow sharing among best effort traffic. Data flow 22 information model is important to the DetNet work that it defines 23 information be used by flow establishment and control protocols. 24 This document describes and DetNet flow information model that 25 represents the flow identifier, traffic description information so 26 that can make resource reservation and provide differentiate 27 service. 29 Status of this Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF), its areas, and its working groups. Note that 36 other groups may also distribute working documents as Internet- 37 Drafts. 39 Internet-Drafts are draft documents valid for a maximum of six 40 months and may be updated, replaced, or obsoleted by other 41 documents at any time. It is inappropriate to use Internet-Drafts 42 as reference material or to cite them other than as "work in 43 progress." 45 The list of current Internet-Drafts can be accessed at 46 http://www.ietf.org/ietf/1id-abstracts.txt 47 The list of Internet-Draft Shadow Directories can be accessed at 48 http://www.ietf.org/shadow.html 50 This Internet-Draft will expire on September 13, 2017. 52 Copyright Notice 54 Copyright (c) 2014 IETF Trust and the persons identified as the 55 document authors. All rights reserved. 57 This document is subject to BCP 78 and the IETF Trust's Legal 58 Provisions Relating to IETF Documents 59 (http://trustee.ietf.org/license-info) in effect on the date of 60 publication of this document. Please review these documents 61 carefully, as they describe your rights and restrictions with 62 respect to this document. Code Components extracted from this 63 document must include Simplified BSD License text as described in 64 Section 4.e of the Trust Legal Provisions and are provided without 65 warranty as described in the Simplified BSD License. 67 Table of Contents 69 1. Introduction ................................................2 70 2. Conventions used in this document ............................3 71 3. DetNet Flow Information Model ................................4 72 3.1. Flow Identifier .........................................4 73 3.1.1. Layer 2 Flow Identification ........................5 74 3.1.2. Layer 3 Flow Identification ........................6 75 3.2. Transport Layer Information .............................6 76 3.3. Flow Traffic Description ................................7 77 3.3.1. Traffic Type .......................................9 78 3.3.2. Traffic Shaping ....................................9 79 3.4. Flow Statistics ........................................10 80 4. Use of Flow Information Model ...............................11 81 4.1. Mapping of Flow Information ............................11 82 4.2. Data Plane Configuration ...............................12 83 5. Security Considerations .....................................13 84 6. IANA Considerations .........................................13 85 7. Acknowledgments .............................................14 86 8. References ..................................................14 87 8.1. Normative References ...................................14 88 8.2. Informative References .................................14 90 1. Introduction 92 Deterministic service with both assured delay and data loss is 93 promising to service providers. Due to lack of deterministic 94 service provisioning mechanism there is no guarantee when 95 deploying a time critical service [RFC3393]. Deterministic 96 Networking (DetNet) tries to provide a solution to this issue with 97 limited scope that the data flows are constrained with some 98 maximum data rate properties. DetNet delivers assured end-to-end 99 latency and packet loss by dedicating network resources to DetNet 100 flows while unused reserved resource are still open to best effort 101 traffic. 103 In order to reserve proper amount of network resource to serve the 104 DetNet flow, the DetNet flow first needs to be described with such 105 parameters that can be understood by the network. Secondly, 106 current flow description and resource reservation are mainly 107 focused on bandwidth which is basically a statistical concept 108 during a relative long observation interval. And also, there are 109 different type of use cases those requires deterministic 110 networking services. All these use cases may send different kind 111 of traffics to the network with different deterministic service 112 provisioning requirements [draft-ietf-detnet-use-cases-11]. 114 Data plane techniques such as queuing, shaping, scheduling and 115 preemption are configured in a standard way to guarantee 116 deterministic forwarding behavior in the network device. The 117 controller or control plane takes the description of the DetNet 118 flow and then translates into data plane level configuration to 119 serve the flow. This is the key of DetNet as to define how to 120 describe DetNet flow and how to reserve network resource for it. 121 The flow description should be focused on traffic characteristics 122 of real time service with parameters that could be converted to 123 device level configurations. 125 An information model defines concepts in a uniform way, enabling 126 formal mapping processes to be developed to the information model 127 to a set of data models. This simplifies the process of 128 constructing software to automate the policy management process. 129 It also simplifies the language generation process, though that is 130 beyond the scope of this document. 132 This document describes an information model for representing 133 DetNet flow with comment concept and parameters of a DetNet 134 service that can be mapped into device level configurations. 136 2. Conventions used in this document 138 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 139 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" 140 in this document are to be interpreted as described in [RFC2119]. 142 In this document, these words will appear with that interpretation 143 only when in ALL CAPS. Lower case uses of these words are not to 144 be interpreted as carrying [RFC2119] significance. 146 3. DetNet Flow Information Model 148 According to current charter, DetNet information model is to 149 identify the information needed for flow establishment and control 150 and be used by reservation protocols and data plane configuration. 151 The work will be independent from the protocol(s) used to control 152 the flows. The DetNet information model presented in this document 153 defines some common concept of DetNet flows with information that 154 can be used for flow identification, flow monitoring, performance 155 management, reservation protocol, and data plane configuration. 156 For example, deterministic properties of controlled latency, low 157 packet loss, low packet delay variation, and high reliability. 158 More information can be added in the future. And each part of the 159 information model can be used individually by different network 160 function or network entities. The DetNet information model only 161 defines what kind of information is needed and how it could be 162 used. Data repository, data definition language, query language, 163 implementation language, and protocol should not be defined here. 164 More specifically, the information model can be used by a data 165 model for different scenarios. In [RFC3198], data model is "A 166 mapping of the contents of an information model into a form that 167 is specific to a particular type of data store or repository." 169 In this document, DetNet information model contains three sets of 170 information, flow identifier information, flow metering statistics, 171 and traffic description. 173 3.1. Flow Identifier 175 Flow identifier is the first step of flow description as DetNet 176 requires differentiate service so flow needs to be identified by 177 the data plane. The DetNet service is described at flow level so 178 each flow could have unique flow identifier. 180 +--------+ 181 | DetNet | --------+ +---------+ 182 | Sender |----\ /--- |||||---| | 183 +--------+ \ +-----------+ / --------+ |Trans- | 184 \ | DetNet |/ DetNet Queue |mission | 185 ---| Classifier|\ |Selection|--- 186 +-----------+ / +-----------+ \ --------+ | | 187 |Best Effort| / \--- ||||||||---| | 188 | Sender |-/ --------+ +---------+ 189 +-----------+ Best Effort Queue 190 Figure 1. DetNet Flow Being Classified 192 As shown in figure 1, network reserves dedicate resource for 193 DetNet flows which will be identified first to use the resource. 194 So a DetNet flow model should first contain information for flow 195 identification. As defined in [draft-ietf-detnet-architecture-00] 196 draft, deterministic service can be applied to both layer 2 and 197 layer 3 network, such as IP routing, MPLS labeling and Ethernet 198 bridging, flow identifier information is needed for both layers. 200 3.1.1. Layer 2 Flow Identification 202 Different flow indentifying technique may be used for different 203 networks. DetNet provides layering flow identification models that 204 can be used for both high layer and low layer. In [802.1qcc], 205 flow identification in layer 2 is usually by mac address plus 206 unique flow ID within the network domain. In access network which 207 is usually layer 2 network, flow is identified by Vlan and MAC 208 address. 210 +--------------+--------------+ 211 | Name | Elements | 212 +--------------+--------------+ 213 | | Source | 214 | | MacAddress | 215 | +--------------+ 216 | | Destination | 217 |Flow | MacAddress | 218 |Identifier +--------------+ 219 | | VlanID | 220 | +--------------+ 221 | | UniqueID | 222 +--------------+--------------+ 223 3.1.2. Layer 3 Flow Identification 225 In IP/MPLS network, flow identification in layer 3 is needed. For 226 example, a LSP is setup to forward packets destined to particular 227 IP address. If both DetNet flow and non-DetNet flow is sending to 228 same destination, how to provide differentiate service becomes 229 problem. First, the preliminary solution can be just provide 230 DetNet service at user level, which means assuming traffic from 231 particular source should be all performance guaranteed. Second, 232 put additional label for per flow identification. 234 +--------------+--------------+ 235 | Name | Elements | 236 +--------------+--------------+ 237 | | Protocol | 238 | +--------------+ 239 | | Source | 240 | | portID | 241 | +--------------+ 242 | | Destination | 243 |Flow | portID | 244 |Identifier +--------------+ 245 | | Source | 246 | | IpAddress | 247 | +--------------+ 248 | | Destination | 249 | | IpAddress | 250 | +--------------+ 251 | | UniqueID | 252 +--------------+--------------+ 254 3.2. Transport Layer Information 256 Since flow model is used and being mapped between multiple layers, 257 transport information is also mandatory. UDP flow and TCP flow 258 apparently have absolute different traffic behavior and working 259 mechanism which lead to different resource reservation scheme as 260 well as forwarding features. So the source tells the network 261 transport information of the flow it is going to send, e.g., 262 protocols related information. More details will be provided in 263 next version. 265 +--------------+----------------------+ 266 | Name | Elements | 267 +--------------+----------------------+ 268 | | udpSourcePort | 269 |UDP +----------------------+ 270 | | udpDestinationPort | 271 |--------------+----------------------+ 272 | | tcpSourcePort | 273 | +----------------------+ 274 | | tcpDestinationPort | 275 |TCP +----------------------+ 276 | | tcpWindowScale | 277 | +----------------------+ 278 | | tcpWindowSize | 279 +--------------+----------------------+ 281 3.3. Flow Traffic Description 283 The information model should contain traffic description 284 information to define the traffic profile from the source. DetNet 285 flow defines the source guarantee that is the promise of source 286 that the maximum amount traffic it can send. It is a kind of 287 contract between the source and network who serve the flow. If the 288 source is sending overload or different type of traffic, the 289 overload or traffic does not match the predefined traffic profile 290 will be not guaranteed. So the DetNet is that the source tells the 291 network "I will send the traffic like this", and the network will 292 reserve the resource for the flow based on its traffic 293 characteristics as defined in the model. 295 Unlike previous flow model or traffic profile which is mainly 296 based on bandwidth of service, DetNet flow should be more accurate 297 and at lower level for deterministic forwarding. For DetNet 298 service provisioning which is focused on absolute worst case delay, 299 the network needs to know not only the number of packets the flow 300 will be sending but also when or during what period of time the 301 source will be sending what amount of packets. Based on the 302 architecture draft, there are two kinds of flows, synchronous one 303 and asynchronous one. The information model of the DetNet flow 304 with traffic description information is shown as below. 306 +--------------+--------------+ 307 | Name | Elements | 308 +--------------+--------------+ 309 | | Guaranteed | 310 | +--------------+ 311 | | RealTime | 312 |ServiceType +--------------+ 313 | | Mux | 314 |--------------+--------------+ 315 |QoS | | 316 |--------------+--------------+ 317 |MTU | | 318 +--------------+--------------+ 319 |Bandwidth | | 320 +--------------+--------------+ 321 |Burst | | 322 |Periodic | | 323 +--------------+--------------+ 324 |PeriodValue | | 325 +--------------+--------------+ 326 | |BurstID | 327 | +--------------+ 328 | |BurstLegnth | 329 | +--------------+ 330 |Burst |MaxFrames | 331 | +--------------+ 332 | |MaxFrameSize | 333 | +--------------+ 334 | |StartTime | 335 | +--------------+ 336 | |EndTime | 337 +--------------+--------------+ 339 The basic idea is that the flow consists of a list of bursts. The 340 Burst is a set of packets with burst duration. The burst is close 341 related to service traffic pattern and also it is dependent on the 342 data plane technique. 344 There are two basic requirements for traffic information 345 definition, first it can be used to describe service; second the 346 parameter defined here can be mapped to data plane configuration. 348 3.3.1. Traffic Type 350 Back to ATM era, when service wants to send traffic to a broadband 351 network, it must inform network with information about what kind 352 of traffic it is going to send as well as the performance 353 requirements. DetNet provides absolute service guarantee for 354 limited amount traffic, so the network also requires the 355 information of traffic of the flow, such as constant rate flow, 356 vibrate rate flow or unspecified. Then the network can make 357 appropriate resource reservation for specific flow. E.g., for a 358 VBR flow, peak rate can be 3-7 times over sustained rate which 359 lead to sophisticated reservation scheme. 361 +---------------+--------------+ 362 | Name | Elements | 363 +---------------+--------------+ 364 | | CBR | 365 | +--------------+ 366 |TrafficType | VBR | 367 | +--------------+ 368 | | UBR | 369 |---------------+--------------+ 371 3.3.2. Traffic Shaping 373 As mentioned above, DetNet service only guarantee limited traffic 374 with bounded delay. It is usually not easy to regulate source 375 behavior when sending traffic, so shaping is necessary in DetNet 376 working system. Meanwhile, only DetNet traffic that follows the 377 predefined traffic behavior will be served properly, those 378 overloaded will not be guaranteed. 380 On the other hand, shaping procedure as one of the necessary 381 working components needs to de standardized for deterministic 382 delay provisioning. Network or control plane needs to know how the 383 shaping, queuing and scheduling is performed to calculate delay. 384 As shaping and queuing in DetNet is a per-flow based, the flow 385 model contains information about shaping information. 387 There are two commonly used shapers, leaky bucket and token bucket. 388 Leaky bucket is defined to limit both bandwidth and burstiness of 389 packet transmission and is recommended for ATM network with 390 constant output rate. There are multiple implementations of leaky 391 bucket, below is a set of parameters for one leaky bucket model. 393 Token bucket, on the other hand is a shaping and policing model 394 used for many protocols such as RSVP. Below is a Two-Parameter 395 Token Bucket [RFC 3290]. 397 +--------------+--------------+ 398 | Name | Elements | 399 +--------------+--------------+ 400 | | BufferSize | 401 | +--------------+ 402 |Leaky Bucket | InputRate | 403 | +--------------+ 404 | | OutputRate | 405 | +--------------+ 406 | | InitialBuffer| 407 |--------------+--------------+ 408 | | Burst | 409 |Token Bucket +--------------+ 410 | | TokenRate | 411 +--------------+--------------+ 413 3.4. Flow Statistics 415 As a matter of fact, there is no mechanism to provide flow delay 416 and loss parameter, which is also important for DetNet service. 417 Keeping the knowledge of flow-based delay and loss information is 418 also crucial for OAM and fault management. 420 The detail of flow metering statistic information in the 421 information model will be proposed in next version. 423 +--------------+--------------+ 424 | Name | Elements | 425 +--------------+--------------+ 426 |MaxDelay | | 427 |--------------+--------------+ 428 |MaxPacketLoss | | 429 +--------------+--------------+ 430 | | FlowStart | 431 |TimeStamp +--------------+ 432 | | FlowEnd | 433 |--------------+--------------+ 434 4. Use of Flow Information Model 436 As defined in current charter, DetNet flow information model is 437 used for flow establishment and control and can also be used by 438 reservation protocols and YANG data models. 440 4.1. Mapping of Flow Information 442 This section proposes a way to map information model parameters 443 into network configuration. [802.1qcc] defined stream reservation 444 protocols in layer 2 network with deterministic characteristics. 445 DetNet works on layer 3, which will not be covered by 802.1qcc. 446 Figure 2 shows that, DetNet flow model is used to configure the 447 DetNet network, e.g., TSN network. Some of the flow information 448 defined in this model is mapped in to 802.1qcc parameters to 449 configure TSN domain. 451 +---------------------------------+ 452 | DetNet Flow Model | 453 +---------------------------------+ 454 V V 455 V V 456 +---------------+ V 457 | TSN Network | V 458 | Configuration | V 459 +---------------+ V 460 | 802.1qcc | V 461 ____ | | V 462 / \ | | V 463 / \____V___________ | V 464 ____/ \ | V _ 465 / \V________________ _V___/ \ 466 | +------+ +---+ +---+ +--------+ \ / \_ 467 | |Talker|=====|NE |=========|NE |===|Listener| | | \ 468 \ +------+ +---+ +---+ +--------+ | \_ / 469 \ ______ / \______/ 470 \ / \ / 471 \_________/ \_______________Domain 1_/ Domain 2 473 Figure 2. DetNet Flow Model to TSN Configuration 475 4.2. Data Plane Configuration 477 As defined in current charter, the DetNet data plane should be TSN 478 compatible. Take TSN TAS (Time Aware Shaper) for example, the 479 information defined in the flow model can be mapped to data plane 480 parameter to configure TSN time aware shaper that provides a 481 deterministic forwarding behavior for the flow. 483 As defined in previous section, information model contains traffic 484 description of DetNet flow that can be used to configure data 485 plane. In this section, take TSN time aware shaper as an example 486 for data plane technique, mapping of data flow parameter to TAS 487 configuration is presented. 489 The basic idea is that, the controller or network control plane 490 takes data flow traffic description as the request and compute the 491 associated time interval and control list of the TAS gate control 492 function. Data flow model contains timing information of the 493 DetNet flow as it arrives at T1 and ends at T2, which can be 494 mapped into control list of TAS to reserve an open gate for the 495 DetNet flow for time period T1 to T2. As shown in figure 2, a 496 DetNet flow with data traffic between T1 and T2 send the request 497 to controller or control plane, and then the control plane uses 498 the information to configure the TAS based on current status of 499 TAS. Finally, the TAS function being configured with control list 500 update for open gate transmission for this flow during T1 and T2. 501 As a result, ideally, the flow will be transmitted immediately 502 using the dedicated open gate time slot with absolute delay and 503 loss guarantee. 505 T1 T2 DetNet data flow 506 +---------------+ /___________\ Traffic description 507 |Data flow model| \ / 508 +---------------+ ||||||||||||| 509 | | 510 | | 511 \ / 512 +---------------+ 513 | Control Plane | 514 +---------------+ 515 / \ 516 | | 517 \ / 518 +-----------------------------+ Control List 519 | Time Aware Shaper | T0 CCCCCCCO 520 | | T1 OCCCCCCC 521 | --------+ +----+ +---------+| T2 CCCCCCCO 522 | |||||-|Gate|-| || . 523 | --------+ +----+ | || . 524 |DetNet Queue |Trans- || . 525 | . |mission || Tn CCCCCCCC 526 | . |Selection|| 527 | . | || 528 | --------+ +----+ | || 529 | |||||-|Gate|-| || 530 | --------+ +----+ +---------+| 531 |Best Effort | 532 |Queue | 533 +-----------------------------+ 534 Figure 3. Mapping of Flow Model into TAS Configuration 536 5. Security Considerations 538 TBD 540 6. IANA Considerations 542 This document has no actions for IANA. 544 7. Acknowledgments 546 This document has benefited from reviews, suggestions, comments 547 and proposed text provided by the following members, listed in 548 alphabetical order: Jinchun Xu and Hengjun Zhu. 550 8. References 552 8.1. Normative References 554 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 555 Requirement Levels", BCP 14, RFC 2119, March 1997. 557 [RFC3393] C. Demichelis, "IP Packet Delay Variation Metric for IP 558 Performance Metrics (IPPM) ", RFC 3393, November 2002. 560 [RFC3290] Y. Bernet, "An Informal Management Model for Diffserv 561 Routers", RFC 3290, May 2002. 563 8.2. Informative References 565 [draft-ietf-detnet-use-cases-11] 567 Grossman, E., et al. "Deterministic Networking Problem Statement", 568 draft draft-ietf-detnet-use-cases-11 (work in progress), October 569 2016. 571 [draft-ietf-detnet-architecture-00] 573 Finn, N., Thubert, P., and M. Teener, "Deterministic Networking 574 Architecture", draft-ietf-detnet-architecture-00 (work in 575 progress), October 2016. 577 [802.1qcc] 579 IEEE 802.1Qcc, Draft 1.2, Mar 2017. 581 Authors' Addresses 583 Yiyong Zha 584 Huawei Technologies 585 Email: zhayiyong@huawei.com 587 Yuanlong Jiang 588 Huawei Technologies 589 Email: jiangyuanlong@huawei.com 591 Liang Geng 592 China Mobile 593 Email: gengliang@chinamobile.com