idnits 2.17.1 draft-varga-detnet-service-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 : ---------------------------------------------------------------------------- ** There are 32 instances of too long lines in the document, the longest one being 4 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 215 has weird spacing: '...e Layer and...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (May 2, 2017) is 2522 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'LSP-label' is mentioned on line 549, but not defined == Unused Reference: 'I-D.ietf-detnet-use-cases' is defined on line 1133, but no explicit reference was found in the text == Outdated reference: A later version (-13) exists of draft-ietf-detnet-architecture-00 ** Downref: Normative reference to an Informational draft: draft-ietf-detnet-dp-alt (ref. 'I-D.ietf-detnet-dp-alt') == Outdated reference: A later version (-20) exists of draft-ietf-detnet-use-cases-12 ** Downref: Normative reference to an Informational draft: draft-ietf-detnet-use-cases (ref. 'I-D.ietf-detnet-use-cases') ** Downref: Normative reference to an Informational RFC: RFC 7806 Summary: 4 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DetNet B. Varga, Ed. 3 Internet-Draft J. Farkas 4 Intended status: Standards Track Ericsson 5 Expires: November 3, 2017 May 2, 2017 7 DetNet Service Model 8 draft-varga-detnet-service-model-02 10 Abstract 12 This document describes service model for scenarios requiring 13 deterministic networking. 15 This new version 02 of the DetNet Service Model draft is primarily 16 intended to prevent it from expiring. Major parts of this document 17 were moved to the architecture draft, but some remaining text is 18 under discussion in the workgroup (e.g., QoS, etc.). 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on November 3, 2017. 37 Copyright Notice 39 Copyright (c) 2017 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 56 3. Terminology and Definitions . . . . . . . . . . . . . . . . . 3 57 4. End systems connected to DetNet . . . . . . . . . . . . . . . 4 58 5. DetNet service model . . . . . . . . . . . . . . . . . . . . 8 59 5.1. Service parameters . . . . . . . . . . . . . . . . . . . 8 60 5.2. Service overview . . . . . . . . . . . . . . . . . . . . 9 61 5.3. Reference Points . . . . . . . . . . . . . . . . . . . . 10 62 5.4. Service scenarios . . . . . . . . . . . . . . . . . . . . 11 63 5.5. Data flows . . . . . . . . . . . . . . . . . . . . . . . 11 64 5.6. Service components/segments . . . . . . . . . . . . . . . 12 65 6. DetNet service instances . . . . . . . . . . . . . . . . . . 12 66 6.1. Attributes used by DetNet functions . . . . . . . . . . . 12 67 6.2. Service instance for DetNet flows . . . . . . . . . . . . 13 68 7. DetNet flows over multiple technology domains . . . . . . . . 14 69 7.1. Flow attribute mapping between layers . . . . . . . . . . 14 70 7.2. Flow-ID mapping examples . . . . . . . . . . . . . . . . 15 71 8. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 72 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 73 10. Security Considerations . . . . . . . . . . . . . . . . . . . 18 74 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 75 12. Annex 1 - Service Instance shared by DetNet and regular 76 traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 77 12.1. L2 service instance shared by regular and DetNet traffic 18 78 12.2. L3 service instance shared by regular and DetNet traffic 19 79 13. Annex 2 - Integrating Layer 3 and Layer 2 QoS . . . . . . . . 20 80 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 81 14.1. Normative References . . . . . . . . . . . . . . . . . . 27 82 14.2. Informative References . . . . . . . . . . . . . . . . . 27 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 85 1. Introduction 87 A Deterministic Networking (DetNet) service provides a capability to 88 carry a unicast or a multicast data flow for an application with 89 constrained requirements on network performance, e.g., low packet 90 loss rate and/or latency. During the discussion of DetNet use cases, 91 DetNet architecture, and various related networking scenarios, 92 several confusions have been raised due to different service model 93 interpretations. This document defines service reference points, 94 service components and proposes naming for service scenarios to 95 achieve common understanding of the DetNet service model. 97 2. Conventions Used in This Document 99 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 100 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 101 document are to be interpreted as described in [RFC2119]. 103 The lowercase forms with an initial capital "Must", "Must Not", 104 "Shall", "Shall Not", "Should", "Should Not", "May", and "Optional" 105 in this document are to be interpreted in the sense defined in 106 [RFC2119], but are used where the normative behavior is defined in 107 documents published by SDOs other than the IETF. 109 3. Terminology and Definitions 111 Additional terms to [I-D.ietf-detnet-architecture] used in this 112 draft. 114 DetLink: Direct link between two entities (node/end system) used for 115 deterministic transport. 117 DetNet flow: A DetNet flow is a sequence of packets to which the 118 DetNet service is to be provided, see 119 [I-D.ietf-detnet-architecture]. This document distinguishes the 120 following three formats of DetNet flows: 122 App-flow: An App-flow is a data flow between the applications 123 requiring deterministic service. An App-flow does not contain 124 any DetNet related attributes. 126 DetNet-s-flow: A DetNet-s-flow is an App-flow extended with some 127 DetNet service layer attributes. 129 DetNet-st-flow: A DetNet-st-flow is an App-flow extended with 130 both DetNet service layer and DetNet transport layer 131 attributes, i.e., encapsulated according to the forwarding 132 paradigm of the DetNet domain. 134 DetNet-NNI: NNI between DetNet domains. 136 DetNet-UNI: UNI of a DetNet edge node to provide DetNet service for 137 a connected node or end system. 139 DetNetwork: Transport network between DetNet-st-flow endpoints. 141 4. End systems connected to DetNet 143 Deterministic connectivity service is required by time/loss sensitive 144 application(s) running on an end system during communication with its 145 peer(s). Such a data exchange has various requirements on delay and/ 146 or loss parameters. 148 A DetNet flow [I-D.ietf-detnet-architecture] can have different 149 formats during while it is transported between the peer end systems. 150 Therefore, the following possible formats of a DetNet flow are 151 distinguished in this document: 153 o App-flow: native format of a DetNet flow. It does not contain any 154 DetNet related attributes. 156 o DetNet-s-flow: specific format of a DetNet flow. It is an App- 157 flow extended with some DetNet service related attributes (i.e., 158 Flow-ID and/or Seq-num). 160 o DetNet-st-flow: specific format of a DetNet flow. It is an App- 161 flow extended with both DetNet service layer and DetNet transport 162 layer attributes, i.e., encapsulated according to the forwarding 163 paradigm of the DetNet domain. 165 App-flow and DetNet-s-flow are generated by end systems. DetNet-st- 166 flow can be generated by a DetNet edge node or an end system that is 167 an integral part of a DetNet domain. Further details are described 168 below. This document uses the exact DetNet flow type where it is 169 important to distinguish the flow type; otherwise, the generic term, 170 i.e., DetNet flow is used. 172 The native data flow between the source/destination end systems is 173 referred to as application-flow (App-flow) as shown in Figure 1. The 174 traffic characteristics of an App-flow can be CBR (constant bit rate) 175 or VBR (variable bit rate) and can have L1 or L2 or L3 encapsulation 176 (e.g., TDM (time-division multiplexing), Ethernet, IP). 178 [Note: Interworking function for L1 application-flows is out-of-scope 179 in this document, therefore, not depicted in figures.] 180 +-----------+ +-----------+ 181 / Application \<---native data flow--->/ Application \ 182 |-------------| (App-flow) +-------------+ 183 | End | | End | 184 | System | | System | 185 | -------- | | -------- | 186 | | NIC | | | | NIC | | 187 +-----+-------+ +-------+-----+ 188 | ____ ____ | 189 | __/ \_____/ \____ | 190 | / \ | 191 +--------| DetNet |-----+ 192 \ Networking / 193 \ ___ __ _/ 194 \__/ \___/ \____/ 196 Figure 1: End systems connected to DetNet 198 An end system may or may not be DetNet transport layer aware or 199 DetNet service layer aware, see [I-D.ietf-detnet-architecture]. That 200 is, an end system may or may not contain DetNet specific 201 functionality. End systems with DetNet functionalities may have the 202 same or different transport layer as the connected DetNet domain. 203 Grouping of end systems are shown in Figure 2. (Note: A "TSN end 204 system" of [I-D.ietf-detnet-dp-alt] is an example for a "DetNet 205 unaware end system".) 207 +---------------------------------------+ 208 No DetNet | DetNet unaware | 209 functions | end system | 210 +-------------------+-------------------+ 211 With DetNet | DetNet aware | DetNet | 212 Functions | end system | end system | 213 +-------------------+-------------------+ 214 Some DetNet DetNet Service 215 Service Layer and Transport Layer 217 Figure 2: Grouping of end systems 219 End system(s) may or may not be directly connected to the DetNet 220 transport network. This document assumes direct connection in the 221 remaining part. The end system types are: 223 o A "DetNet unaware end system" originates a native data flow (App- 224 flow). Such end systems usually assume dedicated (and direct) 225 connectivity to their peers, which is replaced by the DetNet 226 network. Its connection to a DetNet network requires a DetNet 227 edge node, that creates a DetNet-st-flow (with proper Flow-ID and 228 Seq-num attributes) by encapsulating the native data flow 229 according to the forwarding paradigm of the connected DetNet 230 domain. 232 o A "DetNet aware end system" may contain some DetNet specific 233 service functionalities and it extends the App-flow with related 234 DetNet specific flow attributes (i.e., Flow-ID and/or Seq-num). 235 The resulting flow is referred to as DetNet-s-flow as it contains 236 service layer specific fields, but the format of the DetNet-s-flow 237 encapsulation is not identical with the forwarding paradigm (i.e., 238 the transport layer) of the DetNet domain. Therefore, it has to 239 be connected to a DetNet edge node. DetNet aware end systems can 240 be, e.g., an IP end system with some DetNet service functions 241 connected to an MPLS-based DetNet domain. 243 o A "DetNet end node" has DetNet functionalities and the same 244 forwarding paradigm as the connected DetNet domain. It can be 245 treated as an integral part of the DetNet domain, therefore, it is 246 connected to a DetNet relay node (or to a DetNet transit node). 247 It originates a DetNet-st-flow (i.e., the App-flow is extended 248 within the end system with all the DetNet specific flow attributes 249 used inside the DetNet domain). 251 These end systems are shown in Figure 3. A DetNet-UNI ("U" on 252 Figure 3) is assumed in this document to be a packet-based reference 253 point and provides connectivity over the DetNet domain. A DetNet-UNI 254 may add forwarding technology specific encapsulation to the App-flow 255 / DetNet-s-flow and transport it as a DetNet-st-flow over the 256 network. 258 DetNet unaware DetNet aware 259 end system end system 260 _ _ 261 / \ / \ 262 /App\ /App\ 263 /--O--\<-----App-flow-- /-(O)-\ 264 | | |--V--|<--DetNet-s-flow-- 265 | NIC | <-DetNet-st-flow- | NIC | <-DetNet-st-flow- 266 +--+--+ +----+ +--+--+ +----+ 267 | | |T-PE| | | |T-PE| 268 +--------U +- +--------U +- 269 | | | | | | 270 | +----+ | +----+ 271 Attachment Edge Attachment Edge 272 Circuit Node Circuit Node 274 DetNet 275 end system 276 _ 277 / \ 278 /App\ 279 /-(O)-\ 280 |--W--|<--DetNet-st-flow-- 281 | NIC | 282 +--+--+ +----+ 283 | | |S-PE| 284 +--------+ +- 285 | | | 286 | +----+ 287 Internal Relay 288 Link Node 290 Figure 3: Types of end systems 292 [Note: DetNet aware end systems can be also treated as a special mix 293 of a DetNet unaware system and a DetNet end system. It is similar to 294 a DetNet end system as its data flow contains DetNet attributes, 295 however, those attributes cannot be used directly inside the DetNet 296 domain, e.g., due to the different transport layer. Therefore, it is 297 also similar to DetNet unaware end systems as it must be connected to 298 a DetNet edge node to adapt, e.g., the encapsulation of the DetNet 299 flow to the forwarding paradigm of the DetNet domain. A typical 300 example showing a DetNet aware end system can be the following 301 scenario: an end system encapsulates its App-flow in IP-RTP packets. 302 It assumes a single connection to its peer, therefore, the Seq-num 303 field is not used by the end-system. It is connected to an MPLS- 304 based DetNet domain that has redundant paths and applies service 305 protection via the duplication and elimination functionality. As per 306 [I-D.ietf-detnet-architecture], the addition or removal of packet 307 sequencing information is the job of a DetNet edge node. As 308 forwarding is MPLS-based, the Seq-num required for service protection 309 is created and added to the DetNet-s-flow by the DetNet edge node (in 310 the PW control-word field).] 312 5. DetNet service model 314 5.1. Service parameters 316 The DetNet service can be defined as a service that provides a 317 capability to carry a unicast or a multicast data flow for an 318 application with constrained requirements on network performance, 319 e.g., low packet loss rate and/or latency. 321 Delay and loss parameters are somewhat correlated because the effect 322 of late delivery can be equivalent to loss. However, not all 323 applications require hard limits on both parameters (delay and loss). 324 For example, some real-time applications allow graceful degradation 325 if loss happens (e.g., sample-based processing, media distribution). 326 Some others may require high-bandwidth connections that make the 327 usage of techniques like flow duplication economically challenging or 328 even impossible. Some applications may not tolerate loss, but are 329 not delay sensitive (e.g., bufferless sensors). 331 Primary transport service attributes for DetNet transport are: 333 o Bandwidth parameter(s), 335 o Delay parameter(s), 337 o Loss parameter(s), 339 o Connectivity type. 341 Time/loss sensitive applications may have somewhat special 342 requirements especially for loss (e.g., no loss in two consecutive 343 communication cycles; very low outage time, etc.). 345 Two connectivity types are distinguished: point-to-point (p2p) and 346 point-to-multipoint (p2mp). Connectivity type p2mp is created by a 347 transport layer function (e.g., p2mp LSP). (Note: mp2mp connectivity 348 is a superposition of p2mp connections.) 350 5.2. Service overview 352 The figures below show the DetNet service related reference points 353 and components for various end system scenarios (Figure 4 and 354 Figure 5). 356 DetNet DetNet 357 unaware aware 358 end system end system 359 _ _ 360 / \ / \ 361 /App\ +----DetNet-UNI (U) DetNet-UNI (U) /App\ 362 /--O--\ | [DetNet-NNI (N)] /-(O)-\ 363 | | | | |--V--| 364 | NIC | v ________ | | NIC | 365 +--+--+ _____ / \ +------+--+---------+ +--+--+ 366 | / \__/ \ | | | | 367 | / +----+ +----+ \_____ v | | | 368 | | / | | | | \_______ | | | 369 +--------U PE +----+ P +----+ \ v _ v | 370 | | | | | | | | ___/ \ | 371 | | +--+-+ +----+ | +----+ | / \_ | | 372 | \ | | | | | / \ | | 373 | \ | +----+ +--+-+ +--+PE U/N------N/U U------+ 374 | \ | | | | | | | | | \_ _/ | 375 | \ +---+ P +----+ P +--+ +----+ | \____/ | 376 AC \___ | | | | / AC 377 \ +----+__ +----+ Domain-1 Domain-2 378 | \_____/ \___________/ | 379 | | 380 | | End-to-End-Service | | | | 381 <--------------------------------------------------------------------> 382 | | | | | | 383 | | DetNet-Service | | | | 384 | <--------------------------------> <---------> | 385 | <--------------------------------N---------N---------> | 386 | | | | | | 387 | DetLink| | | | | 388 <--------> <---------> <------> 389 | | DetNetwork | | | | 390 | <--------------------------------> <---------> | 391 | <----------------------------------------------------> | 392 | | | | | | 394 Figure 4: DetNet Service Reference Model (multi-domain) 396 DetNet 397 unaware 398 end system 399 _ 400 / \ 401 /App\ +----DetNet-UNI (U) 402 /--O--\ | DetNet 403 | NIC | v ________ end system 404 +--+--+ _____ / \ _ 405 | / \__/ \ / \ 406 | / +----+ +----+ \_____ /App\ 407 | | / | | | | \_______/-(O)-\ 408 +--------U PE +----+ P +----+ |--W--| 409 | | | | | | | | NIC | 410 | | +--+-+ +----+ | +--+--+ 411 | \ | | | | 412 | \ | +----+ +--+-+ +---------+ | 413 | \ | | | | | | | 414 | \ +---+ P +----+ P +----+ _/ 415 AC \___ | | | | DetNet / 416 \ +----+__ +----+ Domain/ 417 | \_____/ \_______________/ | 418 | | 419 | | End-to-End-Service | 420 <---------------------------------------------> 421 | | DetNet-Service | | 422 | <------------------------------------> 423 | | | | 424 | DetLink| | DetLink | 425 <--------> DetNetwork <--------------> 426 | <---------------------> | 427 | | | | 429 Figure 5: DetNet Service Reference Model (single domain) 431 5.3. Reference Points 433 From service model design perspective a fundamental question is the 434 location of the service endpoints, i.e., where the service starts and 435 ends. The following reference points can be distinguished for the 436 DetNet use cases: 438 o App-flow endpoint: End system's internal reference point ("O") for 439 the native data flow. 441 o DetNet-s-flow endpoint: DetNet aware end system's internal 442 reference point ("V"). 444 o DetNet-st-flow endpoint: DetNet edge node UNI ("U") or DetNet end 445 system's internal reference point ("W"). 447 o DetNet-UNI: UNI interface ("U") on a DetNet edge node. 449 o DetNet-NNI: NNI interface ("N") between DetNet domains. 451 Data flow endpoints ("O", "V" and "W" in Figure 4 and Figure 5) are 452 more challenging from control perspective as they are internal 453 reference points of end systems. They are providing access to 454 deterministic transport for the native data flow (App-flow). 456 DetNet-UNI and DetNet-NNI ("U" and "N" in Figure 4) are assumed in 457 this document to be packet-based reference points and provide 458 connectivity over the packet network and between domains. A DetNet- 459 UNI adds networking technology specific encapsulation to the App-flow 460 / DetNet-s-flow in order to transport it as a DetNet-st-flow over the 461 network. There are many similarities regarding the functions of a 462 DetNet-st-flow endpoint ("W") and a DetNet-UNI ("U") but there may be 463 some differences. For example, in-order delivery is expected in end 464 system internal reference points, whereas it is considered optional 465 over the DetNet-UNI. 467 5.4. Service scenarios 469 Using the above defined reference points, two major service scenarios 470 can be identified: 472 o End-to-End-Service: the service reaches out to final source or 473 destination nodes, so it is an e2e service between application 474 hosting devices (end systems). 476 o DetNet-Service: the service connects networking islands, so it is 477 a service between the borders of network domain(s). 479 End-to-End-Service is defined between App-flow endpoints, whereas 480 DetNet-Service is between DetNet-st-flow endpoints. This allows the 481 peering of same layers/functions. 483 5.5. Data flows 485 Three possible DetNet flow formats are distinguished for unambiguous 486 references: 488 o App-flow: data flow requiring deterministic transport between two 489 App-flow endpoints; data format is application specific (e.g., bit 490 stream directly mapped to Ethernet frames, etc.). It does not 491 contain any DetNet attributes. 493 o DetNet-s-flow: similar to the App-flow, but extended with some 494 DetNet attributes as DetNet aware end systems have some DetNet 495 service layer functionalities. However, the encapsulation format 496 differs from the forwarding paradigm of the connected DetNet 497 domain, so those attributes cannot be used directly. 499 o DetNet-st-flow: data flow between DetNet-UNIs ("U") and/or DetNet 500 end systems ("W"). This flow is extended with both DetNet service 501 layer and DetNet transport layer attributes. This format allows 502 simple flow recognition/transport/etc. during forwarding in the 503 DetNet domain. 505 5.6. Service components/segments 507 The follwoing building blocks are used as reference to service 508 components/segments: 510 o DetLink: direct link between two entities (node/end system) used 511 for deterministic transport. 513 o DetNetwork: network between DetNet nodes. 515 Any DetNet service scenario can be described using DetLink and 516 DetNetwork components/segments. For example, the service between the 517 App-flow endpoints in Figure 4 can be composed as a DetLink-1 518 (between the end system on the left and the edge node of Domain-1) + 519 DetNetwork-1 (of Domain-1) + DetLink-2 (between Domain-1 and Domain- 520 2) + DetNetwork-2 (of Domain-2) + DetLink-3 (between edge node of 521 Domain-2 and the end system on the right). 523 6. DetNet service instances 525 6.1. Attributes used by DetNet functions 527 The three DetNet functions (congestion protection, explicit routes, 528 service protection) require two data flow related attributes to work 529 properly: 531 o Flow-ID and 533 o Sequence number (Seq-Num). 535 These attributes are extracted from the ingress packets of the node 536 [I-D.ietf-detnet-architecture]. Flow-ID is used by all the three 537 DetNet functions, but sequence number is used only by the duplicate 538 elimination functionality. 540 Flow-ID must be unique per network domain. Its encoding format is 541 specific to the forwarding paradigm of the domain and to the 542 capabilities of intermediate nodes to identify data flows. For 543 example, in case of "PW over MPLS", one option is to construct the 544 Flow-ID by the PW label and the LSP label (denoted as [PW-label;LSP- 545 label]). In such a case, intermediate P nodes have to check all 546 labels to identify a DetNet flow, what may not be a valid option in 547 some deployment scenarios. Another possible option is to use a 548 dedicated LSP per data flow, so the LSP label itself can be used as a 549 Flow-ID (denoted as [LSP-label]). In such a case, the intermediate P 550 nodes do not have to check the whole label stack to recognize a data 551 flow (DetNet flow), however, it results in larger L-FIB tables on the 552 MPLS nodes. 554 [Note: Seq-num requires a control-word in the label stack in MPLS 555 domains, which should be recognized by intermediate S-PE (relay) 556 nodes.] 558 6.2. Service instance for DetNet flows 560 The DetNet network reference model is shown in Figure 6 for a DetNet- 561 Service scenario (i.e. between two DetNet-UNIs). In this figure, the 562 end systems ("A" and "B") are connected directly to the edge nodes of 563 the PSN ("PE1" and "PE2"). End-systems participating DetNet 564 communication may require connectivity before setting up an App-flow 565 that requires the DetNet service. Such a service instance and the 566 one dedicated for DetNet service share the same attachment circuit. 567 Packets belonging to a DetNet flow are selected by a filter 568 configured on the attachment circuit ("F1" and "F2"). As a result, 569 data flow specific attachment circuits ("AC-A + F1" and "AC-B + F2") 570 are terminated in the flow specific service instance ("SI-1" and "SI- 571 2"). A PSN tunnel is used to provide connectivity between the 572 service instances. The encapsulation used over the PSN tunnel are 573 described in [I-D.ietf-detnet-dp-alt]. 575 The PSN tunnel is used to transport exclusivelly the packets of the 576 DetNet flow between "SI-1" and "SI-2". The service instances are 577 configured to implement a flow specific routing or bridging function 578 depending on what connectivity the participating end systems require 579 (L3 or L2). The service instance and the PSN tunnel may or may not 580 be shared by multiple DetNet flows. Sharing the service istance by 581 multiple DetNet flows requires properly populated forwarding tables 582 of the service instance. 584 Serving regular traffic and DetNet flows by the same service instance 585 is out-of-scope in this draft, but some related thoughts are 586 described in Annex 1. Such a combination can provide the required 587 connectivity before setting up a DetNet service. 589 AC-A AC-B 590 <-----> <-------- PSN tunnel --------> <-----> 592 +---------+ ___ _ +---------+ 593 | +----+ | / \/ \_ | +----+ | 594 "A" ----F1+ | | / \ | | +F2---- "B" 595 | | +==========+ PSN +========+ | | 596 | |SI-1| | \__ _/ | |SI-2| | 597 | +----+ | \____/ | +----+ | 598 |PE1 | | PE2| 599 +---------+ +---------+ 601 Figure 6: DetNet network reference model 603 [Note: There are differences in the usage of a "packet PW" for DetNet 604 traffic compared to the network model described in [RFC6658]. In the 605 DetNet scenario, the packet PW is used exclusivelly by the DetNet 606 flow, whereas [RFC6658] states: "The packet PW appears as a single 607 point-to-point link to the client layer. Network-layer adjacency 608 formation and maintenance between the client equipments will follow 609 the normal practice needed to support the required relationship in 610 the client layer ... This packet pseudowire is used to transport all 611 of the required layer 2 and layer 3 protocols between LSR1 and 612 LSR2".] 614 7. DetNet flows over multiple technology domains 616 7.1. Flow attribute mapping between layers 618 Transport of DetNet flows over multiple technology domains may 619 require that lower layers are aware of specific flows of higher 620 layers. Such an "exporting of flow identification" (see section 4.7 621 in [I-D.ietf-detnet-architecture]) is needed each time when the 622 forwarding paradigm is changed on the transport path (e.g., two LSRs 623 are interconnected by a L2 bridged domain, etc.). The three main 624 forwarding methods considered for deterministic networking are: 626 o IP routing 628 o MPLS label switching 630 o Ethernet bridging 632 The simplest solution for generalized flow identification could be to 633 define a unique Flow-ID triplet per DetNet flow (e.g., [IP: "IPv6- 634 flow-label"+"IPv6-address"; MPLS: "PW-label"+"LSP-label"; Ethernet: 635 "VLAN-ID"+"MAC-address"). This triplet can be used by the DetNet 636 encoding function of technology border nodes (where forwarding 637 paradigm changes) to adapt to capabilities of the next hop node. 638 They push a further (forwarding paradigm specific) Flow-ID to packet 639 header ensuring that flows can be easily recognized by domain 640 internal nodes. This additional Flow-ID might be removed when the 641 packet leaves a given technology domain. 643 [Note: Seq-num attribute may require a similar functionality at 644 technology border nodes.] 646 The additional (domain specific) Flow-ID can be 648 o created by a domain specific function or 650 o derived from the Flow-ID added to the App-flow, 652 so that it must be unique inside the given domain. Note, that the 653 Flow-ID added to the App-flow is still present in the packet, but 654 transport nodes may lack the function to recognize it; that's why the 655 additional Flow-ID is added (pushed). 657 7.2. Flow-ID mapping examples 659 IP nodes and MPLS nodes are assumed to be configured to push such an 660 additional (domain specific) Flow-ID when sending traffic to an 661 Ethernet switch (as shown in the examples below). 663 Figure 7 shows a scenario where an IP end system ("IP-A") is 664 connected via two Ethernet switches ("ETH-n") to an IP router ("IP- 665 1"). 667 IP domain 668 <----------------------------------------------- 670 +======+ +======+ 671 |L3-ID | |L3-ID | 672 +======+ /\ +-----+ +======+ 673 / \ Forwards as | | 674 /IP-A\ per ETH-ID |IP-1 | Recognize 675 Push ------> +-+----+ | +---+-+ <----- ETH-ID 676 ETH-ID | +----+-----+ | 677 | v v | 678 | +-----+ +-----+ | 679 +------+ | | +---------+ 680 +......+ |ETH-1+----+ETH-2| +======+ 681 .L3-ID . +-----+ +-----+ |L3-ID | 682 +======+ +......+ +======+ 683 |ETH-ID| .L3-ID . |ETH-ID| 684 +======+ +======+ +------+ 685 |ETH-ID| 686 +======+ 688 Ethernet domain 689 <----------------> 691 Figure 7: IP nodes interconnected by an Ethernet domain 693 End system "IP-A" uses the original App-flow specific ID ("L3-ID"), 694 but as it is connected to an Ethernet domain it has to push an 695 Ethernet-domain specific flow-ID ("VID + multicast MAC address", 696 referred as "ETH-ID") before sending the packet to "ETH-1" node. 697 Ethernet switch "ETH-1" can recognize the data flow based on the 698 "ETH-ID" and it does forwarding towards "ETH-2". "ETH-2" switches 699 the packet towards the IP router. "IP-1" must be configured to 700 receive the Ethernet Flow-ID specific multicast stream, but (as it is 701 an L3 node) it decodes the data flow ID based on the "L3-ID" fields 702 of the received packet. 704 Figure 8 shows a scenario where MPLS domain nodes ("PE-n" and "P-m") 705 are connected via two Ethernet switches ("ETH-n"). 707 MPLS domain 708 <-----------------------------------------------> 710 +=======+ +=======+ 711 |MPLS-ID| |MPLS-ID| 712 +=======+ +-----+ +-----+ +=======+ +-----+ 713 | | Forwards as | | | | 714 |PE-1 | per ETH-ID | P-2 +-----------+ PE-2| 715 Push -----> +-+---+ | +---+-+ +-----+ 716 ETH-ID | +-----+----+ | \ Recognize 717 | v v | +-- ETH-ID 718 | +-----+ +-----+ | 719 +---+ | | +----+ 720 +.......+ |ETH-1+----+ETH-2| +=======+ 721 .MPLS-ID. +-----+ +-----+ |MPLS-ID| 722 +=======+ +=======+ 723 |ETH-ID | +.......+ |ETH-ID | 724 +=======+ .MPLS-ID. +-------+ 725 +=======+ 726 |ETH-ID | 727 +=======+ 728 Ethernet domain 729 <----------------> 731 Figure 8: MPLS nodes interconnected by an Ethernet domain 733 "PE-1" uses the MPLS specific ID ("MPLS-ID"), but as it is connected 734 to an Ethernet domain it has to push an Ethernet-domain specific 735 flow-ID ("VID + multicast MAC address", referred as "ETH-ID") before 736 sending the packet to "ETH-1". Ethernet switch "ETH-1" can recognize 737 the data flow based on the "ETH-ID" and it does forwarding towards 738 "ETH-2". "ETH-2" switches the packet towards the MPLS node ("P-2"). 739 "P-2" must be configured to receive the Ethernet Flow-ID specific 740 multicast stream, but (as it is an MPLS node) it decodes the data 741 flow ID based on the "MPLS-ID" fields of the received packet. 743 8. Summary 745 This document describes DetNet service model. 747 9. IANA Considerations 749 N/A. 751 10. Security Considerations 753 N/A. 755 11. Acknowledgements 757 The authors wish to thank Lou Berger, Norman Finn, Jouni Korhonen and 758 the members of the data plane design team for their various 759 contributions, comments and suggestions regarding this work. 761 12. Annex 1 - Service Instance shared by DetNet and regular traffic 763 This Annex contains some thoughts about scenarios where the service 764 instance is shared by DetNet and regular traffic. 766 12.1. L2 service instance shared by regular and DetNet traffic 768 In case of a L2 VPN transport, the service instance implements 769 bridging. In MPLS-based PSN, there is a full mesh of PWs between 770 service instances of PE nodes. Adding DetNet flows to the network 771 results in a somewhat modified PW structure, as a DetNet flow 772 requires its unique Flow-ID to be encoded in the labeled packet. 774 +---------+ 775 | PE2| 776 | +----+ | 777 PW-12 | |SI-2| | 778 +----------------+ | | 779 +-----|---+ | +-+--+ | 780 | +--+-+ | +---|-----+ 781 "A" ------+ | | | 782 | |SI-1| | | 783 | +-+-++ | | PW-23 784 |PE1 . | | | 785 +----.-|- + | 786 . | + --|-----+ 787 . | PW-13 | +-+--+ | 788 . +---------------+ | | 789 . | | +------ "B" 790 +.................+SI-3| | 791 PW-AB | +----+ | 792 | PE3| 793 + --------+ 795 Figure 9: DetNet L2 VPN Service 797 Figure 9 shows a scenario where there is a DetNet flow between the 798 end systems ("A" and "B"). "SI-n" denotes the L2 VPN service 799 instance of "PEn". Regular traffic of the L2 VPN instance use "PW- 800 12", "PW-13" and "PW-23". However, for transport of DetNet traffic 801 between "A" and "B" a separate PW ("PW-AB") has to be used. "PW-AB" 802 is a somewhat special PW (called here "virtual PW") and it is treated 803 differently than PWs used by regular traffic (i.e., PW-13, PW-12, and 804 PW-23). Namely, "PW-AB" is used exclusivelly by the DetNet flow 805 between "A" and "B". "PW-AB" does not participate in flooding and no 806 MAC addresses are associated with it (not considered for the MAC 807 learning process). "PW-AB" may use the same LSP as "PW-13" or a 808 dedicated one. 810 Regular traffic between "A" and "B" has an encapsulation [PW-13_label 811 ; LSP_label], whereas DetNet flow has [PW-AB_label ; LSP_label]. 813 12.2. L3 service instance shared by regular and DetNet traffic 815 In case of a L3 DetNet service, the service instance implements 816 routing. In MPLS-based PSN, such a "routing service" can be provided 817 by IP VPNs ([RFC4364]). However, the IP VPN service adds only a 818 single label (VPN label) during forwarding, therefore, the label 819 stack does not contain a "control word" (i.e., there is no field to 820 encode a sequence number). Therefore, transport of DetNet flows 821 requires the combination of IP VPN and PW technologies. 823 Adding DetNet flows to the network results in a somewhat modified 824 label stack structure, as a DetNet flow requires its packet PW 825 encapsulation ([RFC6658]). 827 +---------+ 828 | PE2| 829 | +----+ | 830 VPN-12 | |SI-2| | 831 +----------------+ | | 832 +-----|---+ | +-+--+ | 833 | +--+-+ | +---|-----+ 834 "A" ------+ | | | 835 | |SI-1| | | 836 | +-+-++ | | VPN-23 837 |PE1 . | | | 838 +----.-|- + | 839 . | + --|-----+ 840 . | VPN-13 | +-+--+ | 841 . +---------------+ | | 842 . | | +------ "B" 843 +.................+SI-3| | 844 PW-AB | +----+ | 845 | PE3| 846 + --------+ 848 Figure 10: DetNet L3 VPN Service 850 Figure 10 shows a scenario where there is a DetNet flow between the 851 end systems ("A" and "B"). "SI-n" denotes the L3 VPN service 852 instance of "PEn". Regular traffic of the L3 VPN instance use as 853 service label "VPN-12", "VPN-13" and "VPN-23". However, for 854 transport of DetNet traffic between "A" and "B" a PW ("PW-AB") has to 855 be used, what ensures that DetNet flow can be recognized by 856 intermediate P nodes and a control world can be also present. "PW- 857 AB" is used exclusivelly by the DetNet flow between "A" and "B". 858 "PW-AB" may use the same LSP as regular traffic (labeled by "VPN-13") 859 or a dedicated one. 861 Regular traffic between "A" and "B" has an encapsulation [VPN- 862 13_label ; LSP_label], whereas DetNet flow has [PW-AB_label ; 863 LSP_label]. 865 13. Annex 2 - Integrating Layer 3 and Layer 2 QoS 867 Sophisticated QoS mechanisms are available in Layer 3 (L3), see, 868 e.g., [RFC7806] for an overview. Although, Layer 2 (L2) QoS and 869 queuing used to be simpler; it has been evolving, it is now equipped 870 with Time-Sensitive Networking (TSN) features [IEEE8021TSN]. The TSN 871 features may be beneficial or even essential for DetNet flows if 872 Layer 2 links or sub-networks are included in their path. Therefore, 873 it is worth investigating the problems arising when both Layer 3 and 874 Layer 2 QoS features are supported by a node; even without diving 875 deep into solution/implementation details. 877 In IEEE Std 802.1Q-2005, eight traffic classes are supported, 878 allowing separate queues for each priority as illustrated in 879 Figure 11. Any traffic class-based transmission selection algorithm 880 can be implemented in addition to the strict priority algorithm 881 mandated by IEEE Std 802.1Q-2005. The priority information is 882 encoded in the 3-bit field carried in a tag in the frame header. 883 Note that the IEEE 802.1Q architecture specifies queuing at the 884 output port; however, implementations may differ. Consequently, the 885 following figures only show the queuing at the output port that is 886 selected by the forwarding decision for the transmission of a frame. 888 | | | | | 889 +---v---+ +---v---+ +---v---+ +---v---+ +---v---+ 890 | Queue | | Queue | | Queue | | Queue | | Queue | 891 | for | | for | | for | | for | ... | for | 892 |Traffic| |Traffic| |Traffic| |Traffic| |Traffic| 893 |Class 7| |Class 6| |Class 5| |Class 4| |Class 0| 894 +---+---+ +---+---+ +---+---+ +---+---+ +---+---+ 895 | | | | | 896 +---v----------v----------v----------v-------------v---+ 897 | Transmission Selection | 898 +--------------------------+---------------------------+ 899 | 900 v 902 Figure 11: Queuing in IEEE 802.1Q-2005 904 The Layer 2 QoS architecture has been evolving, see, e.g., IEEE Std 905 802.1Q-2014 [IEEE8021Q], which specifies the Credit-Based Shaper 906 (originally specified by IEEE Std 802.1Qav). There are recent IEEE 907 802.3 and 802.1 standards and ongoing projects to enhance the QoS 908 supported by Ethernet and Layer 2 networks. For instance, frame 909 preemption is specified by IEEE Std 802.3br ([IEEE8023br], to be 910 amended to [IEEE8023]) and IEEE Std 802.1Qbu ([IEEE8021Qbu], to be 911 amended to [IEEE8021Q]) where time-critical (express) frames can 912 suspend the transmission of non-time-critical (preemptable) frames 913 while one or more time-critical frames are transmitted. Another 914 recently published specification is IEEE Std 802.1Qbv [IEEE8021Qbv], 915 which specifies time-aware queue-draining controlled by transmission 916 gates in order to schedule the transmission of frames relative to a 917 known timescale, which can be provided by time synchronization. The 918 architecture extended with time-aware queuing and frame preemption is 919 illustrated in Figure 12. These time-sensitive networking extensions 920 provide deterministic behavior in Layer 2 networks. The ongoing IEEE 921 802.1 projects provide further extensions to the QoS architecture, 922 e.g., ingress filtering and policing (P802.1Qci), cyclic queuing and 923 forwarding (P802.1Qch), and asynchronous traffic shaping (P802.1Qcr), 924 see [IEEE8021TSN]. 926 ...express traffic...|..........preemtable traffic...... 927 | | | | | . 928 +---v---+ +---v---+ +---v---+ +---v---+ +---v---+ . 929 | Queue | | Queue | | Queue | | Queue | | Queue | . 930 | for | | for | | for | | for | ... | for | . 931 |Traffic| |Traffic| |Traffic| |Traffic| |Traffic| . 932 |Class 7| |Class 6| |Class 5| |Class 4| |Class 0| . 933 +---+---+ +---+---+ +---+---+ +---+---+ +---+---+ . 934 | | | | | . 935 +---v---+ +---v---+ +---v---+ +---v---+ +---v---+ . 936 |Transm.| |Transm.| |Transm.| |Transm.| |Transm.| . 937 | Sel. | | Sel. | | Sel. | | Sel. | ... | Sel. | . 938 | Alg. | | Alg. | | Alg. | | Alg. | | Alg. | . 939 +---+---+ +---+---+ +---+---+ +---+---+ +---+---+ . 940 | | | | | 802.1Q 941 +---v---+ +---v---+ +---v---+ +---v---+ +---v---+ . 942 |Transm.| |Transm.| |Transm.| |Transm.| |Transm.| . 943 | Gate | | Gate | | Gate | | Gate | ... | Gate | . 944 +---+---+ +---+---+ +---+---+ +---+---+ +---+---+ . 945 | | | | | . 946 +---v----------v---+ +---v----------v-------------v---+ . 947 | Transmission | | Transmission | . 948 | Selection | | Selection | . 949 +--------+---------+ +----------------+---------------+ . 950 | | --x-- 951 +--------v---------+ +----------------v---------------+ . 952 | Express MAC | | Preemptable MAC | . 953 +--------+---------+ +----------------+---------------+ . 954 | | 802.3 955 +--------v-----------------------------v---------------+ . 956 | MAC merge sublayer | . 957 +--------------------------+---------------------------+ . 958 | . 959 +--------------------------v---------------------------+ . 960 | PHY (unaware of preemption) | . 961 +------------------------------------------------------+ . 963 Figure 12: L2 queuing and frame preemption 965 A QoS architecture integrating both Layer 3 and Layer 2 features is 966 necessary to exploit the benefits provided by the different layers if 967 a DetNet network includes link(s) or sub-network(s) equipped with TSN 968 features. For instance, it can be crucial for a time-critical DetNet 969 flow to leverage TSN features in a Layer 2 sub-network in order to 970 meet the DetNet flow's requirements, which may be spoiled otherwise. 972 Figure 13 provides a theoretical illustration for the integration of 973 the Layer 3 and Layer 2 QoS architecture. The figure only shows the 974 queuing after the routing decision. The figure also illustrates 975 potential implementation dependent borders (Brdr). The borders shown 976 in the figure are critical in the sense that the high priority DetNet 977 flows have to be transferred via a different Service Access Points 978 (SAPs) through these borders than the low priority (background) 979 flows. Having a single SAP for these very different traffic types 980 may result in possible QoS degradation for the DetNet flows because 981 packets of other flows could delay the transmission of DetNet 982 packets. For instance, different SAPs are needed for the DetNet 983 flows and other flows when they get to Layer 3 queuing after the 984 routing decision via Brdr-d. Furthermore, a different SAP is needed 985 for DetNet packets than other packets when they get to Layer 2 986 queuing from Layer 3 queuing via Brdr-c. Similarly, different SAPs 987 are needed for the express and for the preemptable frames when they 988 get to the MAC layer from Layer 2 queuing via Brdr-b, which is 989 provided by the IEEE 802.1Q architecture as shown in Figure 12. It 990 depends on the implementation whether or not Brdr-a exists. 992 ..priority (DetNet)..|............low priority......... . 993 | traffic | | traffic | . 994 xxx|xxxxxxxxxxx|xxxxxxxxxxx|xxxxxxxxxxxxxxxxxxxxxxx|xxxxx Brdr-d 995 | | | | . 996 +--v--+ +--v--+ +--v--+ +--v--+ . 997 |Queue| ... |Queue| |Queue| ... |Queue| . 998 | i | | j | | m | | n | . 999 +--+--+ +--+--+ +--+--+ +--+--+ . 1000 | | | | L3 1001 +--v-----------v--+ +--v-----------------------v--+ . 1002 | Selection | | Selection | . 1003 +--+-----------+--+ +--+---------+----------------+ . 1004 | | | | | . 1005 xxx|xxxxxxxxxxx|xxxxxxxxxxx|xxxxxxxxx|xxxxxxxxxxxxx|xxxxx Brdr-c 1006 | | | | | . 1007 +--v----+ +---v---+ +----v--+ +---v---+ +---v---+ . 1008 | Queue | | Queue | | Queue | | Queue | ... | Queue | . 1009 | (7) | | (6) | | (5) | | (4) | | (0) | . 1010 +---+---+ +---+---+ +---+---+ +---+---+ +---+---+ . 1011 | | | | | . 1012 +---v---+ +---v---+ +---v---+ +---v---+ +---v---+ . 1013 |Transm.| |Transm.| |Transm.| |Transm.| |Transm.| . 1014 |Sel. A.| |Sel. A.| |Sel. A.| |Sel. A.| ... |Sel. A.| . 1015 +---+---+ +---+---+ +---+---+ +---+---+ +---+---+ . 1016 | | | | | L2 1017 +---v---+ +---v---+ +---v---+ +---v---+ +---v---+ . 1018 | Gate | | Gate | | Gate | | Gate | ... | Gate | . 1019 +---+---+ +---+---+ +---+---+ +---+---+ +---+---+ . 1020 | | | | | . 1021 +---v----------v---+ +---v----------v-------------v---+ . 1022 |Transmission Sel. | | Transmission Selection | . 1023 +--------+---------+ +----------------+---------------+ . 1024 xxxxxxxxx|xxxxxxxxxxxxxxxxxxxxxxxxxxxxx|xxxxxxxxxxxxxxxxxx Brdr-b 1025 +--------v---------+ +----------------v---------------+ 1026 | Express MAC | | Preemptable MAC | 1027 +--------+---------+ +----------------+---------------+ 1028 | | 1029 +--------v-----------------------------v---------------+ 1030 | MAC merge sublayer | 1031 +--------------------------+---------------------------+ 1032 xxxxxxxxxxxxxxxxxxxxxxxxxxx|xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx Brdr-a 1033 +--------------------------v---------------------------+ 1034 | PHY | 1035 +------------------------------------------------------+ 1037 Figure 13: Integrated L3/L2 queuing architecture and implementation 1038 options 1040 Not all the functions depicted in Figure 13 are necessarily present 1041 in an implementation. A function may be combined with another one or 1042 may be completely missing. For instance, it may be the case that 1043 there is no Layer 3 queuing for DetNet packets, but they get directly 1044 to the Layer 2 queues. Alternatively, an implementation may combine 1045 the Layer 3 queues and the Layer 2 queues such that there is a single 1046 level of queues. There are further alternatives in addition to the 1047 ones mentioned here. 1049 Different implementation approaches, i.e., different node designs are 1050 illustrated in Figure 14 and Figure 15. Figure 14 illustrates a 1051 monolithic node design where there is a single feature rich chip and 1052 relatively simple interfaces. The single chip implements all routing 1053 (and/or bridging) features as well as almost all QoS features. (Some 1054 aspects of frame preemption may be implemented on the interface.) 1055 Figure 15 illustrates a linecard-based design where each linecard has 1056 its own chip, which implements routing and QoS features. 1058 +---------+ +----------------+ +---------+ 1059 |Interface| | | |Interface| 1060 +---------+ | | +---------+ 1061 | | 1062 +---------+ | | +---------+ 1063 |Interface| | | |Interface| 1064 +---------+ | | +---------+ 1065 | Chip | 1066 . | | . 1067 . | | . 1068 . | | . 1069 | | 1070 +---------+ | | +---------+ 1071 |Interface| | | |Interface| 1072 +---------+ +----------------+ +---------+ 1074 Figure 14: Monolithic node design 1076 +-----------------+ +---------+ +-----------------+ 1077 +---------+ +----+| | | |+----+ +---------+ 1078 |Interface| | || | | || | |Interface| 1079 +---------+ | || | | || | +---------+ 1080 | . | || | | || | . | 1081 | . |Chip|| | | ||Chip| . | 1082 | . | || | | || | . | 1083 +---------+ | || | | || | +---------+ 1084 |Interface| | || | | || | |Interface| 1085 +---------+ +----+| | | |+----+ +---------+ 1086 +-----------------+ | | +-----------------+ 1087 . | | . 1088 . |Backplane| . 1089 . | | . 1090 +-----------------+ | | +-----------------+ 1091 +---------+ +----+| | | |+----+ +---------+ 1092 |Interface| | || | | || | |Interface| 1093 +---------+ | || | | || | +---------+ 1094 | . | || | | || | . | 1095 | . |Chip|| | | ||Chip| . | 1096 | . | || | | || | . | 1097 +---------+ | || | | || | +---------+ 1098 |Interface| | || | | || | |Interface| 1099 +---------+ +----+| | | |+----+ +---------+ 1100 +-----------------+ +---------+ +-----------------+ 1102 Figure 15: Linecard-based node design 1104 Different implementations have different physical borders, which 1105 imply that different borders out of the ones illustrated in Figure 13 1106 exist in a given implementation. For instance, there is no physical 1107 border corresponding to Brdr-d (Figure 13) in the monolithic 1108 implementation approach (Figure 14). However, Brdr-d is inevitably 1109 there in the linecard-based implementation approach (Figure 15) due 1110 to the backplane. 1112 Altogether, it is essential to leverage the benefits of both Layer 3 1113 and Layer 2 QoS features if Layer 2 is also involved in the support 1114 of a DetNet flow. Exploiting both layers requires attention to the 1115 aspects explained related to Figure 12. Nevertheless, the actually 1116 important aspects largely depend on the implementation approach 1117 chosen, see, e.g., Figure 14 vs. Figure 15. 1119 14. References 1120 14.1. Normative References 1122 [I-D.ietf-detnet-architecture] 1123 Finn, N. and P. Thubert, "Deterministic Networking 1124 Architecture", draft-ietf-detnet-architecture-00 (work in 1125 progress), September 2016. 1127 [I-D.ietf-detnet-dp-alt] 1128 Korhonen, J., Farkas, J., Mirsky, G., Thubert, P., 1129 Zhuangyan, Z., and L. Berger, "DetNet Data Plane Protocol 1130 and Solution Alternatives", draft-ietf-detnet-dp-alt-00 1131 (work in progress), October 2016. 1133 [I-D.ietf-detnet-use-cases] 1134 Grossman, E., Gunther, C., Thubert, P., Wetterwald, P., 1135 Raymond, J., Korhonen, J., Kaneko, Y., Das, S., Zha, Y., 1136 Varga, B., Farkas, J., Goetz, F., Schmitt, J., Vilajosana, 1137 X., Mahmoodi, T., Spirou, S., and P. Vizarreta, 1138 "Deterministic Networking Use Cases", draft-ietf-detnet- 1139 use-cases-12 (work in progress), April 2017. 1141 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1142 Requirement Levels", BCP 14, RFC 2119, 1143 DOI 10.17487/RFC2119, March 1997, 1144 . 1146 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 1147 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 1148 2006, . 1150 [RFC6658] Bryant, S., Ed., Martini, L., Swallow, G., and A. Malis, 1151 "Packet Pseudowire Encapsulation over an MPLS PSN", 1152 RFC 6658, DOI 10.17487/RFC6658, July 2012, 1153 . 1155 [RFC7806] Baker, F. and R. Pan, "On Queuing, Marking, and Dropping", 1156 RFC 7806, DOI 10.17487/RFC7806, April 2016, 1157 . 1159 14.2. Informative References 1161 [IEEE8021Q] 1162 IEEE 802.1, "IEEE 802.1Q-2014: IEEE Standard for Local and 1163 metropolitan area networks - Bridges and Bridged 1164 Networks", 2014, . 1167 [IEEE8021Qbu] 1168 IEEE 802.1, "IEEE 802.1Qbu-2016: IEEE Standard for Local 1169 and metropolitan area networks - Bridges and Bridged 1170 Networks -- Amendment 26: Frame Preemption", 2016, 1171 . 1174 [IEEE8021Qbv] 1175 IEEE 802.1, "IEEE 802.1Qbv-2015: IEEE Standard for Local 1176 and metropolitan area networks - Bridges and Bridged 1177 Networks -- Amendment 25: Enhancements for Scheduled 1178 Traffic", 2015, . 1181 [IEEE8021TSN] 1182 IEEE 802.1, "IEEE 802.1 Time-Sensitive Networking (TSN) 1183 Task Group", . 1185 [IEEE8023] 1186 IEEE 802.3, "IEEE 802.3-2015: IEEE Standard for Local and 1187 metropolitan area networks - Ethernet", 2015, 1188 . 1191 [IEEE8023br] 1192 IEEE 802.3, "IEEE 802.3br-2016: IEEE Standard for Local 1193 and metropolitan area networks - Ethernet -- Amendment 5: 1194 Specification and Management Parameters for Interspersing 1195 Express Traffic", 2016, 1196 . 1199 Authors' Addresses 1201 Balazs Varga (editor) 1202 Ericsson 1203 Konyves Kalman krt. 11/B 1204 Budapest 1097 1205 Hungary 1207 Email: balazs.a.varga@ericsson.com 1208 Janos Farkas 1209 Ericsson 1210 Konyves Kalman krt. 11/B 1211 Budapest 1097 1212 Hungary 1214 Email: janos.farkas@ericsson.com