idnits 2.17.1 draft-geng-srv6-based-bounded-latency-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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([I-D.chen-detnet-sr-based-bounded-latency]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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 (May 7, 2019) is 1817 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'SL' is mentioned on line 217, but not defined -- Looks like a reference, but probably isn't: '2' on line 132 -- Looks like a reference, but probably isn't: '1' on line 132 -- Looks like a reference, but probably isn't: '0' on line 180 == Unused Reference: 'I-D.filsfils-spring-srv6-network-programming' is defined on line 247, but no explicit reference was found in the text == Outdated reference: A later version (-03) exists of draft-chen-detnet-sr-based-bounded-latency-00 == Outdated reference: A later version (-26) exists of draft-ietf-6man-segment-routing-header-18 == Outdated reference: A later version (-13) exists of draft-ietf-detnet-architecture-12 Summary: 1 error (**), 0 flaws (~~), 7 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. Mach 4 Intended status: Experimental Huawei 5 Expires: November 8, 2019 May 7, 2019 7 SRv6 Based Bounded Latency 8 draft-geng-srv6-based-bounded-latency-00 10 Abstract 12 One of the goals of DetNet is to provide bounded end-to-end latency 13 for critical flows. This document defines how to leverage Segment 14 Routing over IPv6 (SRv6) to implement bounded latency. Specifically, 15 new SRv6 SID function is used to specify transmission time (cycles) 16 of a packet. When forwarding devices along the path follow the 17 instructions carried in the packet, the bounded latency is achieved. 18 This mechanism of latency guarantee is called Cycle Specified Queuing 19 and Forwarding (CSQF) which is defined in 20 [I-D.chen-detnet-sr-based-bounded-latency]. 22 Requirements Language 24 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 25 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 26 document are to be interpreted as described in RFC 2119 [RFC2119]. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on November 8, 2019. 45 Copyright Notice 47 Copyright (c) 2019 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (https://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 2. Terminology and Conventions . . . . . . . . . . . . . . . . . 3 64 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 65 2.2. Conventions . . . . . . . . . . . . . . . . . . . . . . . 3 66 3. SRv6 DetNet Data Plane Overview . . . . . . . . . . . . . . . 4 67 3.1. Encapsulation . . . . . . . . . . . . . . . . . . . . . . 4 68 3.2. Functions . . . . . . . . . . . . . . . . . . . . . . . . 5 69 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 70 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 71 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 72 7. Normative References . . . . . . . . . . . . . . . . . . . . 6 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 75 1. Introduction 77 Deterministic Networking(DetNet) provides a capability to carry 78 specified data flows with extremely low data loss rates and bounded 79 latency within a network domain. DetNet is enabled by a group of 80 technologies, such as resource allocation, service protection and 81 explicit routes.([I-D.ietf-detnet-architecture]) 83 Segment Routing(SR) leverages the source routing paradigm. A ingress 84 node steers a packet through an ordered list of instructions, called 85 "segments". SR can be applied over IPv6 data plane using Routing 86 Extension Header(SRH). Besides routing, the segment of SRv6 can 87 indicate functions which are executed locally in the node where they 88 are defined. SRv6 network programming makes it convenient to add 89 sophisticated operations in the network. ([RFC8402]) 91 This document describes how to implement DetNet with SRv6. It can 92 provide : 1. Source routing, which can steer the DetNet flows go 93 through the network according to an explicit route with allocated 94 resource by segment list in SRH; 2. Network programming, which can 95 give packet instructions in every node along the path to guarantee 96 bounded latency. DetNet SRv6 encapsulation and new SRv6 functions 97 for DetNet are defined in this document. 99 Control plane and OAM are not in the scope of this document. 101 2. Terminology and Conventions 103 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 104 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 105 document are to be interpreted as described in [RFC2119]. 107 2.1. Terminology 109 Terminologies for DetNet go along with the definition in 110 [I-D.ietf-detnet-architecture]. Other terminologies are defined as 111 follows: 113 o NH: The IPv6 next-header field. 115 o SID: A Segment Identifier which represents a specific segment in a 116 segment routing domain([RFC8402]). 118 o SRH: The Segment Routing Header 119 ([I-D.ietf-6man-segment-routing-header]). 121 2.2. Conventions 123 Conventions in the document are defined as follows: 125 o NH=SRH means that NH is 43 with routing type 4. 127 o A SID list is represented as where S1 is the first 128 SID to visit, S2 is the second SID to visit and S3 is the last SID 129 to visit along the SR path. 131 o SRH[SL] represents the SID pointed by the SL field in the first 132 SRH. In our example, SRH[2] represents S1, SRH[1] represents S2 133 and SRH[0] represents S3. 135 o (SA,DA) (S3, S2, S1; SL) represents an IPv6 packet with: 137 IPv6 header with source and destination addresses SA and DA 138 respectively, and next-header SRH, with SID list 139 with SegmentsLeft = SL 140 The payload of the packet is not represented 142 (S3, S2, S1; SL) represents the same SID list as , 143 but encoded in the SRH format where the rightmost SID in the 144 SRH is the first SID and the leftmost SID in the SRH is the 145 last SID 147 3. SRv6 DetNet Data Plane Overview 149 [I-D.chen-detnet-sr-based-bounded-latency] defines a new segment that 150 is called a Cycle SID, which is used to identify a cycle. . 152 A Cycle SID has two meanings: 1) identify an interface/link, just 153 like the adjacency segment does; 2) identify a cycle of the 154 interface/link. To specify to which interface and in which cycle a 155 packet should be transmitted. By attaching a list of Cycle Segments 156 to a packet in SRH, it can not only implement the explicit route of 157 the packet that is required by DetNet [I-D.ietf-detnet-architecture], 158 but also specify the sending cycle at each node along the path 159 without maintaining per-flow states at the intermediate and egress 160 nodes. 162 SRv6 Cycle SID can be represented as LOC:FUNCT:ARG::, where LOC, 163 abbreviated for "LOCATION", directs the explicit route, FUNCT, 164 abbreviated for "FUNCTION", directs the packet processing in the 165 local node, and ARG, abbreviated for "ARGUMENTS", provides the cycle 166 information. New SID functions for DetNet is defined in section 3.2. 168 3.1. Encapsulation 170 The SRH for DetNet in the outer IPv6 header is showed as follows: 172 0 1 2 3 173 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 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 175 | Next Header | Hdr Ext Len | Routing Type | Segment Left | 176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 177 | Last Entry | Flags | Tag | 178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 179 | Location & Function | 180 | (Segment List[0] for transit node with CSQF Function) | 181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 182 | Cycle Information | 183 | | 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 | ... | 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 | | 188 | Segment List[n] | 189 | | 190 | | 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 192 | Optional TLVS | 193 | ... | 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 196 where: 198 o Location&Function: the 64 most significant bits that are used for 199 routing and function indication; 201 o Cycle Information : 64 bits, which are used for indicate the cycle 202 number in which the packet is supposed to transmit through the 203 output port; 205 3.2. Functions 207 New SID functions are defined as follows: 209 End.X.Cycle.Indication 211 1. IF NH=SRH and SL > 0 213 2. decrement SL 215 3. reserve the value of cycle information field 217 4. update the IPv6 DA with SRH[SL] 219 5. forward to layer-3 adjacency bound to the Location 220 6. put the packet in the queue corresponding to the cycle 221 information reserved 223 7. ELSE 225 8. drop the packet 227 4. IANA Considerations 229 This document makes no request of IANA. 231 Note to RFC Editor: this section may be removed on publication as an 232 RFC. 234 5. Security Considerations 236 TBD 238 6. Acknowledgements 240 7. Normative References 242 [I-D.chen-detnet-sr-based-bounded-latency] 243 Chen, M., Geng, X., and Z. Li, "Segment Routing (SR) Based 244 Bounded Latency", draft-chen-detnet-sr-based-bounded- 245 latency-00 (work in progress), October 2018. 247 [I-D.filsfils-spring-srv6-network-programming] 248 Filsfils, C., Camarillo, P., Leddy, J., 249 daniel.voyer@bell.ca, d., Matsushima, S., and Z. Li, "SRv6 250 Network Programming", draft-filsfils-spring-srv6-network- 251 programming-07 (work in progress), February 2019. 253 [I-D.ietf-6man-segment-routing-header] 254 Filsfils, C., Previdi, S., Leddy, J., Matsushima, S., and 255 d. daniel.voyer@bell.ca, "IPv6 Segment Routing Header 256 (SRH)", draft-ietf-6man-segment-routing-header-18 (work in 257 progress), April 2019. 259 [I-D.ietf-detnet-architecture] 260 Finn, N., Thubert, P., Varga, B., and J. Farkas, 261 "Deterministic Networking Architecture", draft-ietf- 262 detnet-architecture-12 (work in progress), March 2019. 264 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 265 Requirement Levels", BCP 14, RFC 2119, 266 DOI 10.17487/RFC2119, March 1997, 267 . 269 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 270 Decraene, B., Litkowski, S., and R. Shakir, "Segment 271 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 272 July 2018, . 274 Authors' Addresses 276 Xuesong Geng 277 Huawei 279 Email: gengxuesong@huawei.com 281 Mach(Guoyi) Chen 282 Huawei 284 Email: mach.chen@huawei.com