idnits 2.17.1 draft-bernardos-raw-joint-selection-raw-mec-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 22, 2021) is 1152 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-05) exists of draft-bernardos-raw-mec-01 == Outdated reference: A later version (-11) exists of draft-ietf-raw-use-cases-00 == Outdated reference: A later version (-09) exists of draft-pthubert-raw-architecture-05 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RAW WG CJ. Bernardos 3 Internet-Draft UC3M 4 Intended status: Standards Track A. Mourad 5 Expires: August 26, 2021 InterDigital 6 February 22, 2021 8 Terminal-based joint selection and configuration of MEC host and RAW 9 network 10 draft-bernardos-raw-joint-selection-raw-mec-00 12 Abstract 14 There are several scenarios involving multi-hop heterogeneous 15 wireless networks requiring reliable and available features combined 16 with multi-access edge computing, such as Industry 4.0. This 17 document discusses mechanisms to allow a terminal influencing the 18 selection of a MEC host for instantiation of the terminal-targeted 19 MEC applications and functions, and (re)configuring the RAW network 20 lying in between the terminal and the selected MEC host. This 21 document assumes IETF RAW and ETSI MEC integration, fostering 22 discussion about extensions at both IETF and ETSI MEC to better 23 support these scenarios. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on August 26, 2021. 42 Copyright Notice 44 Copyright (c) 2021 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction and Problem Statement . . . . . . . . . . . . . 2 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 3. Terminal-based joint selection and configuration of MEC host 62 and RAW network . . . . . . . . . . . . . . . . . . . . . . . 6 63 3.1. Extended User application look-up to support reliability 64 and availability information/capabilities . . . . . . . . 7 65 3.2. Extended Application context create to support 66 reliability and availability information/capabilities . . 9 67 3.3. Extended Application context update to support 68 reliability and availability information/capabilities . . 11 69 3.4. Receiving extended notification events . . . . . . . . . 12 70 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 71 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 72 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 73 7. Informative References . . . . . . . . . . . . . . . . . . . 13 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 76 1. Introduction and Problem Statement 78 Wireless operates on a shared medium, and transmissions cannot be 79 fully deterministic due to uncontrolled interferences, including 80 self-induced multipath fading. RAW (Reliable and Available Wireless) 81 is an effort to provide Deterministic Networking on across a path 82 that include a wireless interface. RAW provides for high reliability 83 and availability for IP connectivity over a wireless medium. The 84 wireless medium presents significant challenges to achieve 85 deterministic properties such as low packet error rate, bounded 86 consecutive losses, and bounded latency. RAW extends the DetNet 87 Working Group concepts to provide for high reliability and 88 availability for an IP network utilizing scheduled wireless segments 89 and other media, e.g., frequency/time-sharing physical media 90 resources with stochastic traffic: IEEE Std. 802.15.4 timeslotted 91 channel hopping (TSCH), 3GPP 5G ultra-reliable low latency 92 communications (URLLC), IEEE 802.11ax/be, and L-band Digital 93 Aeronautical Communications System (LDACS), etc. Similar to DetNet, 94 RAW technologies aim at staying abstract to the radio layers 95 underneath, addressing the Layer 3 aspects in support of applications 96 requiring high reliability and availability. 98 As introduced in [I-D.pthubert-raw-architecture], RAW separates the 99 path computation time scale at which a complex path is recomputed 100 from the path selection time scale at which the forwarding decision 101 is taken for one or a few packets. RAW operates at the path 102 selection time scale. The RAW problem is to decide, amongst the 103 redundant solutions that are proposed by the Patch Computation 104 Element (PCE), which one will be used for each packet to provide a 105 Reliable and Available service while minimizing the waste of 106 constrained resources. To that effect, RAW defines the Path 107 Selection Engine (PSE) that is the counter-part of the PCE to perform 108 rapid local adjustments of the forwarding tables within the diversity 109 that the PCE has selected for the Track. The PSE enables to exploit 110 the richer forwarding capabilities with Packet (hybrid) ARQ, 111 Replication, Elimination and Ordering (PAREO), and scheduled 112 transmissions at a faster time scale. 114 Multi-access Edge Computing (MEC) -- formerly known as Mobile Edge 115 Computing -- capabilities deployed in the edge of the mobile network 116 can facilitate the efficient and dynamic provision of services to 117 mobile users. The ETSI ISG MEC working group, operative from end of 118 2014, intends to specify an open environment for integrating MEC 119 capabilities with service providers' networks, including also 120 applications from 3rd parties. These distributed computing 121 capabilities will make available IT infrastructure as in a cloud 122 environment for the deployment of functions in mobile access 123 networks. 125 One relevant exemplary scenario showing the need for an integration 126 of RAW and MEC is introduced next. One of the main (and distinct) 127 use cases of 5G is Ultra Reliable and Low Latency Communications 128 (URLLC). Among the many so-called "verticals" that require URLLC 129 features, the Industry 4.0 (also referred to as Wireless for 130 Industrial Applications) is probably the one with more short-term 131 potential. As identified in [I-D.ietf-raw-use-cases], this scenario 132 also calls for RAW solutions, as cables are not that suitable for the 133 robots and mobile vehicles typically used in factories. This is also 134 a very natural scenario for MEC deployments, as bounded, and very low 135 latencies are needed between the robots and physical actuators and 136 the control logic managing them. 138 This scenario includes a wireless domain, involving multiple MEC 139 platforms to ensure low latency to applications, by being able to 140 host MEC applications in several locations, and dynamically migrate 141 the apps as the terminals move around and the serving MEC platform 142 might no longer be capable of meeting the latency requirements. 144 This document discussess mechanisms to allow the UE to influence/ 145 control jointly the RAW and MEC components deployed in the end-to-end 146 path. 148 ----------- 149 | PCE | 150 -----+----- 151 | 152 --+-- 153 ( ) 154 ( ) 155 ( ) 156 --+-- 157 | 158 ----------- 159 | RAW PSE | 160 -----+----- 161 | 162 ____________________+__________________________________ 163 | *( ( o ) ) | 164 | RAW * * ^ | 165 | network ****** * / \ | 166 | ******* * / \ ----- | 167 | * ** ------- |app| | 168 | * * | RAW | ------- | 169 | ( ( o ) )* * |node |-| MEC | | 170 | ----- ^ *( ( o ) ) ------- ------- | 171 | |app| / \ ^ * | 172 | ----- / \ / \ ** | 173 | |app| ------- / \ *( ( o ) ) | 174 | ------- | RAW | ------- ^ (o | 175 | | MEC |------|node | | RAW | / \ -\---- | 176 | ------- ------- |node | / \ |term| | 177 | o) o) ------- ------- -0--0- | 178 | ----/- ----/- | RAW | | 179 | |term| |term| |node | | 180 | -0--0- -0--0- ------- | 181 |_______________________________________________________| 183 Figure 1: Exemplary scenario depicting MEC and RAW in an industrial 184 environments 186 Figure 1 depicts an exemplary scenario that integrates a 3GPP 5G 187 network, with ETSI MEC deployed at the edge, and an IETF RAW-capable 188 wireless multi-hop backhaul segment connecting the RAN and the MEC 189 hosts and UPFs. This setup can be used for example in a factory 190 where multiple robots and AGVs are wirelessly connected, and 191 controlled via remote apps. Control applications running in the edge 192 (implemented as MEC applications) require bounded low latencies and a 193 guaranteed availability, despite the mobility of the terminals and 194 the changing wireless conditions. An heterogeneous wireless mesh 195 network is used to provide connectivity inside the factory. 197 [I-D.bernardos-raw-mec] explores already the integration of RAW and 198 MEC. The current document goes a bit further, proposing solutions to 199 allow terminal-based selection of the MEC platform where to 200 instantiate an app taking into account RAW aspects. 202 2. Terminology 204 The following terms used in this document are defined by the ETSI MEC 205 ISG, and the IETF: 207 MEC host. The mobile edge host is an entity that contains a 208 mobile edge platform and a virtualization infrastructure which 209 provides compute, storage, and network resources, for the purpose 210 of running mobile edge applications. 212 MEC platform. The mobile edge platform is the collection of 213 essential functionalities required to run mobile edge applications 214 on a particular virtualization infrastructure and enable them to 215 provide and consume mobile edge services. 217 MEPM. MEC Platform Manager. 219 MEC applications. Mobile edge applications are instantiated on 220 the virtualization infrastructure of the mobile edge host based on 221 configuration requests validated by the mobile edge management. 223 PAREO. Packet (hybrid) ARQ, Replication, Elimination and 224 Ordering. PAREO is a superset Of DetNet's PREOF that includes 225 radio-specific techniques such as short range broadcast, MUMIMO, 226 constructive interference and overhearing, which can be leveraged 227 separately or combined to increase the reliability. 229 PSE. The Path Selection Engine (PSE) is the counter-part of the 230 PCE to perform rapid local adjustments of the forwarding tables 231 within the diversity that the PCE has selected for the Track. The 232 PSE enables to exploit the richer forwarding capabilities with 233 PAREO and scheduled transmissions at a faster time scale over the 234 smaller domain that is the Track, in either a loose or a strict 235 fashion. 237 UALCMP. The User Application LifeCycle Management Proxy (UALCMP) 238 exposes the Mx2 API to the device application. It allows the 239 device application to request the following application lifecycle 240 management operations from the MEC system: query the available 241 applications, instantiation and deletion of an application and 242 update of an existing application context. 244 3. Terminal-based joint selection and configuration of MEC host and RAW 245 network 247 This document defines extensions to: (i) enable a terminal to 248 discover any RAW-enabled network on the path between the terminal and 249 the MEC app host, and the RAW network associated capabilities; (ii) 250 enable the terminal to request desired reliability and availability 251 requirements to be met simultaneously by the MEC+RAW system; and, 252 (iii) enable direct notifications from the RAW network to the 253 terminal, to help with end-to-end application-level optimization. 254 Most of the required extensions are related to ETSI MEC components 255 and interfaces, and therefore are out of the scope of the IETF. 256 However, we still briefly describe them for completeness, putting the 257 main focus on the IETF RAW components and interactions. 259 Figure 2 shows the components and interfaces impacted by the 260 extensions described in this document. The MEC UALCMP is logically 261 extended with a RAW controller (RAW ctrl) functionality, to enable a 262 terminal to learn about the RAW and MEC capabilities of the 5G 263 network it is attached to, and specify its requirements in terms of 264 availability and reliability for joint MEC app instantiation and RAW 265 network configuration. 267 ------------ 268 | MEC host | 269 ------+----- 270 ------------ ---------- | 271 | User | | Mobile | ------+--------------------- 272 | App. LCM +---+ edge | | MEC host | 273 | Proxy | | orch. | | ----------------- | 274 ------------ ---------- | + ------ ------ | | 275 | RAW | | ----- | | ME | |RAW | | | 276 | ctrl| -----------+ |app+..+ |serv| |ctrl| | | 277 ---+--- | | ----- | ------ ------ | | 278 | +--+--+ | |app+..+ MEC platform | | 279 | | RAW | | ----- ----------------- | 280 +-----.+ PSE | ---------------------------- 281 +-+-+-+ 282 | | ( ( o ) ) ( ( o ) ) 283 | | ^ ^ 284 | | / \ / \ 285 | | / \ / \ 286 | | ------- ------- 287 | +-----------| RAW |-------+ RAW | 288 +-------------+node | |node | 289 ------- ------- 291 Figure 2: Block diagram 293 The RAW ctrl - RAW PSE interface was first introduced in 294 [I-D.bernardos-raw-mec]. 296 3.1. Extended User application look-up to support reliability and 297 availability information/capabilities 299 Here we specify how the terminal/UE is augmented with the additional 300 capability of discovering a RAW network on the path to the hosts of 301 its target MEC applications, and obtaining information about 302 reliability and availability configuration in the RAW network. 304 Figure 3 shows an exemplary signaling flow diagram. 306 +--------------+ 307 +----------+ | MEC host | 308 +--+ | UALCMP | +---+ +----+ +----+ +----+ | +----+ | 309 |UE| +---+----+-+ |RAW| |MEAO| |RAW | |RAW | | +---+ |RAW | | 310 +--+ | |RAW | |PSE| +----+ |node| |node| | |MEP| |ctrl| | 311 | | |ctrl| +---+ | +----+ +----+ | +---+ +----+ | 312 | | +----+ | | | | +---|------|---+ 313 | | | |<...RAW........>| | | | 314 | | | |<...signalling.........>| | | 315 | | | | | | | | | 316 |1.GET ../app_list | | | | | | 317 |....>| | | | | | | | 318 | |........MEC...........>|.....MEC................>| | 319 | |<.......signalling.....|<....signalling..........| | 320 | | | | | | | | | 321 | |2.RAW info req.| | | | | | 322 | |...>|.........>| | | | | | 323 | |<...|<.........| | | | | | 324 | | | | | | | | | 325 |2.200 OK | | | | | | | 326 |(Application List) | | | | | | 327 | | | | | | | | | 329 Figure 3: Extended User application look-up 331 We next explain each of the steps illustrated in the figure: 333 1. An application that requires use of a MEC app with specific 334 reliability/availability requirements is started at the UE. The 335 UE can either make use of a GET request to the MEC UALCMP 336 extended to indicate that the UE is interested in reliability and 337 availability information, or the UALCMP can decide to include 338 this information based on policies. Either way, the UALCMP 339 authorizes the request from the UE. The MEC system retrieves the 340 list of UE applications available to the requesting UE (this 341 might require interaction with other MEC system level components 342 such as MEAO as depicted optionally in the figure). 344 2. The UALCMP requests information related to reliability and 345 availability from the RAW PSE through the RAW ctrl logical 346 component. 348 3. The UALCMP returns the 200 OK response to the device application, 349 following ETSI MEC standards, but with its message body extended 350 to include RAW parameters (namely, Reliability and availability 351 characteristics of the application and its connectivity), such 352 as: 354 * The assured round trip time in milliseconds supported by the 355 MEC system for the MEC application instance. 357 * The assured connection bandwidth in kbit/s for the use of the 358 MEC application instance. 360 * The assured jitter in milliseconds supported by the MEC system 361 for the MEC application instance. 363 * The maximum percentage of packets failed. 365 * The assured number of redundant paths supported by the MEC 366 system for the MEC application instance. 368 3.2. Extended Application context create to support reliability and 369 availability information/capabilities 371 Here we specify how the UE is augmented with the capability to 372 request the creation of a MEC app including requirements about 373 reliability and availability. 375 +--------------+ 376 +----------+ | MEC host | 377 +--+ | UALCMP | +---+ +----+ +----+ +----+ | +----+ | 378 |UE| +---+----+-+ |RAW| |MEAO| |RAW | |RAW | | +---+ |RAW | | 379 +--+ | |RAW | |PSE| +----+ |node| |node| | |MEP| |ctrl| | 380 | | |ctrl| +---+ | +----+ +----+ | +---+ +----+ | 381 | | +----+ | | | | +---|------|---+ 382 | | | |<..RAW.........>| | | | 383 | | | |<..signalling..........>| | | 384 | | | | | | | | | 385 |1.POST ../app_context| | | | | | 386 |....>| | | | | | | | 387 | |..MEC signalling......>|..MEC signalling........>| | 388 | | | | | | | 2.MEC-to-RAW 389 | | | | | | | |.....>| 390 | | | |<..2.RAW................................| 391 | | |<.........|....signalling.>| | | | 392 | | | |.......................>| | | 393 | | | | | | | |<.....| 394 | |<......MEC.signalling..|<........MEC signalling..| | 395 | | | | | | | | | 396 |3.201 Created | | | | | | 397 |(AppContext) | | | | | | 398 | | | | | | | | | 400 Figure 4: Application context create 402 Figure 4 shows an exemplary signaling flow diagram. We next explain 403 each of the steps illustrated in the figure: 405 1. The UE submits the POST request to the UALCMP. The message body 406 contains the data structure for the application context to be 407 created, which is extended to include reliability and 408 availability attributes: 410 * The assured round trip time in milliseconds supported by the 411 MEC system for the MEC application instance. 413 * The assured connection bandwidth in kbit/s for the use of the 414 MEC application instance. 416 * The assured jitter in milliseconds supported by the MEC system 417 for the MEC application instance. 419 * The maximum percentage of packets failed. 421 * The assured number of redundant paths supported by the MEC 422 system for the MEC application instance. 424 The UALCMP authorizes the request from the device application. 425 The request is forwarded to the MEC system level management, 426 which makes the decision on granting the context creation 427 request. The MEC orchestrator triggers the creation of the 428 application context in the MEC system, including the information 429 about reliability and availability requirements. The UALCMP 430 request the context creation to the MEAO, this request including 431 the reliability and availability requirements of the application. 432 The MEAO selects where to instantiate the application (meaning 433 the MEC host and MEC platform), so it can meet all the 434 requirements. 436 2. The MEP request to the local RAW ctrl to establish the 437 connectivity between the app and the UE meeting the indicated 438 reliability and availability requirements. This involves 439 additional steps between the RAW ctrl, the RAW PSE and the RAW 440 nodes that are part of the established path(s), as described in 441 [I-D.bernardos-raw-mec]. 443 3. The UALCMP returns the 201 Created response to the UE with the 444 message body containing the data structure of the created 445 application context. 447 3.3. Extended Application context update to support reliability and 448 availability information/capabilities 450 Here we specify how the UE is augmented with the capability to 451 request the update of the context of a MEC app including requirements 452 about reliability and availability. One example would be 453 communicating new reliability/availability requirements. 455 +--------------+ 456 +----------+ | MEC host | 457 +--+ | UALCMP | +---+ +----+ +----+ +----+ | +----+ | 458 |UE| +---+----+-+ |RAW| |MEAO| |RAW | |RAW | | +---+ |RAW | | 459 +--+ | |RAW | |PSE| +----+ |node| |node| | |MEP| |ctrl| | 460 | | |ctrl| +---+ | +----+ +----+ | +---+ +----+ | 461 | | +----+ | | | | +---|------|---+ 462 | | | |<..RAW.........>| | | | 463 | | | |<..signalling..........>| | | 464 | | | | | | | | | 465 |1.PUT ../app_contexts| | | | | | 466 | {contextID} (AppContext) | | | | | 467 |....>| | | | | | | | 468 | |..MEC signalling......>|..MEC signalling........>| | 469 | | | | | | | 2.MEC-to-RAW 470 | | | | | | | |.....>| 471 | | | |<..2.RAW................................| 472 | | |<.........|...signalling..>| | | | 473 | | | |.......................>| | | 474 | | | | | | | |<.....| 475 | |<......MEC.signalling..|<........MEC signalling..| | 476 | | | | | | | | | 477 |3.204 No Content | | | | | | 478 |<....| | | | | | | | 479 | | | | | | | | | 481 Figure 5: Application context update 483 Figure 5 shows an exemplary signaling flow diagram. We next explain 484 each of the steps illustrated in the figure: 486 1. An application running on the UE making use of a MEC app might 487 change its requirements for the MEC app and associated 488 reliability and availability (for example, in an Industry 4.0 489 scenario, a robot control app might be required less latency to 490 improve its precision). The UE updates a specific application 491 context by sending a PUT request to the resource within the MEC 492 system that represents it, with the message body containing the 493 modified data structure of AppContext in which only the callback 494 reference and/or application location constraints, and/or the 495 application reliability and availability requirements (e.g., 496 assured bandwidth, latency and reliability) may be updated. 498 2. Through interactions with the RAW ctrl, the RAW PSE is indicated 499 to perform the required updates in the RAW network (via 500 signalling with RAW nodes). 502 3. The UALCMP returns a "204 No Content" response. 504 3.4. Receiving extended notification events 506 Here we specify how the UE can receive updates about the RAW 507 connectivity experienced by a MEC application, so it can react in 508 time (e.g., implementing changes at the application level or 509 selecting another point of attachment/slice). 511 +--------------+ 512 +----------+ | MEC host | 513 +--+ | UALCMP | +---+ +----+ +----+ +----+ | +----+ | 514 |UE| +---+----+-+ |RAW| |MEAO| |RAW | |RAW | | +---+ |RAW | | 515 +--+ | |RAW | |PSE| +----+ |node| |node| | |MEP| |ctrl| | 516 | | |ctrl| +---+ | +----+ +----+ | +---+ +----+ | 517 | | +----+ | | | | +---|------|---+ 518 | | | |<..RAW.........>| | | | 519 | | | |<..signalling..........>| | | 520 | | | | | | | | | 521 | | | Event occurs (e.g., it is no longer | | 522 | | | to keep assured RAW conditions) | | 523 | | | | | | | | | 524 | | | |1.MEC-to-RAW | | | | 525 | | | |.......................................>| 526 | | | | | | | |<.....| 527 | |<......MEC signalling..|<........MEC signalling..| | 528 | | | | | | | | | 529 |2.POST ../callback_ref | | | | | 530 | ({Notification}) | | | | | | 531 |<....| | | | | | | | 532 |3.204 No Content | | | | | | 533 |....>| | | | | | | | 534 | | | | | | | | | 536 Figure 6: Receiving notification events 538 Figure 5 shows an exemplary signaling flow diagram. We next explain 539 each of the steps illustrated in the figure: 541 1. If a change of the assured RAW conditions happens (which is 542 detected via RAW OAM mechanisms, out of the scope of this 543 document, and then notified to the MEC platform), this event 544 reaches the MEC orchestrator, and finally the UALCMP. 546 2. The UALCMP sends a POST message to the callback reference address 547 provided by the device application as part of application context 548 creation, with the message body containing the {Notification} 549 data structure. The variable {Notification} is replaced with the 550 data type specified for different notification events as 551 specified in ETSI MEC standards, extended to include a 552 modification to the RAW conditions offered to the user 553 application instance: 555 * Updated assured round trip time in milliseconds supported by 556 the MEC system for the MEC application instance. 558 * Updated assured connection bandwidth in kbit/s for the use of 559 the MEC application instance. 561 * Updated maximum percentage of packets failed. 563 * Updated assured jitter in milliseconds supported by the MEC 564 system for the MEC application instance. 566 * Updated assured number of redundant paths supported by the MEC 567 system for the MEC application instance. 569 3. The device application sends a "204 No Content" response to the 570 UALCMP. 572 4. IANA Considerations 574 TBD. 576 5. Security Considerations 578 TBD. 580 6. Acknowledgments 582 The work in this draft will be further developed and explored under 583 the framework of the H2020 5Growth (Grant 856709). 585 7. Informative References 587 [I-D.bernardos-raw-mec] 588 Bernardos, C. and A. Mourad, "Extensions to enable 589 wireless reliability and availability in multi- access 590 edge deployments", draft-bernardos-raw-mec-01 (work in 591 progress), January 2021. 593 [I-D.ietf-raw-use-cases] 594 Papadopoulos, G., Thubert, P., Theoleyre, F., and C. 595 Bernardos, "RAW use cases", draft-ietf-raw-use-cases-00 596 (work in progress), October 2020. 598 [I-D.pthubert-raw-architecture] 599 Thubert, P., Papadopoulos, G., and R. Buddenberg, 600 "Reliable and Available Wireless Architecture/Framework", 601 draft-pthubert-raw-architecture-05 (work in progress), 602 November 2020. 604 Authors' Addresses 606 Carlos J. Bernardos 607 Universidad Carlos III de Madrid 608 Av. Universidad, 30 609 Leganes, Madrid 28911 610 Spain 612 Phone: +34 91624 6236 613 Email: cjbc@it.uc3m.es 614 URI: http://www.it.uc3m.es/cjbc/ 616 Alain Mourad 617 InterDigital Europe 619 Email: Alain.Mourad@InterDigital.com 620 URI: http://www.InterDigital.com/