idnits 2.17.1 draft-varga-detnet-service-sub-layer-oam-01.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: ---------------------------------------------------------------------------- == There are 2 instances of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC8655]), 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 date (22 October 2021) is 916 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.ietf-detnet-ip-oam' is defined on line 532, but no explicit reference was found in the text == Outdated reference: A later version (-13) exists of draft-ietf-detnet-ip-oam-03 == Outdated reference: A later version (-15) exists of draft-ietf-detnet-mpls-oam-05 == Outdated reference: A later version (-11) exists of draft-ietf-detnet-oam-framework-05 == Outdated reference: A later version (-03) exists of draft-varga-detnet-pof-01 Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DetNet B. Varga 3 Internet-Draft J. Farkas 4 Intended status: Informational G. Mirsky 5 Expires: 25 April 2022 Ericsson 6 22 October 2021 8 Deterministic Networking (DetNet): OAM Functions for The Service Sub- 9 Layer 10 draft-varga-detnet-service-sub-layer-oam-01 12 Abstract 14 Operation, Administration, and Maintenance (OAM) tools are essential 15 for a deterministic network. The DetNet architecture [RFC8655] has 16 defined two sub-layers: (1) DetNet service sub-layer and (2) DetNet 17 forwarding sub-layer. OAM mechanisms exist for the DetNet forwarding 18 sub-layer. Nonetheless, OAM for the service sub-layer might require 19 new extensions to the existing OAM protocols. This draft presents an 20 analysis of OAM procedures for the DetNet service sub-layer 21 functions. 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 25 April 2022. 40 Copyright Notice 42 Copyright (c) 2021 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 (https://trustee.ietf.org/ 47 license-info) in effect on the date of publication of this document. 48 Please review these documents carefully, as they describe your rights 49 and restrictions with respect to this document. Code Components 50 extracted from this document must include Simplified BSD License text 51 as described in Section 4.e of the Trust Legal Provisions and are 52 provided without warranty as 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 2.3. Requirements Language . . . . . . . . . . . . . . . . . . 4 61 3. DetNet Service Sub-layer OAM Challenges . . . . . . . . . . . 4 62 3.1. Illustrative example . . . . . . . . . . . . . . . . . . 4 63 3.2. DetNet Service Sub-layer Specifics for OAM . . . . . . . 5 64 3.3. Information Needed during DetNet OAM Packet Processing . 6 65 3.4. A Possible Format of DetNet Associated Channel Header 66 (d-ACH) . . . . . . . . . . . . . . . . . . . . . . . . . 6 67 4. Requirements on OAM for DetNet Service Sub-layer . . . . . . 7 68 5. DetNet PING . . . . . . . . . . . . . . . . . . . . . . . . . 8 69 5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 8 70 5.2. OAM processing at the DetNet service sub-layer . . . . . 9 71 5.2.1. Relay node with PRF . . . . . . . . . . . . . . . . . 9 72 5.2.2. Relay node with PEF . . . . . . . . . . . . . . . . . 9 73 5.2.3. Relay node with POF . . . . . . . . . . . . . . . . . 10 74 5.2.4. Relay node without PREOF . . . . . . . . . . . . . . 11 75 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 76 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 77 7.1. DetNet MPLS OAM Flags Registry . . . . . . . . . . . . . 11 78 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 79 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 80 9.1. Normative References . . . . . . . . . . . . . . . . . . 11 81 9.2. Informative References . . . . . . . . . . . . . . . . . 12 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 84 1. Introduction 86 The DetNet Working Group has defined two sub-layers: (1) DetNet 87 service sub-layer, at which a DetNet service (e.g., service 88 protection) is provided and (2) DetNet forwarding sub-layer, which 89 optionally provides resource allocation for DetNet flows over paths 90 provided by the underlying network. In [RFC8655] new DetNet-specific 91 functions have been defined for the DetNet service sub-layer, namely 92 PREOF (a collective name for Packet Replication, Elimination, and 93 Ordering Functions). 95 Framework of Operations, Administration and Maintenance (OAM) for 96 Deterministic Networking (DetNet) is described in 97 [I-D.ietf-detnet-oam-framework]. OAM for the DetNet MPLS data plane 98 is described in [I-D.ietf-detnet-mpls-oam] and OAM for the DetNet IP 99 data plane is described in [I-D.ietf-detnet-mpls-oam]. 101 This draft has been submitted as an individual contribution to OAM 102 discussions, in particular, to kick-off Working Group discussions on 103 introducing OAM functions for the DetNet service sub-layer. It is 104 also up to the Working Group discussions to which draft parts of this 105 contribution may go, if any. 107 The OAM functions for the DetNet service sub-layer allow, for 108 example, to recognize/discover DetNet relay nodes, to get information 109 about their configuration, and to check their operation or status. 110 Furthermore, the OAM functions for the DetNet service sub-layer need 111 to meet new challenges (see section Section 3) and requirements (see 112 section Section 4) introduced by PREOF. 114 An approach described in this draft introduces a new OAM shim layer 115 to achieve OAM for the DetNet service sub-layer. In the rest of the 116 draft, this approach is referred to as "DetNet PING", which is an in- 117 band OAM approach, i.e., the OAM packets follow precisely the same 118 path as the data packets of the corresponding DetNet flow(s) The OAM 119 packets provide DetNet service sub-layer specific information, like: 121 * Identity of a DetNet service sub-layer node. 123 * Discover Ingress/Egress flow-specific configuration of a DetNet 124 service sub-layer node. 126 * Detect the status of the flow-specific service sub-layer function. 128 DetNet PING applies both to IP and MPLS DetNet data planes. 130 2. Terminology 132 2.1. Terms Used in This Document 134 This document uses the terminology established in the DetNet 135 architecture [RFC8655], and the reader is assumed to be familiar with 136 that document and its terminology. 138 2.2. Abbreviations 140 The following abbreviations are used in this document: 142 DetNet Deterministic Networking. 144 PEF Packet Elimination Function. 146 POF Packet Ordering Function. 148 PREOF Packet Replication, Elimination and Ordering Functions. 150 PRF Packet Replication Function. 152 2.3. Requirements Language 154 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 155 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 156 "OPTIONAL" in this document are to be interpreted as described in BCP 157 14 [RFC2119] [RFC8174] when, and only when, they appear in all 158 capitals, as shown here. 160 3. DetNet Service Sub-layer OAM Challenges 162 3.1. Illustrative example 164 This section introduces an example that is used to explain the DetNet 165 Service Sub-layer OAM challenges. Figure 1 shows a DetNet flow on 166 which PREOF functions are applied during forwarding from source to 167 destination. 169 <------------------------ App Flow -----------------------> 171 /-------------- DetNet domain -----------------/ 172 <-------------- DetNet flow -----------------> 174 P6 175 P1 P4 +------------+ 176 +--------------E1----+ | P7 | 177 +----+ | | +---R3---+ | P9 +----+ 178 |src |------R1 +---+ | E3----O1---+ dst| 179 +----+ | P2 | P3 E2-------+ +----+ 180 +----------R2 P5 | P8 181 +-----------------+ 183 <----- P1 ----> <- P4 -> <--- P6 ----> <-P9-> 184 <-- P2 --> <- P4 -> <- P8 -> <-P9-> 185 <-- P2 --> <----- P5 ------> <- P8 -> <-P9-> 187 |------------ G1 DetNet graph ----------------> 189 R: replication point (PRF) P: forwarding sub-layer path 190 E: elimination point (PEF) G: service sub-layer graph 191 O: ordering function (POF) 193 Figure 1: PREOF scenario in a DetNet network 195 DetNet service sub-layer nodes are interconnected by DetNet 196 forwarding sub-layer paths. DetNet forwarding sub-layer path (e.g., 197 P1 = R1->E1 path, P4 = E1->R3 path) may contain multiple transit 198 nodes. A DetNet forwarding sub-layer path is used by a member flow 199 and terminated by relay nodes (see [RFC8655] for relay node 200 definition). 202 A DetNet service sub-layer graph includes all relay nodes and the 203 interconnecting forwarding sub-layer paths. This graph can be also 204 called as "PREOF graph" and it describes the compound flow as a 205 whole. 207 3.2. DetNet Service Sub-layer Specifics for OAM 209 Several DetNet Service Sub-layer specifics have to be considered for 210 OAM. 212 1. The service sub-layer graph is segmented into multiple parts, as 213 forwarding sub-layer paths are terminated at DetNet relay nodes. 215 2. These are particular characteristics of DetNet PW: 217 1. PREOF acts as per-packet protection. PEF is a brand-new 218 functionality at network layer, due to the per-packet merge 219 action. 221 2. All paths are active and forward traffic. These paths may 222 have a different number of hops. 224 3. Mandatory usage of a sequence number. 226 The above specifics have to be considered in combination with the 227 requirement that DetNet OAM and DetNet data flows MUST receive the 228 same treatment. OAM packets MUST follow precisely the same graph as 229 the monitored DetNet flow(s). 231 3.3. Information Needed during DetNet OAM Packet Processing 233 This section collects some questions that have been already discussed 234 by the DetNet WG and/or require further discussions by the WG. The 235 section is structured in the form of a question list. 237 Question-1: Injecting OAM traffic in a DetNet flow? A DetNet data 238 flow has a continuous Sequence Number. In order not to spoil that, 239 the injected OAM packets require OAM-specific Sequence Number added. 240 (See also Section Section 5.) 242 Question-2: How to process OAM packets by DetNet service sub-layer 243 nodes? In order to cover the DetNet forwarding graph by OAM, PREOF 244 has to be executed in an OAM specific manner (i.e., PREOF uses a 245 separate SeqNum space for OAM. See details in Section 5. 247 Note: the question list is non-exhaustive. 249 3.4. A Possible Format of DetNet Associated Channel Header (d-ACH) 251 Figure 2 shows a possible format of the DetNet Associated Channel 252 Header (d-ACH). 254 0 1 2 3 255 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 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 |0 0 0 1|Version|Sequence Number| Channel Type | 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 | Node ID |Level| Flags |Ses.ID | 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 Figure 2: DetNet Associated Channel Header Format 263 The d-ACH encodes the following fields: 265 * Bits 0..3 MUST be 0b0001. This value of the first nibble allows 266 the packet to be distinguished from an IP packet [RFC4928] and a 267 DetNet data packet [RFC8964]. 269 * Version: this is the version number of the d-ACH. This 270 specification defines version 0x1. 272 * Sequence Number: this is an unsigned eight-bit field. The 273 sequence number space is a circular one with no restriction on the 274 initial value. The originator DetNet node MUST set the value of 275 the Sequence Number field before the transmission of a packet. 276 The originator node MUST increase the value of the Sequence Number 277 field by 1 for each active OAM packet. 279 * Channel Type: encodes the value of DetNet Associated Channel Type 280 is one of the values defined in the IANA PW Associated Channel 281 Type registry. 283 * Node ID: it is an unsigned 20-bits field. The value of the Node 284 ID field identifies the DetNet node that originated the packet. 285 Methods to distribute Node ID are outside the scope of this 286 specification. 288 * Level: is a 3-bit field. 290 * Flags: is a 5-bit field. Section 7.1 creates an IANA registry for 291 new flags to be defined. 293 * Session ID: is a 4-bit field. 295 The DetNet flow, according to [RFC8964], is identified by the S-label 296 that MUST be at the bottom of the stack. An active DetNet OAM packet 297 MUST include d-ACH immediately following the S-label. 299 4. Requirements on OAM for DetNet Service Sub-layer 301 [Editor's note: The content of this section has been discussed and 302 the outcome of the discussion has been documented in 303 [I-D.ietf-detnet-oam-framework].] 305 The requirements on OAM for a DetNet relay node are: 307 1. to provide OAM functions for the DetNet service sub-layer. 309 2. to discover DetNet relay nodes in a DetNet network. 311 3. to collect DetNet service sub-layer specific (e.g., 312 configuration/operation/status) information from DetNet relay 313 nodes. 315 4. to work for both DetNet data planes: (1) MPLS and (2) IP. 317 5. DetNet PING 319 5.1. Overview 321 The "DetNet PING" approach uses two types of OAM packets: (1) DetNet- 322 Echo-Request and (2) DetNet-Echo-Reply. Their encapsulation is 323 identical to that of the corresponding DetNet data flow, so they 324 follow precisely the same path as the packets of the corresponding 325 DetNet data flow. They target DetNet service sub-layer entities, so 326 they may not be recognized as OAM packets by entities not 327 implementing DetNet service sub-layer for a packet flow (e.g., 328 transit nodes). Other entities treat them as packets belonging to 329 the corresponding DetNet data flow. 331 The following relay node roles can be distinguished: 333 1. DetNet PING originator node, 335 2. Intermediate DetNet service sub-layer node, 337 3. DetNet PING targeted node. 339 An originator node sends (generates) DetNet-Echo-Request packet(s). 340 DetNet-Echo-Request packet contains an OAM specific "PINGSeqNum", 341 which can be used by the DetNet service sub-layer of relay nodes. 342 Note that "PINGSeqNum" is originator specific. 344 An intermediate DetNet service sub-layer node executes DetNet flow- 345 specific service sub-layer functionality. Packet processing may be 346 done in an OAM specific manner (see details in Section 5.2). 348 A targeted node answers with DetNet-Echo-Reply packet for each 349 DetNet-Echo-Request. DetNet-Echo-Reply packet provides DetNet 350 service sub-layer specific information on (i) identities of DetNet 351 service sub-layer node (e.g., Node-ID, local Flow-ID), (ii) ingress/ 352 egress flow related configuration (e.g., in/out member flow specific 353 information (including forwarding sub-layer specifics)), and (iii) 354 status of service sub-layer function (e.g., local PxF-ID, Action- 355 Type=x, operational status, value of key state variable(s), function 356 related counters). 358 5.2. OAM processing at the DetNet service sub-layer 360 Detailed OAM packet processing rules of various DetNet relay nodes 361 are described in the following sections. 363 5.2.1. Relay node with PRF 365 A DetNet relay node with PRF processes DetNet OAM packets in a 366 stateless manner. 368 If the relay node with PRF is the target of a DetNet-Echo-Request 369 packet, then the DetNet-Echo-Request packet MUST NOT be further 370 forwarded, and a DetNet Echo-Reply packet MUST be generated. If the 371 relay node with PRF is not the target of a DetNet Echo-Request 372 packet, then the DetNet Echo-Request packet MUST be sent over all 373 DetNet flow specific member flow paths (i.e., it is replicated). 375 A DetNet Echo-Reply packet MUST contain the following information: 377 * Identities related to the DetNet service sub-layer node (e.g., 378 Node-ID, local Flow-ID), 380 * Ingress/Egress flow related configuration (e.g., in/out member 381 flow specific information (including forwarding sub-layer 382 specifics)), 384 * Status of service sub-layer function (e.g., local PRF-ID, Action- 385 Type=Replication, operational status, value of the flow related 386 key state variable (e.g., "GenSeqNum" in [IEEE8021CB]). 388 A DetNet Echo-Reply packet MAY contain the following information: 390 * PRF related local counters. 392 5.2.2. Relay node with PEF 394 A DetNet relay node with PEF processes DetNet OAM packets in a 395 stateful manner. 397 If the relay node with PEF is the target of DetNet-Echo-Request 398 packet, then the DetNet Echo-Request packet MUST NOT be further 399 forwarded and an DetNet Echo-Reply packet MUST be generated. If the 400 relay node with PEF is not the target of DetNet Echo-Request packet, 401 then elimination MUST be executed on the DetNet Echo-Request 402 packet(s) using the OAM specific "PINGSeqNum" in the packet. So only 403 a single DetNet Echo-Request packet is forwarded and all further 404 replicas (having the same originator's sequence number) MUST be 405 discarded. 407 Note, PEF MAY use a simplified elimination algorithm for DetNet Echo- 408 Request packets (e.g., "MatchRecoveryAlgorithm" in [IEEE8021CB]) as 409 OAM is a slow protocol. 411 A DetNet-Echo-Reply packet MUST contain the following information: 413 * Identities related to the DetNet service sub-layer node (e.g., 414 Node-ID, local Flow-ID), 416 * Ingress/Egress flow related configuration (e.g., in/out member 417 flow specific information (including forwarding sub-layer 418 specifics)) , 420 * Status of service sub-layer function (e.g., local PEF-ID, Action- 421 Type=Elimination, operational status, value of the flow related 422 key state variable (e.g., "RecovSeqNum" in [IEEE8021CB]). 424 A DetNet Echo-Reply packet MAY contain the following information: 426 * PEF-related local counters. 428 5.2.3. Relay node with POF 430 A DetNet relay node with POF processes DetNet OAM packets in a 431 stateless manner. 433 If the relay node with POF is the target of DetNet Echo-Request 434 packet, then the DetNet Echo-Request packet MUST NOT be further 435 forwarded and a DetNet Echo-Reply packet MUST be generated. If the 436 relay node with POF is not the target of DetNet-Echo-Request packet, 437 then the DetNet Echo-Request packet(s) MUST be forwarded without any 438 POF-specific action. 440 A DetNet Echo-Reply packet MUST contain the following information: 442 * Identities of the DetNet service sub-layer node (e.g., Node-ID, 443 local Flow-ID), 445 * Ingress/Egress flow related configuration (e.g., in/out member 446 flow specific information (including forwarding sub-layer 447 specifics)) , 449 * Status of service sub-layer function (e.g., local POF-ID, Action- 450 Type=Ordering, operational status, value of the flow related key 451 state variable (e.g., "POFLastSent" in [I-D.varga-detnet-pof]). 453 A DetNet Echo-Reply packet MAY contain the following information: 455 * POF-related local counters. 457 5.2.4. Relay node without PREOF 459 A DetNet relay node without PREOF processes DetNet OAM packets in a 460 stateless manner. 462 If the relay node without PREOF is the target of DetNet Echo-Request 463 packet, then the DetNet Echo-Request packet MUST NOT be further 464 forwarded and an DetNet Echo-Reply packet MUST be generated. If the 465 relay node without PREOF is not the target of DetNet-Echo-Request 466 packet, then the DetNet-Echo-Request packet(s) MUST be forwarded (as 467 any data packets of the related DetNet flow). 469 A DetNet Echo-Reply packet MUST contain the following information: 471 * Identities of the DetNet service sub-layer node (e.g., Node-ID, 472 local Flow-ID), 474 * Ingress/Egress flow-related configuration (e.g., in/out member 475 flow specific information (including forwarding sub-layer 476 specifics)) . 478 6. Security Considerations 480 Tbd. 482 7. IANA Considerations 484 7.1. DetNet MPLS OAM Flags Registry 486 This document describes a new IANA-managed registry to identify 487 DetNet MPLS OAM Flags Bits. The registration procedure is "IETF 488 Review" [RFC8126]. The registry name is "DetNet MPLS OAM Flags". 489 There are five flags in the five-bit Flags field. 491 8. Acknowledgements 493 Authors extend their appreciation to Janos Szabo and Gyorgy Miklos 494 for their insightful comments and productive discussion that helped 495 to improve the document. 497 9. References 499 9.1. Normative References 501 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 502 Requirement Levels", BCP 14, RFC 2119, 503 DOI 10.17487/RFC2119, March 1997, 504 . 506 [RFC4928] Swallow, G., Bryant, S., and L. Andersson, "Avoiding Equal 507 Cost Multipath Treatment in MPLS Networks", BCP 128, 508 RFC 4928, DOI 10.17487/RFC4928, June 2007, 509 . 511 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 512 Writing an IANA Considerations Section in RFCs", BCP 26, 513 RFC 8126, DOI 10.17487/RFC8126, June 2017, 514 . 516 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 517 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 518 May 2017, . 520 [RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas, 521 "Deterministic Networking Architecture", RFC 8655, 522 DOI 10.17487/RFC8655, October 2019, 523 . 525 [RFC8964] Varga, B., Ed., Farkas, J., Berger, L., Malis, A., Bryant, 526 S., and J. Korhonen, "Deterministic Networking (DetNet) 527 Data Plane: MPLS", RFC 8964, DOI 10.17487/RFC8964, January 528 2021, . 530 9.2. Informative References 532 [I-D.ietf-detnet-ip-oam] 533 Mirsky, G., Chen, M., and D. Black, "Operations, 534 Administration and Maintenance (OAM) for Deterministic 535 Networks (DetNet) with IP Data Plane", Work in Progress, 536 Internet-Draft, draft-ietf-detnet-ip-oam-03, 19 September 537 2021, . 540 [I-D.ietf-detnet-mpls-oam] 541 Mirsky, G. and M. Chen, "Operations, Administration and 542 Maintenance (OAM) for Deterministic Networks (DetNet) with 543 MPLS Data Plane", Work in Progress, Internet-Draft, draft- 544 ietf-detnet-mpls-oam-05, 18 October 2021, 545 . 548 [I-D.ietf-detnet-oam-framework] 549 Mirsky, G., Theoleyre, F., Papadopoulos, G. Z., Bernardos, 550 C. J., Varga, B., and J. Farkas, "Framework of Operations, 551 Administration and Maintenance (OAM) for Deterministic 552 Networking (DetNet)", Work in Progress, Internet-Draft, 553 draft-ietf-detnet-oam-framework-05, 14 October 2021, 554 . 557 [I-D.varga-detnet-pof] 558 Varga, B., Farkas, J., Kehrer, S., and T. Heer, 559 "Deterministic Networking (DetNet): Packet Ordering 560 Function", Work in Progress, Internet-Draft, draft-varga- 561 detnet-pof-01, 21 May 2021, 562 . 565 [IEEE8021CB] 566 IEEE, "IEEE Standard for Local and metropolitan area 567 networks -- Frame Replication and Elimination for 568 Reliability", DOI 10.1109/IEEESTD.2017.8091139, October 569 2017, 570 . 572 Authors' Addresses 574 Balázs Varga 575 Ericsson 576 Budapest 577 Magyar Tudosok krt. 11. 578 1117 579 Hungary 581 Email: balazs.a.varga@ericsson.com 583 János Farkas 584 Ericsson 585 Budapest 586 Magyar Tudosok krt. 11. 587 1117 588 Hungary 590 Email: janos.farkas@ericsson.com 591 Greg Mirsky 592 Ericsson 594 Email: gregimirsky@gmail.com