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