idnits 2.17.1 draft-geng-spring-srv6-for-detnet-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 8, 2019) is 1753 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'Network' is mentioned on line 225, but not defined == Missing Reference: 'SL' is mentioned on line 411, but not defined == Unused Reference: 'I-D.ietf-detnet-dp-sol-mpls' is defined on line 473, but no explicit reference was found in the text == Unused Reference: 'RFC8402' is defined on line 489, but no explicit reference was found in the text == Outdated reference: A later version (-26) exists of draft-ietf-6man-segment-routing-header-21 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-03 Summary: 0 errors (**), 0 flaws (~~), 8 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 9, 2020 Huawei 6 July 8, 2019 8 SRv6 for Deterministic Networking (DetNet) 9 draft-geng-spring-srv6-for-detnet-00 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 9, 2020. 41 Copyright Notice 43 Copyright (c) 2019 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. SRv6 for DetNet Overview . . . . . . . . . . . . . . . . . . 4 61 4. Service Protection . . . . . . . . . . . . . . . . . . . . . 5 62 4.1. Service Protection Scenarios . . . . . . . . . . . . . . 6 63 4.2. Data Plane Considerations . . . . . . . . . . . . . . . . 8 64 4.3. Control Plane Considerations . . . . . . . . . . . . . . 8 65 4.4. Functions for Service Protection . . . . . . . . . . . . 9 66 4.4.1. End. B. Replication: Packet Replication Function . . 9 67 4.4.2. End. B. Elimination: Packet Elimination Function . . 9 68 5. Explicit Route . . . . . . . . . . . . . . . . . . . . . . . 10 69 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 70 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 71 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 72 9. Normative References . . . . . . . . . . . . . . . . . . . . 10 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 75 1. Introduction 77 With more and more applications running in the Internet, quality of 78 the service gains more and more attention, especially for some new 79 applications, for example Cloud VR, Cloud Game, HDV (high-definition 80 video) and so on, SLA (Service Level Agreement), including jitter, 81 delay and loss rate, influences the users' experience significantly. 82 So SLA guarantee is an important issue which requires new 83 technologies and solutions for the network. 85 Deterministic Networking (DetNet defined in 86 [I-D.ietf-detnet-architecture]) provides a capability to carry 87 specified data flows for real-time applications with extremely low 88 data loss rates, low jitter and bounded latency within a network 89 domain. Techniques used include: 1) providing explicit paths for 90 DetNet flows that satisfies the SLA requirement from user and do not 91 immediately change with the network topology; 2) reserving data plane 92 resources for DetNet flows along the allocated path of the flow; 3) 93 replicates DetNet flows into two or more copies and transport 94 different copies through different path in parallel, called service 95 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, 101 [I-D.ietf-6man-segment-routing-header]). A segment in Segment 102 Routing is not limited to a routing/forwarding function. An SRv6 103 Segment can indicate functions that are executed locally in the node 104 where they are defined. 105 [I-D.filsfils-spring-srv6-network-programming] describes some well- 106 known functions and segments associated to them. SRH 107 TLVs([I-D.ietf-6man-segment-routing-header]) also provides meta-data 108 for segment processing. All these features make SRv6 suitable to 109 carry DetNet flows, by defining new segments associated with DetNet 110 functions and meta data for DetNet. 112 This document describes the concepts needed by implementing DetNet in 113 an SRv6-based domain and provides considerations for any 114 corresponding implementation. 116 Editor's note: 118 1. DetNet is limited in a controlled network domain, and it is not 119 the only method to provide SLA guarantee. But it is a good start to 120 discuss how to use SRv6 to have a SLA-guaranteed network service. 122 2. Resource Reservation will be added in future work. 124 2. Terminology 126 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 127 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 128 document are to be interpreted as described in [RFC2119]. 130 Terminologies for DetNet go along with the definition in 131 [I-D.ietf-detnet-architecture] and 132 [I-D.ietf-6man-segment-routing-header]: 134 DetNet domain 136 The portion of a network that is DetNet aware. It includes end 137 systems and DetNet nodes 139 DetNet edge node 141 An instance of a DetNet relay node that acts as a source and/ or 142 destination at the DetNet service sub-layer. For example, it can 143 include a DetNet service sub-layer proxy function for DetNet 144 service protection (e.g., the addition or removal of packet 145 sequencing information) for one or more end systems, or starts or 146 terminates resource allocation at the DetNet forwarding sub-layer, 147 or aggregates DetNet services into new DetNet flows. It is 148 analogous to a Label Edge Router (LER) or a Provider Edge (PE) 149 router. 151 DetNet relay node 153 A DetNet node including a service sub-layer function that 154 interconnects different DetNet forwarding sub-layer paths to 155 provide service protection. A DetNet relay node participates in 156 the DetNet service sub-layer. It typically incorporates DetNet 157 forwarding sub-layer functions as well, in which case it is 158 collocated with a transit node. 160 DetNet transit node 162 A DetNet node operating at the DetNet forwarding sub-layer, that 163 utilizes link layer and/or network layer switching across multiple 164 links and/or sub-networks to provide paths for DetNet service sub- 165 layer functions. Typically provides resource allocation over 166 those paths. An MPLS LSR is an example of a DetNet transit node. 168 End system 170 End systems of interest to this document are either sources or 171 destinations of DetNet flows. And end system may or may not be 172 DetNet forwarding sub-layer aware or DetNet service sub-layer 173 aware. 175 DetNet service sub-layer 177 DetNet functionality is divided into two sub-layers. One of them 178 is the DetNet service sub-layer, at which a DetNet service, e.g., 179 service protection is provided. 181 DetNet forwarding sub-layer 183 DetNet functionality is divided into two sub-layers. One of them 184 is the DetNet forwarding sub-layer, which optionally provides 185 resource allocation for DetNet flows over paths provided by the 186 underlying network. 188 3. SRv6 for DetNet Overview 190 As mentioned above, there are mainly three technologies/functions 191 defined in DetNet: Explicit Route, Resource Reservation and Service 192 Protection. Explicit Route is the basic of the other two 193 technologies, and guarantees the path satisfies the SLA requirement 194 from application. Resource Reservation protects DetNet flows from 195 network congestion, which could reduce the end-to-end latency and 196 congestion loss; Service Protection prevents DetNet flow from random 197 media errors and equipment failures, which makes the loss rate 198 extremely low. 200 In [I-D.ietf-detnet-architecture], DetNet functionality is 201 implemented in two sub-layers in the protocol stack: the DetNet 202 service sub-layer and the DetNet forwarding sub-layer. The DetNet 203 service sub-layer provides DetNet service, e.g., service protection. 204 The DetNet forwarding sub-layer supports DetNet service in the 205 underlying network, by providing explicit routes and resource 206 allocation to DetNet flows. There is no obvious protocol stack as 207 MPLS, in SRv6 both service sub-layer and forwarding sub-layer are 208 implemented through SRH. 210 The following picture shows that a general DetNet enabled network 211 defined in [I-D.ietf-detnet-architecture] : 213 TSN Edge Transit Relay DetNet 214 End System Node Node Node End System 216 +----------+ +.........+ +----------+ 217 | Appl. |<--:Svc Proxy:-- End to End Service -------->| Appl. | 218 +----------+ +---------+ +---------+ +----------+ 219 | TSN | |TSN| |Svc|<- DetNet flow --: Service :-->| Service | 220 +----------+ +---+ +---+ +--------+ +---------+ +----------+ 221 |Forwarding| |Fwd| |Fwd| | Fwd | |Fwd| |Fwd| |Forwarding| 222 +-------.--+ +-.-+ +-.-+ +--.----.+ +-.-+ +-.-+ +---.------+ 223 : Link : / ,-----. \ : Link : / ,-----. \ 224 +........+ +-[ Sub ]-+ +.......+ +-[ Sub ]-+ 225 [Network] [Network] 226 `-----' `-----' 228 In SRv6 for DetNet, the outer IPv6 Header with the SRH is used for 229 carrying DetNet flows. Explicit path is instantiated in the segment 230 list of SRH, and other functions/arguments for service protection 231 (packet replication, elimination and ordering, PREOF) and resource 232 reservation (packet queuing and scheduling) are also defined in the 233 specified SID. Meta data for DetNet could be instantiated in the 234 Optional TLVs. 236 4. Service Protection 237 4.1. Service Protection Scenarios 239 The figure below shows that an IPv6 flow is sent out from the end 240 station E1. The packet of the flow is encapsulated in an outer 241 IPv6+SRH header as a DetNet SRv6 packet in the Ingress(In) and 242 transported through an SRv6 DetNet domain. In the Egress(Eg), the 243 outer IPv6 header+SRH of the packet is popped, and the packet is sent 244 to the destination E2. 246 | | 247 ----IPv6--->|<---------------SRv6 DetNet------------->|<----IPv6--- 248 | | 249 | +------+T2+----+ | 250 +---+ +---+ +-+-+ +-+-+ +---+ +---+ 251 | E1+----| In|--+T1+--+R1 | |R2 |--+T4+--| Eg+----+ E2| 252 +---+ +---+ +-+-+ +-+-+ +---+ +---+ 253 +-----+T3+-----+ 255 The DetNet packet processing is as follows: 257 Ingress: 259 Inserts the SRv6 Policy that will steer the packet from Ingress to 260 the destination 262 The methods and mechanisms used for defining, instantiating and 263 applying the policy are outside of this document. An example of 264 policies are described in [I-D.ietf-spring-segment-routing-policy] 266 Flow Identification and Sequence Number are carried in the SRH. 268 Relay Node 1(Replication Node): 270 Replicates the payload and IPv6 Header with the SRH. This is a 271 new function in the context of SRv6 Network Programming which will 272 associate a given SID to a replication instruction in the node 273 originating and advertising the SID. The replication instruction 274 includes: 276 * The removal of the existing IPv6+SRH header 278 * The encapsulation into a new outer IPv6+SRH header. Each 279 packet (the original and the duplicated) are encapsulated into 280 respectively new outer IPv6+SRH headers. 282 Binding two different SRv6 Policies respectively to the original 283 packet and the replicated packet, which can steer the packets from 284 Relay Node 1 to Relay Node 2 through two tunnels. 286 Relay Node 2(Elimination Node): 288 Eliminates the redundant packets. 290 Binds a new SRv6 Policy to the survival packet, which steers the 291 packet from Relay Node 2 to Egress. 293 Egress: 295 Decapsulates the outer Ipv6 header. 297 Sends the inter packet to the End Station 2. 299 The DetNet packet encapsulation is illustrated here below. It has to 300 be noted that, in the example below, the R2 address is a SRH SID 301 associated to a TBD function related to the packet replication the 302 node R1 has to perform. The same (or reverse) apply to node R2 which 303 is in charge of the discard of the duplicated packet. Here also a 304 new function will have a new SID allocated to it and representing the 305 delete of the duplication in R2. 307 End Station1 output packet: (E1,E2) 309 Ingress output packet: (In, T1)(R1,T1, SL=2)(E1,E2) 311 Transit Node1 output packet: (In, R1)(R1,T1,SL=1)(E1,E2) 313 Relay Node1 output packets : (R1,T2)(R2,T2,SL=2)(E1,E2), 314 (R1,T3)(R2,T3,SL=2)(E1,E2) 316 Transit Node2 output packet: (R1, R2)(R2,T2,SL=1)(E1,E2) 318 Transit Node3 output packet: (R1, R2)(R2,T3,SL=1)(E1,E2) 320 Relay Node2 output packet: (R2, T4)(Eg,T4,SL=2)(E1,E2) 322 Transit Node4 output packet: (R2, Eg)(Eg,T4,SL=1)(E1,E2) 324 Egress out : (E1,E2) 326 4.2. Data Plane Considerations 328 Flow Identification and sequence number are necessary in the 329 encapsulation of SRv6 for DetNet in order to support service 330 protection. Replication nodes decide which DetNet flows are supposed 331 to be replicated by identifying the flow with the flow 332 identification. Elimination nodes decide whether a packet should be 333 dropped because of redundancy by identifying the flow identification 334 and sequence number. 336 4.3. Control Plane Considerations 338 (1) +----------+ 339 +------------------->+Controller| 340 | +----+-----+ 341 |(2) / \ 342 | +---------------/-----\-----------------+ 343 | | / (3) \ | 344 +--V-------+ +--------V-+-->+-----V----+ +----------+ 345 | Ingress +--|Relay Node| |Relay Node|-->| Egresss | 346 +----------+ +----------+-->+----------+ +----------+ 347 | Replication Elimiantion | 348 +---------------------------------------+ 349 DetNet Domain 351 1. Edge node->Controller: Sends a path computation requirement 352 containing that service protection in order to have ultra-reliability 353 through PCEP/BGP extenisons. 355 2. Controller->Edge node: Computes a P2MP2P path, including 356 replication nodes and elimination nodes. Between a pair of 357 replication node and elimination node, there are more than one path, 358 and if any equipment failure happens in one of them, the DetNet 359 service is not interrupted. Send the path computation result to the 360 edge node through PCEP/BGP extensions. 362 3. Controller->Relay Node : In a P2MP2P path, every pair of 363 replication node and elimination node should be configured to 364 identify different DetNet flows by the different flow 365 identifications, and the rule of sequence number should be negotiated 366 between relay nodes. After replication or elimination, the explicit 367 path to the next relay is also required through BGP extensions or 368 Netconf YANG. 370 4.4. Functions for Service Protection 372 New SRv6 Network Programming functions are defined as follows: 374 4.4.1. End. B. Replication: Packet Replication Function 376 1. IF NH=SRH & SL>0 THEN 378 2. extract the DetNet TLV values from the SRH 380 3. create two new outer IPv6+SRH headers: IPv6-SRH-1 and IPv6-SRH-2 381 Insert the policy-instructed segment lists in each newly created 382 SRH (SRH-1 and SRH-2). Also, add the extracted DetNet TLVs into 383 SRH-1 and SRH-2. 385 4. remove the incoming outer IPv6+SRH header. 387 5. create a duplication of the incoming packet. 389 6. encapsulate the original packet into the first outer IPv6+SRH 390 header: (IPv6-SRH-1) (original packet) 392 7. encapsulate the duplicate packet into the second outer IPv6+SRH 393 header: (IPv6-SRH-2) (duplicate packet) 395 8. set the IPv6 SA as the local address of this node. 397 9. set the IPv6 DA of IPv6-SRH-1 to the first segment of the SRv6 398 Policy in of SRH-1 segment list. 400 10. set the IPv6 DA of IPv6-SRH-2 to the first segment of the SRv6 401 Policy in of SRH-2 segment list. 403 11. ELSE 405 12. drop the packet 407 4.4.2. End. B. Elimination: Packet Elimination Function 409 1. IF NH=SRH & SL>0 & "the packet is not a redundant packet" THEN 411 2. do not decrement SL nor update the IPv6 DA with SRH[SL] 413 3. extract the value of DetNet TLVs from the SRH 415 4. create a new outer IPv6+SRH header 416 5. insert the policy-instructed segment lists in the newly created 417 SRH and add the retrieved DetNet TLVs in the newly created SRH 419 6. remove the incoming outer IPv6+SRH header. 421 7. set the IPv6 DA to the first segment of the SRv6 Policy in the 422 newly created SRH 424 8. ELSE 426 9. drop the packet 428 5. Explicit Route 430 SRv6 could support explicit route using segment list without extra 431 extension. In DetNet, explicit route could be used with service 432 protection or resource reservation. When explicit route works with 433 service protection, a P2MP2P path is required to indicate the 434 behavior of replication and elimination. When explicit route works 435 with resource reservation, the explicit path indicates the nodes or 436 links a DetNet flow goes through, and also indicates the resource 437 allocated for the DetNet flow in the specified nodes or links. 439 6. IANA Considerations 441 This document makes no request of IANA. 443 Note to RFC Editor: this section may be removed on publication as an 444 RFC. 446 7. Security Considerations 448 TBD 450 8. Acknowledgements 452 Thank you for valuable comments from James Guichard and Andrew Mails. 454 9. Normative References 456 [I-D.filsfils-spring-srv6-network-programming] 457 Filsfils, C., Camarillo, P., Leddy, J., 458 daniel.voyer@bell.ca, d., Matsushima, S., and Z. Li, "SRv6 459 Network Programming", draft-filsfils-spring-srv6-network- 460 programming-07 (work in progress), February 2019. 462 [I-D.ietf-6man-segment-routing-header] 463 Filsfils, C., Dukes, D., Previdi, S., Leddy, J., 464 Matsushima, S., and d. daniel.voyer@bell.ca, "IPv6 Segment 465 Routing Header (SRH)", draft-ietf-6man-segment-routing- 466 header-21 (work in progress), June 2019. 468 [I-D.ietf-detnet-architecture] 469 Finn, N., Thubert, P., Varga, B., and J. Farkas, 470 "Deterministic Networking Architecture", draft-ietf- 471 detnet-architecture-13 (work in progress), May 2019. 473 [I-D.ietf-detnet-dp-sol-mpls] 474 Korhonen, J. and B. Varga, "DetNet MPLS Data Plane 475 Encapsulation", draft-ietf-detnet-dp-sol-mpls-02 (work in 476 progress), March 2019. 478 [I-D.ietf-spring-segment-routing-policy] 479 Filsfils, C., Sivabalan, S., daniel.voyer@bell.ca, d., 480 bogdanov@google.com, b., and P. Mattes, "Segment Routing 481 Policy Architecture", draft-ietf-spring-segment-routing- 482 policy-03 (work in progress), May 2019. 484 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 485 Requirement Levels", BCP 14, RFC 2119, 486 DOI 10.17487/RFC2119, March 1997, 487 . 489 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 490 Decraene, B., Litkowski, S., and R. Shakir, "Segment 491 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 492 July 2018, . 494 Authors' Addresses 496 Xuesong Geng 497 Huawei 499 Email: gengxuesong@huawei.com 501 Zhenbin Li 502 Huawei 504 Email: lizhenbin@huawei.com 505 Mach Chen 506 Huawei 508 Email: mach.chen@huawei.com