idnits 2.17.00 (12 Aug 2021)
/tmp/idnits43597/draft-ietf-detnet-ip-over-tsn-07.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 (February 19, 2021) is 449 days in the past. Is this
intentional?
Checking references for intended status: Informational
----------------------------------------------------------------------------
== Outdated reference: draft-ietf-detnet-security has been published as RFC
9055
Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 DetNet B. Varga, Ed.
3 Internet-Draft J. Farkas
4 Intended status: Informational Ericsson
5 Expires: August 23, 2021 A. Malis
6 Malis Consulting
7 S. Bryant
8 Futurewei Technologies
9 February 19, 2021
11 DetNet Data Plane: IP over IEEE 802.1 Time Sensitive Networking (TSN)
12 draft-ietf-detnet-ip-over-tsn-07
14 Abstract
16 This document specifies the Deterministic Networking IP data plane
17 when operating over a TSN sub-network. This document does not define
18 new procedures or processes. Whenever this document makes statements
19 or recommendations, these are taken from normative text in the
20 referenced RFCs.
22 Status of This Memo
24 This Internet-Draft is submitted in full conformance with the
25 provisions of BCP 78 and BCP 79.
27 Internet-Drafts are working documents of the Internet Engineering
28 Task Force (IETF). Note that other groups may also distribute
29 working documents as Internet-Drafts. The list of current Internet-
30 Drafts is at https://datatracker.ietf.org/drafts/current/.
32 Internet-Drafts are draft documents valid for a maximum of six months
33 and may be updated, replaced, or obsoleted by other documents at any
34 time. It is inappropriate to use Internet-Drafts as reference
35 material or to cite them other than as "work in progress."
37 This Internet-Draft will expire on August 23, 2021.
39 Copyright Notice
41 Copyright (c) 2021 IETF Trust and the persons identified as the
42 document authors. All rights reserved.
44 This document is subject to BCP 78 and the IETF Trust's Legal
45 Provisions Relating to IETF Documents
46 (https://trustee.ietf.org/license-info) in effect on the date of
47 publication of this document. Please review these documents
48 carefully, as they describe your rights and restrictions with respect
49 to this document. Code Components extracted from this document must
50 include Simplified BSD License text as described in Section 4.e of
51 the Trust Legal Provisions and are provided without warranty as
52 described in the Simplified BSD License.
54 Table of Contents
56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
58 2.1. Terms Used In This Document . . . . . . . . . . . . . . . 3
59 2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3
60 3. DetNet IP Data Plane Overview . . . . . . . . . . . . . . . . 3
61 4. DetNet IP Flows over an IEEE 802.1 TSN sub-network . . . . 4
62 4.1. Functions for DetNet Flow to TSN Stream Mapping . . . . . 5
63 4.2. TSN requirements of IP DetNet nodes . . . . . . . . . . . 6
64 4.3. Service protection within the TSN sub-network . . . . . . 7
65 4.4. Aggregation during DetNet flow to TSN Stream mapping . . 7
66 5. Management and Control Implications . . . . . . . . . . . . . 7
67 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
68 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
69 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
70 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
71 9.1. Normative references . . . . . . . . . . . . . . . . . . 10
72 9.2. Informative references . . . . . . . . . . . . . . . . . 10
73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
75 1. Introduction
77 Deterministic Networking (DetNet) is a service that can be offered by
78 a network to DetNet flows. DetNet provides these flows extremely low
79 packet loss rates and assured maximum end-to-end delivery latency.
80 General background and concepts of DetNet can be found in the DetNet
81 Architecture [RFC8655].
83 [RFC8939] specifies the DetNet data plane operation for IP hosts and
84 routers that provide DetNet service to IP encapsulated data. This
85 document focuses on the scenario where DetNet IP nodes are
86 interconnected by a TSN sub-network.
88 The DetNet Architecture decomposes the DetNet related data plane
89 functions into two sub-layers: a service sub-layer and a forwarding
90 sub-layer. The service sub-layer is used to provide DetNet service
91 protection and reordering. The forwarding sub-layer is used to
92 provides congestion protection (low loss, assured latency, and
93 limited reordering). As described in [RFC8939] no DetNet specific
94 headers are added to support DetNet IP flows. So, only the
95 forwarding sub-layer functions can be supported inside the DetNet IP
96 domain. Service protection can be provided on a per sub-network
97 basis as shown here for the IEEE802.1 TSN sub-network scenario.
99 2. Terminology
101 2.1. Terms Used In This Document
103 This document uses the terminology and concepts established in the
104 DetNet architecture [RFC8655]. TSN (Time-Sensitive Networking)
105 specific terms are defined in the TSN TG of IEEE 802.1 Working Group.
106 The reader is assumed to be familiar with these documents and their
107 terminology.
109 2.2. Abbreviations
111 The following abbreviations used in this document:
113 DetNet Deterministic Networking.
115 FRER Frame Replication and Elimination for Redundancy (TSN
116 function).
118 L2 Layer-2.
120 L3 Layer-3.
122 TSN Time-Sensitive Networking, TSN is a Task Group of the
123 IEEE 802.1 Working Group.
125 3. DetNet IP Data Plane Overview
127 [RFC8939] describes how IP is used by DetNet nodes, i.e., hosts and
128 routers, to identify DetNet flows and provide a DetNet service. From
129 a data plane perspective, an end-to-end IP model is followed. DetNet
130 uses "6-tuple" based flow identification, where "6-tuple" refers to
131 information carried in IP and higher layer protocol headers as
132 defined in [RFC8939]. .
134 DetNet flow aggregation may be enabled via the use of wildcards,
135 masks, prefixes and ranges. IP tunnels may also be used to support
136 flow aggregation. In these cases, it is expected that DetNet aware
137 intermediate nodes will provide DetNet service assurance on the
138 aggregate through resource allocation and congestion control
139 mechanisms.
141 Congestion protection, latency control and the resource allocation
142 (queuing, policing, shaping) are supported using the underlying link
143 / sub-net specific mechanisms. Service protections (packet
144 replication and packet elimination functions) are not provided at the
145 IP DetNet layer end-to-end due to the lack of a unified end-to-end
146 sequencing information that would be available for intermediate
147 nodes. However, such service protection can be provided on a per
148 underlying L2 link and sub-network basis.
150 DetNet routers ensure that DetNet service requirements are met per
151 hop by allocating local resources, both receive and transmit, and by
152 mapping the service requirements of each flow to appropriate sub-
153 network mechanisms. Such mappings are sub-network technology
154 specific. DetNet nodes interconnected by a TSN sub-network are the
155 primary focus of this document. The mapping of DetNet IP flows to
156 TSN streams and TSN protection mechanisms are covered in Section 4.
158 4. DetNet IP Flows over an IEEE 802.1 TSN sub-network
160 This section covers how DetNet IP flows operate over an IEEE 802.1
161 TSN sub-network. Figure 1 illustrates such a scenario, where two IP
162 (DetNet) nodes are interconnected by a TSN sub-network. Dotted lines
163 around the Service components of the IP (DetNet) Nodes indicate that
164 they are DetNet service aware but do not perform any DetNet service
165 sub-layer function. Node-1 is single homed and Node-2 is dual-homed
166 to the TSN sub-network and they are treated as Talker or Listener
167 inside the TSN sub-network. Note, that from TSN perspective dual-
168 homed characteristics of Talker or Listener nodes are transparent to
169 the IP Layer.
171 IP (DetNet) IP (DetNet)
172 Node-1 Node-2
174 ............ ............
175 <--: Service :-- DetNet flow ---: Service :-->
176 +----------+ +----------+
177 |Forwarding| |Forwarding|
178 +--------.-+ <-TSN Str-> +-.-----.--+
179 \ ,-------. / /
180 +----[ TSN-Sub ]---+ /
181 [ Network ]--------+
182 `-------'
183 <----------------- DetNet IP ----------------->
185 Figure 1: DetNet (DN) Enabled IP Network over a TSN sub-network
187 At the time of this writing, the Time-Sensitive Networking (TSN) Task
188 Group of the IEEE 802.1 Working Group have defined (and are defining)
189 a number of amendments to [IEEE8021Q] that provide zero congestion
190 loss and bounded latency in bridged networks. Furthermore,
191 [IEEE8021CB] defines frame replication and elimination functions for
192 reliability that should prove both compatible with and useful to
193 DetNet networks. All these functions have to identify flows that
194 require TSN treatment.
196 TSN capabilities of the TSN sub-network are made available for IP
197 (DetNet) flows via the protocol interworking function described in
198 Annex C.5 of [IEEE8021CB]. For example, applied on the TSN edge port
199 it can convert an ingress unicast IP (DetNet) flow to use a specific
200 L2 multicast destination MAC address and a VLAN, in order to forward
201 the packet through a specific path inside the bridged network. A
202 similar interworking function pair at the other end of the TSN sub-
203 network would restore the packet to its original L2 destination MAC
204 address and VLAN.
206 Placement of TSN functions depends on the TSN capabilities of nodes.
207 IP (DetNet) Nodes may or may not support TSN functions. For a given
208 TSN Stream (i.e., a mapped DetNet flow) an IP (DetNet) node is
209 treated as a Talker or a Listener inside the TSN sub-network.
211 4.1. Functions for DetNet Flow to TSN Stream Mapping
213 Mapping of a DetNet IP flow to a TSN Stream is provided via the
214 combination of a passive and an active stream identification function
215 that operate at the frame level (Layer-2). The passive stream
216 identification function is used to catch the 6-tuple of a DetNet IP
217 flow and the active stream identification function is used to modify
218 the Ethernet header according to the ID of the mapped TSN Stream.
220 Clause 6.7 of [IEEE8021CB] defines an IP Stream identification
221 function that can be used as a passive function for IP DetNet flows
222 using UDP or TCP. Clause 6.8 of [IEEEP8021CBdb] defines a Mask-and-
223 Match Stream identification function that can be used as a passive
224 function for any IP DetNet flows.
226 Clause 6.6 of [IEEE8021CB] defines an Active Destination MAC and VLAN
227 Stream identification function, what can replace some Ethernet header
228 fields namely (1) the destination MAC-address, (2) the VLAN-ID and
229 (3) priority parameters with alternate values. Replacement is
230 provided for the frame passed down the stack from the upper layers or
231 up the stack from the lower layers.
233 Active Destination MAC and VLAN Stream identification can be used
234 within a Talker to set flow identity or a Listener to recover the
235 original addressing information. It can be used also in a TSN bridge
236 that is providing translation as a proxy service for an End System.
238 4.2. TSN requirements of IP DetNet nodes
240 This section covers the required behavior of a TSN-aware DetNet node
241 using a TSN sub-network. The implementation of TSN packet processing
242 functions must be compliant with the relevant IEEE 802.1 standards.
244 From the TSN sub-network perspective DetNet IP nodes are treated as
245 Talker or Listener, that may be (1) TSN-unaware or (2) TSN-aware.
247 In cases of TSN-unaware IP DetNet nodes the TSN relay nodes within
248 the TSN sub-network must modify the Ethernet encapsulation of the
249 DetNet IP flow (e.g., MAC translation, VLAN-ID setting, Sequence
250 number addition, etc.) to allow proper TSN specific handling inside
251 the sub-network. There are no requirements defined for TSN-unaware
252 IP DetNet nodes in this document.
254 IP (DetNet) nodes being TSN-aware can be treated as a combination of
255 a TSN-unaware Talker/Listener and a TSN-Relay, as shown in Figure 2.
256 In such cases the IP (DetNet) node must provide the TSN sub-network
257 specific Ethernet encapsulation over the link(s) towards the sub-
258 network.
260 IP (DetNet)
261 Node
262 <---------------------------------->
264 ............
265 <--: Service :-- DetNet flow ------------------
266 +----------+
267 |Forwarding|
268 +----------+ +---------------+
269 | L2 | | L2 Relay with |<--- TSN ---
270 | | | TSN function | Stream
271 +-----.----+ +--.------.---.-+
272 \__________/ \ \______
273 \_________
274 TSN-unaware
275 Talker / TSN-Bridge
276 Listener Relay
277 <----- TSN Sub-network -----
278 <------- TSN-aware Tlk/Lstn ------->
280 Figure 2: IP (DetNet) node with TSN functions
282 A TSN-aware IP (DetNet) node impementations must support the Stream
283 Identification TSN component for recognizing flows.
285 A Stream identification component must be able to instantiate the
286 following functions (1) Active Destination MAC and VLAN Stream
287 identification function, (2) IP Stream identification function, (3)
288 Mask-and-Match Stream identification function and (4) the related
289 managed objects in Clause 9 of [IEEE8021CB] and [IEEEP8021CBdb].
291 A TSN-aware IP (DetNet) node implementation must support the
292 Sequencing function and the Sequence encode/decode function as
293 defined in Clause 7.4 and 7.6 of [IEEE8021CB] if FRER is used inside
294 the TSN sub-network.
296 The Sequence encode/decode function must support the Redundancy tag
297 (R-TAG) format as per Clause 7.8 of [IEEE8021CB].
299 A TSN-aware IP (DetNet) node implementations must support the Stream
300 splitting function and the Individual recovery function as defined in
301 Clause 7.7 and 7.5 of [IEEE8021CB] when the node is a replication or
302 elimination point for FRER.
304 4.3. Service protection within the TSN sub-network
306 TSN Streams supporting DetNet flows may use Frame Replication and
307 Elimination for Redundancy (FRER) as defined in Clause 8. of
308 [IEEE8021CB] based on the loss service requirements of the TSN
309 Stream, which is derived from the DetNet service requirements of the
310 DetNet mapped flow. The specific operation of FRER is not modified
311 by the use of DetNet and follows [IEEE8021CB].
313 FRER function and the provided service recovery is available only
314 within the TSN sub-network as the TSN Stream-ID and the TSN sequence
315 number are not valid outside the sub-network. An IP (DetNet) node
316 represents a L3 border and as such it terminates all related
317 information elements encoded in the L2 frames.
319 4.4. Aggregation during DetNet flow to TSN Stream mapping
321 Implementations of this document shall use management and control
322 information to map a DetNet flow to a TSN Stream. N:1 mapping
323 (aggregating DetNet flows in a single TSN Stream) shall be supported.
324 The management or control function that provisions flow mapping shall
325 ensure that adequate resources are allocated and configured to
326 provide proper service requirements of the mapped flows.
328 5. Management and Control Implications
330 DetNet flow and TSN Stream mapping related information are required
331 only for TSN-aware IP (DetNet) nodes. From the Data Plane
332 perspective there is no practical difference based on the origin of
333 flow mapping related information (management plane or control plane).
335 The following summarizes the set of information that is needed to
336 configure DetNet IP over TSN:
338 o DetNet IP related configuration information according to the
339 DetNet role of the DetNet IP node, as per [RFC8939].
341 o TSN related configuration information according to the TSN role of
342 the DetNet IP node, as per [IEEE8021Q], [IEEE8021CB] and
343 [IEEEP8021CBdb].
345 o Mapping between DetNet IP flow(s) and TSN Stream(s). DetNet IP
346 flow identification is summarized in Section 5.1 of [RFC8939], and
347 includes all wildcards, port ranges and the ability to ignore
348 specific IP fields). For TSN Streams stream identification
349 information are defined in [IEEE8021CB] and [IEEEP8021CBdb]).
350 Note, that managed objects for TSN Stream identification can be
351 found in [IEEEP8021CBcv].
353 This information must be provisioned per DetNet flow.
355 Mappings between DetNet and TSN management and control planes are out
356 of scope of this document. Some of the challenges are highligthed
357 below.
359 TSN-aware IP DetNet nodes are members of both the DetNet domain and
360 the TSN sub-network. Within the TSN sub-network the TSN-aware IP
361 (DetNet) node has a TSN-aware Talker/Listener role, so TSN specific
362 management and control plane functionalities must be implemented.
363 There are many similarities in the management plane techniques used
364 in DetNet and TSN, but that is not the case for the control plane
365 protocols. For example, RSVP-TE and MSRP behaves differently.
366 Therefore management and control plane design is an important aspect
367 of scenarios, where mapping between DetNet and TSN is required.
369 In order to use a TSN sub-network between DetNet nodes, DetNet
370 specific information must be converted to TSN sub-network specific
371 ones. DetNet flow ID and flow related parameters/requirements must
372 be converted to a TSN Stream ID and stream related parameters/
373 requirements. Note that, as the TSN sub-network is just a portion of
374 the end-to-end DetNet path (i.e., single hop from IP perspective),
375 some parameters (e.g., delay) may differ significantly. Other
376 parameters (like bandwidth) also may have to be tuned due to the L2
377 encapsulation used within the TSN sub-network.
379 In some cases it may be challenging to determine some TSN Stream
380 related information. For example, on a TSN-aware IP (DetNet) node
381 that acts as a Talker, it is quite obvious which DetNet node is the
382 Listener of the mapped TSN stream (i.e., the IP Next-Hop). However
383 it may be not trivial to locate the point/interface where that
384 Listener is connected to the TSN sub-network. Such attributes may
385 require interaction between control and management plane functions
386 and between DetNet and TSN domains.
388 Mapping between DetNet flow identifiers and TSN Stream identifiers,
389 if not provided explicitly, can be done by a TSN-aware IP (DetNet)
390 node locally based on information provided for configuration of the
391 TSN Stream identification functions (IP Stream identification, Mask-
392 and-match Stream identification and active Stream identification
393 function).
395 Triggering the setup/modification of a TSN Stream in the TSN sub-
396 network is an example where management and/or control plane
397 interactions are required between the DetNet and TSN sub-network.
398 TSN-unaware IP (DetNet) nodes make such a triggering even more
399 complicated as they are fully unaware of the sub-network and run
400 independently.
402 Configuration of TSN specific functions (e.g., FRER) inside the TSN
403 sub-network is a TSN domain specific decision and may not be visible
404 in the DetNet domain.
406 6. Security Considerations
408 Security considerations for DetNet are described in detail in
409 [I-D.ietf-detnet-security]. General security considerations are
410 described in [RFC8655]. DetNet IP data plane specific considerations
411 are summarized in [RFC8939]. This section considers exclusively
412 security considerations which are specific to the DetNet IP over TSN
413 sub-network scenario.
415 The sub-network between DetNet nodes needs to be subject to
416 appropriate confidentiality. Additionally, knowledge of what DetNet/
417 TSN services are provided by a sub-network may supply information
418 that can be used in a variety of security attacks. The ability to
419 modify information exchanges between connected DetNet nodes may
420 result in bogus operations. Therefore, it is important that the
421 interface between DetNet nodes and TSN sub-network are subject to
422 authorization, authentication, and encryption.
424 The TSN sub-network operates at Layer-2 so various security
425 mechanisms defined by IEEE can be used to secure the connection
426 between the DetNet nodes (e.g., encryption may be provided using
427 MACSec [IEEE802.1AE-2018]).
429 7. IANA Considerations
431 None.
433 8. Acknowledgements
435 The authors wish to thank Norman Finn, Lou Berger, Craig Gunther,
436 Christophe Mangin and Jouni Korhonen for their various contributions
437 to this work.
439 9. References
441 9.1. Normative references
443 [IEEE8021CB]
444 IEEE 802.1, "Standard for Local and metropolitan area
445 networks - Frame Replication and Elimination for
446 Reliability (IEEE Std 802.1CB-2017)", 2017,
447 .
449 [IEEEP8021CBdb]
450 Mangin, C., "Extended Stream identification functions",
451 IEEE P802.1CBdb /D1.0 P802.1CBdb, September 2020,
452 .
455 [RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas,
456 "Deterministic Networking Architecture", RFC 8655,
457 DOI 10.17487/RFC8655, October 2019,
458 .
460 [RFC8939] Varga, B., Ed., Farkas, J., Berger, L., Fedyk, D., and S.
461 Bryant, "Deterministic Networking (DetNet) Data Plane:
462 IP", RFC 8939, DOI 10.17487/RFC8939, November 2020,
463 .
465 9.2. Informative references
467 [I-D.ietf-detnet-security]
468 Grossman, E., Mizrahi, T., and A. Hacker, "Deterministic
469 Networking (DetNet) Security Considerations", draft-ietf-
470 detnet-security-13 (work in progress), December 2020.
472 [IEEE802.1AE-2018]
473 IEEE Standards Association, "IEEE Std 802.1AE-2018 MAC
474 Security (MACsec)", 2018,
475 .
477 [IEEE8021Q]
478 IEEE 802.1, "Standard for Local and metropolitan area
479 networks--Bridges and Bridged Networks (IEEE Std 802.1Q-
480 2018)", 2018, .
482 [IEEEP8021CBcv]
483 Kehrer, S., "FRER YANG Data Model and Management
484 Information Base Module", IEEE P802.1CBcv
485 /D0.4 P802.1CBcv, August 2020,
486 .
489 Authors' Addresses
491 Balazs Varga (editor)
492 Ericsson
493 Magyar Tudosok krt. 11.
494 Budapest 1117
495 Hungary
497 Email: balazs.a.varga@ericsson.com
499 Janos Farkas
500 Ericsson
501 Magyar Tudosok krt. 11.
502 Budapest 1117
503 Hungary
505 Email: janos.farkas@ericsson.com
507 Andrew G. Malis
508 Malis Consulting
510 Email: agmalis@gmail.com
512 Stewart Bryant
513 Futurewei Technologies
515 Email: stewart.bryant@gmail.com