idnits 2.17.1 draft-jiang-detnet-ring-04.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 (June 17, 2019) is 1767 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) == Outdated reference: A later version (-06) exists of draft-ietf-detnet-data-plane-framework-00 ** 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-00 Summary: 1 error (**), 0 flaws (~~), 3 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: December 19, 2019 J. Ryoo 6 ETRI 7 B. Varga 8 Ericsson 9 L. Geng 10 China Mobile 11 June 17, 2019 13 Deterministic Networking Application in Ring Topologies 14 draft-jiang-detnet-ring-04 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 December 19, 2019. 41 Copyright Notice 43 Copyright (c) 2019 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. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 82 10.1. Normative References . . . . . . . . . . . . . . . . . . 12 83 10.2. Informative References . . . . . . . . . . . . . . . . . 12 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 86 1. Introduction 88 The overall architecture for Deterministic Networking (DetNet), which 89 provides a capability to carry specified unicast or multicast data 90 flows for real-time applications with extremely low data loss rates 91 and bounded latency, is specified in [I-D.ietf-detnet-architecture], 92 and the generic data plane framework, which is common to any DetNet 93 data plane implementations, is provided at 94 [I-D.ietf-detnet-data-plane-framework]. In addition to the DetNet 95 architecture documents, RFC 8578 [RFC8578] outlines several DetNet 96 use cases where multicast capability is needed. If a multicast 97 service replicates all of its packets from the source (as a 98 traditional Virtual Private LAN Service (VPLS) does), the 99 requirements of deterministic delay and high availability for all 100 these replicated packets will pose a great challenge to the DetNet 101 network. 103 Ring topologies have been very popular and widely deployed in network 104 arrangements for various transport networks, such as Synchronous 105 Digital Hierarchy, Synchronous Optical Network, Optical Transport 106 Network, and Ethernet. For Multi-Protocol Label Switching - 107 Transport Profile (MPLS-TP), the applicability of the MPLS-TP linear 108 protection [RFC6378][RFC7271] for ring topologies and the ring- 109 specific protection mechanism are specified in RFC 6974 [RFC6974] and 110 RFC 8227 [RFC8227], respectively. All these works, except Ethernet 111 ring protection, typically use swapping or steering as the protection 112 mechanism. As ring topologies are widely deployed for transport 113 networks, it is also necessary for the DetNet to support ring 114 topologies. 116 This document demonstrates how the DetNet can be used in a ring 117 topology. Specifically, DetNet ring supports for Point-to-Point 118 (P2P) and Point-to-Multipoint (P2MP, for multicast services) are 119 discussed in details. This document assumes that the Multi-Protocol 120 Label Switching (MPLS) encapsulation for DetNet is supported as 121 specified in [I-D.ietf-detnet-mpls] and all nodes in a ring network 122 can support the MPLS functionalities. It should be noted that it is 123 more convenient for the DetNet to support a ring topology with the 124 intrinsic duplication and elimination mechanism, as there is no need 125 of swapping or steering operations (consequently, its Operations, 126 Administration and Maintenance (OAM) can also be simplified) for 127 service protection. 129 2. Conventions Used in This Document 131 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 132 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 133 "OPTIONAL" in this document are to be interpreted as described in BCP 134 14 [RFC2119] [RFC8174] when, and only when, they appear in all 135 capitals, as shown here. 137 3. Abbreviations 138 This document uses the following abbreviations: 140 DetNet Deterministic Networking 141 LSP Label Switched Path 142 MPLS Multi-Protocol Label Switching 143 MPLS-TP Multi-Protocol Label Switching - Transport Profile 144 P2MP Point-to-Multipoint 145 P2P Point-to-Point 146 PEF Packet Elimination Function 147 POF Packet Ordering Function 148 PRF Packet Replication Function 149 PW Pseudowire 151 4. P2P DetNet Ring 153 This section describes how the DetNet can deliver P2P traffic over a 154 single ring. 156 4.1. DetNet applications on a single ring for P2P traffic 158 Figure 1 shows an example of the DetNet ring for P2P real time 159 traffic. Nodes A and C are DetNet aware devices, and P2P DetNet 160 traffic is transported from node A to node C. 162 +---+#############+---+ 163 | B |-------------| C | +-- DetNet 164 +---+ +---+ egress 165 #/ *\ 166 #/ *\ 167 #/ *\ 168 +---+ +---+ 169 DetNet--+ | A | | D | 170 ingress +---+ +---+ 171 \* */ 172 \* */ 173 \* */ 174 +---+*************+---+ 175 | F |-------------| E | 176 +---+ +---+ 178 ----- Physical Links 179 ##### Clockwise_ 180 ***** Counter Clockwise 182 Figure 1: DetNet Ring for P2P traffic 184 A clockwise and a counter clockwise Label Switched Paths (LSPs) are 185 configured from node A to node C using the DetNet forwarding labels 186 (F-Labels) are configured from node A to node C. The DetNet service 187 sub-layer functions are provided at nodes A and C utilizing the 188 DetNet service label(s) (S-Label) and DetNet control word (d-CW) as 189 described in [I-D.ietf-detnet-mpls]. The P2P traffic is replicated 190 by a Packet Replication Function (PRF) in node A, encapsulated with 191 the d-CW and specific S-Label and F-Label(s), and transported on both 192 LSP paths towards node C. Upon reception of the traffic, node C 193 terminates the LSP and is aware of the DetNet traffic by inspection 194 of the S-Label carried in each packet. A Packet Elimination Function 195 (PEF) in node C guarantees that only one copy of the DetNet service 196 exits on egress with the help of the DetNet sequence number. A 197 Packet Ordering Function (POF) can further reorder packets in node C 198 before transport of these packets to the destination. 200 4.2. Implementation implications of a DetNet ring for P2P traffic 202 In a DetNet ring for P2P traffic, one path may be far longer than the 203 other path. The buffer for reordering at the egress needs to be 204 large enough to accommodate for the sequence number difference 205 between these two paths. 207 5. P2MP DetNet Ring 209 5.1. DetNet applications on a single ring for P2MP traffic 211 Figure 2 shows an example of the DetNet ring for P2MP real time 212 traffic. Nodes A, B, C, E and F are DetNet aware devices, and P2MP 213 DetNet traffic is transported from head-end node A to multiple tail- 214 end nodes C, E and F. 216 Two approaches are described in Section 5.2 and Section 5.3 for P2MP 217 traffic. 219 +---+#############+---+ 220 | B |-------------| C | +-- DetNet 221 +---+*************+---+ egress 222 #/ *\# 223 #/ *\# 224 #/ *\# 225 +---+ +---+ 226 DetNet--+ | A | | D | 227 ingress +---+ +---+ 228 \* */# 229 \* */# 230 \* */# 231 +---+*************+---+ 232 DetNet--+ | F |-------------| E |+-- DetNet 233 egress +---+#############+---+ egress 235 ----- Physical Links 236 ##### Clockwise traffic 237 ***** Counter Clockwise traffic 239 Figure 2: DetNet Ring for P2MP traffic 241 5.2. Section LSPs as underlay (service sub-layer replication) 243 If section LSPs are used as an underlay for DetNet services, a 244 bidirectional section LSP tunnel is set up between each pair of 245 neighboring nodes in the ring (e.g., node A and node B, ..., node F 246 and node A). In this case, the DetNet sub-layer replicates the 247 DetNet packets from one tail-end to another neighboring tail-end. 249 The DetNet head-end (i.e., node A) in the ring needs to support 250 DetNet replication function. Upon reception on node A, the DetNet 251 traffic is replicated with a d-CW, encapsulated with a S-Label and a 252 section LSP label per DetNet member flow, and transported on both 253 section LSPs (i.e., A-B and A-F). 255 All intermediate nodes (non tail-ends) on the ring MUST transparently 256 forward the DetNet packet, which contains a d-CW and S-Label, to the 257 next hop on the ring. 259 All DetNet tail-ends except the penultimate node (egress nodes such 260 as nodes C and E in the clockwise, and nodes F, E and C in the 261 counter clockwise) on the ring MUST support both DetNet PRF and PEF 262 functions, and MAY further support a DetNet POF function. For the 263 example of Figure 2, upon reception of the clockwise traffic, node C 264 terminates the section LSP and recognizes the DetNet flow by 265 inspection of the S-label in the packet. Firstly, node C needs to 266 forward the DetNet packet to the next hop on the ring in the 267 clockwise direction. Secondly, the DetNet packet is also directed to 268 a DetNet PEF associated with the DetNet flow, only one copy is 269 egressed from the ring by inspection of the sequence number in the 270 d-CW. Furthermore, if the DetNet POF function is enabled, the 271 packets in the DetNet flow are reordered before exit to DetNet 272 egress. 274 If multiple endpoints are attached to a tail-end node, a multicast 275 module can be used to forward the traffic to all these endpoints. 277 To avoid a loop of DetNet service, the penultimate node in the ring 278 (such as node B on the counter clock-wise LSP) MUST terminate the 279 DetNet flow. For example, upon reception of the clockwise DetNet 280 traffic, node F terminates the DetNet traffic by inspection of the 281 S-Label in the packet. As an alternative, the last DetNet tail-end 282 (such as node C on the counter clock-wise LSP) MAY terminate the 283 DetNet flow, so that the bandwidth from this node to the penultimate 284 node can be saved. 286 5.3. P2MP LSP tunnels as underlay (forwarding sub-layer replication) 288 If P2MP LSPs are used as an underlay for the DetNet service, a P2MP 289 unidirectional LSP tunnel in clockwise is set up from head-end 290 (ingress node A) to all the tail-ends (egress nodes C, E and F) for 291 the ring, and another P2MP unidirectional LSP tunnel in counter 292 clockwise is set up from head-end (ingress node A) to all the tail- 293 ends (egress nodes F, E and C) for the ring. Thus, a PRF in LSP 294 layer replicates the DetNet packets from one tail-end to another 295 neighboring tail-end. 297 The DetNet head-end (i.e., node A) in the ring needs to support the 298 DetNet PRF function. Upon reception on node A, the DetNet traffic is 299 replicated with a d-CW, encapsulated with a S-Label per DetNet member 300 flow, and transported on both P2MP LSP tunnels in the ring. 302 All DetNet tail-ends (egress nodes such as nodes C, E and F in 303 Figure 2) on the ring need to support the DetNet PEF function. For 304 example, upon reception of the traffic, node C pops the P2MP LSP 305 label and is aware of the DetNet traffic by inspection of the S-Label 306 label in the label stack. Two DetNet member flows are identified 307 with their S-Labels and directed to the same PEF so that only one 308 copy of the DetNet service is selected by inspection of the DetNet 309 sequence number in the d-CW. Furthermore, if DetNet POF function is 310 enabled, the packets in the DetNet flow are reordered before exit to 311 DetNet egress. 313 If multiple endpoints are attached to a tail-end node, a multicast 314 module can be used to forward the filtered DetNet traffic to all 315 these endpoints 317 6. DetNet Ring Interconnections 319 Two DetNet rings can be connected via one or more interconnection 320 nodes. Figure 3 shows the ring interconnection scenarios with a 321 single node and dual nodes. In the interconnected rings, each ring 322 operates in the same way as described in Section 4 and Section 5 323 except the node or nodes that are used to interconnect two rings. 325 S T 326 B C S T O----O 327 O----O O----O / \ 328 / \ / \ B I1/ \ 329 / \ / \ O----O Ring R O U 330 A O Ring L O Ring R O U / \ / 331 \ /I\ / / \ / 332 \ / \ / A O Ring L O----O 333 O----O O----O \ /I2 V 334 F E W V \ / 335 O----O 336 F E 337 (a) (b) 339 Figure 3: DetNet ring interconnection with: (a) single node (node I), 340 and (b) dual nodes (nodes I1 and I2) 342 In this section, we describe the behavior of interconnection nodes 343 with the traffic going from Ring L to Ring R. Symmetrical 344 description is assumed for the traffic in the other direction (i.e., 345 from Ring R to Ring L). 347 6.1. Single node interconnection 349 In the case of the single node interconnection, as shown in 350 Figure 3(a), both P2P and P2MP DetNet traffic that needs to be 351 transported between Ring L and Ring R use a single interconnection 352 node between two rings. Thus, the interconnection node acts as a 353 DetNet relay node, which provides both PRF and PEF functions. 355 For P2P DetNet traffic going from Ring L to Ring R, interconnection 356 node I receives the same DetNet flow traffic from both node C and 357 node E (i.e., clockwise and counter-clockwise), a PEF in node I 358 performs packet elimination, and a PRF in node I replicates the 359 packet, node I then sends one copy to node S and another copy to node 360 W. 362 For P2MP DetNet traffic going from Ring L to Ring R, interconnection 363 node I performs the same packet elimination and replication functions 364 as described above. In addition, node I further transparently 365 forwards the P2MP DetNet traffic on Ring L in the same direction if 366 it is not the last tail-end node. 368 6.2. Dual node interconnection 370 In order to prevent a single point of failure, two interconnection 371 nodes can be used as shown in Figure 3(b). To provide high 372 availability for DetNet services, dual node interconnection is 373 recommended. Two interconnection nodes act as DetNet relay nodes, 374 each provides both packet replication and elimination functions. 376 6.2.1. Dual node interconnection for P2P traffic 378 For the P2P DetNet traffic that flows from Ring L to Ring R in 379 Figure 3(b), the operations of interconnection nodes I1 and I2 are 380 described below. 382 When interconnection node I1 receives clockwise traffic from node B, 383 it replicates the traffic and sends one copy to interconnection node 384 I2 and the other copy to a PEF in interconnection node I1. 386 When interconnection node I1 receives counter-clockwise traffic from 387 interconnection node I2, it forwards the traffic to the PEF of 388 interconnection node I1. 390 At the PEF of interconnection node I1, duplicate elimination is 391 performed for the clockwise traffic from node B and the counter- 392 clockwise traffic from interconnection node I2, and only one copy is 393 sent to the clockwise direction of Ring R (i.e., sent towards node 394 S). Furthermore, if DetNet POF function is enabled on 395 interconnection node I1, the packets in the DetNet flow are reordered 396 before being forwarded to Ring R. 398 When interconnection node I2 receives counter-clockwise traffic from 399 node E, it replicates the traffic and sends one copy to 400 interconnection node I1 and the other copy to a PEF in 401 interconnection node I2. 403 When interconnection node I2 receives clockwise traffic from 404 interconnection node I1, it forwards the traffic to the PEF of 405 interconnection node I2. 407 At the PEF of interconnection node I2, duplicate elimination is 408 performed for the counter-clockwise traffic from node E and the 409 clockwise traffic from interconnection node I1, and only one copy is 410 sent to the counter-clockwise direction of Ring R (i.e., sent towards 411 node V). Furthermore, if DetNet POF function is enabled on 412 interconnection node I2, the packets in the DetNet flow are reordered 413 before being forwarded to Ring R. 415 6.2.2. Dual node interconnection for P2MP traffic using section LSP 417 For the P2MP traffic that flows from Ring L to Ring R in Figure 3(b), 418 each ring is configured and operated as described in Section 5.2 419 except the interconnection nodes, whose operations are described 420 below. 422 When interconnection node I1 receives clockwise traffic from node B, 423 its PRF replicates the traffic and sends one copy to interconnection 424 node I2 and the other copy to interconnection node I1's PEF. 426 When interconnection node I1 receives the counter-clockwise traffic 427 from interconnection node I2, its PRF replicates the traffic and 428 sends one copy to node B and the other copy to interconnection node 429 I1's PEF unless interconnection node I1 is the penultimate node for 430 the counter-clockwise traffic on Ring L. In the case that 431 interconnection node I1 is the penultimate node for the counter- 432 clockwise traffic on Ring L, the counter-clockwise traffic from 433 interconnection node I2 is only forwarded to interconnection node 434 I1's PEF. 436 At interconnection node I1's PEF, duplicate elimination is performed 437 for the clockwise traffic from node B and the counter-clockwise 438 traffic from interconnection node I2, and only one copy is sent to 439 the clockwise direction of Ring R (i.e., sent towards node S). 440 Furthermore, if DetNet POF function is enabled on node I1, the 441 packets in the DetNet flow are reordered before being forwarded to 442 Ring R. 444 When interconnection node I2 receives the counter-clockwise traffic 445 from node E, its PRF replicates the traffic and sends one copy to 446 interconnection node I1 and the other copy to node I2's PEF. 448 When interconnection node I2 receives the clockwise traffic from 449 interconnection node I1, its PRF replicates the traffic and sends one 450 copy to node E and the other copy to interconnection node I2's PEF 451 unless interconnection node I2 is the penultimate node for the 452 clockwise traffic on Ring L. In the case that interconnection node 453 I2 is the penultimate node for the clockwise traffic on Ring L, the 454 clockwise traffic from interconnection node I1 is only forwarded to 455 node I2's PEF. 457 At node I2's PEF, duplicate elimination is performed for the counter- 458 clockwise traffic from node E and the clockwise traffic from 459 interconnection node I1, and only one copy is sent to the counter- 460 clockwise direction of Ring R (i.e., sent towards node V). 461 Furthermore, if DetNet POF function is enabled on interconnection 462 node I2, the packets in the DetNet flow are reordered before being 463 forwarded to Ring R. 465 6.2.3. Dual node interconnection for P2MP traffic using P2MP LSP 467 If P2MP LSPs are used in the interconnected rings, two P2MP 468 unidirectional LSP tunnels are used on each ring for the clockwise 469 and counter-clockwise directions. 471 When the P2MP traffic is forwarded from one ring to another ring, for 472 example from Ring L to Ring R in Figure 3(b), each P2MP LSP in Ring L 473 MUST include interconnection nodes I1 and I2 as its tail-ends. For 474 Ring R, one P2MP LSP is set up from interconnection node I1 to all 475 the tail-ends in the clockwise direction on Ring R, and the other 476 P2MP LSP is set up from interconnection node I2 to all the tail-ends 477 in the counter-clockwise direction on Ring R. Therefore, an 478 interconnection node acts as a tail-end for one ring and a head-end 479 for another ring in one direction, and performs the same operation of 480 tail-end and head-end as specified in Section 5.3. 482 7. Resource Reservation 484 In order to guarantee that DetNet flows do not suffer from network 485 congestion, the DetNet data plane considerations on resource 486 reservation and allocation as described in 487 [I-D.ietf-detnet-data-plane-framework] apply here. 489 8. IANA Considerations 491 There are no IANA actions required by this document 493 9. Security Considerations 495 This document describes the application of DetNet MPLS on ring 496 topologies. Thus, the security considerations described in 497 [I-D.ietf-detnet-mpls] are also applied to this document. If any new 498 security considerations specific to ring topologies are identified, 499 they will be added in a future version of this draft. 501 10. References 503 10.1. Normative References 505 [I-D.ietf-detnet-architecture] 506 Finn, N., Thubert, P., Varga, B., and J. Farkas, 507 "Deterministic Networking Architecture", draft-ietf- 508 detnet-architecture-13 (work in progress), May 2019. 510 [I-D.ietf-detnet-data-plane-framework] 511 Varga, B., Farkas, J., Berger, L., Fedyk, D., Malis, A., 512 Bryant, S., and J. Korhonen, "DetNet Data Plane 513 Framework", draft-ietf-detnet-data-plane-framework-00 514 (work in progress), May 2019. 516 [I-D.ietf-detnet-mpls] 517 Varga, B., Farkas, J., Berger, L., Fedyk, D., Malis, A., 518 Bryant, S., and J. Korhonen, "DetNet Data Plane: MPLS", 519 draft-ietf-detnet-mpls-00 (work in progress), May 2019. 521 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 522 Requirement Levels", BCP 14, RFC 2119, 523 DOI 10.17487/RFC2119, March 1997, 524 . 526 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 527 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 528 May 2017, . 530 10.2. Informative References 532 [RFC6378] Weingarten, Y., Ed., Bryant, S., Osborne, E., Sprecher, 533 N., and A. Fulignoli, Ed., "MPLS Transport Profile (MPLS- 534 TP) Linear Protection", RFC 6378, DOI 10.17487/RFC6378, 535 October 2011, . 537 [RFC6974] Weingarten, Y., Bryant, S., Ceccarelli, D., Caviglia, D., 538 Fondelli, F., Corsi, M., Wu, B., and X. Dai, 539 "Applicability of MPLS Transport Profile for Ring 540 Topologies", RFC 6974, DOI 10.17487/RFC6974, July 2013, 541 . 543 [RFC7271] Ryoo, J., Ed., Gray, E., Ed., van Helvoort, H., 544 D'Alessandro, A., Cheung, T., and E. Osborne, "MPLS 545 Transport Profile (MPLS-TP) Linear Protection to Match the 546 Operational Expectations of Synchronous Digital Hierarchy, 547 Optical Transport Network, and Ethernet Transport Network 548 Operators", RFC 7271, DOI 10.17487/RFC7271, June 2014, 549 . 551 [RFC8227] Cheng, W., Wang, L., Li, H., van Helvoort, H., and J. 552 Dong, "MPLS-TP Shared-Ring Protection (MSRP) Mechanism for 553 Ring Topology", RFC 8227, DOI 10.17487/RFC8227, August 554 2017, . 556 [RFC8578] Grossman, E., Ed., "Deterministic Networking Use Cases", 557 RFC 8578, DOI 10.17487/RFC8578, May 2019, 558 . 560 Authors' Addresses 562 Yuanlong Jiang 563 Huawei Technologies 564 Bantian, Longgang district 565 Shenzhen 518129 566 China 568 Phone: +86-18926415311 569 Email: jiangyuanlong@huawei.com 571 Norman Finn 572 Huawei Technologies 573 3755 Avocado Blvd 574 California 91941 575 USA 577 Phone: +1 925 980 6430 578 Email: norman.finn@mail01.huawei.com 580 Jeong-dong Ryoo 581 ETRI 582 218 Gajeongno 583 Yuseong-gu, Daejeon 34129 584 South Korea 586 Phone: +82-42-860-5384 587 Email: ryoo@etri.re.kr 588 Balazs Varga 589 Ericsson 590 Konyves Kalman krt. 11/B 591 Budapest 1097 592 Hungary 594 Email: balazs.a.varga@ericsson.com 596 Liang Geng 597 China Mobile 598 Beijing 599 China 601 Email: gengliang@chinamobile.com