idnits 2.17.1 draft-malis-detnet-ip-dp-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 (March 05, 2018) is 2237 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-04) exists of draft-ietf-detnet-dp-sol-01 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-mpls-12 == Outdated reference: A later version (-13) exists of draft-ietf-detnet-architecture-04 == Outdated reference: A later version (-16) exists of draft-ietf-detnet-security-01 Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DetNet Working Group A. Malis 3 Internet-Draft S. Bryant 4 Intended status: Standards Track M. Chen 5 Expires: September 6, 2018 Huawei Technologies 6 B. Varga 7 Ericsson 8 March 05, 2018 10 DetNet IP Encapsulation 11 draft-malis-detnet-ip-dp-00 13 Abstract 15 This document specifies Deterministic Networking data plane operation 16 over an IP network. It is primarily aimed at IPv4, but would work 17 with IPv6 as well if a unified solution is desired. 19 This document is a derivative work from draft-ietf-detnet-dp-sol-01, 20 to augment or replace the text currently contained in section 5.2.2. 22 Whether this is published as a stand-alone text, or serves as a focal 23 point to refine the IP design and subsequently remerged with draft- 24 ietf-detnet-dp-sol-01 is a matter for the DETNET WG. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on September 6, 2018. 43 Copyright Notice 45 Copyright (c) 2018 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2.1. Terms used in this document . . . . . . . . . . . . . . . 3 63 2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3 64 3. Requirements language . . . . . . . . . . . . . . . . . . . . 3 65 4. DetNet Over an IP Network . . . . . . . . . . . . . . . . . . 3 66 5. DetNet over IP Encapsulation . . . . . . . . . . . . . . . . 5 67 6. Security considerations . . . . . . . . . . . . . . . . . . . 7 68 7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 7 69 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 70 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 71 9.1. Normative References . . . . . . . . . . . . . . . . . . 7 72 9.2. Informative References . . . . . . . . . . . . . . . . . 8 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 75 1. Introduction 77 This document is a derivative work from [I-D.ietf-detnet-dp-sol]. 79 Whether this is published as a stand-alone text, or serves as a focal 80 point to refine the IP design and subsequently remerged with draft- 81 ietf-detnet-dp-sol-01 is a matter for the DetNet WG. 83 Deterministic Networking (DetNet) is a service that can be offered by 84 a network to DetNet flows. DetNet provides these flows extremely low 85 packet loss rates and assured maximum end-to-end delivery latency. 86 General background and concepts of DetNet can be found in 87 [I-D.ietf-detnet-architecture]. 89 This document specifies the encapsulation and operation of 90 deterministic networking over an IP data-plane. The approach is 91 modeled on the operation of PseudoWires (PW) over an IP Packet 92 Switched Network (PSN) [RFC3985][RFC4385][RFC7510]. 94 It is based on the "simplified model" discussed during the DetNet 95 Interim Meeting held on 14 February 2018 97 [http://etherpad.tools.ietf.org:9000/p/notes-ietf-interim-2018- 98 detnet-03]. 100 It is also based on the MPLS encapsulation described in draft-bryant- 101 detnet-mpls-dp (this reference to be updated once draft is 102 available). 104 The DetNet transport layer functionality that provides congestion 105 protection for DetNet flows is assumed to be in place in a DetNet 106 node. 108 This document does not currently define the associated control plane 109 functions, or Operations, Administration, and Maintenance (OAM). It 110 also does not currently specify traffic handling capabilities 111 required to deliver congestion protection and latency control for 112 DetNet flows at the DetNet transport layer. These aspects may be 113 included in future revisions of this draft, or in other DetNet 114 documents. 116 2. Terminology 118 2.1. Terms used in this document 120 This document uses the same terminology as [I-D.ietf-detnet-dp-sol]. 121 Please see that document for the definitions. 123 2.2. Abbreviations 125 This document uses the same abbreviations as 126 [I-D.ietf-detnet-dp-sol]. Please see that document for the list of 127 abbreviations. 129 3. Requirements language 131 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 132 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 133 document are to be interpreted as described in [RFC2119]. 135 4. DetNet Over an IP Network 137 The "simplified model" of DetNet, as discussed during the interim 138 meeting, is carried over an IP network is shown in Figure 1: 140 DetNet Edge Transit Relay Edge DetNet 141 End Sys Node Node Node Node End Sys 143 +-----+ End to End Service +-----+ 144 |Appln|<..............................................>|Appln| 145 +-----+ +---------+ DN Flow +---------+ +---------+ +-----+ 146 | TSN | | Service |<------->| Service |--| Service | | TSN | 147 +-----+ +---+ +---+ +-----+ +---+ +---+ +---+ +---+ +-----+ 148 |DNXpt| |Xpt| |Xpt| |IPXpt| |Xpt| |Xpt| |Xpt| |Xpt| |DNXpt| 149 +--.--+ +-.-+ +-.-+ +-.-.-+ +-.-+ +-.-+ +-.-+ +-.-+ +--.--+ 150 : : : : :Link : :Link : : : 151 +-------+ /-------\+-----+ +------+ /-------\ 152 TSN |Sub N/W| |TSN N/W| 153 Link \-------/ \-------/ 155 Figure 1: Simplified Model of a DetNet Enabled Network 157 In this figure, "DNXpt" and "Xpt" are abbreviations for "DetNet 158 Transport" and "IPXpt" is an abbreviation for "IP Transport". 160 DetNet End Systems sent and receive packets over the DetNet. The 161 supported packet types are IP and Ethernet. 163 Note that in the Simplified Model, while the DetNet service is end- 164 to-end, the End Systems are not DetNet-aware and do not include 165 DetNet information to their packet headers. Rather, the packets 166 between the End Systems and the Edge Nodes may typically consist of 167 application information, L4 Transport (such as TCP or UDP), IP, and 168 Ethernet headers, transmitted over a TSN link or (sub)-Network 169 between the End System and the Edge Node. 171 Alternatively, the packets could contain Ethernet-native 172 applications, with the application information directly encapsulated 173 within Ethernet without L4 Transport or IP headers. 175 Because the End Systems are not DetNet-aware, Edge Nodes are 176 responsible for the imposition and disposition of the required DetNet 177 encapsulation. This functionality is similar to that in pseudowire 178 (PW) Provider Edge (PE) routers. 180 Relay Nodes are also strategically placed and used enhance the 181 reliability of delivery by enabling the DetNet-layer replication of 182 packets so that multiple copies, possibly over multiple paths. They 183 also reduce the impact of replication by the eliminating surplus 184 copies of DetNet packets. These functions may not be performed in 185 End Systems, as they are not DetNet-aware. 187 Relay Nodes are aware of the needs of particular DetNet flows and 188 take care to process them in accordance with the required performance 189 needs. 191 Transit nodes are normal IP routers. They are unaware of DetNet 192 flows per se, although they may be configured to provide congestion 193 protection and delay control in order to meet the required DetNet 194 service level agreement (SLA) via non-DetNet-specific means (IP 195 traffic engineering, queuing mechanisms based on DiffServ markings, 196 etc.). 198 5. DetNet over IP Encapsulation 200 To carry DetNet over IP the following is required: 202 1. A method of identifying the DetNet flow to the processing 203 element. 205 2. A method of carrying the DetNet sequence number. 207 These latter two pieces of information are already carried in the 208 DetNet over MPLS Encapsulation, as shown in Figure 1, where the 209 Control Word contains a 28-bit sequence number, and the S-Label is 210 used to identify the particular flow. 212 +---------------------------------+ 213 | | 214 | DetNet Flow | 215 | Payload Packet | 216 | | 217 +---------------------------------+ <--\ 218 | DetNet Control Word | | 219 +---------------------------------+ +--> DetNet data plane 220 | S-Label | | MPLS encapsulation 221 +---------------------------------+ <--/ 222 | T-Label(s) | 223 +---------------------------------+ 225 Figure 2: MPLS Encapsulation of DetNet 227 To simplify operations and implementations, rather than inventing a 228 brand new encapsulation, the IP encapsulation can take advantage of 229 the MPLS encapsulation. By using the specification of MPLS over UDP 230 and IP in [RFC7510], the T-Label(s) in Figure 2 can be replaced by 231 UDP and IP, resulting in the following encapsulation: 233 +---------------------------------+ 234 | | 235 | DetNet Flow | 236 | Payload Packet | 237 | | 238 +---------------------------------+ <--\ 239 | DetNet Control Word | | 240 +---------------------------------+ +--> DetNet data plane 241 | S-Label | | MPLS encapsulation 242 +---------------------------------+ <--/ 243 | UDP Header | 244 +---------------------------------+ 245 | IP Header | 246 +---------------------------------+ 248 Figure 3: IP Encapsulation of DetNet 250 Where the UDP header is used as defined in Section 3 of [RFC7510]. 252 In ingress Edge Nodes, the encapsulation in Figure 3 will be imposed 253 on Detnet Flow Payload Packets as received from DetNet End Systems, 254 and the encapsulation will be removed in egress Edge Nodes as they 255 transmit the Payload Packets to the End Systems. 257 Note that this encapsulation works equally well with IPv4 and IPv6. 259 This encapsulation can also be used in conjunction with segment 260 routing as specified in [I-D.ietf-spring-segment-routing-mpls]. In 261 this case, the T-Label(s) in Figure 2 should be retained, and at each 262 hop, the top T-label is popped and mapped to a corresponding UDP/IP 263 tunnel, resulting in the following encapsulation: 265 +---------------------------------+ 266 | | 267 | DetNet Flow | 268 | Payload Packet | 269 | | 270 +---------------------------------+ <--\ 271 | DetNet Control Word | | 272 +---------------------------------+ +--> DetNet data plane 273 | S-Label | | MPLS encapsulation 274 +---------------------------------+ <--/ 275 | T-Label(s) | 276 +---------------------------------+ 277 | UDP Header | 278 +---------------------------------+ 279 | IP Header | 280 +---------------------------------+ 282 Figure 4: IP Encapsulation of DetNet with MPLS-SR 284 Again, the UDP header is used as defined in Section 3 of [RFC7510]. 286 6. Security considerations 288 The security considerations of DetNet in general are discussed in 289 [I-D.ietf-detnet-security]. Other security considerations will be 290 added in a future version of this draft. 292 7. IANA considerations 294 This document makes no IANA requests. 296 8. Acknowledgements 298 9. References 300 9.1. Normative References 302 [I-D.ietf-detnet-dp-sol] 303 Korhonen, J., Andersson, L., Jiang, Y., Finn, N., Varga, 304 B., Farkas, J., Bernardos, C., Mizrahi, T., and L. Berger, 305 "DetNet Data Plane Encapsulation", draft-ietf-detnet-dp- 306 sol-01 (work in progress), January 2018. 308 [I-D.ietf-spring-segment-routing-mpls] 309 Bashandy, A., Filsfils, C., Previdi, S., Decraene, B., 310 Litkowski, S., and R. Shakir, "Segment Routing with MPLS 311 data plane", draft-ietf-spring-segment-routing-mpls-12 312 (work in progress), February 2018. 314 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 315 Requirement Levels", BCP 14, RFC 2119, 316 DOI 10.17487/RFC2119, March 1997, 317 . 319 [RFC7510] Xu, X., Sheth, N., Yong, L., Callon, R., and D. Black, 320 "Encapsulating MPLS in UDP", RFC 7510, 321 DOI 10.17487/RFC7510, April 2015, 322 . 324 9.2. Informative References 326 [I-D.ietf-detnet-architecture] 327 Finn, N., Thubert, P., Varga, B., and J. Farkas, 328 "Deterministic Networking Architecture", draft-ietf- 329 detnet-architecture-04 (work in progress), October 2017. 331 [I-D.ietf-detnet-security] 332 Mizrahi, T., Grossman, E., Hacker, A., Das, S., Dowdell, 333 J., Austad, H., Stanton, K., and N. Finn, "Deterministic 334 Networking (DetNet) Security Considerations", draft-ietf- 335 detnet-security-01 (work in progress), October 2017. 337 [RFC3985] Bryant, S., Ed. and P. Pate, Ed., "Pseudo Wire Emulation 338 Edge-to-Edge (PWE3) Architecture", RFC 3985, 339 DOI 10.17487/RFC3985, March 2005, 340 . 342 [RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, 343 "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for 344 Use over an MPLS PSN", RFC 4385, DOI 10.17487/RFC4385, 345 February 2006, . 347 Authors' Addresses 349 Andrew G. Malis 350 Huawei Technologies 352 Email: agmalis@gmail.com 354 Stewart Bryant 355 Huawei Technologies 357 Email: stewart.bryant@gmail.com 358 Mach Chen 359 Huawei Technologies 361 Email: mach.chen@huawei.com 363 Balazs Varga 364 Ericsson 366 Email: balazs.a.varga@ericsson.com