idnits 2.17.1 draft-geng-spring-srv6-for-detnet-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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 13, 2020) is 1382 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'Network' is mentioned on line 218, but not defined == Unused Reference: 'I-D.ietf-6man-segment-routing-header' is defined on line 498, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-detnet-dp-sol-mpls' is defined on line 504, but no explicit reference was found in the text == Unused Reference: 'RFC8402' is defined on line 520, but no explicit reference was found in the text == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-07 Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group X. Geng 3 Internet-Draft Z. Li 4 Intended status: Informational M. Chen 5 Expires: January 14, 2021 Huawei 6 July 13, 2020 8 SRv6 for Deterministic Networking (DetNet) 9 draft-geng-spring-srv6-for-detnet-01 11 Abstract 13 Deterministic Networking provides service with low jitter, bounded 14 latency and low loss rate, using technologies of explicit route, 15 resource reservation and service protection.This document specifies 16 how to implement Deterministic Networking (DetNet) in a SRv6 Network. 18 Requirements Language 20 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 21 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 22 document are to be interpreted as described in RFC 2119 [RFC2119]. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on January 14, 2021. 41 Copyright Notice 43 Copyright (c) 2020 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. SRv6 for DetNet Overview . . . . . . . . . . . . . . . . . . 4 61 4. Service Protection . . . . . . . . . . . . . . . . . . . . . 5 62 4.1. Service Protection Scenarios . . . . . . . . . . . . . . 5 63 4.2. Data Plane Considerations . . . . . . . . . . . . . . . . 7 64 4.3. Control Plane Considerations . . . . . . . . . . . . . . 7 65 5. Resource Reservation . . . . . . . . . . . . . . . . . . . . 8 66 5.1. Resource Reservation Scenarios . . . . . . . . . . . . . 8 67 5.2. Data Plane Considerations . . . . . . . . . . . . . . . . 10 68 5.3. Control Plane Considerations . . . . . . . . . . . . . . 10 69 6. Explicit Route . . . . . . . . . . . . . . . . . . . . . . . 11 70 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 71 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 72 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 73 10. Normative References . . . . . . . . . . . . . . . . . . . . 11 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 76 1. Introduction 78 With more and more applications running in the Internet, quality of 79 the service gains more and more attention, especially for some new 80 applications, for example Cloud VR, Cloud Game, HDV (high-definition 81 video) and so on, SLA (Service Level Agreement), including jitter, 82 delay and loss rate, influences the users' experience significantly. 83 So SLA guarantee is an important issue which requires new 84 technologies and solutions for the network. 86 Deterministic Networking (DetNet defined in [RFC8655]) provides a 87 capability to carry specified data flows for real-time applications 88 with extremely low data loss rates, low jitter and bounded latency 89 within a network domain. Techniques used include: 1) providing 90 explicit paths for DetNet flows that satisfies the SLA requirement 91 from user and do not immediately change with the network topology; 2) 92 reserving data plane resources for DetNet flows along the allocated 93 path of the flow; 3) replicates DetNet flows into two or more copies 94 and transport different copies through different path in parallel, 95 called service protection. 97 Segment Routing(SR) leverages the source routing paradigm. An 98 ingress node steers a packet through an ordered list of instructions, 99 called "segments". SR can be applied over IPv6 data plane using 100 Routing Extension Header(SRH, [RFC8754]). A segment in Segment 101 Routing is not limited to a routing/forwarding function. An SRv6 102 Segment can indicate functions that are executed locally in the node 103 where they are defined. 104 [I-D.filsfils-spring-srv6-network-programming] describes some well- 105 known functions and segments associated to them. SRH TLVs([RFC8754]) 106 also provides meta-data for segment processing. All these features 107 make SRv6 suitable to carry DetNet flows, by defining new segments 108 associated with DetNet functions and meta data for DetNet. 110 This document describes the concepts needed by implementing DetNet in 111 an SRv6-based domain and provides considerations for any 112 corresponding implementation. 114 Editor's note: DetNet is limited in a controlled network domain, and 115 it is not the only method to provide SLA guarantee. But it is a good 116 start to discuss how to use SRv6 to have a SLA-guaranteed network 117 service. 119 2. Terminology 121 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 122 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 123 document are to be interpreted as described in [RFC2119]. 125 Terminologies for DetNet go along with the definition in [RFC8655] 126 and [RFC8754]: 128 DetNet domain 130 The portion of a network that is DetNet aware. It includes end 131 systems and DetNet nodes 133 DetNet edge node 135 An instance of a DetNet relay node that acts as a source and/ or 136 destination at the DetNet service sub-layer. For example, it can 137 include a DetNet service sub-layer proxy function for DetNet 138 service protection (e.g., the addition or removal of packet 139 sequencing information) for one or more end systems, or starts or 140 terminates resource allocation at the DetNet forwarding sub-layer, 141 or aggregates DetNet services into new DetNet flows. It is 142 analogous to a Label Edge Router (LER) or a Provider Edge (PE) 143 router. 145 DetNet relay node 147 A DetNet node including a service sub-layer function that 148 interconnects different DetNet forwarding sub-layer paths to 149 provide service protection. A DetNet relay node participates in 150 the DetNet service sub-layer. It typically incorporates DetNet 151 forwarding sub-layer functions as well, in which case it is 152 collocated with a transit node. 154 DetNet transit node 156 A DetNet node operating at the DetNet forwarding sub-layer, that 157 utilizes link layer and/or network layer switching across multiple 158 links and/or sub-networks to provide paths for DetNet service sub- 159 layer functions. Typically provides resource allocation over 160 those paths. An MPLS LSR is an example of a DetNet transit node. 162 End system 164 End systems of interest to this document are either sources or 165 destinations of DetNet flows. And end system may or may not be 166 DetNet forwarding sub-layer aware or DetNet service sub-layer 167 aware. 169 DetNet service sub-layer 171 DetNet functionality is divided into two sub-layers. One of them 172 is the DetNet service sub-layer, at which a DetNet service, e.g., 173 service protection is provided. 175 DetNet forwarding sub-layer 177 DetNet functionality is divided into two sub-layers. One of them 178 is the DetNet forwarding sub-layer, which optionally provides 179 resource allocation for DetNet flows over paths provided by the 180 underlying network. 182 3. SRv6 for DetNet Overview 184 As mentioned above, there are mainly three technologies/functions 185 defined in DetNet: Explicit Route, Resource Reservation and Service 186 Protection. Explicit Route is the basic of the other two 187 technologies, and guarantees the path satisfies the SLA requirement 188 from application. Resource Reservation protects DetNet flows from 189 network congestion, which could reduce the end-to-end latency and 190 congestion loss; Service Protection prevents DetNet flow from random 191 media errors and equipment failures, which makes the loss rate 192 extremely low. 194 In [RFC8655], DetNet functionality is implemented in two sub-layers 195 in the protocol stack: the DetNet service sub-layer and the DetNet 196 forwarding sub-layer. The DetNet service sub-layer provides DetNet 197 service, e.g., service protection. The DetNet forwarding sub-layer 198 supports DetNet service in the underlying network, by providing 199 explicit routes and resource allocation to DetNet flows. There is no 200 obvious protocol stack as MPLS, in SRv6 both service sub-layer and 201 forwarding sub-layer are implemented through SRH. 203 The following picture shows that a general DetNet enabled network 204 defined in [RFC8655] : 206 TSN Edge Transit Relay DetNet 207 End System Node Node Node End System 209 +----------+ +.........+ +----------+ 210 | Appl. |<--:Svc Proxy:-- End to End Service -------->| Appl. | 211 +----------+ +---------+ +---------+ +----------+ 212 | TSN | |TSN| |Svc|<- DetNet flow --: Service :-->| Service | 213 +----------+ +---+ +---+ +--------+ +---------+ +----------+ 214 |Forwarding| |Fwd| |Fwd| | Fwd | |Fwd| |Fwd| |Forwarding| 215 +-------.--+ +-.-+ +-.-+ +--.----.+ +-.-+ +-.-+ +---.------+ 216 : Link : / ,-----. \ : Link : / ,-----. \ 217 +........+ +-[ Sub ]-+ +.......+ +-[ Sub ]-+ 218 [Network] [Network] 219 `-----' `-----' 221 In SRv6 for DetNet, the outer IPv6 Header with the SRH is used for 222 carrying DetNet flows. Explicit path is instantiated in the segment 223 list of SRH, and other functions/arguments for service protection 224 (packet replication, elimination and ordering, PREOF) and resource 225 reservation (packet queuing and scheduling) are also defined in the 226 specified SID. Meta data for DetNet could be instantiated in the 227 Optional TLVs. 229 4. Service Protection 231 4.1. Service Protection Scenarios 233 The figure below shows that an IPv6 flow is sent out from the end 234 station E1. The packet of the flow is encapsulated in an outer 235 IPv6+SRH header as a DetNet SRv6 packet in the Ingress(In) and 236 transported through an SRv6 DetNet domain. In the Egress(Eg), the 237 outer IPv6 header+SRH of the packet is popped, and the packet is sent 238 to the destination E2. 240 | | 241 ----IPv6--->|<---------------SRv6 DetNet------------->|<----IPv6--- 242 | | 243 | +------+T2+----+ | 244 +---+ +---+ +-+-+ +-+-+ +---+ +---+ 245 | E1+----| In|--+T1+--+R1 | |R2 |--+T4+--| Eg+----+ E2| 246 +---+ +---+ +-+-+ +-+-+ +---+ +---+ 247 +-----+T3+-----+ 249 The DetNet packet processing is as follows: 251 Ingress: 253 Inserts the SRv6 Policy that will steer the packet from Ingress to 254 the destination 256 The methods and mechanisms used for defining, instantiating and 257 applying the policy are outside of this document. An example of 258 policies are described in [I-D.ietf-spring-segment-routing-policy] 260 Flow Identification and Sequence Number are carried in the SRH. 262 Relay Node 1(Replication Node): 264 Replicates the payload and IPv6 Header with the SRH. This is a 265 new function in the context of SRv6 Network Programming which will 266 associate a given SID to a replication instruction in the node 267 originating and advertising the SID. The replication instruction 268 includes: 270 * The removal of the existing IPv6+SRH header 272 * The encapsulation into a new outer IPv6+SRH header. Each 273 packet (the original and the duplicated) are encapsulated into 274 respectively new outer IPv6+SRH headers. 276 Binding two different SRv6 Policies respectively to the original 277 packet and the replicated packet, which can steer the packets from 278 Relay Node 1 to Relay Node 2 through two tunnels. 280 Relay Node 2(Elimination Node): 282 Eliminates the redundant packets. 284 Binds a new SRv6 Policy to the survival packet, which steers the 285 packet from Relay Node 2 to Egress. 287 Egress: 289 Decapsulates the outer Ipv6 header. 291 Sends the inter packet to the End Station 2. 293 The DetNet packet encapsulation is illustrated here below. It has to 294 be noted that, in the example below, the R2 address is a SRH SID 295 associated to a TBD function related to the packet replication the 296 node R1 has to perform. The same (or reverse) apply to node R2 which 297 is in charge of the discard of the duplicated packet. Here also a 298 new function will have a new SID allocated to it and representing the 299 delete of the duplication in R2. 301 End Station1 output packet: (E1,E2) 303 Ingress output packet: (In, T1)(R1,T1, SL=2)(E1,E2) 305 Transit Node1 output packet: (In, R1)(R1,T1,SL=1)(E1,E2) 307 Relay Node1 output packets : (R1,T2)(R2,T2,SL=2)(E1,E2), 308 (R1,T3)(R2,T3,SL=2)(E1,E2) 310 Transit Node2 output packet: (R1, R2)(R2,T2,SL=1)(E1,E2) 312 Transit Node3 output packet: (R1, R2)(R2,T3,SL=1)(E1,E2) 314 Relay Node2 output packet: (R2, T4)(Eg,T4,SL=2)(E1,E2) 316 Transit Node4 output packet: (R2, Eg)(Eg,T4,SL=1)(E1,E2) 318 Egress out : (E1,E2) 320 4.2. Data Plane Considerations 322 Flow Identification and sequence number are necessary in the 323 encapsulation of SRv6 for DetNet in order to support service 324 protection. Replication nodes decide which DetNet flows are supposed 325 to be replicated by identifying the flow with the flow 326 identification. Elimination nodes decide whether a packet should be 327 dropped because of redundancy by identifying the flow identification 328 and sequence number. 330 4.3. Control Plane Considerations 331 (1) +----------+ 332 +------------------->+Controller| 333 | +----+-----+ 334 |(2) / \ 335 | +---------------/-----\-----------------+ 336 | | / (3) \ | 337 +--V-------+ +--------V-+-->+-----V----+ +----------+ 338 | Ingress +--|Relay Node| |Relay Node|-->| Egresss | 339 +----------+ +----------+-->+----------+ +----------+ 340 | Replication Elimiantion | 341 +---------------------------------------+ 342 DetNet Domain 344 1. Edge node->Controller: Sends a path computation requirement 345 containing that service protection in order to have ultra-reliability 346 through PCEP/BGP extenisons. 348 2. Controller->Edge node: Computes a P2MP2P path, including 349 replication nodes and elimination nodes. Between a pair of 350 replication node and elimination node, there are more than one path, 351 and if any equipment failure happens in one of them, the DetNet 352 service is not interrupted. Send the path computation result to the 353 edge node through PCEP/BGP extensions. 355 3. Controller->Relay Node : In a P2MP2P path, every pair of 356 replication node and elimination node should be configured to 357 identify different DetNet flows by the different flow 358 identifications, and the rule of sequence number should be negotiated 359 between relay nodes. After replication or elimination, the explicit 360 path to the next relay is also required through BGP extensions or 361 Netconf YANG. 363 5. Resource Reservation 365 5.1. Resource Reservation Scenarios 367 The figure below shows that an IPv6 flow is sent out from the end 368 station E1. The packet of the flow is encapsulated in an outer 369 IPv6+SRH header as a DetNet SRv6 packet in the Ingress(In) and 370 transported through an SRv6 DetNet domain. In the Egress(Eg), the 371 outer IPv6 header+SRH of the packet is popped, and the packet is sent 372 to the destination E2. 374 | | 375 ----IPv6--->|<---------------SRv6 DetNet------------->|<----IPv6--- 376 | | 377 | | 378 +---+ +---+ +---+ +---+ 379 | E1+----| In|--+T1+---------+T2+---------+T3+----| Eg+----+ E2| 380 +---+ +---+ +---+ +---+ 382 The DetNet packet processing is as follows: 384 Ingress: 386 Inserts the SRv6 Policy that will steer the packet from Ingress to 387 the destination. 389 The methods and mechanisms used for defining, instantiating and 390 applying the policy are outside of this document. An example of 391 policies are described in [I-D.ietf-spring-segment-routing-policy] 393 Explicit route and the corresponding resource is carried in the 394 SRH. 396 T1 Node (Transit Node): 398 Forward the packet with the allocated resource. 400 This is a new function in the context of SRv6 Network Programming 401 which will associate a given SID to a replication instruction in 402 the node originating and advertising the SID. The instruction 403 includes: 405 * Forward the packet to the link bound to the SID 407 * Use the resource when forwarding the packet 409 The processing of T2 and T3 Node is similar. 411 Egress: 413 Decapsulates the outer IPv6 header. 415 Sends the inter packet to the End Station 2. 417 5.2. Data Plane Considerations 419 Congestion could cause uncontrolled delay and packet loss. DetNet 420 flows are supposed to be protected from congestion, so enough 421 resource reservation for DetNet service is necessary. Some of the 422 resource in the network is complex and hard to quantize, e.g., packet 423 processing resource; while some of them is easy to get and calculate, 424 e.g., buffer size, port bandwidth and so on. In order to use the 425 allocated resource for the DetNet flow, SRv6 for DetNet is supposed 426 to carry the information of the resource. And the network device 427 could transit the packet following the instruction in the SRH with 428 the corresponding resources. 430 5.3. Control Plane Considerations 432 (1) +----------+ 433 +------------------->+Controller| 434 | +----+-----+ 435 |(2) / \ 436 | +---------------/-----\-------------------+ 437 | | / (3) \ | 438 +--V-------+ +--------V---+ +---V--------+ +----------+ 439 | Ingress +--|Transit Node|---|Transit Node|-->| Egress | 440 +----------+ +------------+ +------------+ +----------+ 441 | Resource Reservation | 442 +------------------------------------------+ 443 DetNet Domain 445 1. Edge node->Controller: Sends a path computation requirement 446 containing the flow characteristics and resource reservation request 447 through BGP/PCEP. 449 2. Controller->Edge node: The controller should collect the network 450 resource information of the network, e.g., bandwidth, buffer size and 451 so on, and maintain the resource status for every device/output port. 452 Based on the flow characteristics, the controller should find a path 453 which can guarantee that there are enough resources in every device/ 454 output port the flow goes through. The controller sends the path 455 computation results back to the edge node, and update the resources 456 status of the network through BGP/PCEP. 458 3. Controller->Transit Node: Every transit node along the path 459 should be configured in order to make sure that when the DetNet flow 460 goes through, the allocated resource for this flow is able to be used 461 and no more resource than what is allocated will be used for the same 462 flow through BGP/Netconf YANG.\ 464 6. Explicit Route 466 SRv6 could support explicit route using segment list without extra 467 extension. In DetNet, explicit route could be used with service 468 protection or resource reservation. When explicit route works with 469 service protection, a P2MP2P path is required to indicate the 470 behavior of replication and elimination. When explicit route works 471 with resource reservation, the explicit path indicates the nodes or 472 links a DetNet flow goes through, and also indicates the resource 473 allocated for the DetNet flow in the specified nodes or links. 475 7. IANA Considerations 477 This document makes no request of IANA. 479 Note to RFC Editor: this section may be removed on publication as an 480 RFC. 482 8. Security Considerations 484 TBD 486 9. Acknowledgements 488 Thank you for valuable comments from James Guichard and Andrew Mails. 490 10. Normative References 492 [I-D.filsfils-spring-srv6-network-programming] 493 Filsfils, C., Camarillo, P., Leddy, J., 494 daniel.voyer@bell.ca, d., Matsushima, S., and Z. Li, "SRv6 495 Network Programming", draft-filsfils-spring-srv6-network- 496 programming-07 (work in progress), February 2019. 498 [I-D.ietf-6man-segment-routing-header] 499 Filsfils, C., Dukes, D., Previdi, S., Leddy, J., 500 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 501 (SRH)", draft-ietf-6man-segment-routing-header-26 (work in 502 progress), October 2019. 504 [I-D.ietf-detnet-dp-sol-mpls] 505 Korhonen, J. and B. Varga, "DetNet MPLS Data Plane 506 Encapsulation", draft-ietf-detnet-dp-sol-mpls-02 (work in 507 progress), March 2019. 509 [I-D.ietf-spring-segment-routing-policy] 510 Filsfils, C., Sivabalan, S., Voyer, D., Bogdanov, A., and 511 P. Mattes, "Segment Routing Policy Architecture", draft- 512 ietf-spring-segment-routing-policy-07 (work in progress), 513 May 2020. 515 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 516 Requirement Levels", BCP 14, RFC 2119, 517 DOI 10.17487/RFC2119, March 1997, 518 . 520 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 521 Decraene, B., Litkowski, S., and R. Shakir, "Segment 522 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 523 July 2018, . 525 [RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas, 526 "Deterministic Networking Architecture", RFC 8655, 527 DOI 10.17487/RFC8655, October 2019, 528 . 530 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., 531 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 532 (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 533 . 535 Authors' Addresses 537 Xuesong Geng 538 Huawei 540 Email: gengxuesong@huawei.com 542 Zhenbin Li 543 Huawei 545 Email: lizhenbin@huawei.com 547 Mach Chen 548 Huawei 550 Email: mach.chen@huawei.com