idnits 2.17.1
draft-ietf-detnet-tsn-vpn-over-mpls-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 1156 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)
== Missing Reference: 'Network' is mentioned on line 181, but not defined
-- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE8021CB'
-- Possible downref: Non-RFC (?) normative reference: ref. 'IEEEP8021CBdb'
** Downref: Normative reference to an Informational RFC: RFC 8938
== Outdated reference: A later version (-16) exists of
draft-ietf-detnet-security-13
Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 3 comments (--).
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: Standards Track Ericsson
5 Expires: August 23, 2021 A. Malis
6 Malis Consulting
7 S. Bryant
8 Futurewei Technologies
9 D. Fedyk
10 LabN Consulting, L.L.C.
11 February 19, 2021
13 DetNet Data Plane: IEEE 802.1 Time Sensitive Networking over MPLS
14 draft-ietf-detnet-tsn-vpn-over-mpls-07
16 Abstract
18 This document specifies the Deterministic Networking data plane when
19 TSN networks are interconnected over a DetNet MPLS Network.
21 Status of This Memo
23 This Internet-Draft is submitted in full conformance with the
24 provisions of BCP 78 and BCP 79.
26 Internet-Drafts are working documents of the Internet Engineering
27 Task Force (IETF). Note that other groups may also distribute
28 working documents as Internet-Drafts. The list of current Internet-
29 Drafts is at https://datatracker.ietf.org/drafts/current/.
31 Internet-Drafts are draft documents valid for a maximum of six months
32 and may be updated, replaced, or obsoleted by other documents at any
33 time. It is inappropriate to use Internet-Drafts as reference
34 material or to cite them other than as "work in progress."
36 This Internet-Draft will expire on August 23, 2021.
38 Copyright Notice
40 Copyright (c) 2021 IETF Trust and the persons identified as the
41 document authors. All rights reserved.
43 This document is subject to BCP 78 and the IETF Trust's Legal
44 Provisions Relating to IETF Documents
45 (https://trustee.ietf.org/license-info) in effect on the date of
46 publication of this document. Please review these documents
47 carefully, as they describe your rights and restrictions with respect
48 to this document. Code Components extracted from this document must
49 include Simplified BSD License text as described in Section 4.e of
50 the Trust Legal Provisions and are provided without warranty as
51 described in the Simplified BSD License.
53 Table of Contents
55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
57 2.1. Terms Used in This Document . . . . . . . . . . . . . . . 3
58 2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3
59 2.3. Requirements Language . . . . . . . . . . . . . . . . . . 4
60 3. IEEE 802.1 TSN Over DetNet MPLS Data Plane Scenario . . . . . 4
61 4. DetNet MPLS Data Plane . . . . . . . . . . . . . . . . . . . 6
62 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 6
63 4.2. TSN over DetNet MPLS Encapsulation . . . . . . . . . . . 7
64 5. TSN over MPLS Data Plane Procedures . . . . . . . . . . . . . 8
65 5.1. Edge Node TSN Procedures . . . . . . . . . . . . . . . . 8
66 5.2. Edge Node DetNet Service Proxy Procedures . . . . . . . . 9
67 5.3. Edge Node DetNet Service and Forwarding Sub-Layer
68 Procedures . . . . . . . . . . . . . . . . . . . . . . . 10
69 6. Controller Plane (Management and Control) Considerations . . 11
70 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
71 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
72 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
73 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
74 10.1. Normative References . . . . . . . . . . . . . . . . . . 13
75 10.2. Informative References . . . . . . . . . . . . . . . . . 14
76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
78 1. Introduction
80 The Time-Sensitive Networking Task Group (TSN TG) within IEEE 802.1
81 Working Group deals with deterministic services through IEEE 802
82 networks. Deterministic Networking (DetNet) defined by IETF is a
83 service that can be offered by a L3 network to DetNet flows. General
84 background and concepts of DetNet can be found in [RFC8655].
86 This document specifies the use of a DetNet MPLS network to
87 interconnect TSN nodes/network segments. DetNet MPLS data plane is
88 defined in [RFC8964].
90 2. Terminology
92 2.1. Terms Used in This Document
94 This document uses the terminology and concepts established in the
95 DetNet architecture [RFC8655] and [RFC8938], and [RFC8964]. TSN
96 specific terms are defined in the TSN TG of IEEE 802.1 Working Group.
97 The reader is assumed to be familiar with these documents and their
98 terminology.
100 2.2. Abbreviations
102 The following abbreviations are used in this document:
104 AC Attachment Circuit.
106 CE Customer Edge equipment.
108 d-CW DetNet Control Word.
110 DetNet Deterministic Networking.
112 DF DetNet Flow.
114 FRER Frame Replication and Elimination for Redundancy (TSN
115 function).
117 L2 Layer 2.
119 L2VPN Layer 2 Virtual Private Network.
121 L3 Layer 3.
123 LSR Label Switching Router.
125 MPLS Multiprotocol Label Switching.
127 MPLS-TE Multiprotocol Label Switching - Traffic Engineering.
129 NSP Native Service Processing.
131 OAM Operations, Administration, and Maintenance.
133 PE Provider Edge.
135 PREOF Packet Replication, Elimination and Ordering Functions.
137 PW PseudoWire.
139 S-PE Switching Provider Edge.
141 T-PE Terminating Provider Edge.
143 TSN Time-Sensitive Network.
145 2.3. Requirements Language
147 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
148 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
149 "OPTIONAL" in this document are to be interpreted as described in BCP
150 14 [RFC2119] [RFC8174] when, and only when, they appear in all
151 capitals, as shown here.
153 3. IEEE 802.1 TSN Over DetNet MPLS Data Plane Scenario
155 Figure 1 shows IEEE 802.1 TSN end stations operating over a TSN aware
156 DetNet service running over an MPLS network. DetNet Edge Nodes sit
157 at the boundary of a DetNet domain. They are responsible for mapping
158 non-DetNet aware L2 traffic to DetNet services. They also support
159 the imposition and disposition of the required DetNet encapsulation.
160 These are functionally similar to pseudowire (PW) Terminating
161 Provider Edge (T-PE) nodes which use MPLS-TE LSPs. In this example
162 TSN Streams are simple applications over DetNet flows. The specific
163 of this operation are discussed later in this document.
165 TSN Edge Transit Edge TSN
166 End System Node Node Node End System
167 (T-PE) (LSR) (T-PE)
169 +----------+ +----------+
170 | TSN | <---------End to End TSN Service----------> | TSN |
171 | Applic. | | Applic. |
172 +----------+ +.........+ +.........+ +----------+
173 | | | \S-Proxy: :S-Proxy/ | | |
174 | TSN | | +.+---+<-- DetNet flow -->+---+ | | | TSN |
175 | | |TSN| |Svc| |Svc| |TSN| | |
176 +----------+ +---+ +---+ +----------+ +---+ +---+ +----------+
177 | L2 | | L2| |Fwd| |Forwarding| |Fwd| |L2 | | L2 |
178 +------.---+ +-.-+ +-.-+ +---.----.-+ +--.+ +-.-+ +---.------+
179 : Link : / ,-----. \ : Link : / ,-----. \
180 +........+ +-[ Sub ]-+ +........+ +-[ TSN ]-+
181 [Network] [Network]
182 `-----' `-----'
184 |<------ DetNet MPLS ------>|
185 |<---------------------- TSN --------------------->|
187 Figure 1: A TSN over DetNet MPLS Enabled Network
189 In this example, edge nodes provide a service proxy function that
190 "associates" the DetNet flows and native flows (i.e., TSN Streams) at
191 the edge of the DetNet domain. TSN streams are treated as App-flows
192 for DetNet. The whole DetNet domain behaves as a TSN relay node for
193 the TSN streams. The service proxy behaves as a port of that TSN
194 relay node.
196 Figure 2 illustrates how DetNet can provide services for IEEE 802.1
197 TSN end systems, CE1 and CE2, over a DetNet enabled MPLS network.
198 Edge nodes, E1 and E2, insert and remove required DetNet data plane
199 encapsulation. The 'X' in the edge nodes and relay node, R1,
200 represent a potential DetNet compound flow packet replication and
201 elimination point. This conceptually parallels L2VPN services, and
202 could leverage existing related solutions as discussed below.
204 TSN |<------- End to End DetNet Service ------>| TSN
205 Service | Transit Transit | Service
206 TSN (AC) | |<-Tnl->| |<-Tnl->| | (AC) TSN
207 End | V V 1 V V 2 V V | End
208 System | +--------+ +--------+ +--------+ | System
209 +---+ | | E1 |=======| R1 |=======| E2 | | +---+
210 | |--|----|._X_....|..DF1..|.._ _...|..DF3..|...._X_.|---|---| |
211 |CE1| | | \ | | X | | / | | |CE2|
212 | | | \_.|..DF2..|._/ \_..|..DF4..|._/ | | |
213 +---+ | |=======| |=======| | +---+
214 ^ +--------+ +--------+ +--------+ ^
215 | Edge Node Relay Node Edge Node |
216 | (T-PE) (S-PE) (T-PE) |
217 | |
218 |<- TSN -> <------- TSN Over DetNet MPLS -------> <- TSN ->|
219 | |
220 |<-------- Time Sensitive Networking (TSN) Service ------->|
222 X = Service protection
223 DFx = DetNet member flow x over a TE LSP
224 AC = Attachment Circuit
225 Tnl = Tunnel
227 Figure 2: IEEE 802.1TSN Over DetNet
229 4. DetNet MPLS Data Plane
231 4.1. Overview
233 The basic approach defined in [RFC8964] supports the DetNet service
234 sub-layer based on existing pseudowire (PW) encapsulations and
235 mechanisms, and supports the DetNet forwarding sub-layer based on
236 existing MPLS Traffic Engineering encapsulations and mechanisms.
238 A node operating on a DetNet flow in the Detnet service sub-layer,
239 i.e. a node processing a DetNet packet which has the S-Label as top
240 of stack uses the local context associated with that S-Label, for
241 example a received F-Label, to determine what local DetNet
242 operation(s) are applied to that packet. An S-Label may be unique
243 when taken from the platform label space [RFC3031], which would
244 enable correct DetNet flow identification regardless of which input
245 interface or LSP the packet arrives on. The service sub-layer
246 functions (i.e., PREOF) use a DetNet control word (d-CW).
248 The DetNet MPLS data plane builds on MPLS Traffic Engineering
249 encapsulations and mechanisms to provide a forwarding sub-layer that
250 is responsible for providing resource allocation and explicit routes.
252 The forwarding sub-layer is supported by one or more forwarding
253 labels (F-Labels).
255 DetNet edge/relay nodes are DetNet service sub-layer aware,
256 understand the particular needs of DetNet flows and provide both
257 DetNet service and forwarding sub-layer functions. They add, remove
258 and process d-CWs, S-Labels and F-labels as needed. MPLS DetNet
259 nodes and transit nodes include DetNet forwarding sub-layer
260 functions, notably, support for explicit routes and resource
261 allocation to eliminate (or reduce) congestion loss and jitter.
262 Unlike other DetNet node types, transit nodes provide no service sub-
263 layer processing.
265 4.2. TSN over DetNet MPLS Encapsulation
267 The basic encapsulation approach is to treat a TSN Stream as an App-
268 flow from the DetNet MPLS perspective. The corresponding example
269 shown in Figure 3. Note, that three example flows are shown in the
270 figure.
272 /-> +------+ +------+ +------+ TSN ^ ^
273 MPLS | | X | | X | | X |<- Appli : :
274 App-Flow <-+ +------+ +------+ +------+ cation : :(1)
275 | |TSN-L2| |TSN-L2| |TSN-L2| : v
276 \-> +---+======+--+======+--+======+-----+ :
277 | d-CW | | d-CW | | d-CW | :
278 DetNet-MPLS +------+ +------+ +------+ :(2)
279 |Labels| |Labels| |Labels| v
280 +---+======+--+======+--+======+-----+
281 Link/Sub-Network | L2 | | TSN | | UDP |
282 +------+ +------+ +------+
283 | IP |
284 +------+
285 | L2 |
286 +------+
287 (1) TSN Stream
288 (2) DetNet MPLS Flow
290 Figure 3: Examples of TSN over MPLS Encapsulation Formats
292 In the figure, "Application" indicates the application payload
293 carried by the TSN network. "MPLS App-Flow" indicates that the TSN
294 Stream is the payload from the perspective of the DetNet MPLS data
295 plane defined in [RFC8964]. A single DetNet MPLS flow can aggregate
296 multiple TSN Streams.
298 Note: In order to avoid fragmentation (see section 5.3 of [RFC3985]),
299 the network operator has to make sure that all the DetNet
300 encapsulation overhead plus the TSN App-flow do not exceed the DetNet
301 network's MTU.
303 5. TSN over MPLS Data Plane Procedures
305 The description of Edge Nodes procedures and functions for TSN over
306 DetNet MPLS scenarios follows the concepts from [RFC3985], and covers
307 the Edge Nodes components shown in Figure 1. In this section the
308 following procedures of DetNet Edge Nodes are described:
310 o TSN related (Section 5.1)
312 o DetNet Service Proxy (Section 5.2)
314 o DetNet service and forwarding sub-layer (Section 5.3)
316 The sub-sections describe procedures for forwarding packets by DetNet
317 Edge nodes, where such packets are received from either directly
318 connected CEs (TSN nodes) or some other DetNet Edge nodes.
320 5.1. Edge Node TSN Procedures
322 The Time-Sensitive Networking (TSN) Task Group of the IEEE 802.1
323 Working Group have defined (and are defining) a number of amendments
324 to [IEEE8021Q] that provide zero congestion loss and bounded latency
325 in bridged networks. [IEEE8021CB] defines packet replication and
326 elimination functions for a TSN network.
328 The implementation of TSN entity (i.e., TSN packet processing
329 functions) must be compliant with the relevant IEEE 802.1 standards.
331 TSN specific functions are executed on the data received by the
332 DetNet Edge Node from the connected CE before being forwarded to
333 connected CE(s) or presented to the DetNet Service Proxy function for
334 transmission across the DetNet domain. TSN specific functions are
335 also executed on the data received from a DetNet PW by a PE before
336 the data is output on the Attachment Circuit(s) (AC).
338 TSN packet processing function(s) of Edge Nodes (T-PE) are belonging
339 to the native service processing (NSP) [RFC3985] block. This is
340 similar to other functionalities being defined by standard bodies
341 other than the IETF (for example in case of Ethernet: stripping,
342 overwriting or adding VLAN tags, etc.). Depending on the TSN role of
343 the Edge Node in the end-to-end TSN service selected TSN functions
344 are supported.
346 When a PE receives a packet from a CE, on a given AC with DetNet
347 service, it first checks via Stream Identification (see Clause 6. of
348 [IEEE8021CB] and [IEEEP8021CBdb]) whether the packet belongs to a
349 configured TSN Stream (i.e., App-flow from DetNet perspective). If
350 no Stream ID is matched and no other (VPN) service is configured for
351 the AC, then the packet MUST be dropped. If there is a matching TSN
352 Stream, then the Stream ID specific TSN functions are executed (e.g.,
353 ingress policing, header field manipulation in case of active Stream
354 Identification, FRER, etc.). Source MAC lookup may also be used for
355 local MAC address learning.
357 If the PE decides to forward the packet, the packet MUST be forwarded
358 according to the TSN Stream specific configuration to connected CE(s)
359 (in case of local bridging) and/or to the DetNet Service Proxy (in
360 case of forwarding to remote CE(s)). If there are no TSN Stream
361 specific forwarding configurations, the PE MUST flood the packet to
362 other locally attached CE(s) and to the DetNet Service Proxy. If the
363 administrative policy on the PE does not allow flooding, the PE MUST
364 drop the packet.
366 When a TSN entity of the PE receives a packet from the DetNet Service
367 Proxy, it first checks via Stream Identification (see Clause 6. of
368 [IEEE8021CB] and [IEEEP8021CBdb]) whether the packet belongs to a
369 configured TSN Stream. If no Stream ID is matched, then the packet
370 is dropped. If there is a matching TSN Stream, then the Stream ID
371 specific TSN functions are executed (e.g., header field manipulation
372 in case of active Stream Identification, FRER, etc.). Source MAC
373 lookup may also be used for local MAC address learning.
375 If the PE decides to forward the packet, the packet is forwarded
376 according to the TSN Stream specific configuration to connected
377 CE(s). If there are no TSN Stream specific forwarding
378 configurations, the PE floods the packet to locally attached CE(s).
379 If the administrative policy on the PE does not allow flooding, the
380 PE drops the packet.
382 Implementations of this document SHALL use management and control
383 information to ensure TSN specific functions of the Edge Node
384 according to the expectations of the connected TSN network.
386 5.2. Edge Node DetNet Service Proxy Procedures
388 The Service Proxy function maps between App-flows and DetNet flows.
389 The DetNet Edge Node TSN entity MUST support the TSN Stream
390 identification functions and the related managed objects as defined
391 in Clause 6. and Clause 9. of [IEEE8021CB] and [IEEEP8021CBdb] to
392 recognize the App-flow related packets. The Service Proxy presents
393 TSN Streams as an App-flow to a DetNet Flow.
395 When a DetNet Service Proxy receives a packet from the TSN Entity it
396 MUST check whether such an App-flow is present in its mapping table.
397 If present it associates the internal DetNet flow-ID to the packet
398 and MUST forward it to the DetNet Service and Forwarding sub-layers.
399 If no match is found it MUST drop the packet.
401 When a DetNet Service Proxy receives a packet from the DetNet Service
402 and Forwarding sub-layers it MUST be forwarded to the Edge Node TSN
403 Entity.
405 Implementations of this document SHALL use management and control
406 information to map a TSN Stream to a DetNet flow. N:1 mapping
407 (aggregating multiple TSN Streams in a single DetNet flow) SHALL be
408 supported. The management or control function that provisions flow
409 mapping SHALL ensure that adequate resources are allocated and
410 configured to fulfil the service requirements of the mapped flows.
412 Due to the (intentional) similarities of the DetNet PREOF and TSN
413 FRER functions service protection function interworking is possible
414 between the TSN and the DetNet domains. Such service protection
415 interworking scenarios might require to copy sequence number fields
416 from TSN (L2) to PW (MPLS) encapsulation. However, such interworking
417 is out-of-scope in this document and left for further study.
419 5.3. Edge Node DetNet Service and Forwarding Sub-Layer Procedures
421 In the design of [RFC8964] an MPLS service label (the S-Label),
422 similar to a pseudowire (PW) label [RFC3985], is used to identify
423 both the DetNet flow identity and the payload MPLS payload type. The
424 DetNet sequence number is carried in the DetNet Control word (d-CW)
425 which carries the Data/OAM discriminator as well. In [RFC8964] two
426 sequence number sizes are supported: a 16 bit sequence number and a
427 28 bit sequence number.
429 PREOF functions and the provided service recovery is available only
430 within the DetNet domain as the DetNet flow-ID and the DetNet
431 sequence number are not valid outside the DetNet network. MPLS
432 (DetNet) Edge nodes terminate all related information elements
433 encoded in the MPLS labels.
435 When a PE receives a packet from the Service Proxy function it MUST
436 handle the packet as defined in [RFC8964].
438 When a PE receives an MPLS packet from a remote PE, then, after
439 processing the MPLS label stack, if the top MPLS label ends up being
440 a DetNet S-label that was advertised by this node, then the PE MUST
441 forward the packet according to the configured DetNet Service and
442 Forwarding sub-layer rules to other PE nodes or via the Detnet
443 Service Proxy function towards locally connected CE(s).
445 For further details on DetNet Service and Forwarding sub-layers see
446 [RFC8964].
448 6. Controller Plane (Management and Control) Considerations
450 TSN Stream(s) to DetNet flow mapping related information are required
451 only for the service proxy function of MPLS (DetNet) Edge nodes.
452 From the Data Plane perspective there is no practical difference
453 based on the origin of flow mapping related information (management
454 plane or control plane).
456 The following summarizes the set of information that is needed to
457 configure TSN over DetNet MPLS:
459 o TSN related configuration information according to the TSN role of
460 the DetNet MPLS node, as per [IEEE8021Q], [IEEE8021CB] and
461 [IEEEP8021CBdb].
463 o DetNet MPLS related configuration information according to the
464 DetNet role of the DetNet MPLS node, as per [RFC8964].
466 o App-Flow identification information to map received TSN Stream(s)
467 to the DetNet flow. Parameters of TSN stream identification are
468 defined in [IEEE8021CB] and [IEEEP8021CBdb].
470 This information MUST be provisioned per DetNet flow.
472 Mappings between DetNet and TSN management and control planes are out
473 of scope of the document. Some of the challanges are highligthed
474 below.
476 MPLS DetNet Edge nodes are member of both the DetNet domain and the
477 connected TSN network. From the TSN network perspective the MPLS
478 (DetNet) Edge node has a "TSN relay node" role, so TSN specific
479 management and control plane functionalities must be implemented.
480 There are many similarities in the management plane techniques used
481 in DetNet and TSN, but that is not the case for the control plane
482 protocols. For example, RSVP-TE and MSRP behaves differently.
483 Therefore management and control plane design is an important aspect
484 of scenarios, where mapping between DetNet and TSN is required.
486 Note that, as the DetNet network is just a portion of the end to end
487 TSN path (i.e., single hop from Ethernet perspective), some
488 parameters (e.g., delay) may differ significantly. Since there is no
489 interworking function the bandwidth of DetNet network is assumed to
490 be set large enough to handle all TSN Flows it will support. At the
491 egress of the Detnet Domain the MPLS headers are stripped and the TSN
492 flow continues on as a normal TSN flow.
494 In order to use a DetNet network to interconnect TSN segments, TSN
495 specific information must be converted to DetNet domain specific
496 ones. TSN Stream ID(s) and stream(s) related parameters/requirements
497 must be converted to a DetNet flow-ID and flow related parameters/
498 requirements.
500 In some case it may be challenging to determine some egress node
501 related information. For example, it may be not trivial to locate
502 the egress point/interface of a TSN Stream with a multicast
503 destination MAC address. Such scenarios may require interaction
504 between control and management plane functions and between DetNet and
505 TSN domains.
507 Mapping between DetNet flow identifiers and TSN Stream identifiers,
508 if not provided explicitly, can be done by the service proxy function
509 of an MPLS (DetNet) Edge node locally based on information provided
510 for configuration of the TSN Stream identification functions (e.g.,
511 Mask-and-Match Stream identification).
513 Triggering the setup/modification of a DetNet flow in the DetNet
514 network is an example where management and/or control plane
515 interactions are required between the DetNet and the TSN network.
517 Configuration of TSN specific functions (e.g., FRER) inside the TSN
518 network is a TSN domain specific decision and may not be visible in
519 the DetNet domain. Service protection interworking scenarios are
520 left for further study.
522 7. Security Considerations
524 Security considerations for DetNet are described in detail in
525 [I-D.ietf-detnet-security]. General security considerations are
526 described in [RFC8655].
528 DetNet MPLS data plane specific considerations are summarized and
529 described in [RFC8964] including any application flow types. This
530 document focuses on the scenario where TSN Streams are the
531 application flows for DetNet and it is already covered by those
532 DetNet MPLS data plane security considerations.
534 8. IANA Considerations
536 This document makes no IANA requests.
538 9. Acknowledgements
540 The authors wish to thank Norman Finn, Lou Berger, Craig Gunther,
541 Christophe Mangin and Jouni Korhonen for their various contributions
542 to this work.
544 10. References
546 10.1. Normative References
548 [IEEE8021CB]
549 IEEE 802.1, "Standard for Local and metropolitan area
550 networks - Frame Replication and Elimination for
551 Reliability (IEEE Std 802.1CB-2017)", 2017,
552 .
554 [IEEEP8021CBdb]
555 Mangin, C., "Extended Stream identification functions",
556 IEEE P802.1CBdb /D1.0 P802.1CBdb, September 2020,
557 .
560 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
561 Requirement Levels", BCP 14, RFC 2119,
562 DOI 10.17487/RFC2119, March 1997,
563 .
565 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
566 Label Switching Architecture", RFC 3031,
567 DOI 10.17487/RFC3031, January 2001,
568 .
570 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
571 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
572 May 2017, .
574 [RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas,
575 "Deterministic Networking Architecture", RFC 8655,
576 DOI 10.17487/RFC8655, October 2019,
577 .
579 [RFC8938] Varga, B., Ed., Farkas, J., Berger, L., Malis, A., and S.
580 Bryant, "Deterministic Networking (DetNet) Data Plane
581 Framework", RFC 8938, DOI 10.17487/RFC8938, November 2020,
582 .
584 [RFC8964] Varga, B., Ed., Farkas, J., Berger, L., Malis, A., Bryant,
585 S., and J. Korhonen, "Deterministic Networking (DetNet)
586 Data Plane: MPLS", RFC 8964, DOI 10.17487/RFC8964, January
587 2021, .
589 10.2. Informative References
591 [I-D.ietf-detnet-security]
592 Grossman, E., Mizrahi, T., and A. Hacker, "Deterministic
593 Networking (DetNet) Security Considerations", draft-ietf-
594 detnet-security-13 (work in progress), December 2020.
596 [IEEE8021Q]
597 IEEE 802.1, "Standard for Local and metropolitan area
598 networks--Bridges and Bridged Networks (IEEE Std 802.1Q-
599 2018)", 2018, .
601 [RFC3985] Bryant, S., Ed. and P. Pate, Ed., "Pseudo Wire Emulation
602 Edge-to-Edge (PWE3) Architecture", RFC 3985,
603 DOI 10.17487/RFC3985, March 2005,
604 .
606 Authors' Addresses
608 Balazs Varga (editor)
609 Ericsson
610 Magyar Tudosok krt. 11.
611 Budapest 1117
612 Hungary
614 Email: balazs.a.varga@ericsson.com
616 Janos Farkas
617 Ericsson
618 Magyar Tudosok krt. 11.
619 Budapest 1117
620 Hungary
622 Email: janos.farkas@ericsson.com
623 Andrew G. Malis
624 Malis Consulting
626 Email: agmalis@gmail.com
628 Stewart Bryant
629 Futurewei Technologies
631 Email: stewart.bryant@gmail.com
633 Don Fedyk
634 LabN Consulting, L.L.C.
636 Email: dfedyk@labn.net