idnits 2.17.1 draft-jiang-detnet-ring-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 -- The document date (July 2, 2018) is 2117 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) 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: Standards Track Huawei 4 J. Ryoo 5 ETRI 6 B. Varga 7 Ericsson 8 L. Geng 9 China Mobile 10 Expires: January 2019 July 2, 2018 12 Deterministic Networking Application in Ring Topologies 13 draft-jiang-detnet-ring-01 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 January 2, 2019. 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 ....................... 3 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 ............................. 9 77 4.2. Dual node interconnection ............................... 9 78 4.2.1. Dual node interconnection for P2P traffic ............ 9 79 4.2.2. Dual node interconnection for P2MP traffic using 80 section LSP ................................................. 10 81 4.2.3. Dual node interconnection for P2MP traffic using P2MP 82 LSP 11 83 5. Resource reservation ...................................... 11 84 6. Security Considerations ................................... 11 85 7. IANA Considerations ....................................... 12 86 8. References ................................................ 12 87 8.1. Normative References ................................... 12 88 8.2. Informative References ................................. 12 89 9. Acknowledgments ........................................... 13 91 1. Introduction 93 An overview of Deterministic Networking (DetNet) architecture is 94 given in [I-D.ietf-detnet-architecture], and DetNet data plane 95 encapsulations are specified in [I-D.ietf-detnet-dp-sol]. But there 96 is not any discussion on a ring topology in [I-D.ietf-detnet- 97 architecture] yet. Furthermore, [I-D.ietf-detnet-use-cases] 98 outlines several Detnet use cases where multicast capability is 99 needed. If a multicast service replicates all of its packets from 100 the source (as a traditional Virtual Private LAN Service (VPLS) 101 does), the requirements of deterministic delay and high 102 availability for all these replicated packets will pose a great 103 challenge to the Detnet network. 105 In fact, ring topologies have been very popular and widely deployed 106 in network arrangements for various transport networks, such as 107 Synchronous Digital Hierarchy, Synchronous Optical Network, Optical 108 Transport Network, and Ethernet. The IETF has done some work on 109 ring protection in Multi-Protocol Label Switching - Transport 110 Profile (MPLS-TP), such as [RFC6974] and [RFC8227]. All these works, 111 except Ethernet ring protection, typically use swapping or steering 112 as the protection mechanism. As ring topologies are widely deployed 113 for transport networks, it is also necessary for DetNet to support 114 ring topologies (currently, there is not any discussion on a ring 115 topology in [I-D.ietf-detnet-architecture] yet). 117 This draft demonstrates how DetNet can be used in a ring topology. 118 Specifically, DetNet ring supports for Point-to-Point (P2P) and 119 Point-to-Multipoint (P2MP, for multicast services) are discussed in 120 details. This document assumes that MPLS encapsulation for DetNet 121 is supported as specified in [I-D.ietf-detnet-dp-sol-mpls] and all 122 nodes in a ring network can support the Multi-Protocol Label 123 Switching (MPLS) functionalities. It should be noted that it is 124 more convenient for DetNet to support a ring topology with the 125 intrinsic duplication and elimination mechanism, as there is no 126 need of swapping or steering operations (consequently, its 127 Operations, Administration and Maintenance (OAM) can also be 128 simplified) for any service protection. 130 1.1. Conventions used in this document 132 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 133 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 134 this document are to be interpreted as described in [RFC2119]. 136 1.2. Terminology 138 DetNet Deterministic Networking 140 LSP Label Switched Path 142 MPLS Multi-Protocol Label Switching 144 MPLS-TP Multi-Protocol Label Switching - Transport Profile 146 P2MP Point-to-Point 148 P2P Point-to-Multipoint 150 PEF Packet Elimination Function 152 PRF Packet Replication Function 154 PW Pseudowire 156 2. P2P DetNet Ring 158 2.1. DetNet applications on a single ring for P2P traffic 160 Figure 1 depicts an example of the DetNet ring for P2P real time 161 traffic. Nodes A and C are DetNet aware devices, and P2P DetNet 162 traffic is transported from node A to node C. 164 A clockwise and a counter clockwise Pseudowire (PW) and Label 165 Switched Path (LSP) tunnel are configured from node A to node C 166 respectively. The DetNet traffic is replicated by a Packet 167 Replication Function (PRF) in node A, encapsulated with the 168 specific PW and LSP labels, and transported on both LSP paths 169 towards node C. Upon reception of the traffic, node C terminates 170 the LSP and is aware of the DetNet traffic by inspection of the PW 171 label carried in each packet. A Packet Elimination Function (PEF) 172 in node C guarantees that only one copy of the DetNet service exits 173 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 needs 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 PRF and PEF 263 functions. For example, upon reception of the clockwise traffic, 264 node C terminates the section LSP and is aware of the DetNet 265 traffic by inspection of the PW label in the packet. Firstly, node 266 C needs to transparently forward the DetNet traffic with a specific 267 PW to the next hop on the ring in the same direction. Secondly, 268 DetNet traffic is directed to a DetNet PEF associated with a 269 specific PW, only one copy of the DetNet service exits on egress by 270 inspection of the DetNet sequence number. 272 If multiple endpoints are attached to a tail-end node, a multicast 273 module can be used to forward the filtered DetNet traffic to all 274 these endpoints. 276 To avoid a loop of DetNet service, the penultimate node in the ring 277 (such as node B on the counter clock-wise LSP) needs to terminate 278 the DetNet flow. For example, upon reception of the clockwise 279 DetNet traffic, node F terminates the DetNet traffic by inspection 280 of the PW label in the packet. As an alternative, the last DetNet 281 tail-end (such as node C on the counter clock-wise LSP) may 282 terminate the DetNet flow, so that the bandwidth from this node to 283 the penultimate node can be saved. 285 3.3. P2MP LSP tunnels as underlay (LSP layer replication) 287 If P2MP LSPs are used as an underlay for the DetNet service, a P2MP 288 unidirectional LSP tunnel in clockwise is set up from head-end 289 (ingress node A) to all the tail-ends (egress nodes C, E and F) for 290 the ring, and another P2MP unidirectional LSP tunnel in counter 291 clockwise is set up from head-end (ingress node A) to all the tail- 292 ends (egress nodes F, E and C) for the ring. Thus, a PRF in LSP 293 layer replicates the DetNet packets from one tail-end to another 294 neighboring tail-end. 296 The DetNet head-end (i.e., node A) in the ring needs to support 297 DetNet PRF function. Upon reception on node A, the DetNet traffic 298 is replicated, encapsulated with the specific PW and P2MP LSP 299 labels, and transported on both P2MP LSP tunnels in the ring. 301 All DetNet tail-ends (egress nodes such as node C, E and F in 302 Figure 2) on the ring need to support the DetNet PEF function. For 303 example, upon reception of the traffic, node C pops the P2MP LSP 304 label and is aware of the DetNet traffic by inspection of the PW 305 label in the label stack. Traffic from both directions with the 306 same PW is directed to the same PEF so that only one copy of the 307 DetNet service exits on egress by inspection of the DetNet sequence 308 number. 310 If multiple endpoints are attached to a tail-end node, a multicast 311 module can be used to forward the filtered DetNet traffic to all 312 these endpoints. 314 4. DetNet Ring Interconnections 316 Two DetNet rings can be connected via one or more interconnection 317 nodes. Figures 3(a) and 3(b) show the ring interconnection 318 scenarios with a single node and dual nodes respectively. In the 319 interconnected rings, each ring operates in the same way as 320 described in Sections 2 and 3 except the node or nodes that are 321 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 (i.e., 326 from Ring R to Ring L). 328 S T 329 B C S T O---O 330 O---O O---O / \ 331 / \ / \ B I1/ \ 332 / \ / \ O---O Ring R O U 333 A O Ring L O Ring R O U / \ / 334 \ /I\ / / \ / 335 \ / \ / A O Ring L O---O 336 O---O O---O \ /I2 V 337 F E W V \ / 338 O---O 339 F E 341 (a) (b) 343 Figure 3: DetNet ring interconnection with: (a) single node (node 344 I), and (b) dual nodes (nodes I1 and I2). 346 4.1. Single node interconnection 348 In the case of the single node interconnection, as shown in Figure 349 3(a), both P2P and P2MP DetNet traffic that needs to be transported 350 between Ring L and Ring R uses a single interconnection node 351 between two rings. Thus, the interconnection node acts as a DetNet 352 relay node, which provides both PRF and PEF functions. 354 For P2P DetNet traffic going from Ring L to Ring R, interconnection 355 node I receives the same Detnet flow traffic from both node C and 356 node E (i.e., clockwise and counter-clockwise), a PEF in node I 357 performs packet elimination, and a PRF in node I replicates the 358 packet, node I then sends one copy to node S and another copy to 359 node W. 361 For P2MP DetNet traffic going from Ring L to Ring R, 362 interconnection node I performs the same packet elimination and 363 replication functions as described above. In addition, node I 364 further transparently forwards the P2MP DetNet traffic on Ring L in 365 the same direction if it is not the last tail-end node. 367 4.2. Dual node interconnection 369 In order to prevent a single point of failure, two interconnection 370 nodes can be used as shown in Figure 3(b). To provide high 371 availability for DetNet services, dual node interconnection is 372 recommended. Two interconnection nodes act as DetNet relay nodes, 373 each provides both packet replication and elimination functions. 375 4.2.1. Dual node interconnection for P2P traffic 377 For the P2P DetNet traffic that flows from Ring L to Ring R, the 378 operation of interconnection nodes I1 and I2 follows the 379 description on relay nodes shown in Figure 1 of Section 3.2.4 in 380 [I-D.ietf-detnet-architecture]. In the following, the operation is 381 explained with Figure 3(a). 383 When interconnection node I1 receives clockwise traffic from node B, 384 it replicates the traffic and sends one copy to interconnection 385 node I2 and another copy to a PEF in node I1. 387 When interconnection node I1 receives counter-clockwise traffic 388 from interconnection node I2, it also forwards the traffic to the 389 PEF of I1. 391 At the PEF of I1, duplicate elimination is performed for the 392 clockwise traffic from node B and the counter-clockwise traffic 393 from interconnection node I2, and only one copy is sent to the 394 clockwise direction of Ring R (i.e., sent towards node S). 396 When interconnection node I2 receives counter-clockwise traffic 397 from node E, it replicates the traffic and sends one copy to 398 interconnection node I1 and another copy to a PEF in node I2. 400 When interconnection node I2 receives clockwise traffic from 401 interconnection node I1, it also forwards the traffic to the PEF of 402 I2. 404 At the PEF of I2, duplicate elimination is performed for the 405 counter-clockwise traffic from node E and the clockwise traffic 406 from interconnection node I1, and only one copy is sent to the 407 counter-clockwise direction of Ring R (i.e., sent towards node V). 409 4.2.2.Dual node interconnection for P2MP traffic using section LSP 411 For the P2MP traffic that flows from Ring L to Ring R, each ring is 412 configured and operated as described in Section 3.2 except the 413 interconnection nodes, whose operations are described below. 415 When interconnection node I1 receives clockwise traffic from node B, 416 its PRF replicates the traffic and sends one copy to 417 interconnection node I2 and another copy to node I1's PEF. 419 When interconnection node I1 receives the counter-clockwise traffic 420 from interconnection node I2, its PRF replicates the traffic and 421 sends one copy to node B and another copy to node I1's PEF unless 422 interconnection node I1 is the penultimate node for the counter- 423 clockwise traffic on Ring L. In the case that interconnection node 424 I1 is the penultimate node for the counter-clockwise traffic on 425 Ring L, the counter-clockwise traffic from interconnection node I2 426 is only forwarded to node I1's PEF. 428 At node I1's PEF, duplicate elimination is performed for the 429 clockwise traffic from node B and the counter-clockwise traffic 430 from interconnection node I2, and only one copy is sent to the 431 clockwise direction of Ring R (i.e., sent towards node S). 433 When interconnection node I2 receives the counter-clockwise traffic 434 from node E, its PRF replicates the traffic and sends one copy to 435 interconnection node I1 and another copy to node I2's PEF. 437 When interconnection node I2 receives the clockwise traffic from 438 interconnection node I1, its PRF replicates the traffic and sends 439 one copy to node E and another copy to node I2's PEF unless 440 interconnection node I2 is the penultimate node for the clockwise 441 traffic in Ring L. In the case that interconnection node I2 is the 442 penultimate node for the clockwise traffic in Ring L, the clockwise 443 traffic from interconnection node I1 is only forwarded to node I2's 444 PEF. 446 At node I2's PEF, duplicate elimination is performed for the 447 counter-clockwise traffic from node E and the clockwise traffic 448 from interconnection node I1, and only one copy is sent to the 449 counter-clockwise direction of Ring R (i.e., sent towards node V). 451 4.2.3.Dual node interconnection for P2MP traffic using P2MP LSP 453 If P2MP LSPs are used in the interconnected rings, two P2MP 454 unidirectional LSP tunnels are used on each ring for the clockwise 455 and counter-clockwise directions. 457 When the P2MP traffic is forwarded from one ring to another ring, 458 for example from Ring L to Ring R in Figure 3(b), each P2MP LSP in 459 Ring L MUST include interconnection nodes I1 and I2 as its tail- 460 ends. For Ring R, one P2MP LSP is set up from interconnection node 461 I1 to all the tail-ends in the clockwise direction on Ring R, and 462 the other P2MP LSP is set up from interconnection node I2 to all 463 the tail-ends in the counter-clockwise direction on Ring R. 464 Therefore, an interconnection node acts as a tail-end for one ring 465 and a head-end for another ring in one direction, and performs the 466 same operation of tail-end and head-end as specified in Section 3.3. 468 5. Resource reservation 470 In order to guarantee that DetNet flows don't suffer from network 471 congestion, resource reservation considerations as outlined in 472 Section 4.3.2 of [I-D.ietf-detnet-architecture] apply here. 474 6. Security Considerations 476 This document describes the application of DetNet on general ring 477 topologies. Thus the security considerations as described in [I- 478 D.ietf-detnet-dp-sol] also apply to this document. 480 7. IANA Considerations 482 There are no IANA actions required by this document. 484 8. References 486 8.1. Normative References 488 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 489 Requirement Levels", BCP 14, RFC 2119, March 1997 491 [I-D.ietf-detnet-architecture] Finn, N., Thubert, P., Varga, B., 492 and J. Farkas, "Deterministic Networking Architecture", 493 draft-ietf-detnet-architecture (work in progress), June 494 2018 496 [I-D.ietf-detnet-dp-sol-mpls] Korhonen, J., Varga, B., "DetNet MPLS 497 Data Plane Encapsulation", draft-ietf-detnet-dp-sol-mpls 498 (work in progress), June 2018 500 8.2. Informative References 502 [I-D.ietf-detnet-dp-sol] Korhonen, J., Andersson, L., Jiang, Y., 503 and etc., "DetNet Data Plane Encapsulation", draft-ietf- 504 detnet-dp-sol (work in progress), March 2018 506 [I-D.ietf-detnet-use-cases] Grossman, E., and etc., "Deterministic 507 Networking Use Cases", draft-ietf-detnet-use-cases (work 508 in progress), June 2018 510 [RFC6974] Weingarten, Y., Bryant, S., and etc., "Applicability of 511 MPLS Transport Profile for Ring Topologies", RFC 6974, 512 July 2013 514 [RFC8227] Cheng, W., Wang, L., and etc., "MPLS-TP Shared-Ring 515 Protection (MSRP) Mechanism for Ring Topology", RFC 8227, 516 August 2017 518 9. Acknowledgments 520 TBD 522 Authors' Addresses 524 Yuanlong Jiang 525 Huawei Technologies Co., Ltd. 526 Bantian, Longgang district 527 Shenzhen 518129, China 528 Phone: +86-18926415311 529 Email: jiangyuanlong@huawei.com 531 Norman Finn 532 Huawei Technologies Co. Ltd 533 3755 Avocado Blvd, 534 California 91941, USA 535 Phone: +1 925 980 6430 536 Email: norman.finn@mail01.huawei.com 538 Jeong-dong Ryoo 539 ETRI 540 218 Gajeongno 541 Yuseong-gu, Daejeon 305-700, South Korea 542 Phone: +82-42-860-5384 543 Email: ryoo@etri.re.kr 545 Balazs Varga 546 Ericsson 547 Konyves Kalman krt. 11/B 548 Budapest 1097 549 Hungary 550 Email: balazs.a.varga@ericsson.com 552 Liang Geng 553 China Mobile 554 Beijing, China 555 Email: gengliang@chinamobile.com