idnits 2.17.00 (12 Aug 2021) /tmp/idnits49682/draft-ietf-detnet-ip-over-tsn-03.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 (June 8, 2020) is 712 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 170, but not defined == Unused Reference: 'I-D.ietf-detnet-flow-information-model' is defined on line 490, but no explicit reference was found in the text == Outdated reference: draft-ietf-detnet-ip has been published as RFC 8939 == Outdated reference: draft-ietf-detnet-flow-information-model has been published as RFC 9016 == Outdated reference: draft-ietf-detnet-security has been published as RFC 9055 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 B. Varga, Ed. 3 Internet-Draft J. Farkas 4 Intended status: Standards Track Ericsson 5 Expires: December 10, 2020 A. Malis 6 Malis Consulting 7 S. Bryant 8 Futurewei Technologies 9 June 8, 2020 11 DetNet Data Plane: IP over IEEE 802.1 Time Sensitive Networking (TSN) 12 draft-ietf-detnet-ip-over-tsn-03 14 Abstract 16 This document specifies the Deterministic Networking IP data plane 17 when operating over a TSN sub-network. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on December 10, 2020. 36 Copyright Notice 38 Copyright (c) 2020 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (https://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2.1. Terms Used In This Document . . . . . . . . . . . . . . . 3 56 2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3 57 2.3. Requirements Language . . . . . . . . . . . . . . . . . . 3 58 3. DetNet IP Data Plane Overview . . . . . . . . . . . . . . . . 3 59 4. DetNet IP Flows over an IEEE 802.1 TSN sub-network . . . . 5 60 4.1. Functions for DetNet Flow to TSN Stream Mapping . . . . . 6 61 4.2. TSN requirements of IP DetNet nodes . . . . . . . . . . . 6 62 4.3. Service protection within the TSN sub-network . . . . . . 8 63 4.4. Aggregation during DetNet flow to TSN Stream mapping . . 8 64 5. Management and Control Implications . . . . . . . . . . . . . 8 65 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 66 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 67 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 68 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 69 9.1. Normative references . . . . . . . . . . . . . . . . . . 10 70 9.2. Informative references . . . . . . . . . . . . . . . . . 11 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 73 1. Introduction 75 Deterministic Networking (DetNet) is a service that can be offered by 76 a network to DetNet flows. DetNet provides these flows extremely low 77 packet loss rates and assured maximum end-to-end delivery latency. 78 General background and concepts of DetNet can be found in the DetNet 79 Architecture [RFC8655]. 81 [I-D.ietf-detnet-ip] specifies the DetNet data plane operation for IP 82 hosts and routers that provide DetNet service to IP encapsulated 83 data. This document focuses on the scenario where DetNet IP nodes 84 are interconnected by a TSN sub-network. 86 The DetNet Architecture decomposes the DetNet related data plane 87 functions into two sub-layers: a service sub-layer and a forwarding 88 sub-layer. The service sub-layer is used to provide DetNet service 89 protection and reordering. The forwarding sub-layer is used to 90 provides congestion protection (low loss, assured latency, and 91 limited reordering). As described in [I-D.ietf-detnet-ip] no DetNet 92 specific headers are added to support DetNet IP flows, only the 93 forwarding sub-layer functions are supported inside the DetNet 94 domain. Service protection can be provided on a per sub-network 95 basis as shown here for the IEEE802.1 TSN sub-network scenario. 97 2. Terminology 99 2.1. Terms Used In This Document 101 This document uses the terminology and concepts established in the 102 DetNet architecture [RFC8655], and the reader is assumed to be 103 familiar with that document and its terminology. 105 2.2. Abbreviations 107 The following abbreviations used in this document: 109 DetNet Deterministic Networking. 111 DF DetNet Flow. 113 FRER Frame Replication and Elimination for Redundancy (TSN 114 function). 116 L2 Layer-2. 118 L3 Layer-3. 120 PREOF Packet Replication, Ordering and Elimination Function. 122 TSN Time-Sensitive Networking, TSN is a Task Group of the 123 IEEE 802.1 Working Group. 125 2.3. Requirements Language 127 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 128 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 129 "OPTIONAL" in this document are to be interpreted as described in BCP 130 14 [RFC2119] [RFC8174] when, and only when, they appear in all 131 capitals, as shown here. 133 3. DetNet IP Data Plane Overview 135 [I-D.ietf-detnet-ip] describes how IP is used by DetNet nodes, i.e., 136 hosts and routers, to identify DetNet flows and provide a DetNet 137 service. From a data plane perspective, an end-to-end IP model is 138 followed. DetNet uses "6-tuple" based flow identification, where 139 "6-tuple" refers to information carried in IP and higher layer 140 protocol headers. 142 DetNet flow aggregation may be enabled via the use of wildcards, 143 masks, prefixes and ranges. IP tunnels may also be used to support 144 flow aggregation. In these cases, it is expected that DetNet aware 145 intermediate nodes will provide DetNet service assurance on the 146 aggregate through resource allocation and congestion control 147 mechanisms. 149 Congestion protection, latency control and the resource allocation 150 (queuing, policing, shaping) are supported using the underlying link 151 / sub-net specific mechanisms. Service protections (packet 152 replication and packet elimination functions) are not provided at the 153 DetNet layer end-to-end due the lack of a unified end-to-end 154 sequencing information that would be available for intermediate 155 nodes. However, such service protection can be provided on a per 156 underlying L2 link and sub-network basis. 158 Edge Transit Relay 159 Node Node Node 161 +.........+ 162 <--:Svc Proxy:-- End to End Service -----------> 163 +-----....+ +..........+ 164 |IP | :Svc:<-- DetNet flow ---: Service :---> 165 +---+ +---+ +---------+ +---------+ 166 |Fwd| |Fwd| | Fwd | |Fwd| |Fwd| 167 +-.-+ +-.-+ +--.----.-+ +-.-+ +-.-+ 168 : / ,-----. \ : Link : : 169 .....+ +-[TSN Sub]-+ +........+ +..... 170 [Network] 171 `-----' 172 <------------- DetNet IP ------------- 174 Figure 1: Part of a Simple DetNet (DN) Enabled IP Network using a TSN 175 sub-net 177 Figure 1 illustrates an extract of a DetNet enabled IP network, that 178 uses a TSN sub-network as interconnection between two DetNet Nodes. 179 In this figure, an Edge Node sits at the boundary of the DetNet 180 domain and provide DetNet service proxies for the end applications by 181 initiating and terminating DetNet service for the application's IP 182 flows. Node and interface resources are allocated to ensure DetNet 183 service requirements. Dotted lines around the Service components of 184 the Edge and Relay Nodes indicate that they are DetNet service aware 185 but do not perform any DetNet service sub-layer function, e.g., PREOF 186 (Packet Replication, Elimination, and Ordering Functions). In this 187 example the Edge Node and the Transit Node are interconnected by a 188 TSN sub-network, being the primary focus of this document. 190 DetNet routers ensure that DetNet service requirements are met per 191 hop by allocating local resources, both receive and transmit, and by 192 mapping the service requirements of each flow to appropriate sub- 193 network mechanisms. Such mappings are sub-network technology 194 specific. The mapping of DetNet IP flows to TSN streams and TSN 195 protection mechanisms are covered in Section 4. 197 4. DetNet IP Flows over an IEEE 802.1 TSN sub-network 199 This section covers how DetNet IP flows operate over an IEEE 802.1 200 TSN sub-network. Figure 2 illustrates such a scenario, where two IP 201 (DetNet) nodes are interconnected by a TSN sub-network. Node-1 is 202 single homed and Node-2 is dual-homed to the TSN sub-network. 204 IP (DetNet) IP (DetNet) 205 Node-1 Node-2 207 ............ ............ 208 <--: Service :-- DetNet flow ---: Service :--> 209 +----------+ +----------+ 210 |Forwarding| |Forwarding| 211 +--------.-+ <-TSN Str-> +-.-----.--+ 212 \ ,-------. / / 213 +----[ TSN-Sub ]---+ / 214 [ Network ]--------+ 215 `-------' 216 <----------------- DetNet IP -----------------> 218 Figure 2: DetNet (DN) Enabled IP Network over a TSN sub-network 220 The Time-Sensitive Networking (TSN) Task Group of the IEEE 802.1 221 Working Group have defined (and are defining) a number of amendments 222 to IEEE 802.1Q [IEEE8021Q] that provide zero congestion loss and 223 bounded latency in bridged networks. Furthermore, IEEE 802.1CB 224 [IEEE8021CB] defines frame replication and elimination functions for 225 reliability that should prove both compatible with and useful to 226 DetNet networks. All these functions have to identify flows that 227 require TSN treatment. 229 TSN capabilities of the TSN sub-network are made available for IP 230 (DetNet) flows via the protocol interworking function desribed in 231 Annex C.5 of IEEE 802.1CB [IEEE8021CB]. For example, applied on the 232 TSN edge port it can convert an ingress unicast IP (DetNet) flow to 233 use a specific Layer-2 multicast destination MAC address and a VLAN, 234 in order to direct the packet through a specific path inside the 235 bridged network. A similar interworking function pair at the other 236 end of the TSN sub-network would restore the packet to its original 237 Layer-2 destination MAC address and VLAN. 239 Placement of TSN functions depends on the TSN capabilities of nodes. 240 IP (DetNet) Nodes may or may not support TSN functions. For a given 241 TSN Stream (i.e., a mapped DetNet flow) an IP (DetNet) node is 242 treated as a Talker or a Listener inside the TSN sub-network. 244 4.1. Functions for DetNet Flow to TSN Stream Mapping 246 Mapping of a DetNet IP flow to a TSN Stream is provided via the 247 combination of a passive and an active stream identification function 248 that operate at the frame level (Layer-2). The passive stream 249 identification function is used to catch the 6-tuple of a DetNet IP 250 flow and the active stream identification function is used to modify 251 the Ethernet header according to the ID of the mapped TSN Stream. 253 Clause 6.7 of IEEE 802.1CB [IEEE8021CB] defines an IP Stream 254 identification function that can be used as a passive function for IP 255 DetNet flows using UDP or TCP. Clause 6.8 of IEEE P802.1CBdb 256 [IEEEP8021CBdb] defines a Mask-and-Match Stream identification 257 function that can be used as a passive function for any IP DetNet 258 flows. 260 Clause 6.6 of IEEE 802.1CB [IEEE8021CB] defines an Active Destination 261 MAC and VLAN Stream identification function, what can replace some 262 Ethernet header fields namely (1) the destination MAC-address, (2) 263 the VLAN-ID and (3) priority parameters with alternate values. 264 Replacement is provided for the frame passed down the stack from the 265 upper layers or up the stack from the lower layers. 267 Active Destination MAC and VLAN Stream identification can be used 268 within a Talker to set flow identity or a Listener to recover the 269 original addressing information. It can be used also in a TSN bridge 270 that is providing translation as a proxy service for an End System. 272 4.2. TSN requirements of IP DetNet nodes 274 This section covers required behavior of a TSN-aware DetNet node 275 using a TSN sub-network. The implementation of TSN packet processing 276 functions MUST be compliant with the relevant IEEE 802.1 standards. 278 From the TSN sub-network perspective DetNet IP nodes are treated as 279 Talker or Listener, that may be (1) TSN-unaware or (2) TSN-aware. 281 In cases of TSN-unaware IP DetNet nodes the TSN relay nodes within 282 the TSN sub-network must modify the Ethernet encapsulation of the 283 DetNet IP flow (e.g., MAC translation, VLAN-ID setting, Sequence 284 number addition, etc.) to allow proper TSN specific handling inside 285 the sub-network. There are no requirements defined for TSN-unaware 286 IP DetNet nodes in this document. 288 IP (DetNet) nodes being TSN-aware can be treated as a combination of 289 a TSN-unaware Talker/Listener and a TSN-Relay, as shown in Figure 3. 290 In such cases the IP (DetNet) node must provide the TSN sub-network 291 specific Ethernet encapsulation over the link(s) towards the sub- 292 network. 294 IP (DetNet) 295 Node 296 <----------------------------------> 298 ............ 299 <--: Service :-- DetNet flow ------------------ 300 +----------+ 301 |Forwarding| 302 +----------+ +---------------+ 303 | L2 | | L2 Relay with |<--- TSN --- 304 | | | TSN function | Stream 305 +-----.----+ +--.------.---.-+ 306 \__________/ \ \______ 307 \_________ 308 TSN-unaware 309 Talker / TSN-Bridge 310 Listener Relay 311 <----- TSN Sub-network ----- 312 <------- TSN-aware Tlk/Lstn -------> 314 Figure 3: IP (DetNet) node with TSN functions 316 A TSN-aware IP (DetNet) node impementations MUST support the Stream 317 Identification TSN component for recognizing flows. 319 A Stream identification component MUST be able to instantiate the 320 following functions (1) Active Destination MAC and VLAN Stream 321 identification function, (2) IP Stream identification function, (3) 322 Mask-and-Match Stream identification function and (4) the related 323 managed objects in Clause 9 of IEEE 802.1CB [IEEE8021CB] and IEEE 324 P802.1CBdb [IEEEP8021CBdb]. 326 A TSN-aware IP (DetNet) node implementations MUST support the 327 Sequencing function and the Sequence encode/decode function as 328 defined in Clause 7.4 and 7.6 of IEEE 802.1CB [IEEE8021CB] if FRER is 329 used inside the TSN sub-network. 331 The Sequence encode/decode function MUST support the Redundancy tag 332 (R-TAG) format as per Clause 7.8 of IEEE 802.1CB [IEEE8021CB]. 334 A TSN-aware IP (DetNet) node implementations MUST support the Stream 335 splitting function and the Individual recovery function as defined in 336 Clause 7.7 and 7.5 of IEEE 802.1CB [IEEE8021CB] when the node is a 337 replication or elimination point for FRER. 339 4.3. Service protection within the TSN sub-network 341 TSN Streams supporting DetNet flows may use Frame Replication and 342 Elimination for Redundancy (FRER) as defined in Clause 8. of IEEE 343 802.1CB [IEEE8021CB] based on the loss service requirements of the 344 TSN Stream, which is derived from the DetNet service requirements of 345 the DetNet mapped flow. The specific operation of FRER is not 346 modified by the use of DetNet and follows IEEE 802.1CB [IEEE8021CB]. 348 FRER function and the provided service recovery is available only 349 within the TSN sub-network as the TSN Stream-ID and the TSN sequence 350 number are not valid outside the sub-network. An IP (DetNet) node 351 represents a L3 border and as such it terminates all related 352 information elements encoded in the L2 frames. 354 4.4. Aggregation during DetNet flow to TSN Stream mapping 356 Implementations of this document SHALL use management and control 357 information to map a DetNet flow to a TSN Stream. N:1 mapping 358 (aggregating DetNet flows in a single TSN Stream) SHALL be supported. 359 The management or control function that provisions flow mapping SHALL 360 ensure that adequate resources are allocated and configured to 361 provide proper service requirements of the mapped flows. 363 5. Management and Control Implications 365 DetNet flow and TSN Stream mapping related information are required 366 only for TSN-aware IP (DetNet) nodes. From the Data Plane 367 perspective there is no practical difference based on the origin of 368 flow mapping related information (management plane or control plane). 370 The following summarizes the set of information that is needed to 371 configure DetNet IP over TSN: 373 o DetNet IP related configuration information according to the 374 DetNet role of the DetNet IP node, as per [I-D.ietf-detnet-ip]. 376 o TSN related configuration information according to the TSN role of 377 the DetNet IP node, as per [IEEE8021Q], [IEEE8021CB] and 378 [IEEEP8021CBdb]. 380 o Mapping between DetNet IP flow(s) (as flow identification defined 381 in [I-D.ietf-detnet-ip], it is summarized in Section 5.1 of that 382 document, and includes all wildcards, port ranges and the ability 383 to ignore specific IP fields) and TSN Stream(s) (as stream 384 identification information defined in [IEEE8021CB] and 385 [IEEEP8021CBdb]). Note, that managed objects for TSN Stream 386 identification can be found in [IEEEP8021CBcv]. 388 This information MUST be provisioned per DetNet flow. 390 TSN-aware IP DetNet nodes are member of both the DetNet domain and 391 the TSN sub-network. Within the TSN sub-network the TSN-aware IP 392 (DetNet) node has a TSN-aware Talker/Listener role, so TSN specific 393 management and control plane functionalities must be implemented. 394 There are many similarities in the management plane techniques used 395 in DetNet and TSN, but that is not the case for the control plane 396 protocols. For example, RSVP-TE and MSRP behaves differently. 397 Therefore management and control plane design is an important aspect 398 of scenarios, where mapping between DetNet and TSN is required. 400 In order to use a TSN sub-network between DetNet nodes, DetNet 401 specific information must be converted to TSN sub-network specific 402 ones. DetNet flow ID and flow related parameters/requirements must 403 be converted to a TSN Stream ID and stream related parameters/ 404 requirements. Note that, as the TSN sub-network is just a portion of 405 the end-to-end DetNet path (i.e., single hop from IP perspective), 406 some parameters (e.g., delay) may differ significantly. Other 407 parameters (like bandwidth) also may have to be tuned due to the L2 408 encapsulation used within the TSN sub-network. 410 In some case it may be challenging to determine some TSN Stream 411 related information. For example, on a TSN-aware IP (DetNet) node 412 that acts as a Talker, it is quite obvious which DetNet node is the 413 Listener of the mapped TSN stream (i.e., the IP Next-Hop). However 414 it may be not trivial to locate the point/interface where that 415 Listener is connected to the TSN sub-network. Such attributes may 416 require interaction between control and management plane functions 417 and between DetNet and TSN domains. 419 Mapping between DetNet flow identifiers and TSN Stream identifiers, 420 if not provided explicitly, can be done by a TSN-aware IP (DetNet) 421 node locally based on information provided for configuration of the 422 TSN Stream identification functions (IP Stream identification, Mask- 423 and-match Stream identification and active Stream identification 424 function). 426 Triggering the setup/modification of a TSN Stream in the TSN sub- 427 network is an example where management and/or control plane 428 interactions are required between the DetNet and TSN sub-network. 429 TSN-unaware IP (DetNet) nodes make such a triggering even more 430 complicated as they are fully unaware of the sub-network and run 431 independently. 433 Configuration of TSN specific functions (e.g., FRER) inside the TSN 434 sub-network is a TSN domain specific decision and may not be visible 435 in the DetNet domain. 437 6. Security Considerations 439 Security considerations for DetNet are described in detail in 440 [I-D.ietf-detnet-security]. General security considerations are 441 described in [RFC8655]. DetNet IP data plane specific considerations 442 are summarized in [I-D.ietf-detnet-ip]. This section considers 443 exclusively security considerations which are specific to the DetNet 444 IP over TSN sub-network scenario. 446 The sub-network between DetNet nodes needs to be subject to 447 appropriate confidentiality. Additionally, knowledge of what DetNet/ 448 TSN services are provided by a sub-network may supply information 449 that can be used in a variety of security attacks. The ability to 450 modify information exchanges between connected DetNet nodes may 451 result in bogus operations. Therefore, it is important that the 452 interface between DetNet nodes and TSN sub-network are subject to 453 authorization, authentication, and encryption. 455 The TSN sub-network operates at Layer-2 so various security 456 mechanisms defined by IEEE can be used to secure the connection 457 between the DetNet nodes (e.g., encryption may be provided using 458 MACSec [IEEE802.1AE-2018]). 460 7. IANA Considerations 462 None. 464 8. Acknowledgements 466 The authors wish to thank Norman Finn, Lou Berger, Craig Gunther, 467 Christophe Mangin and Jouni Korhonen for their various contributions 468 to this work. 470 9. References 472 9.1. Normative references 474 [I-D.ietf-detnet-ip] 475 Varga, B., Farkas, J., Berger, L., Fedyk, D., and S. 476 Bryant, "DetNet Data Plane: IP", draft-ietf-detnet-ip-06 477 (work in progress), April 2020. 479 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 480 Requirement Levels", BCP 14, RFC 2119, 481 DOI 10.17487/RFC2119, March 1997, 482 . 484 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 485 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 486 May 2017, . 488 9.2. Informative references 490 [I-D.ietf-detnet-flow-information-model] 491 Varga, B., Farkas, J., Cummings, R., Jiang, Y., and D. 492 Fedyk, "DetNet Flow Information Model", draft-ietf-detnet- 493 flow-information-model-10 (work in progress), May 2020. 495 [I-D.ietf-detnet-security] 496 Mizrahi, T. and E. Grossman, "Deterministic Networking 497 (DetNet) Security Considerations", draft-ietf-detnet- 498 security-10 (work in progress), May 2020. 500 [IEEE802.1AE-2018] 501 IEEE Standards Association, "IEEE Std 802.1AE-2018 MAC 502 Security (MACsec)", 2018, 503 . 505 [IEEE8021CB] 506 Finn, N., "Draft Standard for Local and metropolitan area 507 networks - Seamless Redundancy", IEEE P802.1CB 508 /D2.1 P802.1CB, December 2015, 509 . 512 [IEEE8021Q] 513 IEEE 802.1, "Standard for Local and metropolitan area 514 networks--Bridges and Bridged Networks (IEEE Std 802.1Q- 515 2014)", 2014, . 517 [IEEEP8021CBcv] 518 Kehrer, S., "FRER YANG Data Model and Management 519 Information Base Module", IEEE P802.1CBcv 520 /D0.3 P802.1CBcv, May 2020, 521 . 524 [IEEEP8021CBdb] 525 Mangin, C., "Extended Stream identification functions", 526 IEEE P802.1CBdb /D0.2 P802.1CBdb, August 2019, 527 . 530 [RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas, 531 "Deterministic Networking Architecture", RFC 8655, 532 DOI 10.17487/RFC8655, October 2019, 533 . 535 Authors' Addresses 537 Balazs Varga (editor) 538 Ericsson 539 Magyar Tudosok krt. 11. 540 Budapest 1117 541 Hungary 543 Email: balazs.a.varga@ericsson.com 545 Janos Farkas 546 Ericsson 547 Magyar Tudosok krt. 11. 548 Budapest 1117 549 Hungary 551 Email: janos.farkas@ericsson.com 553 Andrew G. Malis 554 Malis Consulting 556 Email: agmalis@gmail.com 558 Stewart Bryant 559 Futurewei Technologies 561 Email: stewart.bryant@gmail.com