idnits 2.17.1 draft-jiang-detnet-ring-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 13, 2020) is 1381 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational draft: draft-ietf-detnet-data-plane-framework (ref. 'I-D.ietf-detnet-data-plane-framework') == Outdated reference: A later version (-13) exists of draft-ietf-detnet-mpls-09 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DetNet Working Group Y. Jiang 3 Internet-Draft N. Finn 4 Intended status: Standards Track Huawei Technologies 5 Expires: January 14, 2021 J. Ryoo 6 ETRI 7 B. Varga 8 Ericsson 9 L. Geng 10 China Mobile 11 July 13, 2020 13 Deterministic Networking Application in Ring Topologies 14 draft-jiang-detnet-ring-06 16 Abstract 18 Deterministic Networking (DetNet) provides a capability to carry data 19 flows for real-time applications with extremely low data loss rates 20 and bounded latency. This document describes how DetNet can be used 21 in ring topologies to support Point-to-Point (P2P) and Point-to- 22 Multipoint (P2MP) real-time services. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on January 14, 2021. 41 Copyright Notice 43 Copyright (c) 2020 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 60 3. Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . 3 61 4. P2P DetNet Ring . . . . . . . . . . . . . . . . . . . . . . . 4 62 4.1. DetNet applications on a single ring for P2P traffic . . 4 63 4.2. Implementation implications of a DetNet ring for P2P 64 traffic . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 5. P2MP DetNet Ring . . . . . . . . . . . . . . . . . . . . . . 5 66 5.1. DetNet applications on a single ring for P2MP traffic . . 5 67 5.2. Section LSPs as underlay (service sub-layer replication) 6 68 5.3. P2MP LSP tunnels as underlay (forwarding sub-layer 69 replication) . . . . . . . . . . . . . . . . . . . . . . 7 70 6. DetNet Ring Interconnections . . . . . . . . . . . . . . . . 8 71 6.1. Single node interconnection . . . . . . . . . . . . . . . 8 72 6.2. Dual node interconnection . . . . . . . . . . . . . . . . 9 73 6.2.1. Dual node interconnection for P2P traffic . . . . . . 9 74 6.2.2. Dual node interconnection for P2MP traffic using 75 section LSP . . . . . . . . . . . . . . . . . . . . . 10 76 6.2.3. Dual node interconnection for P2MP traffic using P2MP 77 LSP . . . . . . . . . . . . . . . . . . . . . . . . . 11 78 7. Resource Reservation . . . . . . . . . . . . . . . . . . . . 11 79 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 80 9. Security Considerations . . . . . . . . . . . . . . . . . . . 11 81 10. Editor's Note . . . . . . . . . . . . . . . . . . . . . . . . 12 82 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 83 11.1. Normative References . . . . . . . . . . . . . . . . . . 12 84 11.2. Informative References . . . . . . . . . . . . . . . . . 13 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 87 1. Introduction 89 The overall architecture for Deterministic Networking (DetNet), which 90 provides a capability to carry specified unicast or multicast data 91 flows for real-time applications with extremely low data loss rates 92 and bounded latency, is specified in [RFC8655], and the generic data 93 plane framework, which is common to any DetNet data plane 94 implementations, is provided at 95 [I-D.ietf-detnet-data-plane-framework]. In addition to the DetNet 96 architecture documents, RFC 8578 [RFC8578] outlines several DetNet 97 use cases where multicast capability is needed. If a multicast 98 service replicates all of its packets from the source (as a 99 traditional Virtual Private LAN Service (VPLS) does), the 100 requirements of deterministic delay and high availability for all 101 these replicated packets will pose a great challenge to the DetNet 102 network. 104 Ring topologies have been very popular and widely deployed in network 105 arrangements for various transport networks, such as Synchronous 106 Digital Hierarchy, Synchronous Optical Network, Optical Transport 107 Network, and Ethernet. For Multi-Protocol Label Switching - 108 Transport Profile (MPLS-TP), the applicability of the MPLS-TP linear 109 protection [RFC6378][RFC7271] for ring topologies and the ring- 110 specific protection mechanism are specified in RFC 6974 [RFC6974] and 111 RFC 8227 [RFC8227], respectively. All these works, except Ethernet 112 ring protection, typically use swapping or steering as the protection 113 mechanism. As ring topologies are widely deployed for transport 114 networks, it is also necessary for the DetNet to support ring 115 topologies. 117 This document demonstrates how the DetNet can be used in a ring 118 topology. Specifically, DetNet ring supports for Point-to-Point 119 (P2P) and Point-to-Multipoint (P2MP, for multicast services) are 120 discussed in details. This document assumes that the Multi-Protocol 121 Label Switching (MPLS) encapsulation for DetNet is supported as 122 specified in [I-D.ietf-detnet-mpls] and all nodes in a ring network 123 can support the MPLS functionalities. It should be noted that it is 124 more convenient for the DetNet to support a ring topology with the 125 intrinsic duplication and elimination mechanism, as there is no need 126 of swapping or steering operations (consequently, its Operations, 127 Administration and Maintenance (OAM) can also be simplified) for 128 service protection. 130 2. Conventions Used in This Document 132 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 133 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 134 "OPTIONAL" in this document are to be interpreted as described in BCP 135 14 [RFC2119] [RFC8174] when, and only when, they appear in all 136 capitals, as shown here. 138 3. Abbreviations 139 This document uses the following abbreviations: 141 DetNet Deterministic Networking 142 LSP Label Switched Path 143 MPLS Multi-Protocol Label Switching 144 MPLS-TP Multi-Protocol Label Switching - Transport Profile 145 P2MP Point-to-Multipoint 146 P2P Point-to-Point 147 PEF Packet Elimination Function 148 POF Packet Ordering Function 149 PRF Packet Replication Function 150 PW Pseudowire 152 4. P2P DetNet Ring 154 This section describes how the DetNet can deliver P2P traffic over a 155 single ring. 157 4.1. DetNet applications on a single ring for P2P traffic 159 Figure 1 shows an example of the DetNet ring for P2P real time 160 traffic. Nodes A and C are DetNet aware devices, and P2P DetNet 161 traffic is transported from node A to node C. 163 +---+#############+---+ 164 | B |-------------| C | +-- DetNet 165 +---+ +---+ egress 166 #/ *\ 167 #/ *\ 168 #/ *\ 169 +---+ +---+ 170 DetNet--+ | A | | D | 171 ingress +---+ +---+ 172 \* */ 173 \* */ 174 \* */ 175 +---+*************+---+ 176 | F |-------------| E | 177 +---+ +---+ 179 ----- Physical Links 180 ##### Clockwise_ 181 ***** Counter Clockwise 183 Figure 1: DetNet Ring for P2P traffic 185 A clockwise and a counter clockwise Label Switched Paths (LSPs) are 186 configured from node A to node C using the DetNet forwarding labels 187 (F-Labels) are configured from node A to node C. The DetNet service 188 sub-layer functions are provided at nodes A and C utilizing the 189 DetNet service label(s) (S-Label) and DetNet control word (d-CW) as 190 described in [I-D.ietf-detnet-mpls]. The P2P traffic is replicated 191 by a Packet Replication Function (PRF) in node A, encapsulated with 192 the d-CW and specific S-Label and F-Label(s), and transported on both 193 LSP paths towards node C. Upon reception of the traffic, node C 194 terminates the LSP and is aware of the DetNet traffic by inspection 195 of the S-Label carried in each packet. A Packet Elimination Function 196 (PEF) in node C guarantees that only one copy of the DetNet service 197 exits on egress with the help of the DetNet sequence number. A 198 Packet Ordering Function (POF) can further reorder packets in node C 199 before transport of these packets to the destination. 201 4.2. Implementation implications of a DetNet ring for P2P traffic 203 In a DetNet ring for P2P traffic, one path may be far longer than the 204 other path. The buffer for reordering at the egress needs to be 205 large enough to accommodate for the sequence number difference 206 between these two paths. 208 5. P2MP DetNet Ring 210 5.1. DetNet applications on a single ring for P2MP traffic 212 Figure 2 shows an example of the DetNet ring for P2MP real time 213 traffic. Nodes A, B, C, E and F are DetNet aware devices, and P2MP 214 DetNet traffic is transported from head-end node A to multiple tail- 215 end nodes C, E and F. 217 Two approaches are described in Section 5.2 and Section 5.3 for P2MP 218 traffic. 220 +---+#############+---+ 221 | B |-------------| C | +-- DetNet 222 +---+*************+---+ egress 223 #/ *\# 224 #/ *\# 225 #/ *\# 226 +---+ +---+ 227 DetNet--+ | A | | D | 228 ingress +---+ +---+ 229 \* */# 230 \* */# 231 \* */# 232 +---+*************+---+ 233 DetNet--+ | F |-------------| E |+-- DetNet 234 egress +---+#############+---+ egress 236 ----- Physical Links 237 ##### Clockwise traffic 238 ***** Counter Clockwise traffic 240 Figure 2: DetNet Ring for P2MP traffic 242 5.2. Section LSPs as underlay (service sub-layer replication) 244 If section LSPs are used as an underlay for DetNet services, a 245 bidirectional section LSP tunnel is set up between each pair of 246 neighboring nodes in the ring (e.g., node A and node B, ..., node F 247 and node A). In this case, the DetNet sub-layer replicates the 248 DetNet packets from one tail-end to another neighboring tail-end. 250 The DetNet head-end (i.e., node A) in the ring needs to support 251 DetNet replication function. Upon reception on node A, the DetNet 252 traffic is replicated with a d-CW, encapsulated with a S-Label and a 253 section LSP label per DetNet member flow, and transported on both 254 section LSPs (i.e., A-B and A-F). 256 All intermediate nodes (non tail-ends) on the ring MUST transparently 257 forward the DetNet packet, which contains a d-CW and S-Label, to the 258 next hop on the ring. 260 All DetNet tail-ends except the penultimate node (egress nodes such 261 as nodes C and E in the clockwise, and nodes F, E and C in the 262 counter clockwise) on the ring MUST support both DetNet PRF and PEF 263 functions, and MAY further support a DetNet POF function. For the 264 example of Figure 2, upon reception of the clockwise traffic, node C 265 terminates the section LSP and recognizes the DetNet flow by 266 inspection of the S-label in the packet. Firstly, node C needs to 267 forward the DetNet packet to the next hop on the ring in the 268 clockwise direction. Secondly, the DetNet packet is also directed to 269 a DetNet PEF associated with the DetNet flow, only one copy is 270 egressed from the ring by inspection of the sequence number in the 271 d-CW. Furthermore, if the DetNet POF function is enabled, the 272 packets in the DetNet flow are reordered before exit to DetNet 273 egress. 275 If multiple endpoints are attached to a tail-end node, a multicast 276 module can be used to forward the traffic to all these endpoints. 278 To avoid a loop of DetNet service, the penultimate node in the ring 279 (such as node B on the counter clock-wise LSP) MUST terminate the 280 DetNet flow. For example, upon reception of the clockwise DetNet 281 traffic, node F terminates the DetNet traffic by inspection of the 282 S-Label in the packet. As an alternative, the last DetNet tail-end 283 (such as node C on the counter clock-wise LSP) MAY terminate the 284 DetNet flow, so that the bandwidth from this node to the penultimate 285 node can be saved. 287 5.3. P2MP LSP tunnels as underlay (forwarding sub-layer replication) 289 If P2MP LSPs are used as an underlay for the DetNet service, a P2MP 290 unidirectional LSP tunnel in clockwise is set up from head-end 291 (ingress node A) to all the tail-ends (egress nodes C, E and F) for 292 the ring, and another P2MP unidirectional LSP tunnel in counter 293 clockwise is set up from head-end (ingress node A) to all the tail- 294 ends (egress nodes F, E and C) for the ring. Thus, a PRF in LSP 295 layer replicates the DetNet packets from one tail-end to another 296 neighboring tail-end. 298 The DetNet head-end (i.e., node A) in the ring needs to support the 299 DetNet PRF function. Upon reception on node A, the DetNet traffic is 300 replicated with a d-CW, encapsulated with a S-Label per DetNet member 301 flow, and transported on both P2MP LSP tunnels in the ring. 303 All DetNet tail-ends (egress nodes such as nodes C, E and F in 304 Figure 2) on the ring need to support the DetNet PEF function. For 305 example, upon reception of the traffic, node C pops the P2MP LSP 306 label and is aware of the DetNet traffic by inspection of the S-Label 307 label in the label stack. Two DetNet member flows are identified 308 with their S-Labels and directed to the same PEF so that only one 309 copy of the DetNet service is selected by inspection of the DetNet 310 sequence number in the d-CW. Furthermore, if DetNet POF function is 311 enabled, the packets in the DetNet flow are reordered before exit to 312 DetNet egress. 314 If multiple endpoints are attached to a tail-end node, a multicast 315 module can be used to forward the filtered DetNet traffic to all 316 these endpoints 318 6. DetNet Ring Interconnections 320 Two DetNet rings can be connected via one or more interconnection 321 nodes. Figure 3 shows the ring interconnection scenarios with a 322 single node and dual nodes. In the interconnected rings, each ring 323 operates in the same way as described in Section 4 and Section 5 324 except the node or nodes that are used to interconnect two rings. 326 S T 327 B C S T O----O 328 O----O O----O / \ 329 / \ / \ B I1/ \ 330 / \ / \ O----O Ring R O U 331 A O Ring L O Ring R O U / \ / 332 \ /I\ / / \ / 333 \ / \ / A O Ring L O----O 334 O----O O----O \ /I2 V 335 F E W V \ / 336 O----O 337 F E 338 (a) (b) 340 Figure 3: DetNet ring interconnection with: (a) single node (node I), 341 and (b) dual nodes (nodes I1 and I2) 343 In this section, we describe the behavior of interconnection nodes 344 with the traffic going from Ring L to Ring R. Symmetrical 345 description is assumed for the traffic in the other direction (i.e., 346 from Ring R to Ring L). 348 6.1. Single node interconnection 350 In the case of the single node interconnection, as shown in 351 Figure 3(a), both P2P and P2MP DetNet traffic that needs to be 352 transported between Ring L and Ring R use a single interconnection 353 node between two rings. Thus, the interconnection node acts as a 354 DetNet relay node, which provides both PRF and PEF functions. 356 For P2P DetNet traffic going from Ring L to Ring R, interconnection 357 node I receives the same DetNet flow traffic from both node C and 358 node E (i.e., clockwise and counter-clockwise), a PEF in node I 359 performs packet elimination, and a PRF in node I replicates the 360 packet, node I then sends one copy to node S and another copy to node 361 W. 363 For P2MP DetNet traffic going from Ring L to Ring R, interconnection 364 node I performs the same packet elimination and replication functions 365 as described above. In addition, node I further transparently 366 forwards the P2MP DetNet traffic on Ring L in the same direction if 367 it is not the last tail-end node. 369 6.2. Dual node interconnection 371 In order to prevent a single point of failure, two interconnection 372 nodes can be used as shown in Figure 3(b). To provide high 373 availability for DetNet services, dual node interconnection is 374 recommended. Two interconnection nodes act as DetNet relay nodes, 375 each provides both packet replication and elimination functions. 377 6.2.1. Dual node interconnection for P2P traffic 379 For the P2P DetNet traffic that flows from Ring L to Ring R in 380 Figure 3(b), the operations of interconnection nodes I1 and I2 are 381 described below. 383 When interconnection node I1 receives clockwise traffic from node B, 384 it replicates the traffic and sends one copy to interconnection node 385 I2 and the other copy to a PEF in interconnection node I1. 387 When interconnection node I1 receives counter-clockwise traffic from 388 interconnection node I2, it forwards the traffic to the PEF of 389 interconnection node I1. 391 At the PEF of interconnection node I1, duplicate elimination is 392 performed for the clockwise traffic from node B and the counter- 393 clockwise traffic from interconnection node I2, and only one copy is 394 sent to the clockwise direction of Ring R (i.e., sent towards node 395 S). Furthermore, if DetNet POF function is enabled on 396 interconnection node I1, the packets in the DetNet flow are reordered 397 before being forwarded to Ring R. 399 When interconnection node I2 receives counter-clockwise traffic from 400 node E, it replicates the traffic and sends one copy to 401 interconnection node I1 and the other copy to a PEF in 402 interconnection node I2. 404 When interconnection node I2 receives clockwise traffic from 405 interconnection node I1, it forwards the traffic to the PEF of 406 interconnection node I2. 408 At the PEF of interconnection node I2, duplicate elimination is 409 performed for the counter-clockwise traffic from node E and the 410 clockwise traffic from interconnection node I1, and only one copy is 411 sent to the counter-clockwise direction of Ring R (i.e., sent towards 412 node V). Furthermore, if DetNet POF function is enabled on 413 interconnection node I2, the packets in the DetNet flow are reordered 414 before being forwarded to Ring R. 416 6.2.2. Dual node interconnection for P2MP traffic using section LSP 418 For the P2MP traffic that flows from Ring L to Ring R in Figure 3(b), 419 each ring is configured and operated as described in Section 5.2 420 except the interconnection nodes, whose operations are described 421 below. 423 When interconnection node I1 receives clockwise traffic from node B, 424 its PRF replicates the traffic and sends one copy to interconnection 425 node I2 and the other copy to interconnection node I1's PEF. 427 When interconnection node I1 receives the counter-clockwise traffic 428 from interconnection node I2, its PRF replicates the traffic and 429 sends one copy to node B and the other copy to interconnection node 430 I1's PEF unless interconnection node I1 is the penultimate node for 431 the counter-clockwise traffic on Ring L. In the case that 432 interconnection node I1 is the penultimate node for the counter- 433 clockwise traffic on Ring L, the counter-clockwise traffic from 434 interconnection node I2 is only forwarded to interconnection node 435 I1's PEF. 437 At interconnection node I1's PEF, duplicate elimination is performed 438 for the clockwise traffic from node B and the counter-clockwise 439 traffic from interconnection node I2, and only one copy is sent to 440 the clockwise direction of Ring R (i.e., sent towards node S). 441 Furthermore, if DetNet POF function is enabled on node I1, the 442 packets in the DetNet flow are reordered before being forwarded to 443 Ring R. 445 When interconnection node I2 receives the counter-clockwise traffic 446 from node E, its PRF replicates the traffic and sends one copy to 447 interconnection node I1 and the other copy to node I2's PEF. 449 When interconnection node I2 receives the clockwise traffic from 450 interconnection node I1, its PRF replicates the traffic and sends one 451 copy to node E and the other copy to interconnection node I2's PEF 452 unless interconnection node I2 is the penultimate node for the 453 clockwise traffic on Ring L. In the case that interconnection node 454 I2 is the penultimate node for the clockwise traffic on Ring L, the 455 clockwise traffic from interconnection node I1 is only forwarded to 456 node I2's PEF. 458 At node I2's PEF, duplicate elimination is performed for the counter- 459 clockwise traffic from node E and the clockwise traffic from 460 interconnection node I1, and only one copy is sent to the counter- 461 clockwise direction of Ring R (i.e., sent towards node V). 462 Furthermore, if DetNet POF function is enabled on interconnection 463 node I2, the packets in the DetNet flow are reordered before being 464 forwarded to Ring R. 466 6.2.3. Dual node interconnection for P2MP traffic using P2MP LSP 468 If P2MP LSPs are used in the interconnected rings, two P2MP 469 unidirectional LSP tunnels are used on each ring for the clockwise 470 and counter-clockwise directions. 472 When the P2MP traffic is forwarded from one ring to another ring, for 473 example from Ring L to Ring R in Figure 3(b), each P2MP LSP in Ring L 474 MUST include interconnection nodes I1 and I2 as its tail-ends. For 475 Ring R, one P2MP LSP is set up from interconnection node I1 to all 476 the tail-ends in the clockwise direction on Ring R, and the other 477 P2MP LSP is set up from interconnection node I2 to all the tail-ends 478 in the counter-clockwise direction on Ring R. Therefore, an 479 interconnection node acts as a tail-end for one ring and a head-end 480 for another ring in one direction, and performs the same operation of 481 tail-end and head-end as specified in Section 5.3. 483 7. Resource Reservation 485 In order to guarantee that DetNet flows do not suffer from network 486 congestion, the DetNet data plane considerations on resource 487 reservation and allocation as described in 488 [I-D.ietf-detnet-data-plane-framework] apply here. 490 8. IANA Considerations 492 There are no IANA actions required by this document 494 9. Security Considerations 496 This document describes the application of DetNet MPLS on ring 497 topologies. Thus, the security considerations described in 498 [I-D.ietf-detnet-mpls] are also applied to this document. If any new 499 security considerations specific to ring topologies are identified, 500 they will be added in a future version of this draft. 502 10. Editor's Note 504 This section lists current issues raised by experts in DetNet and 505 other ring protection technologies. This section will be removed 506 once the issues are addressed. 508 o See if Resilient MPLS Ring (RMR) can be used for automatic 509 configuration of a DetNet ring topology network. 511 o Consideration of coexistence with existing ring protection 512 solutions in the DetNet forwarding sublayer. 514 o Consideration on scalability 516 o Explain why this document is needed when the DetNet architecture 517 and data plane documents exist. 519 11. References 521 11.1. Normative References 523 [I-D.ietf-detnet-data-plane-framework] 524 Varga, B., Farkas, J., Berger, L., Malis, A., and S. 525 Bryant, "DetNet Data Plane Framework", draft-ietf-detnet- 526 data-plane-framework-06 (work in progress), May 2020. 528 [I-D.ietf-detnet-mpls] 529 Varga, B., Farkas, J., Berger, L., Malis, A., Bryant, S., 530 and J. Korhonen, "DetNet Data Plane: MPLS", draft-ietf- 531 detnet-mpls-09 (work in progress), July 2020. 533 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 534 Requirement Levels", BCP 14, RFC 2119, 535 DOI 10.17487/RFC2119, March 1997, 536 . 538 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 539 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 540 May 2017, . 542 [RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas, 543 "Deterministic Networking Architecture", RFC 8655, 544 DOI 10.17487/RFC8655, October 2019, 545 . 547 11.2. Informative References 549 [RFC6378] Weingarten, Y., Ed., Bryant, S., Osborne, E., Sprecher, 550 N., and A. Fulignoli, Ed., "MPLS Transport Profile (MPLS- 551 TP) Linear Protection", RFC 6378, DOI 10.17487/RFC6378, 552 October 2011, . 554 [RFC6974] Weingarten, Y., Bryant, S., Ceccarelli, D., Caviglia, D., 555 Fondelli, F., Corsi, M., Wu, B., and X. Dai, 556 "Applicability of MPLS Transport Profile for Ring 557 Topologies", RFC 6974, DOI 10.17487/RFC6974, July 2013, 558 . 560 [RFC7271] Ryoo, J., Ed., Gray, E., Ed., van Helvoort, H., 561 D'Alessandro, A., Cheung, T., and E. Osborne, "MPLS 562 Transport Profile (MPLS-TP) Linear Protection to Match the 563 Operational Expectations of Synchronous Digital Hierarchy, 564 Optical Transport Network, and Ethernet Transport Network 565 Operators", RFC 7271, DOI 10.17487/RFC7271, June 2014, 566 . 568 [RFC8227] Cheng, W., Wang, L., Li, H., van Helvoort, H., and J. 569 Dong, "MPLS-TP Shared-Ring Protection (MSRP) Mechanism for 570 Ring Topology", RFC 8227, DOI 10.17487/RFC8227, August 571 2017, . 573 [RFC8578] Grossman, E., Ed., "Deterministic Networking Use Cases", 574 RFC 8578, DOI 10.17487/RFC8578, May 2019, 575 . 577 Authors' Addresses 579 Yuanlong Jiang 580 Huawei Technologies 581 Bantian, Longgang district 582 Shenzhen 518129 583 China 585 Phone: +86-18926415311 586 Email: jiangyuanlong@huawei.com 587 Norman Finn 588 Huawei Technologies 589 3755 Avocado Blvd 590 California 91941 591 USA 593 Phone: +1 925 980 6430 594 Email: norman.finn@mail01.huawei.com 596 Jeong-dong Ryoo 597 ETRI 598 218 Gajeongno 599 Yuseong-gu, Daejeon 34129 600 South Korea 602 Phone: +82-42-860-5384 603 Email: ryoo@etri.re.kr 605 Balazs Varga 606 Ericsson 607 Konyves Kalman krt. 11/B 608 Budapest 1097 609 Hungary 611 Email: balazs.a.varga@ericsson.com 613 Liang Geng 614 China Mobile 615 Beijing 616 China 618 Email: gengliang@chinamobile.com