idnits 2.17.1 draft-ietf-detnet-data-plane-framework-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 198 has weird spacing: '...e stack v ...' -- The document date (September 12, 2019) is 1688 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-14) exists of draft-ietf-detnet-flow-information-model-05 == Outdated reference: A later version (-07) exists of draft-ietf-detnet-ip-01 == Outdated reference: A later version (-13) exists of draft-ietf-detnet-mpls-01 == Outdated reference: A later version (-07) exists of draft-ietf-detnet-mpls-over-tsn-00 == Outdated reference: A later version (-08) exists of draft-ietf-detnet-mpls-over-udp-ip-01 == Outdated reference: A later version (-16) exists of draft-ietf-detnet-security-05 == Outdated reference: A later version (-14) exists of draft-ietf-pce-pcep-extension-for-pce-controller-02 == Outdated reference: A later version (-28) exists of draft-ietf-spring-srv6-network-programming-01 -- Obsolete informational reference (is this intentional?): RFC 5575 (Obsoleted by RFC 8955) Summary: 0 errors (**), 0 flaws (~~), 10 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DetNet B. Varga, Ed. 3 Internet-Draft J. Farkas 4 Intended status: Informational Ericsson 5 Expires: March 15, 2020 L. Berger 6 D. Fedyk 7 LabN Consulting, L.L.C. 8 A. Malis 9 Independent 10 S. Bryant 11 Futurewei Technologies 12 J. Korhonen 13 September 12, 2019 15 DetNet Data Plane Framework 16 draft-ietf-detnet-data-plane-framework-02 18 Abstract 20 This document provides an overall framework for the Deterministic 21 Networking data plane. It covers concepts and considerations that 22 are generally common to any Deterministic Networking data plane 23 specification. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on March 15, 2020. 42 Copyright Notice 44 Copyright (c) 2019 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 2.1. Terms Used in This Document . . . . . . . . . . . . . . . 4 62 2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 4 63 3. DetNet Data Plane Overview . . . . . . . . . . . . . . . . . 5 64 3.1. Data Plane Characteristics . . . . . . . . . . . . . . . 6 65 3.2. Encapsulation . . . . . . . . . . . . . . . . . . . . . . 7 66 3.3. DetNet Specific Metadata . . . . . . . . . . . . . . . . 7 67 3.4. DetNet IP Data Plane . . . . . . . . . . . . . . . . . . 8 68 3.5. DetNet MPLS Data Plane . . . . . . . . . . . . . . . . . 9 69 3.6. Further DetNet Data Plane Considerations . . . . . . . . 9 70 3.6.1. Service Protection . . . . . . . . . . . . . . . . . 11 71 3.6.2. Aggregation Considerations . . . . . . . . . . . . . 13 72 3.6.3. End-System Specific Considerations . . . . . . . . . 14 73 3.6.4. Sub-Network Considerations . . . . . . . . . . . . . 15 74 4. Controller Plane (Management and Control) 75 Considerations . . . . . . . . . . . . . . . . . . . . . . . 16 76 4.1. DetNet Controller Plane Requirements . . . . . . . . . . 16 77 4.2. Generic Controller Plane Considerations . . . . . . . . . 17 78 4.2.1. Flow Aggregation Control . . . . . . . . . . . . . . 18 79 4.2.2. Explicit Routes . . . . . . . . . . . . . . . . . . . 19 80 4.2.3. Contention Loss and Jitter Reduction . . . . . . . . 19 81 4.2.4. Bidirectional Traffic . . . . . . . . . . . . . . . . 20 82 4.3. Packet Replication, Elimination, and Ordering (PREOF) . . 21 83 5. Security Considerations . . . . . . . . . . . . . . . . . . . 21 84 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 85 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 86 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 87 8.1. Normative References . . . . . . . . . . . . . . . . . . 22 88 8.2. Informative References . . . . . . . . . . . . . . . . . 22 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 91 1. Introduction 93 Deterministic Networking (DetNet) provides a capability to carry 94 specified unicast or multicast data flows for real-time applications 95 with extremely low packet loss rates and assured maximum end-to-end 96 delivery latency. A description of the general background and 97 concepts of DetNet can be found in [I-D.ietf-detnet-architecture]. 99 This document describes the concepts needed by any DetNet data plane 100 specification and provides considerations for any corresponding 101 implementation. It covers the building blocks that provide the 102 DetNet service, the DetNet service sub-layer and the DetNet 103 forwarding sub-layer functions as described in the DetNet 104 Architecture. 106 The DetNet Architecture models the DetNet related data plane 107 functions decomposed into two sub-layers: a service sub-layer and a 108 forwarding sub-layer. The service sub-layer is used to provide 109 DetNet service protection and reordering. The forwarding sub-layer 110 is used to provide congestion protection (low loss, assured latency, 111 and limited out-of-order delivery) and leverages Traffic Engineering 112 mechanisms. 114 As part of the service sub-layer functions, this document describes 115 typical DetNet node data plane operation. It describes the function 116 and operation of the Packet Replication (PRF) Packet Elimination 117 (PEF) and the Packet Ordering (POF) functions within the service sub- 118 layer. It also describes the forwarding sub-layer that is used to 119 eliminate (or reduce) contention loss and provide bounded latency for 120 DetNet flows. 122 DetNet flows may be carried over network technologies that can 123 provide the DetNet required service characteristics. For example, 124 DetNet MPLS flows can be carried over IEEE 802.1 Time Sensitive 125 Network (TSN) [IEEE802.1TSNTG] sub-networks. However, IEEE 802.1 TSN 126 support is not required and some of the DetNet benefits can be gained 127 by running over a data link layer that has not been specifically 128 enhanced to support TSN. 130 Different traffic types, or application flows, can be mapped on top 131 of DetNet. DetNet can optionally reuse header information provided 132 by, or shared with, applications. An example of shared header fields 133 can be found in [I-D.ietf-detnet-ip]. 135 This document also covers concepts related to the controller plane 136 and Operations, Administration, and Maintenance (OAM) functions 137 related to the control plane. Data plane OAM specifics are out of 138 scope for this docuement. 140 2. Terminology 142 2.1. Terms Used in This Document 144 This document uses the terminology established in the DetNet 145 architecture [I-D.ietf-detnet-architecture], and the reader is 146 assumed to be familiar with that document and its terminology. 148 2.2. Abbreviations 150 The following abbreviations are used in this document: 152 CW Control Word. 154 DetNet Deterministic Networking. 156 GRE Generic Routing Encapsulation. 158 IPSec IP Security. 160 L2 Layer 2. 162 LSR Label Switching Router. 164 MPLS Multiprotocol Label Switching. 166 MPLS-TE Multiprotocol Label Switching - Traffic Engineering. 168 OAM Operations, Administration, and Maintenance. 170 PEF Packet Elimination Function. 172 PRF Packet Replication Function. 174 PREOF Packet Replication, Elimination and Ordering Functions. 176 POF Packet Ordering Function. 178 PSN Packet Switched Network. 180 PW PseudoWire. 182 QoS Quality of Service. 184 TSN Time-Sensitive Network. 186 3. DetNet Data Plane Overview 188 This document describes how application flows, or app-flows, are 189 carried over DetNet networks. The DetNet Architecture, 190 [I-D.ietf-detnet-architecture], models the DetNet related data plane 191 functions decomposed into two sub-layers: a service sub-layer and a 192 forwarding sub-layer. 194 Figure 1 reproduced from the [I-D.ietf-detnet-architecture],shows a 195 logical DetNet service with the two sub-layers. 197 | packets going | ^ packets coming ^ 198 v down the stack v | up the stack | 199 +-----------------------+ +-----------------------+ 200 | Source | | Destination | 201 +-----------------------+ +-----------------------+ 202 | Service sub-layer: | | Service sub-layer: | 203 | Packet sequencing | | Duplicate elimination | 204 | Flow replication | | Flow merging | 205 | Packet encoding | | Packet decoding | 206 +-----------------------+ +-----------------------+ 207 | Forwarding sub-layer: | | Forwarding sub-layer: | 208 | Resource allocation | | Resource allocation | 209 | Explicit routes | | Explicit routes | 210 +-----------------------+ +-----------------------+ 211 | Lower layers | | Lower layers | 212 +-----------------------+ +-----------------------+ 213 v ^ 214 \_________________________/ 216 Figure 1: DetNet data plane protocol stack 218 The DetNet forwarding sub-layer may be directly provided by the 219 DetNet service sub-layer, for example by IP tunnels or MPLS. 220 Alternatively, an overlay approach may be used in which the packet is 221 natively carried between key nodes within the DetNet network (say 222 between PREOF nodes) and a sub-layer is used to provide the 223 information needed to reach the next hop in the overlay. 225 The forwarding sub-layer provides the quality underpin needed by the 226 DetNet flow. It may do this directly through the use of queuing 227 techniques and traffic engineering methods, or it may do this through 228 the assistance of its underlying connectivity. For example it may 229 call upon Ethernet TSN capabilities defined in IEEE 802.1 TSN 230 [IEEE802.1TSNTG]. 232 The service sub-layer provides additional support beyond the 233 connectivity function of the forwarding sub-layer. An example of 234 this is Packet Replication, Elimination, and Ordering (PREOF) 235 functions see Section 4.3. 237 The method of instantiating each of the layers is specific to the 238 particular DetNet data plane method. There may be more than one 239 approach that is applicable to a given bearer network type. 241 3.1. Data Plane Characteristics 243 There are two major characteristics to the data plane: 245 1. Data plane technology: The DetNet data plane is provided by the 246 DetNet service and forwarding sub layers. The DetNet service 247 sub-layer generally provides its functions for the DetNet 248 application flows by using or applying existing standardized 249 headers and/or encapsulations. The Detnet forwarding sub-layer 250 may provide capabilities leveraging that same header or 251 encapsulation technology e.g. Figure 2 or it may be achieved by 252 other technologies e.g. Figure 3. DetNet is currently defined 253 for operation over packet switched (IP) networks or label 254 switched (MPLS) networks. 256 2. Encapsulation format: DetNet encodes specific flow attributes 257 (namely flow identity and sequence number) in packets. For 258 example, in DetNet IP, zero encapsulation may be used and no 259 sequence number is available, and in DetNet MPLS, DetNet specific 260 information may be added explicitly to the packets in the format 261 of S-label and d-CW. 263 +-------+ +---------+ 264 | DN IP | | DN MPLS | 265 +-------+ +---------+ 267 Figure 2: DetNet Services 268 +-----+ 269 | TSN | 270 +-------+ +-+-----+-+ 271 | DN IP | | DN MPLS | 272 +--+--+----+----+ +-+---+-----+-+ 273 | TSN | DN MPLS | | TSN | DN IP | 274 +-----+---------+ +-----+-------+ 276 Figure 3: DetNet Service Examples 278 3.2. Encapsulation 280 The encapsulation of the DetNet flows allows them to be sent over a 281 data plane technology other than their native type. Encapsulation is 282 essential if, for example, it is required to send Ethernet TSN stream 283 as a DetNet Application over a data plane such as MPLS. Figure 3 284 illustrates some relationships between the components. 286 The use of encapsulation is also required if additional information 287 (meta-data) is needed by the DetNet data plane and there is either no 288 ability to include it in the client data packet, or the specification 289 of the client data plane does not permit the modification of the 290 packet to include additional data. An example of such meta-data is 291 the inclusion of a sequence number required by the PREOF function. 293 Encapsulation may also be used to carry or aggregate flows for 294 equipment with limited DetNet capability. 296 3.3. DetNet Specific Metadata 298 The DetNet data plane can provide or carry meta-data: 300 1. Flow-ID 302 2. Sequence Number 304 Both of these metadata are required for DetNet service sub-layer 305 specific functions (e.g., PREOF). DetNet forwarding sub-layer 306 related functions require only Flow-ID. 308 Metadata can be a useful way of identifying packets that need to be 309 treated as a flow or flow aggregate. It is also useful as a way of 310 including a sequence number the packet for use by the PREOF function 311 or as a place to carry OAM indications or OAM information to 312 instrument DetNet data plane operation. 314 Explicit inclusion of metadata is possible through the use of IP 315 options or IP extension headers. New IP options are almost 316 impossible to get standardized or to deploy in an operational network 317 and will not be discussed further in this text. IPv6 extensions 318 headers are finding popularity in current IPv6 development work, 319 particularly in connection with Segment Routing of IPv6 (SRv6) and IP 320 OAM. The design of a new IPv6 extension header or the modification 321 of an existing one is a technique available in the tool box of the 322 DetNet IP data plane designer. 324 Explicit inclusion of metadata in an IP packet is also possible 325 through the inclusion of an MPLS label stack and the MPLS DetNet 326 Control Word using one of the methods for carrying MPLS over IP 327 [I-D.ietf-detnet-mpls-over-udp-ip]. This is described in more detail 328 in Section 3.6.4. 330 Implicit metadata in IP can be included through the use of the 331 network programming paradigm 332 [I-D.ietf-spring-srv6-network-programming] in which the suffix of an 333 IPv6 address is used to encode additional information for use by the 334 network of the receiving host. 336 Some MPLS examples of implicit metadata include the sequence number 337 for use by the PREOF function, or even all the essential information 338 being included into the DetNet over MPLS label stack (the DetNet 339 Control Word and the DetNet Service label). 341 3.4. DetNet IP Data Plane 343 An IP data plane may operate natively or through the use of an 344 encapsulation. Many types of IP encapsulation can satisfy DetNet 345 requirements and it is anticipated that more than one encapsulation 346 may be deployed for example GRE, IPSec etc. 348 One method of operating an IP DetNet data plane without encapsulation 349 is to use "6-tuple" based flow identification, where "6-tuple" refers 350 to information carried in IP and higher layer protocol headers. 351 General background on the use of IP headers, and "6-tuples", to 352 identify flows and support Quality of Service (QoS) can be found in 353 [RFC3670]. [RFC7657] also provides useful background on the delivery 354 differentiated services (DiffServ) and "tuple" based flow 355 identification. DetNet flow aggregation may be enabled via the use 356 of wildcards, masks, prefixes and ranges. The operation of this 357 method is described in detail in [I-D.ietf-detnet-ip]. 359 The DetNet forwarding plane may use explicit route capabilities and 360 traffic engineering capabilities to provide a forwarding sub-layer 361 that is responsible for providing resource allocation and explicit 362 routes. It is possible to include such information in a native IP 363 packet explicitly, or implicitly. 365 3.5. DetNet MPLS Data Plane 367 MPLS provides the ability to forward traffic over implicit and 368 explicit paths to the point in the network where the next DetNet 369 service sub-layer action needs to take place. It does this through 370 the use of a stack of one or more labels with various forwarding 371 semantics. 373 MPLS also provides the ability to identify a service instance that is 374 used to process the packet through the use of a label that maps the 375 packet to a service instance. 377 In cases where metadata is needed to process an MPLS encapsulated 378 packet at the service sub-layer, a shim layer also called a control 379 word (CW) [RFC4385] can be used. Although such CWs are frequently 32 380 bits long, there is no architectural constraint on its size of this 381 structure, only the requirement that it is fully understood by all 382 parties operating on it in the DetNet service sub-layer. The 383 operation of this method is described in detail in 384 [I-D.ietf-detnet-mpls]. 386 3.6. Further DetNet Data Plane Considerations 388 This section provides informative considerations related to providing 389 DetNet service to flows which are identified based on their header 390 information. At a high level, the following are provided on a per 391 flow basis: 393 Reservation and Allocation of resources: 395 Reservation of resources can allocate resources to specific DetNet 396 flows. This can eliminate packet contention and loss for DetNet 397 traffic. This also can reduce jitter for the DetNet traffic. 398 DetNet flows are assumed to behave with respect to the reserved 399 traffic profile. If other traffic shares the link resources, the 400 use of (queuing, policing, shaping) policies can be used to ensure 401 that the allocation of resources reserved for DetNet is met. 402 Queuing and shaping of DetNet traffic could be required to ensure 403 that DetNet traffic does not exceed its reserved profile but this 404 would impact the DetNet service characteristics. 406 Explicit routes: 408 Use of a specific path for a flow. This allows control of the 409 network delay by steering the packet with the ability to influence 410 the physical path. Explicit routes complement reservation by 411 ensuring that a consistent path can be associated with its 412 resources for the duration of that path. Coupled with the traffic 413 mechanism, this limits misordering and bounds latency. Explicit 414 route computation can encompass a wide set of constraints and 415 optimize the path for a certain characteristic e.g. highest 416 bandwidth or lowest jitter. In these cases the "best" path for 417 any set of characteristics may not be a shortest path. The 418 selection of path can take into account multiple network metrics. 419 Some of these metrics are measured and distributed by the routing 420 system as traffic engineering metrics. 422 Service protection: 424 Use of multiple packet streams using multiple paths, for example 425 1+1 or 1:1 linear protection. For DetNet this primarily relates 426 to packet replication and elimination capabilities. MPLS offers a 427 number of protection schemes. MPLS hitless protection can be used 428 to switch traffic to an already established path in order to 429 restore delivery rapidly after a failure. Path changes, even in 430 the case of failure recovery, can lead to the out of order 431 delivery of data requiring packet ordering functions either within 432 the DetNet service or at a high layer in the application traffic. 433 Establishment of new paths after a failure is out of scope for 434 DetNet services. 436 Network Coding: 438 Network Coding, not to be confused with network programming, 439 comprises several techniques where multiple data flows are 440 encoded. These resulting flows can then be sent on different 441 paths. The encoding operation can combine flows and error 442 recovery information. When the encoded flows are decoded and 443 recombined the original flows can be recovered. Note that Network 444 coding uses an alternative to packet by packet PREOF. Therefore, 445 for certain network topologies and traffic loads, Network Coding 446 can be used to improve a network's throughput, efficiency, 447 latency, and scalability, as well as resilience to partition, 448 attacks, and eavesdropping, as compared to traditional methods. 449 DetNet could utilized Network coding as an alternative to other 450 protection means. Network coding is often applied in wireless 451 networks and is being explored for other network types. 453 Load sharing: 455 Use of packet by packet distribution of the same DetNet flow over 456 multiple paths is not recommended except for the cases listed 457 above where PREOF is utilized to improve protection of traffic and 458 maintain order. Packet by packet load sharing, e.g., via ECMP or 459 UCMP, impacts ordering and possibly jitter. 461 Troubleshooting: 463 Since Detnet leverages many different forwarding sub-layers, those 464 technologies also support a number of tools to troubleshoot 465 connectivity for example, to support identification of misbehaving 466 flows. At the service layer again there are existing mechanisms 467 to troubleshoot or monitor flows. Many of these mechanisms exist 468 for IP and MPLS networks. A client of a DetNet service can 469 introduce any monitoring applications which can detect and monitor 470 delay and loss. 472 Recognize flow(s) for analytics: 474 To a large degree this follows the logic in the previous section. 475 Analytics can be inherited from the two sub-layers. At the DetNet 476 service edge packet and bit counters e.g. sent, received, dropped, 477 and out of sequence are maintained. 479 Correlate events with flows: 481 The provider of a DetNet service may allow other capabilities to 482 monitor flows such as more detail loss statistics and time 483 stamping of events. The details of these capabilities are 484 currently out of scope for this document. 486 Several of these capabilities are expanded upon in more detail below. 488 3.6.1. Service Protection 490 Service protection allow DetNet services to increase reliability and 491 maintain a DetNet Service Assurance in the case of network congestion 492 or some failures. Detnet relies on the underlying technology 493 capabilities for various protection schemes. Protection schemes 494 enable partial or complete coverage of the network paths and active 495 protection with combinations of PRF, PRE, and POF. 497 3.6.1.1. Linear Service Protection 499 An example DetNet MPLS network fragment and packet flow is 500 illustrated in Figure 4. 502 1 1.1 1.1 1.2.1 1.2.1 1.2.2 503 CE1----EN1--------R1-------R2-------R3--------EN2-----CE2 504 \ 1.2.1 / / 505 \1.2 /-----+ / 506 +------R4------------------------+ 507 1.2.2 509 Figure 4: Example Packet Flow in DetNet protected Network 511 In Figure 4 the numbers are used to identify the instance of a 512 packet. Packet 1 is the original packet, and packets 1.1, and 1.2 513 are two first generation copies of packet 1. Packet 1.2.1 is a 514 second generation copy of packet 1.2 etc. Note that these numbers 515 never appear in the packet, and are not to be confused with sequence 516 numbers, labels or any other identifier that appears in the packet. 517 They simply indicate the generation number of the original packet so 518 that its passage through the network fragment can be identified to 519 the reader. 521 Customer Equipment CE1 sends a packet into the DetNet enabled 522 network. This is packet (1). Edge Node EN1 encapsulates the packet 523 as a DetNet Packet and sends it to Relay node R1 (packet 1.1). EN1 524 makes a copy of the packet (1.2), encapsulates it and sends this copy 525 to Relay node R4. 527 Note that along the path from EN1 to R1 there may be zero or more 528 nodes which, for clarity, are not shown. The same is true for any 529 other path between two DetNet entities shown in Figure 4 . 531 Relay node R4 has been configured to send one copy of the packet to 532 Relay Node R2 (packet 1.2.1) and one copy to Edge Node EN2 (packet 533 1.2.2). 535 R2 receives packet copy 1.2.1 before packet copy 1.1 arrives, and, 536 having been configured to perform packet elimination on this DetNet 537 flow, forwards packet 1.2.1 to Relay Node R3. Packet copy 1.1 is of 538 no further use and so is discarded by R2. 540 Edge Node EN2 receives packet copy 1.2.2 from R4 before it receives 541 packet copy 1.2.1 from R2 via relay Node R3. EN2 therefore strips 542 any DetNet encapsulation from packet copy 1.2.2 and forwards the 543 packet to CE2. When EN2 receives the later packet copy 1.2.1 this is 544 discarded. 546 The above is of course illustrative of many network scenarios that 547 can be configured. 549 This example also illustrates 1:1 protection scheme meaning there is 550 traffic and path for each segment of the end to end path. Local 551 DetNet relay nodes determine which packets are eliminated and which 552 packets are forwarded. A 1+1 scheme where only one path is used for 553 traffic at a time, could use the same topology. In this case there 554 is no PRF function and traffic is switched upon detection of failure. 555 An OAM scheme that monitors the paths detects the loss of path or 556 traffic is required to initiate the switch. A POF may still be used 557 in this case to prevent misordering of packets. In both cases the 558 protection paths are established and maintained for the duration of 559 the DetNet service. 561 3.6.1.2. Ring Service Protection 563 Ring protection may also be supported if the underlying technology 564 supports it. Many of the same concepts apply however Rings are 565 normally 1+1 protection for data efficiency reasons. [RFC8227] is an 566 example of MPLS-TP data plane that supports Ring protection. 568 3.6.2. Aggregation Considerations 570 The DetNet data plane also allows for the aggregation of DetNet 571 flows, to improved scaling by reducing the state per hop. How this 572 is accomplished is data plane or control plane dependent. When 573 DetNet flows are aggregated, transit nodes provide service to the 574 aggregate and not on a per-DetNet flow basis. When aggregating 575 DetNet flows the flows should be compatible i.e. the same or very 576 similar QoS and CoS characteristics. In this case, nodes performing 577 aggregation will ensure that per-flow service requirements are 578 achieved. 580 If bandwidth reservations are used, the sum of the reservations 581 should be the sum of all the individual reservations, in other words, 582 the reservations should not create an over subscription of bandwidth 583 reservation. If maximum delay bounds are used the system should 584 ensure that the aggregate does not exceed the delay bounds of the 585 individual flows. 587 DetNet encapsulation is a data plane mechanism that can be used to 588 aggregate traffic. Encapsulation can either be in the same service 589 type or in a different service type see Figure 3 for example. When 590 an encapsulation is used the choice of reserving a maximum resource 591 level and then tracking the services in the aggregated service or 592 adjusting the aggregated resources as the services are added is 593 implementation and technology specific. 595 DetNet flows at edges must be able to handle rejection to an 596 aggregation group due to lack of resources as well as conditions 597 where general requirements are not satisfied. 599 3.6.2.1. IP Aggregation 601 IP aggregation has both data plane and controller plane aspects. For 602 the data plane flows may be aggregated for treatment based on shared 603 characteristics such as 6-tuple. Alternatively, an IP encapsulation 604 may be used to tunnel an aggregate number of DetNet Flows between 605 relay nodes. 607 3.6.2.2. MPLS Aggregation 609 MPLS aggregation similarly has data plane and controller plane 610 aspects. In the case of MPLS flows are often tunneled in a 611 forwarding sub-layer and reservation is associated with that MPLS 612 tunnel. 614 3.6.3. End-System Specific Considerations 616 Data-flows requiring DetNet service are generated and terminated on 617 end-systems. Encapsulation depends on the application and its 618 preferences. For example, a DetNet MPLS domain the DN functions use 619 the d-CWs, S-Labels and F-Labels to provide DetNet services. 620 However, an application may exchange further flow related parameters 621 (e.g., time-stamp), which are not provided by DN functions. 623 As a general rule, DetNet domains are capable of forwarding any 624 DetNet flows and the DetNet domain does not mandate the end-system or 625 edge system encapsulation format. Unless there is a proxy of some 626 form present, end-systems peer with similar end-systems using the 627 same application encapsulation format. For example, as shown in 628 Figure 5, IP applications peer with IP applications and Ethernet 629 applications peer with Ethernet applications. 631 +-----+ 632 | X | +-----+ 633 +-----+ | X | 634 | Eth | ________ +-----+ 635 +-----+ _____ / \ | Eth | 636 \ / \__/ \___ +-----+ 637 \ / \ / 638 0======== tunnel-1 ========0_ 639 | \ 640 \ | 641 0========= tunnel-2 =========0 642 / \ __/ \ 643 +-----+ \__ DetNet MPLS domain / \ 644 | X | \ __ / +-----+ 645 +-----+ \_______/ \_____/ | X | 646 | IP | +-----+ 647 +-----+ | IP | 648 +-----+ 650 Figure 5: End-Systems and The DetNet MPLS Domain 652 3.6.4. Sub-Network Considerations 654 Any of the DetNet service types may be transported by another DetNet 655 service. MPLS nodes may interconnected by different sub-network 656 technologies, which may include point-to-point links. Each of these 657 sub-network technologies need to provide appropriate service to 658 DetNet flows. In some cases, e.g., on dedicated point-to-point links 659 or TDM technologies, all that is required is for a DetNet node to 660 appropriately queue its output traffic. In other cases, DetNet nodes 661 will need to map DetNet flows to the flow semantics (i.e., 662 identifiers) and mechanisms used by an underlying sub-network 663 technology. Figure 6 shows several examples of header formats that 664 can be used to carry DetNet MPLS flows over different sub-network 665 technologies. L2 represent a generic layer-2 encapsulation that 666 might be used on a point-to-point link. TSN represents the 667 encapsulation used on an IEEE 802.1 TSN network, as described in 668 [I-D.ietf-detnet-mpls-over-tsn]. UDP/IP represents the encapsulation 669 used on a DetNet IP PSN, as described in 670 [I-D.ietf-detnet-mpls-over-udp-ip]. 672 +------+ +------+ +------+ 673 App-Flow | X | | X | | X | 674 +-----+======+--+======+--+======+-----+ 675 DetNet-MPLS | d-CW | | d-CW | | d-CW | 676 +------+ +------+ +------+ 677 |Labels| |Labels| |Labels| 678 +-----+======+--+======+--+======+-----+ 679 Sub-Network | L2 | | TSN | | UDP | 680 +------+ +------+ +------+ 681 | IP | 682 +------+ 683 | L2 | 684 +------+ 686 Figure 6: Example DetNet MPLS Sub-Network Formats 688 4. Controller Plane (Management and Control) Considerations 690 4.1. DetNet Controller Plane Requirements 692 While the definition of controller plane for DetNet is out of the 693 scope of this document, there are particular considerations and 694 requirements for such that result from the unique characteristics of 695 the DetNet architecture [I-D.ietf-detnet-architecture] and data plane 696 as defined herein. 698 The primary requirements of the DetNet controller plane are that it 699 must be able to: 701 o Instantiate DetNet flows in a DetNet domain (which may include 702 some or all of explicit path determination, link bandwidth 703 reservations, restricting flows to IEEE 802.1 TSN links, node 704 buffer and other resource reservations, specification of required 705 queuing disciplines along the path, ability to manage 706 bidirectional flows, etc.) as needed for a flow. 708 o In the case of MPLS, manage DetNet S-Label and F-Label allocation 709 and distribution, where the DetNet MPLS encapsulation is in use 710 see [I-D.ietf-detnet-mpls]. 712 o Support DetNet flow aggregation. 714 o Advertise static and dynamic node and link resources such as 715 capabilities and adjacencies to other network nodes (for dynamic 716 signaling approaches) or to network controllers (for centralized 717 approaches). 719 o Scale to handle the number of DetNet flows expected in a domain 720 (which may require per-flow signaling or provisioning). 722 o Provision flow identification information at each of the nodes 723 along the path. Flow identification may differ depending on the 724 location in the network and the DetNet functionality (e.g. transit 725 node vs. relay node). 727 These requirements, as stated earlier, could be satisfied using 728 distributed control protocol signaling (such as RSVP-TE), centralized 729 network management provisioning mechanisms (such as BGP, PCEP, YANG 730 [I-D.ietf-detnet-flow-information-model], etc.) or hybrid 731 combinations of the two, and could also make use of MPLS-based 732 segment routing. 734 In the abstract, the results of either distributed signaling or 735 centralized provisioning are equivalent from a DetNet data plane 736 perspective - flows are instantiated, explicit routes are determined, 737 resources are reserved, and packets are forwarded through the domain 738 using the DetNet data plane. 740 However, from a practical and implementation standpoint, they are not 741 equivalent at all. Some approaches are more scalable than others in 742 terms of signaling load on the network. Some can take advantage of 743 global tracking of resources in the DetNet domain for better overall 744 network resource optimization. Some are more resilient than others 745 if link, node, or management equipment failures occur. While a 746 detailed analysis of the control plane alternatives is out of the 747 scope of this document, the requirements from this document can be 748 used as the basis of a later analysis of the alternatives. 750 4.2. Generic Controller Plane Considerations 752 This section covers control plane considerations that are independent 753 of the data plane technology used for DetNet service delivery. 755 While management plane and control planes are traditionally 756 considered separately, from the Data Plane perspective there is no 757 practical difference based on the origin of flow provisioning 758 information, and the DetNet architecture 759 [I-D.ietf-detnet-architecture] refers to these collectively as the 760 'Controller Plane'. This document therefore does not distinguish 761 between information provided by distributed control plane protocols, 762 e.g., RSVP-TE [RFC3209] and [RFC3473], or by centralized network 763 management mechanisms, e.g., RestConf [RFC8040], YANG [RFC7950], and 764 the Path Computation Element Communication Protocol (PCEP) 765 [I-D.ietf-pce-pcep-extension-for-pce-controller] or any combination 766 thereof. Specific considerations and requirements for the DetNet 767 Controller Plane are discussed in Section 4.1. 769 Each respective data plane document also covers the control plane 770 considerations for that technology. For example [I-D.ietf-detnet-ip] 771 covers IP control plane normative considerations and 772 [I-D.ietf-detnet-mpls] covers MPLS control plane normative 773 considerations. 775 4.2.1. Flow Aggregation Control 777 Flow aggregation includes aggregation accomplished through the use of 778 hierarchical LSPs in MPLS and tunnels, in the case of IP, MPLS and 779 TSN, all of which aggregate multiple DetNet flows into a single new 780 DetNet flow. Aggregation can also be grouping of IP flows that share 781 6-tuple attributes or flow identifiers at the DetNet sub-layer. 783 Control of aggregation involves a set of procedures listed here. 784 Aggregation may use some or all of these capabilities and the order 785 may vary: 787 o Traffic engineering resource collection and distribution: 789 Available resources are tracked through control plane or 790 management plane databases and distributed amongst controllers 791 or nodes that can manage resources. 793 o Path computation and resource allocation: 795 When DetNet services are provisioned or requested one or more 796 paths meeting the requirements are selected and the resources 797 verified and recorded. 799 o Resource assignment and data plane co-ordination: 801 The assignment of resources along the path depends on the 802 technology and it includes assignment of specific links and 803 coordination of the queuing and other traffic management 804 capabilities such as policing and shaping. 806 o Assigned Resource recording and updating: 808 Depending on the specific technology the assigned resources are 809 updated and distributed in the databases preventing over 810 subscription. 812 4.2.2. Explicit Routes 814 Explicit routes are used to ensure that packets are routed through 815 the resources that have been reserved for them, and hence provide the 816 DetNet application with the required service. A requirement for the 817 DetNet Controller Plane will be the ability to assign a particular 818 identified DetNet IP flow to a path through the DetNet domain that 819 has been assigned the required nodal resources. This provides the 820 appropriate traffic treatment for the flow and also includes 821 particular links as a part of the path that are able to support the 822 DetNet flow. For example, by using IEEE 802.1 TSN links (as 823 discussed in [I-D.ietf-detnet-mpls-over-tsn] ) DetNet parameters can 824 be maintained. Further considerations and requirements for the 825 DetNet Controller Plane are discussed in Section 4.1. 827 Whether configuring, calculating and instantiating these routes is a 828 single-stage or multi-stage process, or in a centralized or 829 distributed manner, is out of scope of this document. 831 There are several approaches that could be used to provide explicit 832 routes and resource allocation in the DetNet forwarding sub-layer. 833 For example: 835 o The path could be explicitly set up by a controller which 836 calculates the path and explicitly configures each node along that 837 path with the appropriate forwarding and resource allocation 838 information. 840 o The path could use a distributed control plane such as RSVP 841 [RFC2205] or RSVP-TE [RFC3473] extended to support DetNet IP 842 flows. 844 o The path could be implemented using IPv6-based segment routing 845 when extended to support resource allocation. 847 See Section 4.1 for further discussion of these alternatives. In 848 addition, [RFC2386] contains useful background information on QoS- 849 based routing, and [RFC5575] discusses a specific mechanism used by 850 BGP for traffic flow specification and policy-based routing. 852 4.2.3. Contention Loss and Jitter Reduction 854 As discussed in Section 1, this document does not specify the 855 mechanisms needed to eliminate packet contention, packet loss or 856 reduce jitter for DetNet flows at the DetNet forwarding sub-layer. 857 The ability to manage node and link resources to be able to provide 858 these functions is a necessary part of the DetNet controller plane. 859 It is also necessary to be able to control the required queuing 860 mechanisms used to provide these functions along a flow's path 861 through the network. See [I-D.ietf-detnet-ip] and Section 4.1 for 862 further discussion of these requirements. 864 4.2.4. Bidirectional Traffic 866 DetNet applications typically generate bidirectional traffic. IP and 867 MPLS typically treat each direction separately and do not force 868 interdependence of each direction. MPLS has considered bidirectional 869 traffic requirements and the MPLS definitions from [RFC5654] are 870 useful to illustrate terms such as associated bidirectional flows and 871 co-routed bidirectional flows. MPLS defines a point-to-point 872 associated bidirectional LSP as consisting of two unidirectional 873 point-to-point LSPs, one from A to B and the other from B to A, which 874 are regarded as providing a single logical bidirectional forwarding 875 path. This is analogous to standard IP routing. MPLS defines a 876 point-to-point co-routed bidirectional LSP as an associated 877 bidirectional LSP which satisfies the additional constraint that its 878 two unidirectional component LSPs follow the same path (in terms of 879 both nodes and links) in both directions. An important property of 880 co-routed bidirectional LSPs is that their unidirectional component 881 LSPs share fate. In both types of bidirectional LSPs, resource 882 reservations may differ in each direction. The concepts of 883 associated bidirectional flows and co-routed bidirectional flows can 884 also be applied to DetNet IP flows. 886 While the DetNet IP data plane must support bidirectional DetNet 887 flows, there are no special bidirectional features with respect to 888 the data plane other than the need for the two directions of a co- 889 routed bidirectional flow to take the same path. That is to say that 890 bidirectional DetNet flows are solely represented at the management 891 and control plane levels, without specific support or knowledge 892 within the DetNet data plane. Fate sharing and associated or co- 893 routed bidirectional flows, can be managed at the control level. 895 DetNet's use of PREOF may increase the complexity of using co-routing 896 bidirectional flows, since if PREOF is used, then the replication 897 points in one direction would have to match the elimination points in 898 the other direction, and vice versa, and the optimal points for these 899 functions in one direction may not match the optimal points in the 900 other subsequent to the network and traffic constraints. 901 Furthermore, due to the per packet service protection nature, 902 bidirectional forwarding per packet may not be ensured. The first 903 packet of received member flows is selected by the elimination 904 function independently of which path it has taken through the 905 network. 907 Control and management mechanisms need to support bidirectional 908 flows, but the specification of such mechanisms are out of scope of 909 this document. An example control plane solution for MPLS can be 910 found in [RFC3473] , [RFC6387] and [RFC7551]. These requirements are 911 included in Section 4.1. 913 4.3. Packet Replication, Elimination, and Ordering (PREOF) 915 The controller plane protocol solution required for managing the 916 PREOF processing is outside the scope of this document. That said, 917 it should be noted that the ability to determine, for a particular 918 flow, optimal packet replication and elimination points in the DetNet 919 domain requires explicit support. There may be capabilities that can 920 be used, or extended, for example GMPLS end-to-end recovery [RFC4872] 921 and GMPLS segment recovery [RFC4873]. 923 5. Security Considerations 925 Security considerations for DetNet are described in detail in 926 [I-D.ietf-detnet-security]. General security considerations are 927 described in [I-D.ietf-detnet-architecture]. This section considers 928 general security considerations applicable to all data planes. 930 Security aspects which are unique to DetNet are those whose aim is to 931 provide the specific quality of service aspects of DetNet, which are 932 primarily to deliver data flows with extremely low packet loss rates 933 and bounded end-to-end delivery latency. 935 The primary considerations for the data plane is to maintain 936 integrity of data and delivery of the associated DetNet service 937 traversing the DetNet network. Application flows can be protected 938 through whatever means is provided by the underlying technology. For 939 example, encryption may be used, such as that provided by IPSec 940 [RFC4301] for IP flows and/or by an underlying sub-net using MACSec 941 [IEEE802.1AE-2018] for Ethernet (Layer-2) flows. 943 From a data plane perspective DetNet does not add or modify any 944 header information. 946 At the management and control level DetNet flows are identified on a 947 per-flow basis, which may provide controller plane attackers with 948 additional information about the data flows (when compared to 949 controller planes that do not include per-flow identification). This 950 is an inherent property of DetNet which has security implications 951 that should be considered when determining if DetNet is a suitable 952 technology for any given use case. 954 To provide uninterrupted availability of the DetNet service, 955 provisions can be made against DOS attacks and delay attacks. To 956 protect against DOS attacks, excess traffic due to malicious or 957 malfunctioning devices can be prevented or mitigated, for example 958 through the use of existing mechanism such as policing and shaping 959 applied at the input of a DetNet domain. To prevent DetNet packets 960 from being delayed by an entity external to a DetNet domain, DetNet 961 technology definition can allow for the mitigation of Man-In-The- 962 Middle attacks, for example through use of authentication and 963 authorization of devices within the DetNet domain. 965 6. IANA Considerations 967 This document makes no IANA requests. 969 7. Acknowledgements 971 The authors wish to thank Pat Thaler, Norman Finn, Loa Anderson, 972 David Black, Rodney Cummings, Ethan Grossman, Tal Mizrahi, David 973 Mozes, Craig Gunther, George Swallow, Yuanlong Jiang and Carlos J. 974 Bernardos for their various contributions to this work. 976 8. References 978 8.1. Normative References 980 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 981 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 982 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 983 . 985 [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label 986 Switching (GMPLS) Signaling Resource ReserVation Protocol- 987 Traffic Engineering (RSVP-TE) Extensions", RFC 3473, 988 DOI 10.17487/RFC3473, January 2003, 989 . 991 [RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, 992 "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for 993 Use over an MPLS PSN", RFC 4385, DOI 10.17487/RFC4385, 994 February 2006, . 996 8.2. Informative References 998 [I-D.ietf-detnet-architecture] 999 Finn, N., Thubert, P., Varga, B., and J. Farkas, 1000 "Deterministic Networking Architecture", draft-ietf- 1001 detnet-architecture-13 (work in progress), May 2019. 1003 [I-D.ietf-detnet-flow-information-model] 1004 Farkas, J., Varga, B., Cummings, R., Jiang, Y., and D. 1005 Fedyk, "DetNet Flow Information Model", draft-ietf-detnet- 1006 flow-information-model-05 (work in progress), September 1007 2019. 1009 [I-D.ietf-detnet-ip] 1010 Varga, B., Farkas, J., Berger, L., Fedyk, D., Malis, A., 1011 Bryant, S., and J. Korhonen, "DetNet Data Plane: IP", 1012 draft-ietf-detnet-ip-01 (work in progress), July 2019. 1014 [I-D.ietf-detnet-mpls] 1015 Varga, B., Farkas, J., Berger, L., Fedyk, D., Malis, A., 1016 Bryant, S., and J. Korhonen, "DetNet Data Plane: MPLS", 1017 draft-ietf-detnet-mpls-01 (work in progress), July 2019. 1019 [I-D.ietf-detnet-mpls-over-tsn] 1020 Varga, B., Farkas, J., Malis, A., Bryant, S., and J. 1021 Korhonen, "DetNet Data Plane: MPLS over IEEE 802.1 Time 1022 Sensitive Networking (TSN)", draft-ietf-detnet-mpls-over- 1023 tsn-00 (work in progress), May 2019. 1025 [I-D.ietf-detnet-mpls-over-udp-ip] 1026 Varga, B., Farkas, J., Berger, L., Malis, A., Bryant, S., 1027 and J. Korhonen, "DetNet Data Plane: MPLS over UDP/IP", 1028 draft-ietf-detnet-mpls-over-udp-ip-01 (work in progress), 1029 July 2019. 1031 [I-D.ietf-detnet-security] 1032 Mizrahi, T., Grossman, E., Hacker, A., Das, S., Dowdell, 1033 J., Austad, H., Stanton, K., and N. Finn, "Deterministic 1034 Networking (DetNet) Security Considerations", draft-ietf- 1035 detnet-security-05 (work in progress), August 2019. 1037 [I-D.ietf-pce-pcep-extension-for-pce-controller] 1038 Zhao, Q., Li, Z., Negi, M., and C. Zhou, "PCEP Procedures 1039 and Protocol Extensions for Using PCE as a Central 1040 Controller (PCECC) of LSPs", draft-ietf-pce-pcep- 1041 extension-for-pce-controller-02 (work in progress), July 1042 2019. 1044 [I-D.ietf-spring-srv6-network-programming] 1045 Filsfils, C., Camarillo, P., Leddy, J., 1046 daniel.voyer@bell.ca, d., Matsushima, S., and Z. Li, "SRv6 1047 Network Programming", draft-ietf-spring-srv6-network- 1048 programming-01 (work in progress), July 2019. 1050 [IEEE802.1AE-2018] 1051 IEEE Standards Association, "IEEE Std 802.1AE-2018 MAC 1052 Security (MACsec)", 2018, 1053 . 1055 [IEEE802.1TSNTG] 1056 IEEE Standards Association, "IEEE 802.1 Time-Sensitive 1057 Networking Task Group", . 1059 [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. 1060 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 1061 Functional Specification", RFC 2205, DOI 10.17487/RFC2205, 1062 September 1997, . 1064 [RFC2386] Crawley, E., Nair, R., Rajagopalan, B., and H. Sandick, "A 1065 Framework for QoS-based Routing in the Internet", 1066 RFC 2386, DOI 10.17487/RFC2386, August 1998, 1067 . 1069 [RFC3670] Moore, B., Durham, D., Strassner, J., Westerinen, A., and 1070 W. Weiss, "Information Model for Describing Network Device 1071 QoS Datapath Mechanisms", RFC 3670, DOI 10.17487/RFC3670, 1072 January 2004, . 1074 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1075 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 1076 December 2005, . 1078 [RFC4872] Lang, J., Ed., Rekhter, Y., Ed., and D. Papadimitriou, 1079 Ed., "RSVP-TE Extensions in Support of End-to-End 1080 Generalized Multi-Protocol Label Switching (GMPLS) 1081 Recovery", RFC 4872, DOI 10.17487/RFC4872, May 2007, 1082 . 1084 [RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel, 1085 "GMPLS Segment Recovery", RFC 4873, DOI 10.17487/RFC4873, 1086 May 2007, . 1088 [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., 1089 and D. McPherson, "Dissemination of Flow Specification 1090 Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009, 1091 . 1093 [RFC5654] Niven-Jenkins, B., Ed., Brungard, D., Ed., Betts, M., Ed., 1094 Sprecher, N., and S. Ueno, "Requirements of an MPLS 1095 Transport Profile", RFC 5654, DOI 10.17487/RFC5654, 1096 September 2009, . 1098 [RFC6387] Takacs, A., Berger, L., Caviglia, D., Fedyk, D., and J. 1099 Meuric, "GMPLS Asymmetric Bandwidth Bidirectional Label 1100 Switched Paths (LSPs)", RFC 6387, DOI 10.17487/RFC6387, 1101 September 2011, . 1103 [RFC7551] Zhang, F., Ed., Jing, R., and R. Gandhi, Ed., "RSVP-TE 1104 Extensions for Associated Bidirectional Label Switched 1105 Paths (LSPs)", RFC 7551, DOI 10.17487/RFC7551, May 2015, 1106 . 1108 [RFC7657] Black, D., Ed. and P. Jones, "Differentiated Services 1109 (Diffserv) and Real-Time Communication", RFC 7657, 1110 DOI 10.17487/RFC7657, November 2015, 1111 . 1113 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1114 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1115 . 1117 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1118 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 1119 . 1121 [RFC8227] Cheng, W., Wang, L., Li, H., van Helvoort, H., and J. 1122 Dong, "MPLS-TP Shared-Ring Protection (MSRP) Mechanism for 1123 Ring Topology", RFC 8227, DOI 10.17487/RFC8227, August 1124 2017, . 1126 Authors' Addresses 1128 Balazs Varga (editor) 1129 Ericsson 1130 Magyar Tudosok krt. 11. 1131 Budapest 1117 1132 Hungary 1134 Email: balazs.a.varga@ericsson.com 1136 Janos Farkas 1137 Ericsson 1138 Magyar Tudosok krt. 11. 1139 Budapest 1117 1140 Hungary 1142 Email: janos.farkas@ericsson.com 1143 Lou Berger 1144 LabN Consulting, L.L.C. 1146 Email: lberger@labn.net 1148 Don Fedyk 1149 LabN Consulting, L.L.C. 1151 Email: dfedyk@labn.net 1153 Andrew G. Malis 1154 Independent 1156 Email: agmalis@gmail.com 1158 Stewart Bryant 1159 Futurewei Technologies 1161 Email: stewart.bryant@gmail.com 1163 Jouni Korhonen 1165 Email: jouni.nospam@gmail.com