idnits 2.17.1 draft-jiang-detnet-ring-00.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 (January 24, 2018) is 2282 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: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Y. Jiang 2 Internet-Draft N. Finn 3 Intended status: Informational Huawei 4 J. Ryoo 5 ETRI 6 B. Varga 7 Ericsson 8 L. Geng 9 China Mobile 10 Expires: July 2018 January 24, 2018 12 Deterministic Networking Application in Ring Topologies 13 draft-jiang-detnet-ring-00 15 Abstract 17 Deterministic Networking (DetNet) provides a capability to carry 18 data flows for real-time applications with extremely low data loss 19 rates and bounded latency. This document describes how DetNet can 20 be used in ring topologies to support Point-to-Point (P2P) and 21 Point-to-Multipoint (P2MP) real-time services. 23 Status of this Memo 25 This Internet-Draft is submitted to IETF in full conformance with 26 the provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF), its areas, and its working groups. Note that 30 other groups may also distribute working documents as Internet- 31 Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six 34 months and may be updated, replaced, or obsoleted by other 35 documents at any time. It is inappropriate to use Internet-Drafts 36 as reference material or to cite them other than as "work in 37 progress." 39 The list of current Internet-Drafts can be accessed at 40 http://www.ietf.org/ietf/1id-abstracts.txt 42 The list of Internet-Draft Shadow Directories can be accessed at 43 http://www.ietf.org/shadow.html 45 This Internet-Draft will expire on July 24, 2018. 47 Copyright Notice 49 Copyright (c) 2018 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with 57 respect to this document. Code Components extracted from this 58 document must include Simplified BSD License text as described in 59 Section 4.e of the Trust Legal Provisions and are provided without 60 warranty as described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction ............................................... 3 65 1.1. Conventions used in this document ....................... 4 66 1.2. Terminology ............................................. 4 67 2. P2P DetNet Ring ............................................ 4 68 2.1. DetNet applications on a single ring for P2P traffic .... 4 69 2.2. Implementation implications of a DetNet ring for P2P 70 traffic ...................................................... 5 71 3. P2MP DetNet Ring ........................................... 5 72 3.1. DetNet applications on a single ring for P2MP traffic ... 5 73 3.2. Section LSPs as underlay (Service layer replication) .... 6 74 3.3. P2MP LSP tunnels as underlay (LSP layer replication) .... 7 75 4. DetNet Ring Interconnections ............................... 8 76 4.1. Single node interconnection ............................. 8 77 4.1.1. DetNet relay node as interconnection node ............ 9 78 4.1.2. Elimination first approach ........................... 9 79 4.2. Dual node interconnection .............................. 10 80 4.2.1. Dual node interconnection for P2P traffic ........... 10 81 4.2.2. Elimination first approach in dual node interconnection 82 for P2P traffic ............................................. 11 83 4.2.3. Dual node interconnection for P2MP traffic using 84 section LSP ................................................. 11 85 4.2.4. Elimination first approach in dual node interconnection 86 for P2MP traffic using section LSP .......................... 12 87 4.2.5. Dual node interconnection for P2MP traffic using P2MP 88 LSP 13 89 5. Resource reservation ...................................... 13 90 6. Security Considerations ................................... 13 91 7. IANA Considerations ....................................... 13 92 8. References ............................................... 13 93 1.1. Informative References ................................ 13 94 9. Acknowledgments .......................................... 15 96 1. Introduction 98 An overview of Deterministic Networking (DetNet) architecture is 99 given in [I-D.ietf-detnet-architecture], and DetNet data plane 100 encapsulations are specified in [I-D.ietf-detnet-dp-sol]. But there 101 is not any discussion on a ring topology in [I-D.ietf-detnet- 102 architecture] yet. Furthermore, [I-D.ietf-detnet-use-cases] 103 outlines several Detnet use cases where multicast capability is 104 needed. If a multicast service replicates all of its packets from 105 the source (as a traditional Virtual Private LAN Service (VPLS) 106 does), the requirements of deterministic delay and high 107 availability for all these replicated packets will pose a great 108 challenge to the Detnet network. 110 In fact, ring topologies have been very popular and widely deployed 111 in network arrangements for various transport networks, such as 112 Synchronous Digital Hierarchy, Synchronous Optical Network, Optical 113 Transport Network, and Ethernet. The IETF has done some work on 114 ring protection in Multi-Protocol Label Switching - Transport 115 Profile (MPLS-TP), such as [RFC6974] and [RFC8227]. All these works, 116 except Ethernet ring protection, typically use swapping or steering 117 as the protection mechanism. As ring topologies are widely deployed 118 for transport networks, it is also necessary for DetNet to support 119 ring topologies (currently, there is not any discussion on a ring 120 topology in [I-D.ietf-detnet-architecture] yet). 122 This draft demonstrates how DetNet can be used in a ring topology. 123 Specifically, DetNet ring supports for Point-to-Point (P2P) and 124 Point-to-Multipoint (P2MP, for multicast services) are discussed in 125 details. This document assumes that MPLS encapsulation for DetNet 126 is supported as specified in [I-D.ietf-detnet-dp-sol] and all nodes 127 in a ring network can support the Multi-Protocol Label Switching 128 (MPLS) functionalities. It should be noted that it is more 129 convenient for DetNet to support a ring topology with the intrinsic 130 duplication and elimination mechanism, as there is no need of 131 swapping or steering operations (consequently, Operations, 132 Administration and Maintenance is not needed either for its working) 133 for any service protection. 135 1.1. Conventions used in this document 137 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 138 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 139 this document are to be interpreted as described in [RFC2119]. 141 1.2. Terminology 143 DetNet Deterministic Networking 145 LSP Label Switched Path 147 MPLS Multi-Protocol Label Switching 149 MPLS-TP Multi-Protocol Label Switching - Transport Profile 151 P2MP Point-to-Point 153 P2P Point-to-Multipoint 155 PW Pseudowire 157 2. P2P DetNet Ring 159 2.1. DetNet applications on a single ring for P2P traffic 161 Figure 1 depicts an example of the DetNet ring for P2P real time 162 traffic. Nodes A and C are DetNet aware devices, and P2P DetNet 163 traffic is transported from node A to node C. 165 A clockwise and a counter clockwise Pseudowire (PW) and Label 166 Switched Path (LSP) tunnel are configured from node A to node C 167 respectively. The DetNet traffic is replicated on node A, 168 encapsulated with the specific PW and LSP labels, and transported 169 on both LSP paths towards node C. Upon reception of the traffic, 170 node C terminates the LSP and is aware of the DetNet traffic by 171 inspection of the PW label carried in each packet. An elimination 172 function in node C guarantees that only one copy of the DetNet 173 service exits on egress with the help of the DetNet sequence number. 175 +---+#############+---+ 176 | B |-------------| C | +-- DetNet 177 +---+ +---+ egress 178 #/ *\ 179 #/ *\ 180 #/ *\ 181 +---+ +---+ 182 DetNet--+ | A | | D | 183 ingress +---+ +---+ 184 \* */ 185 \* */ 186 \* */ 187 +---+*************+---+ 188 | F |-------------| E | 189 +---+ +---+ 191 ----- Physical Links 192 ##### Clockwise_ 193 ***** Counter Clockwise 195 Figure 1: DetNet Ring for P2P traffic 197 2.2. Implementation implications of a DetNet ring for P2P traffic 199 In a DetNet ring for P2P traffic, one path may be far longer than 200 the other path for the DetNet (this is a DetNet issue more general 201 than a ring). 203 The buffer need to be large enough to accommodate for the sequence 204 number difference between these two paths. Otherwise, some packets 205 may get lost when a link fault causes traffic switching from a path 206 to another path. 208 3. P2MP DetNet Ring 210 3.1. DetNet applications on a single ring for P2MP traffic 212 Figure 2 further depicts an example of the DetNet ring for P2MP 213 real time traffic. Nodes A, B, C, E and F are DetNet aware devices, 214 and P2MP DetNet traffic is transported from head-end node A to 215 multiple tail-end nodes C, E and F. 217 Two approaches are described in Section 3.2 and 3.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 3.2. Section LSPs as underlay (Service 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, DetNet PW layer replicates the DetNet 248 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 in node A, encapsulated with the specific PW 253 and section LSP labels, and then transported on both section LSPs 254 (i.e., A-B and A-F) originated from the head-end. 256 All intermediate nodes (non tail-ends) on the ring SHOULD 257 transparently forward the DetNet traffic with a specific PW to the 258 next hop on the ring in the same direction. 260 All DetNet tail-ends except the penultimate node (egress nodes such 261 as nodes C and E in the clockwise, and node F, E and C in the 262 counter clockwise) on the ring MUST support both DetNet 263 replication and elimination functions. For example, upon reception 264 of the clockwise traffic, node C terminates the section LSP and is 265 aware of the DetNet traffic by inspection of the PW label in the 266 packet. Firstly, node C needs to transparently forward the DetNet 267 traffic with a specific PW to the next hop on the ring in the same 268 direction. Secondly, DetNet traffic is directed to a DetNet 269 elimination function associated with a specific PW, only one copy 270 of the DetNet service exits on egress by inspection of the DetNet 271 sequence number. 273 If multiple endpoints are attached to a tail-end node, a multicast 274 module can be used to forward the filtered DetNet traffic to all 275 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) needs to terminate 279 the DetNet flow. For example, upon reception of the clockwise 280 DetNet traffic, node F terminates the DetNet traffic by inspection 281 of the PW label in the packet. As an alternative, the last DetNet 282 tail-end (such as node C on the counter clock-wise LSP) may 283 terminate the DetNet flow, so that the bandwidth from this node to 284 the penultimate node can be saved. 286 3.3. P2MP LSP tunnels as underlay (LSP 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, LSP layer 294 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 298 DetNet replication function. Upon reception on node A, the DetNet 299 traffic is replicated, encapsulated with the specific PW and P2MP 300 LSP labels, and transported on both P2MP LSP tunnels in the ring. 302 All DetNet tail-ends (egress nodes such as node C, E and F in 303 Figure 2) on the ring need to support the DetNet elimination 304 function. For example, upon reception of the traffic, node C pops 305 the P2MP LSP label and is aware of the DetNet traffic by inspection 306 of the PW label in the label stack. Traffic from both directions 307 with the same PW is directed to the same DetNet elimination 308 function so that only one copy of the DetNet service exits on 309 egress by inspection of the DetNet sequence number. 311 If multiple endpoints are attached to a tail-end node, a multicast 312 module can be used to forward the filtered DetNet traffic to all 313 these endpoints. 315 4. DetNet Ring Interconnections 317 Two DetNet rings can be connected via one or more interconnection 318 nodes. Figures 3a and 3b show ring interconnection scenarios with a 319 single node and dual nodes, respectively. In the interconnected 320 rings, each ring operates in the same way as described in Sections 321 2 and 3 except the nodes that are used to interconnect two rings. 323 In this section, we describe the behavior of interconnection nodes 324 with the traffic going from Ring L to Ring R. Symmetrical 325 description is assumed for the traffic in the other direction. 327 S T 328 B C S T O---O 329 O---O O---O / \ 330 / \ / \ B I1/ \ 331 / \ / \ O---O Ring R O U 332 A O Ring L O Ring R O U / \ / 333 \ /I\ / / \ / 334 \ / \ / A O Ring L O---O 335 O---O O---O \ /I2 V 336 F E W V \ / 337 O---O 338 F E 339 (a) (b) 341 Figure 3: DetNet ring interconnection with: a) single node (node I), 342 and b) dual nodes (nodes I1 and I2). 344 4.1. Single node interconnection 346 In the case of the single node interconnection, as shown in Figure 347 3(a), both P2P and P2MP DetNet traffic that needs to be transported 348 between Ring L and Ring R uses the single interconnection node 349 between two rings. Two approaches are described in the following 350 subsections. 352 4.1.1. DetNet relay node as interconnection node 354 In this approach, the interconnection node acts as a DetNet relay 355 node, which provides packet replication and elimination. 357 For P2P DetNet traffic going from Ring L to Ring R, interconnection 358 node I performs packet replication on input and sends the packet to 359 the outputs connected to the links on Ring R clockwise and counter- 360 clockwise. Then, after each output of interconnection node I 361 eliminates any duplicates, the packet is transported over Ring R. 362 In Figure 3(a), when interconnection node I receives traffic on 363 input from node C, node I replicates the traffic and send it to 364 both outputs to nodes S and W. For the traffic from input from node 365 E, node I also replicates the traffic and send it to both outputs 366 to nodes S and W. Then, the output to node S eliminates any 367 duplicates, and sends only one copy to node S. Similarly, the 368 output to node W eliminates any duplicates, and sends only one copy 369 to node W. 371 For P2MP DetNet traffic going from Ring L to Ring R, the input of 372 interconnection node I performs the same packet replication as 373 described for P2P DetNet traffic going from Ring L to Ring R. In 374 addition, the third copy is sent to the other ring port on Ring L, 375 in order to deliver the P2MP DetNet traffic to the remaining tail- 376 end nodes that reside in the other side of Ring L over the 377 interconnected node. The outputs to nodes S and W perform the same 378 duplicate elimination as described for P2P DetNet traffic going 379 from Ring L to Ring R. 381 4.1.2. Elimination first approach 383 This approach uses two "logical" DetNet relay nodes (or, DA-*-PE as 384 described in [I-D.ietf-detnet-dp-sol]) coupled back-to-back, such 385 that interconnection node I performs the duplicate elimination 386 function first. 388 For the Detnet traffic arrived from both node C and node E, the 389 interconnection node I performs duplicate elimination first, and 390 then replicates the traffic in both clockwise and counter-clockwise 391 directions of Ring R, i.e., one copy to node S and the other copy 392 to node W. Therefore, this approach reduces the bandwidth used 393 inside the interconnection node when there is a central unit that 394 eliminates any duplicate among the packets arrived from two ring 395 ports before replication. 397 4.2. Dual node interconnection 399 In order to prevent a single point of failure, two interconnection 400 nodes can be used as shown in Figure 3(b). To provide high 401 availability for DetNet services, dual node interconnection is 402 recommended. Two interconnection nodes act as DetNet relay nodes, 403 which provide packet replication and elimination. 405 4.2.1. Dual node interconnection for P2P traffic 407 For the P2P DetNet traffic that flows from Ring L to Ring R, the 408 operation of interconnection nodes I1 and I2 follows the 409 description on relay nodes shown in Figure 1 of Section 3.2.4 in 410 [I-D.ietf-detnet-architecture]. In the following, the operation is 411 explained with Figure 3(a). 413 When interconnection node I1 receives clockwise traffic from node B, 414 it replicates the traffic and sends one copy to interconnection 415 node I2 and the other copy to output towards node S. 417 When interconnection node I1 receives counter-clockwise traffic 418 from interconnection node I2, it forwards the traffic to the output 419 that is connected to node S. 421 At the output of interconnection node I1 facing to node S, 422 duplicate elimination is performed for the clockwise traffic from 423 node B and the counter-clockwise traffic from interconnection node 424 I2, and only one copy is sent to the clockwise direction of Ring R 425 (i.e., sent towards node S). 427 When interconnection node I2 receives counter-clockwise traffic 428 from node E, it replicates the traffic and sends one copy to 429 interconnection node I1 and the other copy to the output that is 430 connected to node V. 432 When interconnection node I2 receives clockwise traffic from 433 interconnection node I1, it forwards the traffic to the output that 434 is connected to node V. 436 At the output of interconnection node I2 facing to node V, 437 duplicate elimination is performed for the counter-clockwise 438 traffic from node E and the clockwise traffic from interconnection 439 node I1, and only one copy is sent to the counter-clockwise 440 direction of Ring R (i.e., sent towards node V). 442 4.2.2. Elimination first approach in dual node interconnection for P2P 443 traffic 445 The elimination first approach described in Section 4.1.2 can also 446 be used for dual node interconnection, so that each interconnection 447 node performs the duplicate elimination function first. 449 For the traffic arrived from both node B and interconnection node 450 I2, the interconnection node I1 performs duplicate elimination 451 first, and replicates the traffic in both clockwise and counter- 452 clockwise directions of Ring R, i.e., one copy to node S and the 453 other copy to interconnection node I2. 455 For the traffic arrived from both node E and interconnection node 456 I1, the interconnection node I2 performs duplicate elimination 457 first, and replicates the traffic in both clockwise and counter- 458 clockwise directions of Ring R, i.e., one copy to interconnection 459 node I1 and the other copy to node V. 461 4.2.3.Dual node interconnection for P2MP traffic using section LSP 463 For the P2MP traffic that flows from Ring L to Ring R, each ring is 464 configured and operated as described in Section 3.2 except the 465 interconnection nodes, whose operations are described below. 467 When interconnection node I1 receives clockwise traffic from node B, 468 it replicates the traffic and sends one copy to interconnection 469 node I2 and the other copy to the output that is connected to node 470 S. 472 When interconnection node I1 receives the counter-clockwise traffic 473 from interconnection node I2, it replicates the traffic and sends 474 one copy to node B and the other copy to the output that is 475 connected to node S unless interconnection node I1 is the 476 penultimate node for the counter-clockwise traffic on Ring L. In 477 the case that interconnection node I1 is the penultimate node for 478 the counter-clockwise traffic on Ring L, the counter-clockwise 479 traffic from interconnection node I2 is forwarded to the output 480 that is connected to node S. 482 At the output interface of I1 facing to node S, duplicate 483 elimination is performed for the clockwise traffic from node B and 484 the counter-clockwise traffic from interconnection node I2, and 485 only one copy is sent to the clockwise direction of Ring R (i.e., 486 sent towards node S). 488 When interconnection node I2 receives the counter-clockwise traffic 489 from node E, it replicates the traffic and sends one copy to 490 interconnection node I1 and the other copy to the output that is 491 connected to node V. 493 When interconnection node I2 receives the clockwise traffic from 494 interconnection node I1, it replicates the traffic and sends one 495 copy to node E and the other copy to the output that is connected 496 to node V unless interconnection node I2 is the penultimate node 497 for the clockwise traffic in Ring L. In the case that 498 interconnection node I2 is the penultimate node for the clockwise 499 traffic in Ring L, the clockwise traffic from interconnection node 500 I1 is forwarded to the output that is connected to node V. 502 At the output interface of I2 facing to node V, duplicate 503 elimination is performed for the counter-clockwise traffic from 504 node E and the clockwise traffic from interconnection node I1, and 505 only one copy is sent to the counter-clockwise direction of Ring R 506 (i.e., sent towards node V). 508 4.2.4. Elimination first approach in dual node interconnection for 509 P2MP traffic using section LSP 511 The elimination first approach described in Section 4.2.2 is 512 applied without modification for dual node interconnection for P2MP 513 traffic using section LSP only if interconnection nodes I1 and I2 514 are the penultimate nodes for the counter-clockwise traffic and the 515 clockwise traffic on Ring L, respectively. 517 When an interconnection node is not the penultimate node for either 518 clockwise or counter-clockwise traffic, the interconnection node 519 replicates the traffic in three ways; one for the remaining tail- 520 ends on Ring L and two for the tail-ends in both clockwise and 521 counter-clockwise directions on Ring R. 523 For example, assume that interconnection node I2 is not the 524 penultimate node for the clock-wise traffic on Ring L. For the 525 traffic arrived from both node E and interconnection node I1, 526 interconnection node I2 performs duplicate elimination first, and 527 replicates the traffic for the following three outputs; one copy to 528 the output towards node E, another copy to the output towards 529 interconnection node I1, and the other copy to the output towards 530 node V. 532 4.2.5.Dual node interconnection for P2MP traffic using P2MP LSP 534 If P2MP LSPs are used in the interconnected rings, two P2MP 535 unidirectional LSP tunnels are used on each ring for the clockwise 536 and counter-clockwise directions. 538 When the P2MP traffic is forwarded from one ring to another ring, 539 for example from Ring L to Ring R in Figure 3(b), each P2MP LSP in 540 Ring L MUST include interconnection nodes I1 and I2 as tail-ends. 541 For Ring R, one P2MP LSP is set up from interconnection node I1 to 542 all the tail-ends in the clockwise direction on Ring R, and the 543 other P2MP LSP is set up from interconnection node I2 to all the 544 tail-ends in the counter-clockwise direction on Ring R. Therefore, 545 an interconnection node acts as a tail-end for one ring and a head- 546 end for another ring in one direction, and performs the same 547 operation of tail-end and head-end as specified in Section 3.3. 549 5. Resource reservation 551 In order to guarantee that DetNet flows don't suffer from network 552 congestion, resource reservation considerations as outlined in 553 Section 4.3.2 of [I-D.ietf-detnet-architecture] apply here. 555 6. Security Considerations 557 This document describes the application of DetNet on general ring 558 topologies. Thus the security considerations as described in [I- 559 D.ietf-detnet-dp-sol] also apply to this document. 561 7. IANA Considerations 563 There are no IANA actions required by this document. 565 8. References 567 1.1. Informative References 569 [I-D.ietf-detnet-architecture] Finn, N., Thubert, P., Varga, B., 570 and J. Farkas, "Deterministic Networking Architecture", 571 draft-ietf-detnet-architecture (work in progress), 572 October 2017 574 [I-D.ietf-detnet-dp-sol] Korhonen, J., Andersson, L., Jiang, Y., 575 and etc., "DetNet Data Plane Encapsulation", draft-ietf- 576 detnet-dp-sol (work in progress), October, 2017 578 [I-D.ietf-detnet-use-cases] Grossman, E., and etc., "Deterministic 579 Networking Use Cases", draft-ietf-detnet-use-cases (work 580 in progress), October, 2017 582 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 583 Requirement Levels", BCP 14, RFC 2119, March 1997 585 [RFC6974] Weingarten, Y., Bryant, S., and etc., "Applicability of 586 MPLS Transport Profile for Ring Topologies", RFC 6974, 587 July 2013 589 [RFC8227] Cheng, W., Wang, L., and etc., "MPLS-TP Shared-Ring 590 Protection (MSRP) Mechanism for Ring Topology", RFC 8227, 591 August 2017 593 9. Acknowledgments 595 TBD 597 Authors' Addresses 599 Yuanlong Jiang 600 Huawei Technologies Co., Ltd. 601 Bantian, Longgang district 602 Shenzhen 518129, China 603 Phone: +86-18926415311 604 Email: jiangyuanlong@huawei.com 606 Norman Finn 607 Huawei Technologies Co. Ltd 608 3755 Avocado Blvd, 609 California 91941, USA 610 Phone: +1 925 980 6430 611 Email: norman.finn@mail01.huawei.com 613 Jeong-dong Ryoo 614 ETRI 615 218 Gajeongno 616 Yuseong-gu, Daejeon 305-700, South Korea 617 Phone: +82-42-860-5384 618 Email: ryoo@etri.re.kr 620 Balazs Varga 621 Ericsson 622 Konyves Kalman krt. 11/B 623 Budapest 1097 624 Hungary 625 Email: balazs.a.varga@ericsson.com 627 Liang Geng 628 China Mobile 629 Beijing, China 630 Email: gengliang@chinamobile.com