idnits 2.17.1 draft-geng-detnet-dp-sol-srv6-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 -- The document date (March 12, 2020) is 1478 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'SL' is mentioned on line 552, but not defined -- Looks like a reference, but probably isn't: '2' on line 155 -- Looks like a reference, but probably isn't: '1' on line 155 -- Looks like a reference, but probably isn't: '0' on line 655 == Unused Reference: 'I-D.ietf-detnet-dp-sol-mpls' is defined on line 713, but no explicit reference was found in the text == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-06 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group X. Geng 3 Internet-Draft M. Chen 4 Intended status: Experimental Huawei 5 Expires: September 13, 2020 Y. Zhu 6 China Telecom 7 March 12, 2020 9 DetNet SRv6 Data Plane Encapsulation 10 draft-geng-detnet-dp-sol-srv6-02 12 Abstract 14 This document specifies Deterministic Networking data plane operation 15 for SRv6 encapsulated user data. 17 Requirements Language 19 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 20 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 21 document are to be interpreted as described in RFC 2119 [RFC2119]. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on September 13, 2020. 40 Copyright Notice 42 Copyright (c) 2020 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Terminology and Conventions . . . . . . . . . . . . . . . . . 3 59 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 60 2.2. Conventions . . . . . . . . . . . . . . . . . . . . . . . 4 61 3. SRv6 DetNet Data Plane Overview . . . . . . . . . . . . . . . 4 62 3.1. SRv6 DetNet Data Plane Layers . . . . . . . . . . . . . . 5 63 3.2. SRv6 DetNet Data Plane Scenarios . . . . . . . . . . . . 5 64 4. SRv6 DetNet Data Plane Solution Considerations . . . . . . . 7 65 5. SRv6 DetNet Data Plane Solution for Service Sub-layer . . . . 8 66 5.1. TLV Based SRv6 Data Plane Solution . . . . . . . . . . . 9 67 5.1.1. Encapsulation . . . . . . . . . . . . . . . . . . . . 9 68 5.1.2. Replication SID and Elimination for DetNet . . . . . 11 69 5.2. SID Based SRv6 Data Plane Solution . . . . . . . . . . . 13 70 5.2.1. Encapsulation . . . . . . . . . . . . . . . . . . . . 13 71 5.2.2. Functions . . . . . . . . . . . . . . . . . . . . . . 14 72 5.3. DetNet SID Based SRv6 Data Plane Solution . . . . . . . . 15 73 5.3.1. Encapulation . . . . . . . . . . . . . . . . . . . . 15 74 5.3.2. Functions . . . . . . . . . . . . . . . . . . . . . . 15 75 6. SRv6 DetNet Data Plane Solution for Transport Sub-layer . . . 16 76 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 77 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 78 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 79 10. Normative References . . . . . . . . . . . . . . . . . . . . 16 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 82 1. Introduction 84 Deterministic Networking (DetNet), as described in 85 [I-D.ietf-detnet-architecture] provides a capability to carry 86 specified data flows with extremely low data loss rates and bounded 87 latency within a network domain. DetNet is enabled by a group of 88 technologies, such as resource allocation, service protection and 89 explicit routes. 91 Segment Routing(SR) leverages the source routing paradigm. An 92 ingress node steers a packet through an ordered list of instructions, 93 called "segments". SR can be applied over IPv6 data plane using the 94 Segment Routing Extension Header (SRH, 95 [I-D.ietf-6man-segment-routing-header]). A segment in segment 96 routing terminology is not limited to a routing/forwarding function. 98 A segment can be associated to an arbitrary processing of the packet 99 in the node identified by the segment. In other words, an SRv6 100 Segment can indicate functions that are executed locally in the node 101 where they are defined. SRv6 network Programming 102 [I-D.filsfils-spring-srv6-network-programming] describe the different 103 segments and functions associated to them. 105 This document describes how to implement DetNet in an SRv6 enabled 106 domain, including : 108 o Source routing, which steers the DetNet flows through the network 109 according to an explicit path with allocated resources; 111 o Network programming, which applies instructions (functions) to 112 packets in some special nodes (or even all the nodes) along the path 113 in order to guarantee, e.g., service protection and congestion 114 protection. 116 DetNet SRv6 encapsulation and new SRv6 functions 117 ([I-D.filsfils-spring-srv6-network-programming]) for DetNet are 118 defined in this document. Control plane and OAM are not in the scope 119 of this document. 121 Control plane and OAM are not in the scope of this document. 123 2. Terminology and Conventions 125 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 126 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 127 document are to be interpreted as described in [RFC2119]. 129 2.1. Terminology 131 Terminologies for DetNet go along with the definition in 132 [I-D.ietf-detnet-architecture] and [RFC8402]. Other terminologies 133 are defined as follows: 135 o NH: The IPv6 next-header field. 137 o SID: A Segment Identifier ([RFC8402]). 139 o SRH: The Segment Routing Header 140 ([I-D.ietf-6man-segment-routing-header]). 142 2.2. Conventions 144 Conventions in the document are defined as follows: 146 o NH=SRH means that NH is 43 with routing type 4 which is (as 147 defined in [I-D.ietf-6man-segment-routing-header], the values 148 representing the SRH. 150 o A SID list is represented as where S1 is the first 151 SID to visit, S2 is the second SID to visit and S3 is the last SID 152 to visit along the SR path. 154 o SRH[SL] represents the SID pointed by the SL field in the first 155 SRH. In our example, SRH[2] represents S1, SRH[1] represents S2 156 and SRH[0] represents S3. It has to be noted that 157 [I-D.ietf-6man-segment-routing-header] defines the segment list 158 encoding in the reverse order of the path. A path represented by 159 , will be encoded in the SRH as follows: 161 SegmentList[0]=S3 163 SegmentList[1]=S2 165 SegmentList[2]=S1 167 The reverse encoding has been defined in order to optimise the 168 processing time of the segment list. See [draft-ietf-6man- 169 segment-routing-header] for more details. 171 o (SA,DA) (S3, S2, S1; SL) represents an IPv6 packet with: 173 IPv6 header with source and destination addresses SA and DA 174 respectively, and next-header set to SRH (i.e.: 43 with type 4) 175 , with a list of segments(SIDs) with SegmentsLeft 176 = SL 178 The payload of the packet is not represented 180 (S3, S2, S1; SL) represents the same SID list as , 181 but encoded in the SRH format where the rightmost SID in the 182 SRH is the first SID and the leftmost SID in the SRH is the 183 last SID 185 3. SRv6 DetNet Data Plane Overview 186 3.1. SRv6 DetNet Data Plane Layers 188 [I-D.ietf-detnet-architecture]decomposes the DetNet data plane into 189 two sub-layers: service sub-layer and transport sub-layer. Different 190 from DetNet MPLS data plane solution, which uses DetNet Control 191 Word(d-CW) and S-Label to support service sub-layer and uses T-Label 192 to support transport sub-layer, no explicit sub-layer division exists 193 in SRv6 data plane. A classical SRv6 DetNet data plane solution is 194 showed in the picture below: 196 +-------------------+ 197 | Outer Ipv6 Header | 198 +-------------------+ 199 | SRH | 200 +-------------------+ +-------------------+ 201 | Ipv6 Header | ----> | Ipv6 Header | 202 +-------------------+ +-------------------+ 204 The outer IPv6 Header with the SRH is used for carrying DetNet flows. 205 Traffic Engineering is instantiated in the segment list of SRH, and 206 other functions and arguments for service protection (packet 207 replication, elimination and ordering) and congestion control (packet 208 queuing and forwarding) are also defined in the SRH. 210 3.2. SRv6 DetNet Data Plane Scenarios 212 | | 213 ----IPv6--->|<---------------SRv6 DetNet------------->|<----IPv6--- 214 | | 215 | +------+T2+----+ | 216 +---+ +---+ +-+-+ +-+-+ +---+ +---+ 217 | E1+----| In|--+T1+--+R1 | |R2 |--+T4+--| Eg+----+ E2| 218 +---+ +---+ +-+-+ +-+-+ +---+ +---+ 219 +-----+T3+-----+ 221 The figure above shows that an IPv6 flow is sent out from the end 222 station E1. The packet of the flow is encapsulated in an outer 223 IPv6+SRH header as a DetNet SRv6 packet in the Ingress(In) and 224 transported through an SRv6 DetNet domain. In the Egress(Eg), the 225 outer IPv6 header+SRH of the packet is popped, and the packet is sent 226 to the destination E2. 228 The figure above shows that an IPv6 flow is sent our from the end 229 station: E1. The packet of the flow is encapsulated as a DetNet SRv6 230 packet in the Ingress(In) and transported through an SRv6 DetNet 231 domain. In the Egress(Eg), the upper IPv6 header with SRH of the 232 packet is popped, and the packet is transmitted to the 233 destination(E2). 235 The DetNet packet processing is as follows: 237 Ingress: 239 Inserts the SRv6 Policy that will steer the packet from Ingress to 240 the destination 242 The methods and mechanisms used for defining, instantiating and 243 applying the policy are outside of this document. An example of 244 policies are described in [I-D.ietf-spring-segment-routing-policy] 246 Flow Identification and Sequence Number are carried in the SRH 247 optionally. 249 Relay Node 1(Replication Node): 251 Replicates the payload and IPv6 Header with the SRH. This is a 252 new function in the context of SRv6 Network Programming which will 253 associate a given SID to a replication instruction in the node 254 originating and advertising the SID. The replication instruction 255 includes: 257 * The removal of the existing IPv6+SRH header 259 * The encapsulation into a new outer IPv6+SRH header. Each 260 packet (the original and the duplicated) are encapsulated into 261 respectively new outer IPv6+SRH headers. 263 Binding two different SRv6 Policies respectively to the original 264 packet and the replicated packet, which can steer the packets from 265 Relay Node 1 to Relay Node 2 through two tunnels. 267 If Flow Identification and Sequence Number are not carried in the 268 SRH in the ingress, add it them in the SRH. 270 Relay Node 2(Elimination Node): 272 Eliminates the redundant packets. 274 Binds a new SRv6 Policy to the survival packet, which steers the 275 packet from Relay Node 2 to Egress. 277 Egress: 279 Decapsulates the outer Ipv6 header. 281 Sends the inter packet to the End Station 2. 283 The DetNet packet encapsulation is illustrated here below. It has to 284 be noted that, in the example below, the R2 address is a SRH SID 285 associated to a TBD function related to the packet replication the 286 node R1 has to perform. The same (or reverse) apply to node R2 which 287 is in charge of the discard of the duplicated packet. Here also a 288 new function will have a new SID allocated to it and representing the 289 delete of the duplication in R2. 291 End Station1 output packet: (E1,E2) 293 Ingress output packet: (In, T1)(R1,T1, SL=2)(E1,E2) 295 Transit Node1 output packet: (In, R1)(R1,T1,SL=1)(E1,E2) 297 Relay Node1 output packets : (R1,T2)(R2,T2,SL=2)(E1,E2), 298 (R1,T3)(R2,T3,SL=2)(E1,E2) 300 Transit Node2 output packet: (R1, R2)(R2,T2,SL=1)(E1,E2) 302 Transit Node3 output packet: (R1, R2)(R2,T3,SL=1)(E1,E2) 304 Relay Node2 output packet: (R2, T4)(Eg,T4,SL=2)(E1,E2) 306 Transit Node4 output packet: (R2, Eg)(Eg,T4,SL=1)(E1,E2) 308 Egress out : (E1,E2) 310 4. SRv6 DetNet Data Plane Solution Considerations 312 To carry DetNet over SRv6, the following elements are required: 314 1. A method of identifying the SRv6 payload type; 316 2. A suitable explicit path to deliver the DetNet flow ; 318 3. A method of indicating packet processing, such as PREOF(Packet 319 Replication, Elimination and Ordering as defined in 320 [I-D.ietf-detnet-architecture]); 322 4. A method of identifying the DetNet flow; 324 5. A method of carrying DetNet sequence number; 326 6. A method of carrying queuing and forwarding indication to do 327 congestion protection; 328 In this design, DetNet flows are encapsulated in an outer IPv6+SRH 329 header at the Ingress Node. The SR policy identified in the SRH 330 steers the DetNet flow along a selected path. The explicit path 331 followed by a DetNet flow, which protect it from temporary 332 interruptions caused by the convergence of routing, is encoded within 333 the SID list of the SR policy. The network device inside the DetNet 334 domain forwards the packet according to IPv6 Destination Address(DA), 335 and the IPv6 DA is updated with the SID List according to SRv6 336 forwarding procedures defined in 337 [I-D.ietf-6man-segment-routing-header] and 338 [I-D.filsfils-spring-srv6-network-programming] 340 With SRv6 network programming, the SID list can also give instruments 341 representing a function to be called at the node in the DetNet 342 domain. Therefore DetNet specific functions defined in 343 [I-D.ietf-detnet-architecture], corresponding to local packet 344 processing in the network, can also be implemented by SRv6. New 345 functions associated with SIDs for DetNet are defined in this 346 document. 348 This document describes how DetNet flows are encapsulated/identified, 349 and how functions of Packet Replication/Elimination/Ordering are 350 implemented in an SRv6 domain. Congestion protection is also in the 351 scope of this document. 353 Editor: This version only covers the functions of service protection 354 and the congestion protection considerations will be added in the 355 following versions. 357 5. SRv6 DetNet Data Plane Solution for Service Sub-layer 359 This section defines options of SRv6 data plane solution to support 360 DetNet Service Sub-layer. 362 SRH is as follows, which defined in 363 [I-D.ietf-6man-segment-routing-header] 364 0 1 2 3 365 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 367 | Next Header | Hdr Ext Len | Routing Type | Segment Left | 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 | Last Entry | Flags | Tag | 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 371 | | 372 | Segment List[0] | 373 | | 374 | | 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 | ... | 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 | | 379 | Segment List[n] | 380 | | 381 | | 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 383 | Optional TLVs | 384 | ... | 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 387 The SRH specification allows the use of optional TLVs. 389 Each SRv6 Segment in the segment list is a 128-bit value. SID is 390 used as a shorter reference for "SRv6 Segment Identifier" or "SRV6 391 Segment". SRv6 SID can also be represented as LOC:FUNCT, where: 393 LOC, means "LOCATION" and defines the node associated with the SID 394 (i.e.: represented by the SID). 396 FUNCT, means "FUNCTION", and identifies the processing that the 397 node specified in LOC applies to the packet. See 398 [I-D.filsfils-spring-srv6-network-programming] for details on SRV6 399 Network Programming. 401 as defined in [I-D.filsfils-spring-srv6-network-programming]. 403 5.1. TLV Based SRv6 Data Plane Solution 405 5.1.1. Encapsulation 407 Two new TLVs are defined to support DetNet service protection. 408 DetNet Flow Identification TLV is used to uniquely identify a DetNet 409 flow in an SRv6 DetNet node. DetNet sequence number is used to 410 discriminate packets in the same DetNet flow. They are defined as 411 follows: 413 Option 1: separated TLVs for flow identification and sequence 414 number 416 0 1 2 3 417 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 | Type | Length | RESERVED | 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 | RESERVED | Flow Identification | 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 424 where: 426 o Type: 8bits, to be assigned by IANA. 428 o Length: 8 octets. 430 o RESERVED: 28 bits, MUST be 0 on transmission and ignored on 431 receipt. 433 o Flow Identification: 20 bits, which is used for identifying DetNet 434 flow. 436 0 1 2 3 437 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 439 | Type | Length | RESERVED | 440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 441 |RESERVD| Sequence Number | 442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 444 where: 446 o Type: 8 bits, to be assigned by IANA. 448 o Length: 8. 450 o RESERVED: 20 bits. MUST be 0 on transmission and ignored on 451 receipt. 453 o Sequence Number: 28 bits, which is used for indicating sequence 454 number of a DetNet flow. 456 Option 2: unified TLV for flow identification and sequence number 458 0 1 2 3 459 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 461 | Type | Length | Flow Identification | 462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 463 | | Sequence Number | 464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 465 | RESERVED | 466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 468 where: 470 o Type: 8 bits, to be assigned by IANA. 472 o Length: 12. 474 o Flow Identification: 20 bits, which is used for identifying DetNet 475 flow. 477 o Sequence Number: 28 bits, which is used for indicating sequence 478 number of a DetNet flow. 480 o RESERVED: 32 bits. MUST be 0 on transmission and ignored on 481 receipt. 483 5.1.2. Replication SID and Elimination for DetNet 485 New SIDs, replication SID and elimination SID, are defined as 486 follows: 488 5.1.2.1. Replication SID 490 Redundancy SID is a variation of binding SID defined in 491 [I-D.ietf-spring-segment-routing-policy] Redundancy SID indicates the 492 following operations: 494 o Steering the packet into the corresponding redundancy policy 496 o Packet replication based on the redundancy policy, e.g., the 497 number of replication copies 499 o Encapsulate the packet with necessary meta data (e.g., flow 500 identification, sequence number) if it is not included in the 501 original packet 503 When N receives a packet whose IPv6 DA is S and S is a Replication 504 SID, N could do: 506 1. IF NH=SRH & SL>0 THEN 508 2. extract the DetNet TLV values from the SRH 510 3. create two new outer IPv6+SRH headers: IPv6-SRH-1 and IPv6-SRH-2 511 Insert the policy-instructed segment lists in each newly created 512 SRH (SRH-1 and SRH-2). Also, add the extracted DetNet TLVs into 513 SRH-1 and SRH-2. 515 4. remove the incoming outer IPv6+SRH header. 517 5. create a duplication of the incoming packet. 519 6. encapsulate the original packet into the first outer IPv6+SRH 520 header: (IPv6-SRH-1) (original packet) 522 7. encapsulate the duplicate packet into the second outer IPv6+SRH 523 header: (IPv6-SRH-2) (duplicate packet) 525 8. set the IPv6 SA as the local address of this node. 527 9. set the IPv6 DA of IPv6-SRH-1 to the first segment of the SRv6 528 Policy in of SRH-1 segment list. 530 10. set the IPv6 DA of IPv6-SRH-2 to the first segment of the SRv6 531 Policy in of SRH-2 segment list. 533 11. ELSE 535 12. drop the packet 537 5.1.2.2. Elimination SID 539 Elimination SID indicates the following operations: 541 o Packet elimination: forward the first received packets and 542 eliminate the redundant packets. 544 o Packet ordering(optional): reorder the packets if the packet 545 arrives out of order 547 When N receives a packet whose IPv6 DA is S and S is a Elimination 548 SID, N could do: 550 1. IF NH=SRH & SL>0 & "the packet is not a redundant packet" THEN 552 2. do not decrement SL nor update the IPv6 DA with SRH[SL] 553 3. extract the value of DetNet TLVs from the SRH 555 4. create a new outer IPv6+SRH header 557 5. insert the policy-instructed segment lists in the newly created 558 SRH and add the retrieved DetNet TLVs in the newly created SRH 560 6. remove the incoming outer IPv6+SRH header. 562 7. set the IPv6 DA to the first segment of the SRv6 Policy in the 563 newly created SRH 565 8. ELSE 567 9. drop the packet 569 5.2. SID Based SRv6 Data Plane Solution 571 5.2.1. Encapsulation 573 SRv6 SID can be represented as LOC:FUNCT:ARG::, where: 575 LOC, means "LOCATION" and defines the node associated with the SID 576 (i.e.: represented by the SID). 578 FUNCT, means "FUNCTION", and identifies the processing that the node 579 specified in LOC applies to the packet. 581 ARG, means "ARGUMENTS" and provides the additional arguments for the 582 function. New SID functions for DetNet is defined in section 5.2.2. 583 See [I-D.filsfils-spring-srv6-network-programming] for details on 584 SRV6 Network Programming. The SRH for DetNet in the outer IPv6 585 header is illustrated as follows 586 0 1 2 3 587 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 588 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 589 | Next Header | Hdr Ext Len | Routing Type | Segment Left | 590 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 591 | Last Entry | Flags | Tag | 592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 593 | Location & Function | 594 | (Segment List[0] for relay node or edge node) | 595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 596 | Location & Function | Flow Identification | 597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 598 |Flow ID| Sequence Number | 599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 600 | ... | 601 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 602 | | 603 | Segment List[n] | 604 | | 605 | | 606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 607 | Optional TLVS | 608 | ... | 609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 611 where: 613 o LOCATION&FUNCTION: the 80 most significant bits that are used for 614 routing the packet towards the LOCATION (as defined in 615 [I-D.filsfils-spring-srv6-network-programming]); 617 o FLOW IDENTIFICATION: 20 bits, in the DetNet TLVs in the SRH, used 618 for DetNet flow identification in the DetNet relay node; 620 o SEQUENCE NUMBER : 28 bits, in the DetNet TLVs, used for dis crime 621 packets in the same DetNet flow; 623 5.2.2. Functions 625 New SID functions are defined as follows: 627 5.2.2.1. End. B.Replication: Packet Replication Function 629 The function is similar as that has been defined in section 5.1.2.1. 630 The only difference is that instead of retrieving the TLV values, 631 this function retrieves the argument. 633 5.2.2.2. End. B. Elimination: Packet Elimination Function 635 The function is similar as that has been defined in section 5.1.2.2. 636 The only difference is that instead of retrieving the TLV values, 637 this function retrieves the argument. 639 5.3. DetNet SID Based SRv6 Data Plane Solution 641 5.3.1. Encapulation 643 A non-forwarding DetNet SID is defined to carry Flow Identification 644 and Sequence Number. 646 0 1 2 3 647 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 648 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 649 | Next Header | Hdr Ext Len | Routing Type | Segment Left | 650 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 651 | Last Entry | Flags | Tag | 652 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 653 | | 654 | Location & Function | 655 | (Segment List[0] for relay node or edge node) | 656 | | 657 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 658 | ... | 659 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 660 | | 661 | Segment List[n] | 662 | | 663 | | 664 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 665 | | 666 | DetNet SID | 667 | | 668 | | 669 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 670 | Optional TLVs | 671 | ... | 672 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 674 5.3.2. Functions 676 TBD 678 6. SRv6 DetNet Data Plane Solution for Transport Sub-layer 680 TBD 682 7. IANA Considerations 684 TBD 686 8. Security Considerations 688 TBD 690 9. Acknowledgements 692 Thank you for valuable comments from James Guichard and Andrew Mails. 694 10. Normative References 696 [I-D.filsfils-spring-srv6-network-programming] 697 Filsfils, C., Camarillo, P., Leddy, J., 698 daniel.voyer@bell.ca, d., Matsushima, S., and Z. Li, "SRv6 699 Network Programming", draft-filsfils-spring-srv6-network- 700 programming-07 (work in progress), February 2019. 702 [I-D.ietf-6man-segment-routing-header] 703 Filsfils, C., Dukes, D., Previdi, S., Leddy, J., 704 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 705 (SRH)", draft-ietf-6man-segment-routing-header-26 (work in 706 progress), October 2019. 708 [I-D.ietf-detnet-architecture] 709 Finn, N., Thubert, P., Varga, B., and J. Farkas, 710 "Deterministic Networking Architecture", draft-ietf- 711 detnet-architecture-13 (work in progress), May 2019. 713 [I-D.ietf-detnet-dp-sol-mpls] 714 Korhonen, J. and B. Varga, "DetNet MPLS Data Plane 715 Encapsulation", draft-ietf-detnet-dp-sol-mpls-02 (work in 716 progress), March 2019. 718 [I-D.ietf-spring-segment-routing-policy] 719 Filsfils, C., Sivabalan, S., Voyer, D., Bogdanov, A., and 720 P. Mattes, "Segment Routing Policy Architecture", draft- 721 ietf-spring-segment-routing-policy-06 (work in progress), 722 December 2019. 724 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 725 Requirement Levels", BCP 14, RFC 2119, 726 DOI 10.17487/RFC2119, March 1997, 727 . 729 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 730 Decraene, B., Litkowski, S., and R. Shakir, "Segment 731 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 732 July 2018, . 734 Authors' Addresses 736 Xuesong Geng 737 Huawei 739 Email: gengxuesong@huawei.com 741 Mach(Guoyi) Chen 742 Huawei 744 Email: mach.chen@huawei.com 746 Yongqing Zhu 747 China Telecom 749 Email: zhuyq@gsta.com