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