idnits 2.17.00 (12 Aug 2021) /tmp/idnits15028/draft-bernardos-raw-mec-03.txt: -(322): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(324): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(328): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(329): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(330): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(331): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(378): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(382): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(386): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(389): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(390): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(391): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(482): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(483): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(484): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(485): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(486): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(488): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(489): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(493): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(496): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(497): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(498): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(499): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(500): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(574): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(578): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(581): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(582): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(583): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(584): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(585): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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 37 instances of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 374 has weird spacing: '... | app ctrl ...' == Line 562 has weird spacing: '... |app ctrl|...' -- The document date (January 2022) is 119 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 (-04) exists of draft-ietf-raw-architecture-02 == Outdated reference: A later version (-04) exists of draft-ietf-raw-oam-support-03 == Outdated reference: A later version (-05) exists of draft-ietf-raw-use-cases-03 Summary: 0 errors (**), 0 flaws (~~), 6 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: 31 July 2022 InterDigital 6 January 2022 8 Extensions to enable wireless reliability and availability in multi- 9 access edge deployments 10 draft-bernardos-raw-mec-03 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 describes solutions integrating IETF RAW and ETSI MEC, 18 fostering discussion about extensions at both IETF and ETSI MEC to 19 better support these scenarios. 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 5 July 2022. 38 Copyright Notice 40 Copyright (c) 2022 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 (https://trustee.ietf.org/ 45 license-info) in effect on the date of publication of this document. 46 Please review these documents carefully, as they describe your rights 47 and restrictions with respect to this document. Code Components 48 extracted from this document must include Revised BSD License text as 49 described in Section 4.e of the Trust Legal Provisions and are 50 provided without warranty as described in the Revised BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5 57 4. RAW and MEC integration . . . . . . . . . . . . . . . . . . . 7 58 4.1. MEC app request for RAW . . . . . . . . . . . . . . . . . 8 59 4.2. RAW OAM triggering MEC app migration . . . . . . . . . . 11 60 4.3. MEC OAM for RAW updates . . . . . . . . . . . . . . . . . 13 61 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 62 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 63 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 64 8. Informative References . . . . . . . . . . . . . . . . . . . 15 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 67 1. Introduction 69 Wireless operates on a shared medium, and transmissions cannot be 70 fully deterministic due to uncontrolled interferences, including 71 self-induced multipath fading. RAW (Reliable and Available Wireless) 72 is an effort to provide Deterministic Networking on across a path 73 that include a wireless interface. RAW provides for high reliability 74 and availability for IP connectivity over a wireless medium. The 75 wireless medium presents significant challenges to achieve 76 deterministic properties such as low packet error rate, bounded 77 consecutive losses, and bounded latency. RAW extends the DetNet 78 Working Group concepts to provide for high reliability and 79 availability for an IP network utilizing scheduled wireless segments 80 and other media, e.g., frequency/time-sharing physical media 81 resources with stochastic traffic: IEEE Std. 802.15.4 timeslotted 82 channel hopping (TSCH), 3GPP 5G ultra-reliable low latency 83 communications (URLLC), IEEE 802.11ax/be, and L-band Digital 84 Aeronautical Communications System (LDACS), etc. Similar to DetNet, 85 RAW technologies aim at staying abstract to the radio layers 86 underneath, addressing the Layer 3 aspects in support of applications 87 requiring high reliability and availability. 89 As introduced in [I-D.ietf-raw-architecture], RAW separates the path 90 computation time scale at which a complex path is recomputed from the 91 path selection time scale at which the forwarding decision is taken 92 for one or a few packets. RAW operates at the path selection time 93 scale. The RAW problem is to decide, amongst the redundant solutions 94 that are proposed by the Patch Computation Element (PCE), which one 95 will be used for each packet to provide a Reliable and Available 96 service while minimizing the waste of constrained resources. To that 97 effect, RAW defines the Path Selection Engine (PSE) that is the 98 counter-part of the PCE to perform rapid local adjustments of the 99 forwarding tables within the diversity that the PCE has selected for 100 the Track. The PSE enables to exploit the richer forwarding 101 capabilities with Packet (hybrid) ARQ, Replication, Elimination and 102 Ordering (PAREO), and scheduled transmissions at a faster time scale. 104 Multi-access Edge Computing (MEC) -- formerly known as Mobile Edge 105 Computing -- capabilities deployed in the edge of the mobile network 106 can facilitate the efficient and dynamic provision of services to 107 mobile users. The ETSI ISG MEC working group, operative from end of 108 2014, intends to specify an open environment for integrating MEC 109 capabilities with service providers' networks, including also 110 applications from 3rd parties. These distributed computing 111 capabilities will make available IT infrastructure as in a cloud 112 environment for the deployment of functions in mobile access 113 networks. 115 One relevant exemplary scenario showing the need for an integration 116 of RAW and MEC is introduced next. One of the main (and distinct) 117 use cases of 5G is Ultra Reliable and Low Latency Communications 118 (URLLC). Among the many so-called "verticals" that require URLLC 119 features, the Industry 4.0 (also referred to as Wireless for 120 Industrial Applications) is probably the one with more short-term 121 potential. As identified in [I-D.ietf-raw-use-cases], this scenario 122 also calls for RAW solutions, as cables are not that suitable for the 123 robots and mobile vehicles typically used in factories. This is also 124 a very natural scenario for MEC deployments, as bounded, and very low 125 latencies are needed between the robots and physical actuators and 126 the control logic managing them. Figure 1 depicts an exemplary 127 scenario of a factory where terminals (robots and mobile automated 128 guided vehicles) are wirelessly connected. Control applications 129 running in the edge (implemented as MEC applications) require bounded 130 low latencies and a guaranteed availability, despite the mobility of 131 the terminals and the changing wireless conditions. An heterogeneous 132 wireless mesh network is used to provide connectivity inside the 133 factory. 135 ----------- 136 | PCE | 137 -----+----- 138 | 139 --+-- 140 ( ) 141 ( ) 142 ( ) 143 --+-- 144 | 145 ----------- 146 | RAW PSE | 147 -----+----- 148 | 149 ____________________+__________________________________ 150 | *( ( o ) ) | 151 | RAW * * ^ | 152 | network ****** * / \ | 153 | ******* * / \ ----- | 154 | * ** ------- |app| | 155 | * * | RAW | ------- | 156 | ( ( o ) )* * |node |-| MEC | | 157 | ----- ^ *( ( o ) ) ------- ------- | 158 | |app| / \ ^ * | 159 | ----- / \ / \ ** | 160 | |app| ------- / \ *( ( o ) ) | 161 | ------- | RAW | ------- ^ (o | 162 | | MEC |------|node | | RAW | / \ -\---- | 163 | ------- ------- |node | / \ |term| | 164 | o) o) ------- ------- -0--0- | 165 | ----/- ----/- | RAW | | 166 | |term| |term| |node | | 167 | -0--0- -0--0- ------- | 168 |_______________________________________________________| 170 Figure 1: Exemplary scenario depicting MEC and RAW in an industrial 171 environments 173 This scenario includes a wireless domain, involving multiple MEC 174 platforms to ensure low latency to applications, by being able to 175 host MEC applications in several locations, and dynamically migrate 176 the apps as the terminals move around and the serving MEC platform 177 might no longer be capable of meeting the latency requirements. 179 2. Terminology 181 The following terms used in this document are defined by the ETSI MEC 182 ISG, and the IETF: 184 MEC host. The mobile edge host is an entity that contains a 185 mobile edge platform and a virtualization infrastructure which 186 provides compute, storage, and network resources, for the purpose 187 of running mobile edge applications. 189 MEC platform. The mobile edge platform is the collection of 190 essential functionalities required to run mobile edge applications 191 on a particular virtualization infrastructure and enable them to 192 provide and consume mobile edge services. 194 MEPM. MEC Platform Manager. 196 MEC applications. Mobile edge applications are instantiated on 197 the virtualization infrastructure of the mobile edge host based on 198 configuration requests validated by the mobile edge management. 200 PAREO. Packet (hybrid) ARQ, Replication, Elimination and 201 Ordering. PAREO is a superset Of DetNet's PREOF that includes 202 radio-specific techniques such as short range broadcast, MUMIMO, 203 constructive interference and overhearing, which can be leveraged 204 separately or combined to increase the reliability. 206 PSE. The Path Selection Engine (PSE) is the counter-part of the 207 PCE to perform rapid local adjustments of the forwarding tables 208 within the diversity that the PCE has selected for the Track. The 209 PSE enables to exploit the richer forwarding capabilities with 210 PAREO and scheduled transmissions at a faster time scale over the 211 smaller domain that is the Track, in either a loose or a strict 212 fashion. 214 3. Problem Statement 216 With current standards, the MEC platform(s) would have to interact 217 with a Path Computation Element (PCE) for data plane requests and 218 updates. This tremendously limits the capabilities to guarantee 219 real-time forwarding decisions, as it will make it challenging and 220 not possible to manage forwarding decisions in real or near-real 221 time. 223 RAW solutions and approaches being explored today consider the role 224 of the PSE, which computes at a short time scale which of the 225 available paths (called tracks) -- computed by a PCE -- should be 226 used per flow/packet and also which PAREO functions can be used, in 227 order to provide the flow with the required availability and 228 reliability features. The PSE interacts with the PCE and with the 229 RAW nodes so they can setup the required per-flow state, to recognize 230 the flow and determine the forwarding policy to be applied. These 231 RAW forwarding decisions can be distributed among the necessary nodes 232 using in-band signaling (e.g., extending Segment Routing, BIER-TE or 233 DETNET tagging) or can be taken autonomously by each forwarding node 234 locally (based on its knowledge of the status of the network, gained 235 via OAM RAW-specific mechanisms). 237 Figure 1 shows an exemplary scenario, depicting an industrial 238 environment where different nodes are wirelessly connected to provide 239 connectivity to several stationary and mobile terminals (i.e., 240 robots). Industry environments are a good example of applications 241 where reliability and availability are critical. Ensuring this in 242 wireless heterogeneous and multi-hop networks requires using multiple 243 paths, using PAREO functions and even using dual or multiple 244 connectivity. Terminal mobility makes it even more challenging to 245 guarantee certain reliability and availability levels, due to the 246 dynamic and fast changes that this needs at the data plane level. 247 The short-time scale forwarding decisions that are required to ensure 248 reliability and availability with terminal mobility cannot be managed 249 if MEC platforms can only interact with the data plane through the 250 PCE. 252 The PCE is responsible for routing computation and maintenance in a 253 network and it is typically a centralized entity that can even reside 254 outside the network. It is meant to compute and establish redundant 255 paths, but not to be sensitive/reactive to transient changes, and 256 therefore is not capable of ensuring a certain level of reliability 257 and availability in a wireless heterogeneous mesh network, especially 258 if some of the nodes (e.g., the end terminals) might be mobile. With 259 currently standardized solutions, a MEC platform could only interact 260 with the RAW network through the PCE, most possibly through the Mp2 261 reference point defined by ETSI MEC. This reference point is defined 262 between the MEC platform and the data plane of the virtualization 263 infrastructure to instruct the data plane on how to route traffic 264 among applications, networks, services, etc. This reference point is 265 not further specified by ETSI MEC, but it would be the one that could 266 be used by current solutions to allow for MEC to request the data 267 plane on the RAW network a certain behavior (in terms of availability 268 and reliability) for MEC app traffic flows. With existing solutions, 269 the PCE would be the entry point for configuring and managing the RAW 270 network, probably through the Mp2 reference point. Note that the PCE 271 might reside outside the RAW network, the path between the RAW 272 network and the PCE might be expensive and slow (e.g., it might need 273 to traverse the whole RAW network) and reaching to the PCE can also 274 be slow in regards to the speed of events that affect the forwarding 275 operation at the radio layer. 277 Additionally, the MEC architecture as currently defined by ETSI does 278 not have any component designed to deal with the specifics of an 279 heterogeneous wireless multi-hop networks (such a RAW one), and 280 therefore, it is very limited in terms of what a MEC app (through the 281 MEC platform) can request to the data plane of an heterogeneous 282 wireless multi-hop network. Besides, this lack of RAW-aware 283 component at the ETSI MEC architecture prevents any enhancement at 284 either the MEC side (e.g., MEC app migrations triggered by RAW status 285 updates) or the RAW side (e.g., PAREO function updates triggered by 286 MEC app/terminal mobility). 288 Because of all these aforementioned reasons, it is needed to define a 289 new RAW-enabled component at the ETSI MEC architecture, aimed at 290 enabling a more direct interaction between the MEC platform and the 291 RAW network, allowing the MEC platform to notify events and/or 292 request actions to the RAW network quick enough. This involves some 293 challenges, as the RAW PSE has to understand the needs from the 294 running MEC applications, so it can properly configure the RAW nodes 295 so the data plane provides the required reliability and availability. 297 4. RAW and MEC integration 299 This document defines a new entity inside the MEC platform: the RAW 300 ctrl. This entity is responsible for computing what to instruct the 301 RAW PSE, based on the requirements of the MEC apps, as well as to 302 take decisions at the MEC side (e.g., migration of apps) based on 303 information about the RAW network status. 305 As a result of the introduction of the RAW ctrl and the actions it is 306 responsible of, new interactions and interface semantics are added. 307 These interactions and semantics can be terminated at either the PCE 308 or the RAW PSE, depending on the requirements of the MEC apps. For 309 near real-time coordination and control between MEC and RAW 310 mechanisms, the interactions are between the RAW ctrl and the RAW 311 PSE. We mostly refer to this deployment model from now on, as it is 312 the one that allow for near real-time updates on the forwarding 313 plane, but note that an alternative deployment model in which the RAW 314 ctrl interacts with the PCE is also possible, though only supporting 315 non real-time interactions. 317 The MEC-RAW new interface semantics/extensions depicted in Figure 2 318 allows the MEC platform to issue requests to the RAW network, through 319 the RAW PSE, so it can behave as required by MEC apps. 321 ------------ --- Data plane 322 | MEC host | ------- ··· Control plane 323 ---------- ------------ ·······+ PCE +·· 324 | Mobile | · · ---+--- ·( ( o ) ) ( ( o ) ) 325 | edge | ------+--------------·------ | · ^ ^ 326 | orch. | | MEC host · | | · / \ / \ 327 ----+----- | ------------·---- | | · / \ / \ 328 · ·············+ ------ ---+-- | --+-- ··+------ ------- 329 ----+----- · | ----- | | ME | |RAW +·····+RAW| | RAW +···+ RAW | 330 | Mobile | · | |app+··+ |serv| |ctrl| | | |PSE+····+node | |node + 331 | edge +·· | ----- | ------ ------ | | ----- ---+--+---+------ 332 |platform| | |app+··+ MEC platform | | | 333 |manager | | --+-- ----------------- | | 334 ---------- ----|----------------------- | 335 | | 336 +------------------------------------+ 338 Figure 2: Block diagram 340 The new semantics of the interface between the MEC platform and the 341 RAW PSE do not only serve to convey the requests, but also to 342 synchronize the status and topology of the RAW (relevant portion of 343 the) network, enabling to perform real-time or near-real time 344 forwarding decisions. In the sequel, we show different exemplary 345 signaling diagrams for the most relevant procedures. 347 4.1. MEC app request for RAW 349 Here we specify the interface extensions and signaling procedures 350 needed to enable a MEC app describe and request its needs in terms of 351 availability and reliability. As it will be further developed in 352 other subsections, the wireless network conditions could also have an 353 impact back on the MEC platform (e.g., by triggering the migration of 354 the MEC app). 356 Figure 3 shows an exemplary signaling flow diagram, in which a 357 certain MEC app request a given behavior for the treatment of the 358 packets the app generates. We consider an industrial wireless 359 application scenario, as the one used in previous sections, as an 360 example for the sake of describing the interface and specified 361 interactions. 363 The MEC platform is enhanced with a RAW ctrl entity, as introduced in 364 the previous section. The RAW ctrl is a RAW-aware component within 365 the MEC architecture that enables the required interactions with the 366 RAW network, through the RAW PSE. This allows MEC apps to: (i) adapt 367 to RAW conditions (e.g., if the requested reliability and 368 availability is not possible), and (ii) dynamically modify the 369 requested flow forwarding to the RAW network, based on the MEC app 370 and mobility conditions. 372 +-----------+ +-----+ +----+ +----+ +----+ +----+ 373 | RAW | | RAW | |RAW | |RAW | |RAW | |RAW | 374 | app ctrl | | PSE | |node| |node| |node| |term| 375 +-----------+ +-----+ +----+ +----+ +----+ +----+ 376 | | | | | | | 377 1.MEC app req. | | | | | 378 |····>| | | | | | 379 | | | | | | | 380 | 2a.MEC-to-RAW req. | | | | 381 |(flow ID,flow spec,reqs.) | | | | 382 | |··········>| | | | | 383 | | | | | | | 384 | 2b.MEC-to-RAW resp. | | | | 385 | (flow ID,status=OK) | | | | 386 | |<··········| | | | | 387 | | | 3.RAW control | | | 388 | | | (flow ID,flow spec,PAREO) | | 389 | | |··········>| | | | 390 | | |·····················>| | | 391 | | |································>| | 392 | | | | | | | 393 | 4a.MEC app | |4b.MEC app traffic w/ in-band | 394 | traffic | | RAW control (flow ID, PAREO) | 395 |<--------------------------->|<------------------->| | 396 | | | | (example: packet replication/ | 397 | | | | overhearing, elimination) | 398 | | | |<-------->|<-------->|<------->| 399 | | | | | | | 401 Figure 3: MEC app request for RAW 403 We next explain each of the steps illustrated in the figure: 405 1. A MEC app which is going to be consumed by a given terminal (or 406 set of terminals, though in this example we show just one 407 consumer), specifies to the MEC platform the characteristics of 408 the traffic is going to generate and its associated requirements. 410 2. The MEC platform -- namely the RAW ctrl component, which is RAW- 411 aware and knows the characteristics of the deployment -- analyzes 412 the characteristics of the MEC app traffic and the provided 413 requirements, and generates a new request -- over a new interface 414 between the MEC platform and the RAW PSE -- that includes, among 415 others, the following parameters: 417 * An ID for the given flow, which can be used for future near 418 real-time update/configuration operations on the same flow. 420 * The flow specification, describing the characteristics of the 421 packets, allowing an efficient identification of flow(s) based 422 on well-known fields in IPv4, IPv6, and transport layer 423 headers like TCP and UDP. An example of how to do this is 424 defined in the Traffic Selectors for Flow Bindings [RFC6088]. 426 * The requirements of the flow in terms of reliability and 427 availability. 429 3. The RAW PSE processes the request, and based on its knowledge of 430 the network (topology, node capabilities and ongoing flows) 431 computes the best way of transmitting the packets over the RAW 432 network (using the available paths/tracks, previously computed by 433 a PCE). Note that at this point it might be possible that the 434 RAW PSE realizes that it is not possible to provide the requested 435 reliability and availability characteristics, and would report 436 that back to the MEC platform (which might issue a new request 437 with less requirements). The RAW PSE sends control packets to 438 each of the RAW nodes involved, instructing how to deal with the 439 packets belonging to the MEC app flow. This includes: 441 * assigning an ID to the flow; 443 * instructing the entry point in the RAW network to tag packets 444 with that ID; 446 * specific PAREO functions to be used by each of the RAW nodes. 447 This might be signaled to each of the RAW nodes, or just to 448 some of them (e.g., only the entry point) who can then use in- 449 band signaling to specify it. 451 4. The MEC app generates traffic (step 4a in the figure) which 452 arrives at the RAW entry point in the network, which following 453 the instructions of the RAW PSE, encapsulates and tags the 454 packet, and might also include in-band signaling (e.g., using 455 Segment Routing). Some PAREO functions are applied to the MEC 456 app traffic packets (step 4b in the figure) to achieve the 457 required levels of reliability and availability. In the figure, 458 as an example, packets are replicated (this could be done by 459 means of wireless overhearing) at one point of the network, and 460 then later duplicated packets eliminated. 462 4.2. RAW OAM triggering MEC app migration 464 Here we specify the mechanisms for MEC to benefit from RAW OAM 465 information, for example, to trigger the migration of a MEC 466 application to a different MEC platform, to ensure that the 467 requirements of the MEC app continue to be met. 469 +----+ +--------+ +---+ +----+ +----+ +----+ +----+ 470 | | | RAW | |RAW| |RAW | |RAW | |RAW | |RAW | 471 |MEPM| |app ctrl| |PSE| |node| |node| |node| |term| 472 +----+ +--------+ +---+ +----+ +----+ +----+ +----+ 473 | | | | | | | | 474 | | MEC app | MEC app traffic w/ in-band | 475 | | traffic | RAW control (flow ID, PAREO) | 476 | |<--------------------->|<------------->| | 477 | | | | (example: packet replication/ | 478 | | | | overhearing, elimination) | 479 | | | | |<----->|<----->|<------>| 480 | | | | | | | | 481 | | | | 1.RAW OAM signalling | | 482 | +--------+ | | |<·······| | | | 483 | | RAW | | 2.MEC-to-RAW |<···············| | | 484 | |app ctrl| | (flow ID, |<·······················| | 485 | +--------+ | status=KO)|<································| 486 | | | | |<········| | | | | 487 |3.MEC app migration| | | | | | 488 |<·················>| | | | | | 489 |<·······>| | | | | | | | 490 | | | | | | | | | | 491 | | | 4a.MEC-to-RAW req.| | | | | 492 | | (flow ID,flow spec,reqs.) | | | | 493 | | |··················>| | | | | 494 | | 4b.MEC-to-RAW resp. | | | | | 495 | | (flow ID,status=OK) | 5.RAW control | | | 496 | | |<··················| (flow ID,flow spec,PAREO) | 497 | | | | | |·······>| | | | 498 | | | | | |···············>| | | 499 | | | | | |·······················>| | 500 | | | | | |································>| 501 | | | | | | | | | | 502 | 6a.MEC app| | | 6b.MEC app traffic w/ in-band | 503 | | traffic| | | RAW control (flow ID, PAREO) | 504 | |<------------------------------->|<------------->| | 505 | | | | | | (example: packet replication/ | 506 | | | | | | overhearing, elimination) | 507 | | | | | | |<----->|<----->|<------>| 508 | | | | | | | | | | 510 Figure 4: RAW OAM triggering MEC app migration 512 Figure 4 shows an exemplary signaling flow diagram, in which changes 513 in the RAW network, detected thanks to RAW OAM, trigger the migration 514 of a MEC app. We assume there is already a MEC app deployed and 515 traffic is already flowing (i.e., all the procedures explained in the 516 previous section took already place). We next explain each of the 517 steps illustrated in the figure: 519 1. RAW OAM signaling is periodically and reactively exchanged 520 between the RAW nodes and the RAW PSE [I-D.ietf-raw-oam-support]. 522 2. If the conditions of the network get worse (e.g., because of 523 changes in the radio propagation of a critical link), making it 524 impossible to guarantee the required levels of reliability and 525 availability, this generates a message from the RAW PSE to the 526 MEC platform, indicating that a given MEC app flow can no longer 527 be served. 529 3. The currently serving MEC platform triggers a MEC app migration 530 to a different MEC platform. This involves the MEC platform 531 manager. Note that the MEC platform might provide suggestions 532 regarding where to migrate the MEC app, based on its knowledge of 533 the RAW network status, acquired by the RAW ctrl through 534 interactions with the PSE. 536 4. The same steps 2-3-4 specified in the procedure described in 537 Section 4.1 take place. In this step, the MEC platform generates 538 a new request to the RAW PSE. 540 5. The RAW PSE processes the request, and based on its knowledge of 541 the network computes the best way of transmit the packets over 542 the RAW network. The RAW PSE sends control packets to each of 543 the RAW nodes involved. 545 6. The MEC app generates traffic, arriving at the RAW entry point in 546 the network, which following the instructions of the RAW PSE, 547 encapsulates and tags the packet. 549 4.3. MEC OAM for RAW updates 551 There are scenarios and situations where -- due to the mobility of 552 the terminals or the nodes hosting the MEC platform hosting a given 553 MEC app -- it might be needed to take actions on the RAW network: 554 e.g., to update the paths, apply different PAREO functions, migrate 555 the MEC app (thus involving a change in the RAW forwarding). This 556 triggers the need for mechanisms enabling the RAW PSE to get and use 557 MEC OAM information to update traffic forwarding at the RAW network 558 as needed to adapt to varying conditions, e.g., due to node mobility. 560 +---------+ +-----+ +----+ +----+ +----+ +----+ +----+ 561 | RAW | | RAW | |RAW | |RAW | |RAW | |RAW | |RAW | 562 |app ctrl| | PSE | |node| |node| |node| |node| |term| 563 +---------+ +-----+ +----+ +----+ +----+ +----+ +----+ 564 | | | | | | | | 565 | MEC app | | MEC app traffic w/ in-band | 566 | traffic | | RAW control (flow ID, PAREO) | 567 |<------------------------>|<--------------->| | | 568 | | | | (example: packet replication/ | 569 | | | | overhearing, elimination) | 570 | | | |<------>|<------>|<-------------->| 571 | | | | | | | | 572 | |1a.Mobility trigger | | | | | 573 | |(flow ID,trajectory)| | | | | 574 | |········>| | | | | | 575 | | | | | | | | 576 | |1b.Mobility trigger ACK | | | | 577 | |(flow ID)| | | | | | 578 | |<········| | | | | | 579 | | | 2.RAW control | | | | 580 | | | (flow ID,flow spec,PAREO) | | | 581 | | |·········>| | | | | 582 | | |··················>| | | | 583 | | |···························>| | | 584 | | |····································>| | 585 | | |············································>| 586 | | | | | | | | 587 | 3a.MEC app | |3b.MEC app traffic w/ in-band | 588 | traffic | | RAW control (flow ID, PAREO) | 589 |<------------------------>|<--------------->|<------>| | 590 | | | | (example: packet replication/ | 591 | | | | overhearing, elimination) | 592 | | | |<-------->|<---->|<------>|<----->| 593 | | | | | | | | 595 Figure 5: MEC OAM for RAW updates 597 Figure 5 shows an exemplary signaling flow diagram, in which the 598 mobility of the a node (in this case the terminal, but it could have 599 been the MEC platform hosting the MEC app) triggers the need for 600 updating RAW forwarding mechanisms. As in the previous section, we 601 assume there is already a MEC app deployed and traffic is already 602 flowing (i.e., all the procedures explained in Section 4.1 took 603 already place). We next explain each of the steps illustrated in the 604 figure: 606 1. The MEC platform notifies that the terminal consuming the MEC app 607 is moving (note that it other events can be notified, such as the 608 mobility of the MEC platform itself), including the expected 609 trajectory (if can be known or predicted in advance, as it will 610 be the case in most cases in several scenarios, such as 611 industrial use cases). 613 2. The RAW PSE uses this information to re-compute how to best 614 provided the reliability and availability needed by the MEC app 615 traffic flow, and updates the RAW nodes about the PAREO functions 616 that they have to apply. 618 3. After this, traffic from the MEC app benefits from updated 619 policies, computed according to the new conditions, and ensuring 620 that the requirements of the MEC app continue to be fulfilled. 622 5. IANA Considerations 624 TBD. 626 6. Security Considerations 628 TBD. 630 7. Acknowledgments 632 The work in this draft will be further developed and explored under 633 the framework of the H2020 5Growth (Grant 856709). 635 8. Informative References 637 [I-D.ietf-raw-architecture] 638 Thubert, P. and G. Z. Papadopoulos, "Reliable and 639 Available Wireless Architecture", Work in Progress, 640 Internet-Draft, draft-ietf-raw-architecture-02, 29 641 November 2021, . 644 [I-D.ietf-raw-oam-support] 645 Theoleyre, F., Papadopoulos, G. Z., Mirsky, G., and C. J. 646 Bernardos, "Operations, Administration and Maintenance 647 (OAM) features for RAW", Work in Progress, Internet-Draft, 648 draft-ietf-raw-oam-support-03, 17 January 2022, 649 . 652 [I-D.ietf-raw-use-cases] 653 Papadopoulos, G. Z., Thubert, P., Theoleyre, F., and C. J. 654 Bernardos, "RAW use cases", Work in Progress, Internet- 655 Draft, draft-ietf-raw-use-cases-03, 20 October 2021, 656 . 659 [RFC6088] Tsirtsis, G., Giarreta, G., Soliman, H., and N. Montavont, 660 "Traffic Selectors for Flow Bindings", RFC 6088, 661 DOI 10.17487/RFC6088, January 2011, 662 . 664 Authors' Addresses 666 Carlos J. Bernardos 667 Universidad Carlos III de Madrid 668 Av. Universidad, 30 669 28911 Leganes, Madrid 670 Spain 672 Phone: +34 91624 6236 673 Email: cjbc@it.uc3m.es 674 URI: http://www.it.uc3m.es/cjbc/ 676 Alain Mourad 677 InterDigital Europe 679 Email: Alain.Mourad@InterDigital.com 680 URI: http://www.InterDigital.com/