idnits 2.17.00 (12 Aug 2021) /tmp/idnits6579/draft-bernardos-raw-multidomain-00.txt: -(257): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(261): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(264): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(269): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(272): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(273): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(275): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(276): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(280): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(282): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(283): 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 12 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: ---------------------------------------------------------------------------- -- The document date (6 March 2022) is 69 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-03 Summary: 0 errors (**), 0 flaws (~~), 2 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: 7 September 2022 InterDigital 6 6 March 2022 8 RAW multidomain extensions 9 draft-bernardos-raw-multidomain-00 11 Abstract 13 This document describes the multi-domain RAW problem and explores and 14 proposes some extensions to enable RAW multi-domain operation. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at https://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on 7 September 2022. 33 Copyright Notice 35 Copyright (c) 2022 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 40 license-info) in effect on the date of publication of this document. 41 Please review these documents carefully, as they describe your rights 42 and restrictions with respect to this document. Code Components 43 extracted from this document must include Revised BSD License text as 44 described in Section 4.e of the Trust Legal Provisions and are 45 provided without warranty as described in the Revised BSD License. 47 Table of Contents 49 1. Introduction and Problem Statement . . . . . . . . . . . . . 2 50 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 51 3. RAW multi-domain extensions . . . . . . . . . . . . . . . . . 6 52 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 53 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 54 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 55 7. Informative References . . . . . . . . . . . . . . . . . . . 9 56 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 58 1. Introduction and Problem Statement 60 Wireless operates on a shared medium, and transmissions cannot be 61 fully deterministic due to uncontrolled interferences, including 62 self-induced multipath fading. RAW (Reliable and Available Wireless) 63 is an effort to provide Deterministic Networking on across a path 64 that include a wireless interface. RAW provides for high reliability 65 and availability for IP connectivity over a wireless medium. The 66 wireless medium presents significant challenges to achieve 67 deterministic properties such as low packet error rate, bounded 68 consecutive losses, and bounded latency. RAW extends the DetNet 69 Working Group concepts to provide for high reliability and 70 availability for an IP network utilizing scheduled wireless segments 71 and other media, e.g., frequency/time-sharing physical media 72 resources with stochastic traffic: IEEE Std. 802.15.4 timeslotted 73 channel hopping (TSCH), 3GPP 5G ultra-reliable low latency 74 communications (URLLC), IEEE 802.11ax/be, and L-band Digital 75 Aeronautical Communications System (LDACS), etc. Similar to DetNet, 76 RAW technologies aim at staying abstract to the radio layers 77 underneath, addressing the Layer 3 aspects in support of applications 78 requiring high reliability and availability. 80 As introduced in [I-D.ietf-raw-architecture], RAW separates the path 81 computation time scale at which a complex path is recomputed from the 82 path selection time scale at which the forwarding decision is taken 83 for one or a few packets. RAW operates at the path selection time 84 scale. The RAW problem is to decide, amongst the redundant solutions 85 that are proposed by the Patch Computation Element (PCE), which one 86 will be used for each packet to provide a Reliable and Available 87 service while minimizing the waste of constrained resources. To that 88 effect, RAW defines the Path Selection Engine (PSE) that is the 89 counter-part of the PCE to perform rapid local adjustments of the 90 forwarding tables within the diversity that the PCE has selected for 91 the Track. The PSE enables to exploit the richer forwarding 92 capabilities with Packet (hybrid) ARQ, Replication, Elimination and 93 Ordering (PAREO), and scheduled transmissions at a faster time scale. 95 There are several use cases [I-D.ietf-raw-use-cases] where 96 reliability and availability are key requirements for wireless 97 heterogeneous networks. A couple of relevant examples are (i) the 98 manufacturing sector, where a plethora of devices are interconnected 99 and generate data that need to be reliably delivered to the control 100 and monitoring agents; and (ii) the residential gaming, with eXtended 101 Reality (XR). 103 We can refer to domains managed by a single PCE, as "single-domain 104 RAW", where nodes are typically run and managed by a single 105 administration entity. In this scenario, the PSE can make use of 106 "tracks" and paths involving only the nodes belonging to this RAW 107 domain. 109 There are scenarios where hosts are connected to different RAW 110 domains and they need to communicate to each other with certain 111 reliability and/or availability guarantees, for example in large 112 factories where networks might be organized in domains (per 113 production lines or building/sites), in residential environments 114 where there are different networks (e.g., one at home and one in the 115 garden), or even vehicular scenarios (e.g., hosts connected to 116 different vehicles). 118 ____________________________________________ 119 | | 120 | ( ( o ) ) | 121 | * ^ | 122 | * / \ | 123 | * / \ | 124 | ** ------+-- | 125 | * | RAW |P| | 126 | ( ( o ) )* * |node |S| | 127 | ^ *( ( o ) ) | 1-1 |E| +------+ 128 | / \ ^ * ------+-- | PCE1 | 129 | / \ / \ ** +------+ 130 | +-----+ / \ *( ( o ) ) | 131 | |host1| ------+-- ^ | 132 | | | | RAW |P| / \ | 133 | | | |node |S| / \ | 134 | | o | | 1-2 |E| ------+-- | 135 | +-----+ ------+-- | RAW |P| | 136 | \ / |node |S| | 137 | RAW \ / | 1-3 |E| | 138 | domain 1 v ------+-- | 139 | ( ( o ) ) | 140 | **** | 141 |______________ *____**** ______________| 142 ____________ *__________***** _____________ 143 | * ** | 144 | * ****( ( o ) ) | 145 | * **** ^ | 146 | ( ( o ) )**** / \ | 147 | ^ * / \ | 148 | / \ * ------+-- | 149 | / \ * | RAW |P| | 150 | ------+-- * |node |S| | 151 | | RAW |P| * | 2-1 |E| +------+ 152 | |node |S| * ------+-- | PCE2 | 153 | | 2-2 |E| * +------+ 154 | ------+-- *( ( o ) ) | 155 | * ^ | 156 | ( ( o ) ) / \ | 157 | ^ / \ | 158 | / \ ------+-- | 159 | / \ | RAW |P| | 160 | +-----+ |node |S| | 161 | RAW |host2| | 2-3 |E| | 162 | domain 2 +-----+ ------+-- | 163 |___________________________________________| 165 Figure 1: Exemplary scenario showing multiple RAW domains 167 Figure 1 shows an example of communication involving two RAW domains. 168 As opposed to a single-domain scenario, where a single PCE may 169 compute all possible "tracks" at longer time scale, and the PSE 170 functionality may perform "subtrack" selection and optimization at a 171 shorter time scale using all information available at the domain, 172 multidomain scenarios pose additional burdens that are not solved 173 yet. 175 Each RAW domain operates independently of the other domains. While 176 there exist inter-PCE solutions today, allowing one domain's PCE to 177 learn some inter-domain paths, this would not be sufficient, as the 178 PSE of one domain would not have full visibility nor capability to 179 act on the other domains (e.g., there are no multi-domain OAM 180 solutions in place yet), limiting its capability to guarantee any 181 given SLA. Therefore, there is a need to define inter-PSE 182 coordination mechanisms across domains. 184 There exist today standardized solutions, such as the ones in the 185 context of Path Computation Element (PCE), enabling computing multi- 186 /inter-domain paths. As an example, the Hierarchical PCE (G-PCE) was 187 defined in RFC 6805 [RFC6805] and is described hereafter. A parent 188 PCE maintains a domain topology map that contains the child domains 189 (seen as vertices in the topology) and their interconnections (links 190 in the topology). The parent PCE has no information about the 191 content of the child domains; that is, the parent PCE does not know 192 about the resource availability within the child domains, nor does it 193 know about the availability of connectivity across each domain 194 because such knowledge would violate the confidentiality requirement 195 and either would require flooding of full information to the parent 196 (scaling issue) or would necessitate some form of aggregation. The 197 parent PCE is used to compute a multi-domain path based on the domain 198 connectivity information. A child PCE may be responsible for single 199 or multiple domains and is used to compute the intra-domain path 200 based on its own domain topology information. 202 Solutions like the above are not sufficient alone to solve the multi- 203 domain RAW problem, as the PSEs need to have some additional 204 information from the other involved domains to be sensitive/reactive 205 to transient changes, in order to ensure a certain level of 206 reliability and availability in a multi-domain wireless heterogeneous 207 mesh network. 209 Within a single domain, the RAW framework architecture works, by 210 having the PCE in charge of computing the paths (tracks) and the 211 PSE(s) taking the short time decisions of which sub-tracks to use. 212 Note that the PSE is assumed to be either a distributed functionality 213 (performed by every RAW router of the path, which takes forwarding 214 decisions based on the local and OAM information that they have), or 215 a centralized functionality played by the entry (ingress) router in 216 the domain (note that if there are multiple ingress nodes, then there 217 might be multiple PSEs), which then performs source routing. 219 In scenarios with multiple connected RAW domains, running 220 uncoordinated RAW solutions in each domain is not sufficient. PSEs 221 would need to have global end-to-end information as well as be 222 capable of running OAM mechanisms [I-D.ietf-raw-oam-support] to 223 monitor the quality of the selected paths. 225 2. Terminology 227 The following terms used in this document are defined by the IETF: 229 PAREO. Packet (hybrid) ARQ, Replication, Elimination and 230 Ordering. PAREO is a superset Of DetNet's PREOF that includes 231 radio-specific techniques such as short range broadcast, MUMIMO, 232 constructive interference and overhearing, which can be leveraged 233 separately or combined to increase the reliability. 235 PSE. The Path Selection Engine (PSE) is the counter-part of the 236 PCE to perform rapid local adjustments of the forwarding tables 237 within the diversity that the PCE has selected for the Track. The 238 PSE enables to exploit the richer forwarding capabilities with 239 PAREO and scheduled transmissions at a faster time scale over the 240 smaller domain that is the Track, in either a loose or a strict 241 fashion. 243 3. RAW multi-domain extensions 245 Here we specify the new mechanisms and signaling extensions to enable 246 inter-domain RAW connectivity. 248 +-----+-+ +----+ +----+ +-----+-+ +-----+-+ 249 | RAW |P| | | | | | RAW |P| | RAW |P| 250 |node |S| |PCE1| |PCE2| |node |S| |node |S| 251 | 1-2 |E| | | | | | 2-1 |E| | 2-2 |E| 252 +-----+-+ +----+ +----+ +-----+-+ +-----+-+ 253 | | | | | 254 1.Path compute req| | | | 255 (src=node1-2, | | | | 256 dst=node2-3, SLA)| | | | 257 |··········>| | | | 258 | |2.Path compute req | | 259 | |(src={node2-1,node2-2}, | | 260 | | dst=node2-3) | | 261 | |···········>| | | 262 | |3.Path compute resp | | 263 | |({tracks2},{links_quality})| | 264 | |<···········| | | 265 4.Path compute resp | | | 266 ({{tracks1},{tracks2}}, | | | 267 PSE={node2-1,node2-2}, | | | 268 {SLA1,SLA2}) | | | | 269 |<··········| | | | 270 |5.RAW inter-domain path | | | 271 |({{tracks1,tracks2}},{SLA1,SLA2}) | | 272 |······································>| | 273 |····················································>| 274 | | 6.RAW inter-domain path ACK | 275 |<······································| | 276 |<····················································| 277 | | | | | 278 |7.RAW OAM(flow/track,SLA1) | | 279 <···>|<···> | | 7.RAW OAM(flow/track,SLA1)| 280 | | | <··>|<··> <··>|<··> 281 | 8.RAW OAM (flow/track, metrics) | 282 |<·····································>| | 283 |<···················································>| 284 | | | | | 286 Figure 2: Multi-domain RAW signaling 288 Figure 2 shows a signaling flow diagram, taking as baseline scenario 289 the one shown in Figure 1, where host1 (connected to node1-2) wants 290 to communicate with host2 (connected to node2-3). An ingress RAW 291 node (node1-2) gets a request for connectivity, with a given 292 destination RAW node (node2-3) and the desired SLA in terms of 293 reliability and availability. The source and/or destination RAW 294 nodes might be hostss. We next explain each of the steps illustrated 295 in the figure: 297 1. The ingress node plays the role of PSE (also referred to as 298 PSE@domain1) and requests the computation of the tracks towards 299 the destination node2-3 with the intended SLA to the PCE of the 300 domain (PCE1). 302 2. PCE1 knows that the destination is in another domain (domain2) 303 and that the PCE of the destination domain is PCE2. PCE1 also 304 knows the ingress nodes in domain2 that are connected to domain1. 305 How this is done is outside of the scope of this document. These 306 nodes (node2-1 and node2-2) play the role of PSEs@domain2. PCE1 307 requests to PCE2 to compute the available tracks from 308 PSEs@domain2 to the destination, and the characteristics of the 309 links (link_quality) forming these tracks. The detail and nature 310 of the information provided by PCE2 regarding the links might 311 vary depending on the deployment, and is meant to be used by PCE1 312 and the PSE@domain1 (node1-2) to compute how to distribute the 313 SLA among the domains. 315 3. PCE2 computes the tracks and responds to PCE1, including also the 316 characteristics of the links (link_quality). Examples of 317 potential information elements including in the link_quality are: 318 available bandwidth, observed reliability, delay, link 319 variability/mobility, etc. 321 4. PCE1 provides to the PSE@domain1 the tracks to reach the 322 destination, as well as the split of SLAs among domain1 and 323 domain2 (SLA1 and SLA2). An SLA, or a Quality of Service (QoS) 324 figure, may include aspects such as, among others: max. delay, 325 assured BW, max. Jitter, packet loss ratio, availability ratio, 326 etc. PCE1 also provides the PSEs@domain2. 328 5. The PSE@domain1 sends a message to each PSE@domain2, in order to 329 set-up a direct communication channel to provide OAM information 330 useful to the PSE@domain1 for computing the subtracks to use for 331 the traffic. This message includes the SLA that each domain has 332 to monitor and guarantee (SLA1 and SLA2). 334 6. Each of the PSEs@domain2 acknowledges the message. At this 335 point, the communication channel is established and the 336 PSE@domain1 can start taking decisions at a forwarding time scale 337 regarding which paths (subtracks) to use. 339 7. All PSEs, at each domain, start performing OAM procedures 340 [I-D.ietf-raw-oam-support], which are key to observe if traffic 341 is meeting the desired SLAs (SLA1 and SLA2) and adapt the 342 subtracks and tracks if needed. OAM mechanisms can be applied 343 in-band (sharing the traffic's fate) or out-of band. Note that 344 this per-domain distributed OAM is critical to ensure that the 345 required SLAs (reliability and availability) are met by reacting 346 on a short time scale at each of the involved domains. 348 8. PSEs share aggregated and pre-processed information among them to 349 facilitate early detection of issues and computation of 350 subtracks. If a violation of an SLA is detected, the respective 351 PSE would notify the domain PCE and the other PSE, so a reaction 352 measure can be taken (e.g., selecting different subtracks, taking 353 different PAREO decisions, requesting the PCEs to recompute the 354 paths and/or adjust the split of the SLAs across the domains). 356 Note that this example covers the direction host1-to-host2. If there 357 is traffic in the opposite direction, the process has to be repeated 358 in the reverse direction, as paths might not be bidirectional. 360 4. IANA Considerations 362 TBD. 364 5. Security Considerations 366 TBD. 368 6. Acknowledgments 370 This work has been partially supported by the Spanish Ministry of 371 Economic Affairs and Digital Transformation and the European Union- 372 NextGenerationEU through the UNICO 5G I+D 6G-DATADRIVEN-04. 374 7. Informative References 376 [I-D.ietf-raw-architecture] 377 Thubert, P. and G. Z. Papadopoulos, "Reliable and 378 Available Wireless Architecture", Work in Progress, 379 Internet-Draft, draft-ietf-raw-architecture-03, 14 January 380 2022, . 383 [I-D.ietf-raw-oam-support] 384 Theoleyre, F., Papadopoulos, G. Z., Mirsky, G., and C. J. 385 Bernardos, "Operations, Administration and Maintenance 386 (OAM) features for RAW", Work in Progress, Internet-Draft, 387 draft-ietf-raw-oam-support-04, 5 March 2022, 388 . 391 [I-D.ietf-raw-use-cases] 392 Bernardos, C. J., Papadopoulos, G. Z., Thubert, P., and F. 393 Theoleyre, "RAW use-cases", Work in Progress, Internet- 394 Draft, draft-ietf-raw-use-cases-05, 23 February 2022, 395 . 398 [RFC6805] King, D., Ed. and A. Farrel, Ed., "The Application of the 399 Path Computation Element Architecture to the Determination 400 of a Sequence of Domains in MPLS and GMPLS", RFC 6805, 401 DOI 10.17487/RFC6805, November 2012, 402 . 404 Authors' Addresses 406 Carlos J. Bernardos 407 Universidad Carlos III de Madrid 408 Av. Universidad, 30 409 28911 Leganes, Madrid 410 Spain 411 Phone: +34 91624 6236 412 Email: cjbc@it.uc3m.es 413 URI: http://www.it.uc3m.es/cjbc/ 415 Alain Mourad 416 InterDigital Europe 417 Email: Alain.Mourad@InterDigital.com 418 URI: http://www.InterDigital.com/