idnits 2.17.1 draft-dt-detnet-dp-sol-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 637 has weird spacing: '..."Packet o <-...' == Line 642 has weird spacing: '...Service o<--...' == Line 647 has weird spacing: '...Service o<--...' == Line 652 has weird spacing: '...Service o<--...' == Line 716 has weird spacing: '...Service o -...' == (3 more instances...) == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (June 30, 2017) is 2491 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: 'Network' is mentioned on line 263, but not defined == Missing Reference: 'TBD' is mentioned on line 1046, but not defined == Unused Reference: 'RFC7510' is defined on line 1186, but no explicit reference was found in the text == Unused Reference: 'RFC4023' is defined on line 1240, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 3985 == Outdated reference: A later version (-26) exists of draft-ietf-6man-segment-routing-header-06 == Outdated reference: A later version (-13) exists of draft-ietf-detnet-architecture-02 Summary: 1 error (**), 0 flaws (~~), 14 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DetNet J. Korhonen, Ed. 3 Internet-Draft 4 Intended status: Standards Track L. Andersson 5 Expires: January 1, 2018 Y. Jiang 6 N. Finn 7 Huawei 8 B. Varga 9 J. Farkas 10 Ericsson 11 CJ. Bernardos 12 UC3M 13 T. Mizrahi 14 Marvell 15 L. Berger 16 LabN 17 June 30, 2017 19 DetNet Data Plane Encapsulation 20 draft-dt-detnet-dp-sol-01 22 Abstract 24 This document specifies Deterministic Networking data plane 25 encapsulation solutions. The described data plane solutions can be 26 applied over either IP or MPLS Packet Switched Networks. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on January 1, 2018. 45 Copyright Notice 47 Copyright (c) 2017 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 2.1. Terms used in this document . . . . . . . . . . . . . . . 4 65 2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 5 66 3. Requirements language . . . . . . . . . . . . . . . . . . . . 6 67 4. DetNet data plane overview . . . . . . . . . . . . . . . . . 6 68 4.1. DetNet data plane encapsulation requirements . . . . . . 8 69 5. DetNet data plane solution . . . . . . . . . . . . . . . . . 9 70 5.1. DetNet specific packet fields . . . . . . . . . . . . . . 9 71 5.2. DetNet encapsulation . . . . . . . . . . . . . . . . . . 9 72 5.2.1. PseudoWire-based data plane encapsulation . . . . . . 9 73 5.2.2. Native IPv6-based data plane encapsulation . . . . . 11 74 5.3. DetNet flow identification for duplicate detection . . . 12 75 5.3.1. PseudoWire encapsulation . . . . . . . . . . . . . . 13 76 5.3.2. Native IPv6 encapsulation . . . . . . . . . . . . . . 13 77 6. PREF specific considerations . . . . . . . . . . . . . . . . 13 78 6.1. PseudoWire-based data plane . . . . . . . . . . . . . . . 13 79 6.1.1. Forwarder clarifications . . . . . . . . . . . . . . 13 80 6.1.2. Edge node processing clarifications . . . . . . . . . 14 81 6.1.3. Relay node processing clarifications . . . . . . . . 16 82 6.2. Native IPv6-based data plane . . . . . . . . . . . . . . 17 83 7. Other DetNet data plane considerations . . . . . . . . . . . 17 84 7.1. Class of Service . . . . . . . . . . . . . . . . . . . . 17 85 7.2. Quality of Service . . . . . . . . . . . . . . . . . . . 18 86 7.3. Cross-DetNet flow resource aggregation . . . . . . . . . 19 87 7.4. Bidirectional traffic . . . . . . . . . . . . . . . . . . 20 88 7.5. Layer 2 addressing and QoS Considerations . . . . . . . . 21 89 7.6. Interworking between PW- and IPv6-based encapsulations . 21 90 8. Time synchronization . . . . . . . . . . . . . . . . . . . . 21 91 9. Management and control considerations . . . . . . . . . . . . 23 92 9.1. PW Label and IPv6 Flow Label assignment and distribution 23 93 9.2. Packet replication and elimination . . . . . . . . . . . 23 94 9.3. Explicit paths . . . . . . . . . . . . . . . . . . . . . 23 95 9.4. Congestion protection and latency control . . . . . . . . 23 96 9.5. Flow aggregation control . . . . . . . . . . . . . . . . 24 97 10. Security considerations . . . . . . . . . . . . . . . . . . . 24 98 11. IANA considerations . . . . . . . . . . . . . . . . . . . . . 24 99 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24 100 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 101 13.1. Normative references . . . . . . . . . . . . . . . . . . 25 102 13.2. Informative references . . . . . . . . . . . . . . . . . 27 103 Appendix A. Example of DetNet data plane operation . . . . . . . 28 104 Appendix B. Example of pinned paths using IPv6 . . . . . . . . . 29 105 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 107 1. Introduction 109 Deterministic Networking (DetNet) is a service that can be offered by 110 a network to DetNet flows. DetNet provides these flows extremely low 111 packet loss rates and assured maximum end-to-end delivery latency. 112 General background and concepts of DetNet can be found in 113 [I-D.ietf-detnet-architecture]. 115 This document specifies the DetNet data plane. It defines how DetNet 116 traffic is encapsulated at the network layer, and how DetNet-aware 117 nodes can identity DetNet flows. Two data plane definitions are 118 given. 120 o PW-based: One solution is based on PseudoWires (PW) [RFC3985] and 121 makes use of multi-segment pseudowires (MS-PW) [RFC6073] to map 122 DetNet Relay and Edge Nodes [I-D.ietf-detnet-architecture] 123 [I-D.ietf-detnet-dp-alt] to PW architecture. The PW-based data 124 plane can be run over an MPLS [RFC4448] [RFC6658] Packet Switched 125 Network (PSN). 127 o Native-IP: The other solution is based on IP header fields, namely 128 on the IPv6 Flow Label and a new DetNet Control Word extension 129 header option. It is targeted for native IPv6 networks. 131 It is worth noting that while PWs are designed to work over IP PSNs 132 this document describes a native-IP solution that operates without 133 PWs. The primary reason for this is the benefit gained by enabling 134 the use of a normal application stack, where transport protocols such 135 as TCP or UDP are directly encapsulated in IP. 137 This document specifies the encapsulation for DetNet flows, including 138 a DetNet Control Word (CW). Furthermore, it describes how DetNet 139 flows are identified, how DetNet Relay and Edge nodes work, and how 140 the Packet Replication and Elimination function (PREF) is implemented 141 with these two data plane solutions. This document does not define 142 the associated control plane functions, or Operations, 143 Administration, and Maintenance (OAM). It also does not specify 144 traffic handling capabilities required to deliver congestion 145 protection and latency control to DetNet flows as this is defined to 146 be provided by the underlying MPLS or IP network. 148 2. Terminology 150 2.1. Terms used in this document 152 This document uses the terminology established in the DetNet 153 architecture [I-D.ietf-detnet-architecture] and the DetNet Data Plane 154 Solution Alternatives [I-D.ietf-detnet-dp-alt]. 156 The following terms are also used in this document: 158 DA-T-PE MPLS based DetNet edge node: a DetNet-aware PseudoWire 159 Terminating Provider Edge (T-PE). 161 DA-S-PE MPLS based DetNet relay node: a DetNet-aware PseudoWire 162 Switching Provider Edge (S-PE). 164 T-Label A label used to identify the LSP used to transport a 165 DetNet flow across an MPLS PSN, e.g., a hop-by-hop 166 label used between label switching routers (LSR). 168 S-Label A DetNet node to DetNet node "service" label that is 169 used between DA-*-PE devices. 171 PW Label A PseudoWire label that is used to identify DetNet flow 172 related PW Instances within a PE node. 174 Flow Label IPv6 header field that is used to identify a DetNet 175 flow (together with the source IP address field). 177 local-ID An edge and relay node internal construct that uniquely 178 identifies a DetNet flow. It may be used to select 179 proper forwarding and/or DetNet specific service 180 function. 182 PREF A Packet Replication and Elimination Function (PREF) 183 does the replication and elimination processing of 184 DetNet flow packets in edge or relay nodes. The 185 replication function is essentially the existing 1+1 186 protection mechanism. The elimination function reuses 187 and extends the existing duplicate detection mechanism 188 to operate over multiple (separate) DetNet member flows 189 of a DetNet compound flow. 191 2.2. Abbreviations 193 The following abbreviations used in this document: 195 AC Attachment Circuit. 197 CE Customer Edge equipment. 199 CoS Class of Service. 201 CW Control Word. 203 d-CW DetNet Control Word. 205 DetNet Deterministic Networking. 207 DF DetNet Flow. 209 L2VPN Layer 2 Virtual Private Network. 211 LSR Label Switching Router. 213 MPLS Multiprotocol Label Switching. 215 MPLS-TP Multiprotocol Label Switching - Transport Profile. 217 MS-PW Multi-Segment PseudoWire (MS-PW). 219 NSP Native Service Processing. 221 OAM Operations, Administration, and Maintenance. 223 PE Provider Edge. 225 PREF Packet Replication and Elimination Function. 227 PSN Packet Switched Network. 229 PW PseudoWire. 231 QoS Quality of Service. 233 TSN Time-Sensitive Network. 235 3. Requirements language 237 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL" "SHALL NOT", 238 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 239 document are to be interpreted as described in [RFC2119]. 241 4. DetNet data plane overview 243 This document describes how to use IP and/or MPLS to support a data 244 plane method of flow identification and packet formwarding over 245 layer-3. Two different cases are covered: (i) the inter-connect 246 scenario, in which IEEE802.1 TSN is routed over a layer-3 network 247 (i.e., to enlarge the layer-2 domain), and (ii) native connectivity 248 between DetNet-aware end systems. Figure 1 illustrates an exemplary 249 scenario. 251 TSN Edge Transit Relay DetNet 252 End System Node Node Node End System 254 +---------+ +.........+ +---------+ 255 | Appl. |<---:Svc Proxy:-- End to End Service ---------->| Appl. | 256 +---------+ +---------+ +---------+ +---------+ 257 | TSN | |TSN| |Svc|<-- DetNet flow ---: Service :-->| Service | 258 +---------+ +---+ +---+ +---------+ +---------+ +---------+ 259 |Transport| |Trp| |Trp| |Transport| |Trp| |Trp| |Transport| 260 +-------.-+ +-.-+ +-.-+ +--.----.-+ +-.-+ +-.-+ +---.-----+ 261 : Link : / ,-----. \ : Link : / ,-----. \ 262 +........+ +-[ Sub ]-+ +........+ +-[ Sub ]-+ 263 [Network] [Network] 264 `-----' `-----' 266 Figure 1: A simple DetNet enabled network architecture 268 Figure 2 illustrates how DetNet can provide services for IEEE 269 802.1TSN end systems over a DetNet enabled network. The edge nodes 270 insert and remove required DetNet data plane encapsulation. The 'X' 271 in the edge and relay nodes represents a potential DetNet flow packet 272 replication and elimination point. This conceptually parallels L2VPN 273 services, and could leverage existing related solutions as discussed 274 below. 276 TSN |<---------- End to End DetNet Service ------>| TSN 277 Service | Transit Transit | Service 278 TSN (AC) | |<-Tunnel->| |<-Tnl->| | (AC) TSN 279 End | V V 1 V V 2 V V | End 280 System | +--------+ +--------+ +--------+ | System 281 +---+ | | E1 |==========| R1 |=======| E2 | | +---+ 282 | |--|----|._X_....|..DetNet..|.._ _...|..DF3..|...._X_.|---|---| | 283 |CE1| | | \ | Flow 1 | X | | / | | |CE2| 284 | | | \_.|...DF2....|._/ \_..|..DF4..|._/ | | | 285 +---+ | |==========| |=======| | +---+ 286 ^ +--------+ +--------+ +--------+ ^ 287 | Edge Node Relay Node Edge Node | 288 | | 289 |<----- Emulated Time Sensitive Networking (TSN) Service ---->| 291 Figure 2: IEEE 802.1TSN over DetNet 293 Figure 3 illustrates how end to end PW-based DetNet service can be 294 provided. In this case, the end systems are able to send and receive 295 DetNet flows. For example, an end system sends data encapsulated in 296 PseudoWire (PW) and in MPLS. Like earlier the 'X' in the end 297 systems, edge and relay nodes represents potential DetNet flow packet 298 replication and elimination points. Here the relay nodes may change 299 the underlying transport, for example tunneling IP over MPLS, or 300 simply interconnect network segments. 302 DetNet DetNet 303 Service Transit Transit Service 304 DetNet | |<-Tnl->| |<-Tnl->| | DetNet 305 End | V 1 V V 2 V | End 306 System | +--------+ +--------+ +--------+ | System 307 +---+ | | R1 |=======| R2 |=======| R3 | | +---+ 308 | X...DFa...|._X_....|..DF1..|.__ ___.|..DF3..|...._X_.|.DFa..|.X | 309 |CE1|========| \ | | X | | / |======|CE2| 310 | | | | \_.|..DF2..|._/ \__.|..DF4..|._/ | | | | 311 +---+ | |=======| |=======| | +---+ 312 ^ +--------+ +--------+ +--------+ ^ 313 | Relay Node Relay Node Relay Node | 314 | | 315 |<--------------- End to End DetNet Service -------------->| 317 Figure 3: PW-Based Native DetNet 319 Figure 4 illustrates how end to end IP-based DetNet service can be 320 provided. In this case, the end systems are able to send and receive 321 DetNet flows. [Editor's note: TBD] 322 NOTE: This figures is TBD 324 DetNet DetNet 325 Service Transit Transit Service 326 DetNet | |<-Tnl->| |<-Tnl->| | DetNet 327 End | V 1 V V 2 V | End 328 System | +--------+ +--------+ +--------+ | System 329 +---+ | | R1 |=======| R2 |=======| R3 | | +---+ 330 | X...DFa...| | | | | | .|.X | 331 | H1|========| | | | | |======| H2| 332 | | | | | | | | | | | | 333 +---+ | |=======| |=======| | +---+ 334 ^ +--------+ +--------+ +--------+ ^ 335 | Relay Node Relay Node Relay Node | 336 | | 337 |<--------------- End to End DetNet Service -------------->| 339 Figure 4: IP-Based Native DetNet 341 4.1. DetNet data plane encapsulation requirements 343 Two major groups of scenarios can be distinguished which require flow 344 identification during transport: 346 1. DetNet function related scenarios: 348 * Congestion protection and latency control: usage of allocated 349 resources (queuing, policing, shaping). 351 * Explicit routes: select/apply the flow specific path. 353 * Service protection: recognize DetNet compound and member flows 354 for replication an elimination. 356 2. OAM function related scenarios: 358 * troubleshooting (e.g., identify misbehaving flows, etc.) 360 * recognize flow(s) for analytics (e.g., increase counters, 361 etc.) 363 * correlate events with flows (e.g., volume above threshold, 364 etc.) 366 * etc. 368 Each node (edge, relay and transit) use a local-ID of the DetNet- 369 (compound)-flow in order to accomplish its role during transport. 371 Recognizing the DetNet flow is more relaxed for edge and relay nodes, 372 as they are fully aware of both the DetNet service and transport 373 layers. The primary DetNet role of intermediate transport nodes is 374 limited to ensuring congestion protection and latency control for the 375 above listed DetNet functions. 377 The DetNet data plane allows for the aggregation of DetNet flows, 378 e.g., via MPLS hierarchical LSPs, to improved scaling. When DetNet 379 flows are aggregated, transit nodes may have limited ability to 380 provide service on per-flow DetNet identifiers. Therefore, 381 identifying each individual DetNet flow on a transit node may not be 382 achieved in some network scenarios, but DetNet service can still be 383 assured in these scenarios through resource allocation and control. 385 On each node dealing with DetNet flows, a local-ID is assumed to 386 determine what local operation a packet goes through. Therefore, 387 local-IDs MUST be unique on each edge and relay nodes. Local-ID MUST 388 be unambiguously bound to the DetNet flow. 390 5. DetNet data plane solution 392 5.1. DetNet specific packet fields 394 The DetNet data plane encapsulation should include two DetNet 395 specific information element in each packet of a DetNet flow: (1) 396 flow identification and (2) sequence number. 398 The DetNet data plane encapsulation may consists further elements 399 used for overlay tunneling, to distinguish between DetNet member 400 flows of the same DetNet compound flow or to support OAM functions. 402 5.2. DetNet encapsulation 404 This document specifies two encapsulations for the DetNet data plane: 405 (1) PseudoWire (PW) for MPLS PSN and (2) native IPv6 based 406 encapsulation for IP PSN. 408 5.2.1. PseudoWire-based data plane encapsulation 410 Figure 5 illustrates a DetNet PW encapsulation over an MPLS PSN. The 411 PW-based encapsulation of the DetNet flows fits perfectly for the 412 Layer-2 interconnect deployment cases (see Figure 2). Furthermore, 413 end to end DetNet service i.e., native DetNet deployment (see 414 Figure 3) is also possible if DetNet-aware end systems are capable of 415 initiating and termination MPLS encapsulated PWs. It is also 416 possible use the same encapsulation format with a Packet PW over MPLS 417 [RFC6658]. Transport of IP encapsulated DetNet flows, see 418 Section 5.2.2, over DetNet PWs is also possible. Interworking 419 between PW- and IPv6-based encapsulations is discussed further in 420 Section 7.6. 422 The PW-based DetNet data plane encapsulation consists of: 424 o DetNet control word (d-CW) containing sequencing information for 425 packet replication and duplicate elimination purposes. There is a 426 separate sequence number space for each DetNet flow. 428 o PseudoWire Label (PW Label) that is a standard PW label 429 identifying a DetNet flow and a PW Instance within a (DA-)T-PE or 430 (DA-)S-PE device. 432 o An optional S-Label that represents DetNet Service LSP used 433 between (DA-)T-PE or (DA-)S-PE nodes. One possible use of an 434 S-Label is to identify the different DetNet member flows used to 435 provide protection to a DetNet composite flow, perhaps even when 436 both LSPs appear on the same link for some reason. 438 o MPLS transport LSP label(s) (T-label) which may be a hop-by-hop 439 label used between LSRs. 441 RFC3985 Encapsulation DetNet PW Encapsulation 443 +---------------------+ 444 | Payload | +---------------------------------+ 445 /=====================\ | | 446 H Payload Convergence H--. | DetNet Flow | 447 H---------------------H | | Payload Packet | 448 H Timing H +-\ | | 449 H---------------------H | \ /=================================\ 450 H Sequencing H--' \-->H DetNet Control Word H 451 \=====================/ \=================================/ 452 | PW Demultiplexer |--------->| PW Label | 453 +---------------------+ +---------------------------------+ 454 | PSN Convergence | .--->| Optional MPLS S-Label | 455 +---------------------+ | +---------------------------------+ 456 | PSN |-----+--->| MPLS T-Label(s) | 457 +---------------------+ +---------------------------------+ 458 | Data-Link | 459 +---------------------+ 460 | Physical | 461 +---------------------+ 463 Figure 5: Encapsulation of a DetNet flow in a PW with MPLS(-TP) PSN 465 The DetNet control word (d-CW) is identical to the control word 466 defined for Ethernet over MPLS networks in [RFC4448]. The DetNet 467 control word is illustrated in Figure 6. 469 0 1 2 3 470 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 472 |0 0 0 0| reserved - set to 0 | 16 bit Sequence Number | 473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 475 Figure 6: DetNet Control Word 477 5.2.2. Native IPv6-based data plane encapsulation 479 Figure 7 illustrates a DetNet native IPv6 encapsulation. The native 480 IPv6 encapsulation is meant for end to end Detnet service use cases, 481 where the end stations are DetNet-aware (see Figure 4). Technically 482 it is possible to use the IPv6 encapsulation to tunnel any traffic 483 over a DetNet enabled network, which would make native IPv6 484 encapsulation also a valid data plane choice for an interconnect use 485 case (see Figure 2). 487 The native IPv6-based DetNet data plane encapsulation consists of: 489 o IPv6 header as the transport protocol. 491 o IPv6 header Flow Label that is used to help to identify a DetNet 492 flow (i.e., roughly an equivalent to the PW Label). A Flow Label 493 together with the IPv6 source address uniquely identifies a DetNet 494 flow. 496 o DetNet Control Word IPv6 Destination Option containing sequencing 497 information for packet replication and duplicate elimination 498 function (PREF) purposes. The DetNet Destination Option is 499 equivalent to the DetNet Control Word. 501 A DetNet-aware end station (a host) or an intermediate node 502 initiating an IPv6 packet is responsible for setting the Flow Label, 503 adding the required DetNet Destination Option, and possibly adding a 504 routing header such as the segment routing option (for pre-defined 505 paths [I-D.ietf-6man-segment-routing-header]). The payload of the 506 native IPv6 encapsulation is any payload protocol that can be 507 identified using the Next Header field either in the IPv6 packet 508 header or in the last IPv6 extension header. 510 A DetNet-aware end station (a host) or an intermediate node receiving 511 an IPv6 packet destined to it and containing a DetNet Destination 512 Option does the appropriate processing of the packet. This may 513 involve packet duplication and elimination (PREF processing), 514 terminating a tunnel or delivering the packet to the upper layers/ 515 Applications. 517 +---------------------------------+ 518 | | 519 | DetNet Flow | 520 | Payload | 521 | | 522 /---------------------------------\ 523 H DetNet Control Word DstOpt Hdr H 524 \---------------------------------/ 525 | IPv6 header | 526 | (with set Flow label) | 527 +---------------------------------+ 529 Figure 7: Encapsulation of a native IPv6 DetNet flow 531 A DetNet flow must carry sequencing information for packet 532 replication and elimination function (PREF) purposes. This document 533 specifies a new IPv6 Destination Option: the DetNet Destination 534 Option for that purpose. The format of the option is illustrated in 535 Figure 8. 537 0 1 2 3 538 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 540 | TBD1 | 4 | Reserved | 541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 542 | 16 bit Sequence Number | 543 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 545 Figure 8: DetNet Destination Option 547 The Option Type for the DetNet Destination Option is set to TBD1. 548 [To be removed from the final version of the document: The Option 549 Type MUST have the two most significant bits set to 10b] 551 5.3. DetNet flow identification for duplicate detection 553 Duplicate elimination depends on flow identification. Mapping 554 between packet fields and Local-ID may impact the implementation of 555 duplicate elimination. 557 5.3.1. PseudoWire encapsulation 559 RFC3985 Section 5.2.1. describes PW sequencing provides a duplicate 560 detection service among other things. This specification clarifies 561 this definition as follows: 563 DetNet flows that need to undergo PREF processing MUST have the 564 same PW Label when they arrive at the DA-*-PE node. 566 From the label stack processing point of view receiving the same 567 label from multiple sources is analogous to Fast Reroute backup 568 tunnel behavior [RFC4090]. The PW Label for a DetNet flow can be 569 different on each PW segment. 571 5.3.2. Native IPv6 encapsulation 573 The DetNet flow identification is based on the IPv6 Flow Label and 574 the source address combination. The two fields uniquelly identify 575 the end to end native IPv6 encapsulated DetNet flow. Obviously, the 576 identification fails if any intermediate node modifies either the 577 source address or the Flow Label. 579 6. PREF specific considerations 581 This section applies equally to DetNet flows transported via IPv6 and 582 MPLS. While flow identification and some header related processing 583 will differ between the two, the considerations covered in this 584 section are common to both. 586 6.1. PseudoWire-based data plane 588 6.1.1. Forwarder clarifications 590 The DetNet specific new functionality in an edge or relay node 591 processing is the packet replication and duplication elimination 592 function (PREF). This function is a part of the DetNet-aware 593 "extended" forwarder. The PREF processing is triggered by the 594 received packet of a DetNet flow. Basically the forwarding entry has 595 to be extended with a "PREF enabled" boolean configuration switch 596 that is associated with the normal forwarding actions (e.g., in case 597 of MPLS a swap, push, pop, ..). The output of the PREF elimination 598 function is always a single packet. The output of the PREF 599 replication function is always one or more packets (i.e., 1:M 600 replication). The replicated packets MUST share the same DetNet 601 control word sequence number. 603 The complex part of the DetNet PREF processing is tracking the 604 history of received packets for multiple DetNet member flows. These 605 ingress DetNet member flows (to a node) MUST have the same local-ID 606 if they belong to the same DetNet-(compound)-flow and share the same 607 sequence number counter and the history information. 609 The edge and relay node internal procedures of the PREF are 610 implementation specific. The order of a packet elimination or 611 replication is out of scope in this specification. However, care 612 should be taken that the replication function does not actually 613 loopback packets as "replicas". Looped back packets include 614 artificial delay when the node that originally initiated the packet 615 receives it again. Also, looped back packets may make the network 616 condition to look healthier than it actually is (in some cases link 617 failures are not reflected properly because looped back packets make 618 the situation appear better than it actually is). 620 6.1.2. Edge node processing clarifications 622 The DetNet data plane solution overloads the edge node with DetNet 623 Edge Node functions. Edge nodes are also aware of DetNet flows and 624 may need to operate upon those. Figure 9 illustrates the overall 625 edge device functions. The figure shows both physical attachment 626 circuit (AC) (e.g., Ethernet [RFC4448]) connecting to the edge node, 627 and a packet service connecting to the edge node via an embedded 628 router function (similarly as described e.g., in [RFC6658]). Whether 629 traffic flow from a client AC and PSN tunnel receives DetNet specific 630 treatment is up to a local configuration and policy. 632 +---------------------------------------+ 633 | DetNet Edge Device | 634 +---------------------------------------+ Egress/ 635 | | Forwarder | | Ingress 636 | | | Single | member Inst. 637 Client PSN | "Packet o <-X-----> o Service o<----------> 638 tunnels | NSP" | | Repl. | Instance | 639 <---------->o | | Elim. +-------------+ Duplicate 640 | | : | | Egress 641 | | . | Single | member Inst. 642 | | +-> o Service o<----------> 643 | | | | Instance | 644 +-------------+ | +-------------+ Egress/ 645 | | | | | Ingress 646 Client AC | NSP | Repl. | | Single | member Inst. 647 <---------->o o <-----X-> o Service o<----------> 648 | | Elim. | Instance | 649 +-------------+ +-------------+ Egress/ 650 | | | | Ingress 651 Client AC | NSP | | Single | member Inst. 652 <---------->o o <-------> o Service o<----------> 653 | | | Instance | 654 +---------------------------------------+ 656 Figure 9: DetNet Edge Node processing 658 An edge node participates to the packet replication and duplication 659 elimination. Required processing is done within an extended 660 forwarder function. In the case the native service processing (NSP) 661 is IEEE 802.1CB [IEEE8021CB] capable, the packet replication and 662 duplicate elimination MAY entirely be done in the NSP and bypassing 663 the DetNet flow encapsulation and logic entirely, and thus is able to 664 operate over unmodified implementation and deployment. The NSP 665 approach works only between edge nodes and cannot make use of relay 666 nodes (see Section 6.1.3). 668 The DetNet-aware extended forwarder selects the egress DetNet member 669 flow based on the DetNet forwarding rules. In both "normal AC" and 670 "Packet AC" cases there may be no DetNet encapsulation header 671 available yet as it is the case with relay nodes (see Section 6.1.3). 672 It is the responsibility of the extended forwarder within the edge 673 node to push the DetNet specific encapsulation (if not already 674 present) to the packet before forwarding it to the appropriate egress 675 DetNet member flow instance(s). The extended forwarder MAY copy the 676 sequencing information from the native DetNet packet into the DetNet 677 sequence number field and vice versa. If there is no existing 678 sequencing information available in the native packet or the 679 forwarder chose not to copy it from the native packet, then the 680 extended forwarder MUST maintain a sequence number counter for each 681 DetNet flow (indexed by the DetNet flow identification). 683 6.1.3. Relay node processing clarifications 685 The DetNet data plane solution overloads a relay node with DetNet 686 Relay node functions. Relay node is aware of DetNet flows and may 687 operate upon those. Figure 10 illustrates the overall DetNet relay 688 device functions. 690 A DetNet Relay node participates to the packet replication and 691 duplication elimination. This processing is done within an extended 692 forwarder function. Whether an ingress DetNet member flow receives 693 DetNet specific processing depends on how the forwarding is 694 programmed. For some DetNet member flows the relay node can act as a 695 normal relay node and for some apply the DetNet specific processing 696 (i.e., PREF). It is also possible to treat the relay node as a 697 transit node, see Section 7.3. Again, this is entirely up to how the 698 forwarding has been programmed. 700 The DetNet-aware forwarder selects the egress DetNet member flow 701 segment based on the flow identification. The mapping of ingress 702 DetNet member flow segment to egress DetNet member flow segment may 703 be statically or dynamically configured. Additionally the DetNet- 704 aware forwarder does duplicate frame elimination based on the flow 705 identification and the sequence number combination. The packet 706 replication is also done within the DetNet-aware forwarder. During 707 elimination and the replication process the sequence number of the 708 DetNet member flow MUST be preserved and copied to the egress DetNet 709 member flow. 711 +---------------------------------------+ 712 | DetNet Relay Device | 713 Ingress +---------------------------------------+ 714 member | | Forwarder | | Egress 715 instance | Single | | Single | member Inst. 716 ----------->o Service o --X-----> o Service o-----------> 717 | Instance | | Elim. | Instance | 718 Ingress +-------------+ | +-------------+ Duplicate 719 member | | | | | Egress 720 instance | Single | | | Single | member Inst. 721 ----------->o Service o --+ +-> o Service o-----------> 722 | Instance | | | Instance | 723 Ingress +-------------+ | +-------------+ 724 member | | | | | Egress 725 instance | Single | Repl. | | Single | member Inst. 726 ----------->o Service o ------X-> o Service o-----------> 727 | Instance | | Instance | 728 Ingress +-------------+ +-------------+ 729 member | | | | Egress 730 instance | Single | | Single | member Inst. 731 ----------->o Service o --------> o Service o-----------> 732 | Instance | | Instance | 733 +---------------------------------------+ 735 Figure 10: DetNet Relay Node processing 737 6.2. Native IPv6-based data plane 739 [Editor's note: this section is TBD.] 741 7. Other DetNet data plane considerations 743 7.1. Class of Service 745 Class and quality of service, i.e., CoS and QoS, are terms that are 746 often used interchangeably and confused. In the context of DetNet, 747 CoS is used to refer to mechanisms that provide traffic forwarding 748 treatment based on aggregate group basis and QoS is used to refer to 749 mechanisms that provide traffic forwarding treatment based on a 750 specific DetNet flow basis. Examples of existing network level CoS 751 mechanisms include DiffServ which is enabled by IP header 752 differentiated services code point (DSCP) field [RFC2474] and MPLS 753 label traffic class field [RFC5462], and at Layer-2, by IEEE 802.1p 754 priority code point (PCP). 756 CoS for DetNet flows carried in PWs and MPLS is provided using the 757 existing MPLS Differentiated Services (DiffServ) architecture 759 [RFC3270]. Both E-LSP and L-LSP MPLS DiffServ modes MAY be used to 760 support DetNet flows. The Traffic Class field (formerly the EXP 761 field) of an MPLS label follows the definition of [RFC5462] and 762 [RFC3270]. The Uniform, Pipe, and Short Pipe DiffServ tunneling and 763 TTL processing models are described in [RFC3270] and [RFC3443] and 764 MAY be used for MPLS LSPs supporting DetNet flows. MPLS ECN MAY also 765 be used as defined in ECN [RFC5129] and updated by [RFC5462]. 767 CoS for DetNet flows carried in IPv6 is provided using the standard 768 differentiated services code point (DSCP) field [RFC2474] and related 769 mechanisms. The 2-bit explicit congestion notification (ECN) 770 [RFC3168] field MAY also be used. 772 One additional consideration for DetNet nodes which support CoS 773 services is that they MUST ensure that the CoS service classes do not 774 impact the congestion protection and latency control mechanisms used 775 to provide DetNet QoS. This requirement is similar to requirement 776 for MPLS LSRs to that CoS LSPs do not impact the resources allocated 777 to TE LSPs via [RFC3473]. 779 7.2. Quality of Service 781 Quality of Service (QoS) mechanisms for flow specific traffic 782 treatment typically includes a guarantee/agreement for the service, 783 and allocation of resources to support the service. Example QoS 784 mechanisms include discrete resource allocation, admission control, 785 flow identification and isolation, and sometimes path control, 786 traffic protection, shaping, policing and remarking. Example 787 protocols that support QoS control include Resource ReSerVation 788 Protocol (RSVP) [RFC2205] (RSVP) and RSVP-TE [RFC3209] and [RFC3473]. 789 The existing MPLS mechanisms defined to support CoS [RFC3270] can 790 also be used to reserve resources for specific traffic classes. 792 In addition to path pinning and packet replication and elimination, 793 described in Section 5 above, DetNet provides zero congestion loss 794 and bounded latency and jitter. As described in 795 [I-D.ietf-detnet-architecture], there are different mechanisms that 796 maybe used separately or in combination to deliver a zero congestion 797 loss service. These mechanisms are provided by the either the MPLS 798 or IP layers, and may be combined with the mechanisms defined by the 799 underlying network layer such as 802.1TSN. 801 A baseline set of QoS capabilities for DetNet flows carried in PWs 802 and MPLS can provided by MPLS with Traffic Engineering (MPLS-TE) 803 [RFC3209] and [RFC3473]. TE LSPs can also support explicit routes 804 (path pinning). Current service definitions for packet TE LSPs can 805 be found in "Specification of the Controlled Load Quality of 806 Service", [RFC2211], "Specification of Guaranteed Quality of 807 Service", [RFC2212], and "Ethernet Traffic Parameters", [RFC6003]. 808 Additional service definitions are expected in future documents to 809 support the full range of DetNet services. In all cases, the 810 existing label-based marking mechanisms defined for TE-LSPs and even 811 E-LSPs are use to support the identification of flows requiring 812 DetNet QoS. 814 QoS for DetNet flows carried in IPv6 MUST be provided locally by the 815 DetNet-aware hosts and routers supporting DetNet flows. Such support 816 will leverage the underlying network layer such as 802.1TSN. The 817 traffic control mechanisms used to deliver QoS for IP encapsulated 818 DetNet flows are expected to be defined in a future document. From 819 an encapsulation perspective, and as defined in Section 5.2.2, the 820 combination of the Flow Label together with the IP source address 821 uniquely identifies a DetNet flow. 823 Packets that are marked with a DetNet Class of Service value, but 824 that have not been the subject of a completed reservation, can 825 disrupt the QoS offered to properly reserved DetNet flows by using 826 resources allocated to the reserved flows. Therefore, the network 827 nodes of a DetNet network SHOULD: 829 o Defend the DetNet QoS by discarding or remarking (to a non-DetNet 830 CoS) packets received that are not the subject of a completed 831 reservation. 833 o Not use a DetNet reserved resource, e.g. a queue or shaper 834 reserved for DetNet flows, for any packet that does not carry a 835 DetNet Class of Service marker. 837 7.3. Cross-DetNet flow resource aggregation 839 The ability to aggregate individual flows, and their associated 840 resource control, into a larger aggregate is an important technique 841 for improving scaling of control in the data, management and control 842 planes. This document identifies the traffic identification related 843 aspects of aggregation of DetNet flows. The resource control and 844 management aspects of aggregation (including the queuing/shaping/ 845 policing implications) will be covered in other documents. The data 846 plane implications of aggregation are independent for PW/MPLS and IP 847 encapsulated DetNet flows. 849 DetNet flows transported via MPLS can leverage MPLS-TE's existing 850 support for hierarchical LSPs (H-LSPs), see [RFC4206]. H-LSPs are 851 typically used to aggregate control and resources, they may also be 852 used to provide OAM or protection for the aggregated LSPs. Arbitrary 853 levels of aggregation naturally falls out of the definition for 854 hierarchy and the MPLS label stack [RFC3032]. DetNet nodes which 855 support aggregation (LSP hierarchy) map one or more LSPs (labels) 856 into and from an H-LSP. Both carried LSPs and H-LSPs may or may not 857 use the TC field, i.e., L-LSPs or E-LSPs. Such nodes will need to 858 ensure that traffic from aggregated LSPs are placed (shaped/policed/ 859 enqueued) onto the H-LSPs in a fashion that ensures the required 860 DetNet service is preserved. 862 DetNet flows transported via IP have more limited aggregation 863 options, due to the available traffic flow identification fields of 864 the IP solution. One available approach is to manage the resources 865 associated with a DSCP identified traffic class and to map (remark) 866 individually controlled DetNet flows onto that traffic class. This 867 approach also requires that nodes support aggregation ensure that 868 traffic from aggregated LSPs are placed (shaped/policed/enqueued) in 869 a fashion that ensures the required DetNet service is preserved. 871 In both the MPLS and IP cases, additional details of the traffic 872 control capabilities needed at a DetNet-aware node may be covered in 873 the new service descriptions mentioned above or in separate future 874 documents. Management and control plane mechanisms will also need to 875 ensure that the service required on the aggregate flow (H-LSP or 876 DSCP) are provided, which may include the discarding or remarking 877 mentioned in the previous sections. 879 7.4. Bidirectional traffic 881 Some DetNet applications generate bidirectional traffic. Using MPLS 882 definitions [RFC5654] there are associated bidirectional flows, and 883 co-routed bidirectional flows. MPLS defines a point-to-point 884 associated bidirectional LSP as consisting of two unidirectional 885 point-to-point LSPs, one from A to B and the other from B to A, which 886 are regarded as providing a single logical bidirectional transport 887 path. This would be analogous of standard IP routing, or PWs running 888 over two reciprocal unidirection LSPs. MPLS defines a point-to-point 889 co-routed bidirectional LSP as an associated bidirectional LSP which 890 satisfies the additional constraint that its two unidirectional 891 component LSPs follow the same path (in terms of both nodes and 892 links) in both directions. An important property of co-routed 893 bidirectional LSPs is that their unidirectional component LSPs share 894 fate. In both types of bidirectional LSPs, resource allocations may 895 differ in each direction. The concepts of associated bidirectional 896 flows and co-routed bidirectional flows can be applied to DetNet 897 flows as well whether IPv6 or MPLS is used. 899 While the IPv6 and MPLS data planes must support bidirectional DetNet 900 flows, there are no special bidirectional features with respect to 901 the data plane other than need for the two directions take the same 902 paths. Fate sharing and associated vs co-routed bidirectional flows 903 can be managed at the control level. Note, that there is no stated 904 requirement for bidirectional DetNet flows to be supported using the 905 same IPv6 Flow Labels or MPLS Labels in each direction. Control 906 mechanisms will need to support such bidirectional flows for both 907 IPv6 and MPLS, but such mechanisms are out of scope of this document. 908 An example control plane solution for MPLS can be found in [RFC7551]. 910 7.5. Layer 2 addressing and QoS Considerations 912 The Time-Sensitive Networking (TSN) Task Group of the IEEE 802.1 913 Working Group have defined (and are defining) a number of amendments 914 to IEEE 802.1Q [IEEE8021Q] that provide zero congestion loss and 915 bounded latency in bridged networks. IEEE 802.1CB [IEEE8021CB] 916 defines packet replication and elimination functions that should 917 prove both compatible with and useful to, DetNet networks. 919 As is the case for DetNet, a Layer 2 network node such as a bridge 920 may need to identify the specific DetNet flow to which a packet 921 belongs in order to provide the TSN/DetNet QoS for that packet. It 922 also will likely need a CoS marking, such as the priority field of an 923 IEEE Std 802.1Q VLAN tag, to give the packet proper service. 925 Although the flow identification methods described in IEEE 802.1CB 926 [IEEE8021CB] are flexible, and in fact, include IP 5-tuple 927 identification methods, the baseline TSN standards assume that every 928 Ethernet frame belonging to a TSN stream (i.e. DetNet flow) carries 929 a multicast destination MAC address that is unique to that flow 930 within the bridged network over which it is carried. Furthermore, 931 IEEE 802.1CB [IEEE8021CB] describes three methods by which a packet 932 sequence number can be encoded in an Ethernet frame. 934 Ensuring that the proper Ethernet VLAN tag priority and destination 935 MAC address are used on a DetNet/TSN packet may require further 936 clarification of the customary L2/L3 transformations carried out by 937 routers and edge label switches. Edge nodes may also have to move 938 sequence number fields among Layer 2, PW, and IPv6 encapsulations. 940 7.6. Interworking between PW- and IPv6-based encapsulations 942 [Editor's note: add considerations for interworking between PW-based 943 and native IPv6-based DetNet encapsuations.] 945 8. Time synchronization 947 [Editor's note: describe a bit of issues and deployment 948 considerations related to time-synchronization within DetNet. Refer 949 to DT discussion and the slides that summarize different approaches 950 and rough synchronization performance numbers. Finally, scope time- 951 synchronization solution outside data plane.] 953 When DetNet is used, there is an underlying assumption that the 954 applicaton(s) require clock synchronization such as the Precision 955 Time Protocol (PTP) [IEEE1588]. The relay nodes may or may not 956 utilize clock synchronization in order to provide zero congestion 957 loss and controlled latency delivery. In either case, there are a 958 few possible approaches of how synchronization protocol packets are 959 forwarded and handled by the network: 961 o PTP packets can be sent either as DetNet flows or as high-priority 962 best effort packets. Using DetNet for PTP packets requires 963 careful consideration to prevent unwanted interactions between 964 clock-synchronized network nodes and the packets that synchronize 965 the clocks. 967 o PTP packets are sent as a normal DetNet flow through network nodes 968 that are not time-synchronized: in this approach PTP traffic is 969 forwarded as a DetNet flow, and as such it is forwarded in a way 970 that allows a low delay variation. However, since intermediate 971 nodes do not take part in the synchronization protocol, this 972 approach provides a relatively low degree of accuracy. 974 o PTP with on-path support: in this approach PTP packets are sent as 975 ordinary or as DetNet flows, and intermediate nodes take part in 976 the protocol as Transparent Clocks or Boundary Clocks [IEEE1588]. 977 The on-path PTP support by intermediate nodes provides a higher 978 degree of accuracy than the previous approach. The actual 979 accuracy depends on whether all intermediate nodes are PTP- 980 capable, or only a subset of them. 982 o Time-as-a-service: in this approach accurate time is provided as- 983 a-service to the DetNet source and destination, as well as the 984 intermediate nodes. Since traffic between the source and 985 destination is sent over a provider network, if the provider 986 supports time-as-a-service, then accurate time can be provided to 987 both the source and the destination of DetNet traffic. This 988 approach can potentially provide the highest degree of accuracy. 990 It is expected that the latter approach will be the most common one, 991 as it provides the highest degree of accuracy, and creates a layer 992 separation between the DetNet data and the synchronization service. 994 It should be noted that in all four approaches it is not recommended 995 to use replication and elimination for synchronization packets; the 996 replication/elimination approach may in some cases reduce the 997 synchronization accuracy, since the observed path delay will be 998 bivalent. 1000 9. Management and control considerations 1002 While management plane and control planes are traditionally 1003 considered separately, from the Data Plane perspective there is no 1004 practical difference based on the origin of flow provisioning 1005 information. This document therefore does not distinguish between 1006 information provided by a control plane protocol, e.g., RSVP-TE 1007 [RFC3209] and [RFC3473], or by a network management mechanisms, e.g., 1008 RestConf [RFC8040] and YANG [RFC7950]. 1010 [Editor's note: This section is a work in progress. discuss here 1011 what kind of enhancements are needed for DetNet and specifically for 1012 PREF and DetNet zero congest loss and latency control. Need to cover 1013 both traffic control (queuing) and connection control (control 1014 plane).] 1016 9.1. PW Label and IPv6 Flow Label assignment and distribution 1018 The PW label distribution follows the same mechanisms specified for 1019 MS-PW [RFC6073]. The details of the control plane protocol solution 1020 required for the label distribution and the management of the label 1021 number space are out of scope of this document. 1023 The IPv6 Flow Label distribution and the label number space are out 1024 of scope of this document. However, it should be noted that the 1025 combination of the IPv6 source address and the IPv6 Flow Label is 1026 assumed to be unique within the DetNet-enabled network. Therefore, 1027 as long as each node is able to assign unique Flow Labels for the 1028 source address(es) it is using the DetNet-enabled network wide flow 1029 identification uniqueness is guaranteed. 1031 9.2. Packet replication and elimination 1033 The control plane protocol solution required for managing the PREF 1034 processing is outside the scope of this document. 1036 9.3. Explicit paths 1038 [TBD: based on MPLS TE and SR.] 1040 9.4. Congestion protection and latency control 1042 [TBD] 1044 9.5. Flow aggregation control 1046 [TBD] 1048 10. Security considerations 1050 The security considerations of DetNet in general are discussed in 1051 [I-D.ietf-detnet-architecture] and [I-D.sdt-detnet-security]. Other 1052 security considerations will be added in a future version of this 1053 draft. 1055 11. IANA considerations 1057 TBD. 1059 12. Acknowledgements 1061 The author(s) ACK and NACK. 1063 The following people were part of the DetNet Data Plane Solution 1064 Design Team: 1066 Jouni Korhonen 1068 Janos Farkas 1070 Norman Finn 1072 Balazs Varga 1074 Loa Andersson 1076 Tal Mizrahi 1078 David Mozes 1080 Yuanlong Jiang 1082 Carlos J. Bernardos 1084 The DetNet chairs serving during the DetNet Data Plane Solution 1085 Design Team: 1087 Lou Berger 1089 Pat Thaler 1091 13. References 1093 13.1. Normative references 1095 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1096 Requirement Levels", BCP 14, RFC 2119, 1097 DOI 10.17487/RFC2119, March 1997, 1098 . 1100 [RFC2211] Wroclawski, J., "Specification of the Controlled-Load 1101 Network Element Service", RFC 2211, DOI 10.17487/RFC2211, 1102 September 1997, . 1104 [RFC2212] Shenker, S., Partridge, C., and R. Guerin, "Specification 1105 of Guaranteed Quality of Service", RFC 2212, 1106 DOI 10.17487/RFC2212, September 1997, 1107 . 1109 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 1110 "Definition of the Differentiated Services Field (DS 1111 Field) in the IPv4 and IPv6 Headers", RFC 2474, 1112 DOI 10.17487/RFC2474, December 1998, 1113 . 1115 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 1116 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 1117 Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, 1118 . 1120 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 1121 of Explicit Congestion Notification (ECN) to IP", 1122 RFC 3168, DOI 10.17487/RFC3168, September 2001, 1123 . 1125 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 1126 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 1127 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 1128 . 1130 [RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, 1131 P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi- 1132 Protocol Label Switching (MPLS) Support of Differentiated 1133 Services", RFC 3270, DOI 10.17487/RFC3270, May 2002, 1134 . 1136 [RFC3443] Agarwal, P. and B. Akyol, "Time To Live (TTL) Processing 1137 in Multi-Protocol Label Switching (MPLS) Networks", 1138 RFC 3443, DOI 10.17487/RFC3443, January 2003, 1139 . 1141 [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label 1142 Switching (GMPLS) Signaling Resource ReserVation Protocol- 1143 Traffic Engineering (RSVP-TE) Extensions", RFC 3473, 1144 DOI 10.17487/RFC3473, January 2003, 1145 . 1147 [RFC3985] Bryant, S., Ed. and P. Pate, Ed., "Pseudo Wire Emulation 1148 Edge-to-Edge (PWE3) Architecture", RFC 3985, 1149 DOI 10.17487/RFC3985, March 2005, 1150 . 1152 [RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) 1153 Hierarchy with Generalized Multi-Protocol Label Switching 1154 (GMPLS) Traffic Engineering (TE)", RFC 4206, 1155 DOI 10.17487/RFC4206, October 2005, 1156 . 1158 [RFC4448] Martini, L., Ed., Rosen, E., El-Aawar, N., and G. Heron, 1159 "Encapsulation Methods for Transport of Ethernet over MPLS 1160 Networks", RFC 4448, DOI 10.17487/RFC4448, April 2006, 1161 . 1163 [RFC5129] Davie, B., Briscoe, B., and J. Tay, "Explicit Congestion 1164 Marking in MPLS", RFC 5129, DOI 10.17487/RFC5129, January 1165 2008, . 1167 [RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching 1168 (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic 1169 Class" Field", RFC 5462, DOI 10.17487/RFC5462, February 1170 2009, . 1172 [RFC6003] Papadimitriou, D., "Ethernet Traffic Parameters", 1173 RFC 6003, DOI 10.17487/RFC6003, October 2010, 1174 . 1176 [RFC6073] Martini, L., Metz, C., Nadeau, T., Bocci, M., and M. 1177 Aissaoui, "Segmented Pseudowire", RFC 6073, 1178 DOI 10.17487/RFC6073, January 2011, 1179 . 1181 [RFC6658] Bryant, S., Ed., Martini, L., Swallow, G., and A. Malis, 1182 "Packet Pseudowire Encapsulation over an MPLS PSN", 1183 RFC 6658, DOI 10.17487/RFC6658, July 2012, 1184 . 1186 [RFC7510] Xu, X., Sheth, N., Yong, L., Callon, R., and D. Black, 1187 "Encapsulating MPLS in UDP", RFC 7510, 1188 DOI 10.17487/RFC7510, April 2015, 1189 . 1191 13.2. Informative references 1193 [I-D.ietf-6man-segment-routing-header] 1194 Previdi, S., Filsfils, C., Raza, K., Leddy, J., Field, B., 1195 daniel.voyer@bell.ca, d., daniel.bernier@bell.ca, d., 1196 Matsushima, S., Leung, I., Linkova, J., Aries, E., Kosugi, 1197 T., Vyncke, E., Lebrun, D., Steinberg, D., and R. Raszuk, 1198 "IPv6 Segment Routing Header (SRH)", draft-ietf-6man- 1199 segment-routing-header-06 (work in progress), March 2017. 1201 [I-D.ietf-detnet-architecture] 1202 Finn, N., Thubert, P., Varga, B., and J. Farkas, 1203 "Deterministic Networking Architecture", draft-ietf- 1204 detnet-architecture-02 (work in progress), June 2017. 1206 [I-D.ietf-detnet-dp-alt] 1207 Korhonen, J., Farkas, J., Mirsky, G., Thubert, P., 1208 Zhuangyan, Z., and L. Berger, "DetNet Data Plane Protocol 1209 and Solution Alternatives", draft-ietf-detnet-dp-alt-00 1210 (work in progress), October 2016. 1212 [I-D.sdt-detnet-security] 1213 Mizrahi, T., Grossman, E., Hacker, A., Das, S., 1214 "Deterministic Networking (DetNet) Security 1215 Considerations, draft-sdt-detnet-security, work in 1216 progress", 2017. 1218 [IEEE1588] 1219 IEEE, "IEEE 1588 Standard for a Precision Clock 1220 Synchronization Protocol for Networked Measurement and 1221 Control Systems Version 2", 2008. 1223 [IEEE8021CB] 1224 Finn, N., "Draft Standard for Local and metropolitan area 1225 networks - Seamless Redundancy", IEEE P802.1CB 1226 /D2.1 P802.1CB, December 2015, 1227 . 1230 [IEEE8021Q] 1231 IEEE 802.1, "Standard for Local and metropolitan area 1232 networks--Bridges and Bridged Networks (IEEE Std 802.1Q- 1233 2014)", 2014, . 1235 [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. 1236 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 1237 Functional Specification", RFC 2205, DOI 10.17487/RFC2205, 1238 September 1997, . 1240 [RFC4023] Worster, T., Rekhter, Y., and E. Rosen, Ed., 1241 "Encapsulating MPLS in IP or Generic Routing Encapsulation 1242 (GRE)", RFC 4023, DOI 10.17487/RFC4023, March 2005, 1243 . 1245 [RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast 1246 Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, 1247 DOI 10.17487/RFC4090, May 2005, 1248 . 1250 [RFC5654] Niven-Jenkins, B., Ed., Brungard, D., Ed., Betts, M., Ed., 1251 Sprecher, N., and S. Ueno, "Requirements of an MPLS 1252 Transport Profile", RFC 5654, DOI 10.17487/RFC5654, 1253 September 2009, . 1255 [RFC7551] Zhang, F., Ed., Jing, R., and R. Gandhi, Ed., "RSVP-TE 1256 Extensions for Associated Bidirectional Label Switched 1257 Paths (LSPs)", RFC 7551, DOI 10.17487/RFC7551, May 2015, 1258 . 1260 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1261 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1262 . 1264 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1265 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 1266 . 1268 Appendix A. Example of DetNet data plane operation 1270 [Editor's note: Add a simplified example of DetNet data plane and how 1271 labels etc work in the case of MPLS-based PSN and utilizing PREF. 1272 The figure is subject to change depending on the further DT decisions 1273 on the label handling..] 1275 Appendix B. Example of pinned paths using IPv6 1277 TBD. 1279 Authors' Addresses 1281 Jouni Korhonen (editor) 1283 Email: jouni.nospam@gmail.com 1285 Loa Andersson 1286 Huawei 1288 Email: loa@pi.nu 1290 Yuanlong Jiang 1291 Huawei 1293 Email: jiangyuanlong@huawei.com 1295 Norman Finn 1296 Huawei 1297 3101 Rio Way 1298 Spring Valley, CA 91977 1299 USA 1301 Email: norman.finn@mail01.huawei.com 1303 Balazs Varga 1304 Ericsson 1305 Konyves Kalman krt. 11/B 1306 Budapest 1097 1307 Hungary 1309 Email: balazs.a.varga@ericsson.com 1311 Janos Farkas 1312 Ericsson 1313 Konyves Kalman krt. 11/B 1314 Budapest 1097 1315 Hungary 1317 Email: janos.farkas@ericsson.com 1318 Carlos J. Bernardos 1319 Universidad Carlos III de Madrid 1320 Av. Universidad, 30 1321 Leganes, Madrid 28911 1322 Spain 1324 Phone: +34 91624 6236 1325 Email: cjbc@it.uc3m.es 1326 URI: http://www.it.uc3m.es/cjbc/ 1328 Tal Mizrahi 1329 Marvell 1330 6 Hamada st. 1331 Yokneam 1332 Israel 1334 Email: talmi@marvell.com 1336 Lou Berger 1337 LabN Consulting, L.L.C. 1339 Email: lberger@labn.net