idnits 2.17.00 (12 Aug 2021) /tmp/idnits18364/draft-boucadair-irtf-sdn-and-semantic-routing-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 document date (2 February 2022) is 101 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-04) exists of draft-farrel-irtf-introduction-to-semantic-routing-03 == Outdated reference: A later version (-19) exists of draft-ietf-lsr-flex-algo-18 == Outdated reference: A later version (-10) exists of draft-ietf-teas-ietf-network-slices-05 == Outdated reference: A later version (-08) exists of draft-king-irtf-challenges-in-routing-06 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IRTF M. Boucadair 3 Internet-Draft Orange 4 Intended status: Informational D. Trossen 5 Expires: 6 August 2022 Huawei 6 A. Farrel 7 Old Dog Consulting 8 2 February 2022 10 Considerations for the use of SDN in Semantic Routing Networks 11 draft-boucadair-irtf-sdn-and-semantic-routing-00 13 Abstract 15 Semantic Routing is the process of making routing and forwarding 16 decisions based, not only on the destination IP address, but on other 17 information carried in an IP packet. The intent is to facilitate 18 enhanced routing decisions based on this information in order to 19 provide differentiated forwarding paths for specific packet flows. 21 Software Defined Networking (SDN) places control of network elements 22 (including all or some of their forwarding decisions) within external 23 software components called controllers and orchestrators. This 24 approach differs from conventional approaches that solely rely upon 25 distributed routing protocols for the delivery of advanced 26 connectivity services. By doing so, SDN aims to enable network 27 elements to be simplified while still performing (some high level) 28 forwarding function. 30 This document examines the applicability of SDN techniques to 31 Semantic Routing and provides considerations for the development of 32 Semantic Routing solutions in the context of SDN. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at https://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on 6 August 2022. 50 Copyright Notice 52 Copyright (c) 2022 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 57 license-info) in effect on the date of publication of this document. 58 Please review these documents carefully, as they describe your rights 59 and restrictions with respect to this document. Code Components 60 extracted from this document must include Revised BSD License text as 61 described in Section 4.e of the Trust Legal Provisions and are 62 provided without warranty as described in the Revised BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 67 2. Software Defined Networking (SDN): An Overview . . . . . . . 3 68 3. Semantic Routing: Summary of Required Technical Elements . . 5 69 4. Programmable Forwarding . . . . . . . . . . . . . . . . . . . 5 70 4.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 6 71 4.2. SDN for Semantic Routing: The Intended Behavior . . . . . 8 72 5. Policy-Based Semantic Routing . . . . . . . . . . . . . . . . 10 73 6. Network-Wide Coordination . . . . . . . . . . . . . . . . . . 10 74 7. Applying Semantic Information to Packets . . . . . . . . . . 10 75 8. Benefits and Concerns with the Use of SDN for Semantic 76 Routing . . . . . . . . . . . . . . . . . . . . . . . . . 11 77 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 78 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 79 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 80 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 12 81 13. Informative References . . . . . . . . . . . . . . . . . . . 12 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 84 1. Introduction 86 Service differentiation in the network can be enforced by 87 manipulating a set of parameters that belong to distinct dimensions 88 (e.g., forwarding, routing, traffic classification, resource 89 partitioning). Among the techniques to achieve such differentiation, 90 this document focuses on Semantic Routing, which refers to a process 91 that is meant to provide differentiated forwarding paths for specific 92 packet flows distinct from simple shortest path first routing and, 93 thus, satisfy specific service/application requirements. 95 More concretely, Semantic Routing is the process of making routing 96 and forwarding decisions based, not only on the destination IP 97 address of a packet, but also by taking into account other 98 information that is carried in the packet such as (but not limited 99 to): 101 * Other fields of the IP header, e.g., DSCP/Traffic Class. 103 * The transport header, e.g., transport port numbers [RFC7597] or 104 subflows [RFC8803]. 106 * Specific transport encapsulation shims, e.g., [RFC8926]. 108 * Specific service headers, e.g., [RFC8300]. 110 * Specific metadata. 112 Section 3 provides more details about Semantic Routing. 114 Software Defined Networking (SDN) places (partial or full) control of 115 network elements and their forwarding decisions within dedicated 116 software components called controllers and orchestrators. This 117 approach differs from those that solely rely upon distributed routing 118 protocols. An ambition of SDN is to enable network elements to be 119 simplified while the network is optimized to deliver value-added 120 connectivity services. Refer to Section 2 for an overview of SDN. 122 This document examines the applicability of SDN to Semantic Routing 123 (Section 4) and provides considerations for the development of 124 Semantic Routing solutions in the context of SDN. 126 This version of the document does not elaborate on specific SDN 127 protocols. 129 2. Software Defined Networking (SDN): An Overview 131 SDN refers to an approach for network programmability, that is, the 132 capacity to initialize, control, and manage network behavior 133 dynamically via open interfaces. Such programmability should 134 facilitate the delivery of services in a deterministic, dynamic, and 135 scalable manner. 137 SDN emphasizes the role of software in running networks by endorsing 138 the separation between data and control planes. Even if such a 139 separation has been adopted by most routing processes for decades 140 (Section 2.1 of [RFC7149]), SDN focuses more on the power of 141 "central" controllers to optimize route computation within a network 142 before populating the Forwarding Information Base (FIB) of involved 143 network elements. 145 The separation between control and data planes allows faster 146 innovation in both planes, and enables a dynamic and flexible 147 approach to implementing new network behaviors and reacting to 148 changes in network state and traffic demands. 150 SDN has been discussed in many places during the last decade. For 151 example, within the IRTF, [RFC7426] provides a concise reference for 152 the SDN research community to address the questions of what SDN is, 153 what the layer structure of an SDN architecture is, and how layers 154 interface with each other within that architecture. [RFC7149] 155 (published in the IETF stream) offers a service provider's 156 perspective of the SDN landscape by describing requirements, issues, 157 and other considerations about SDN. In particular, [RFC7149] 158 classifies SDN techniques into the following functional domains: 160 * Techniques for the dynamic discovery of network topology, devices, 161 and capabilities, along with relevant information and data models 162 that are meant to precisely document such topology, devices, and 163 their capabilities. 165 * Techniques for exposing network services and their characteristics 166 and for dynamically capturing the set of service parameters that 167 will be used to measure the level of quality associated with the 168 delivery of a given service or a combination thereof. 170 * Techniques used by service-requirement-derived dynamic resource 171 allocation and policy enforcement schemes, so that networks can be 172 programmed accordingly. 174 * Dynamic feedback mechanisms that are meant to assess how 175 efficiently a set of policies are enforced from a service 176 fulfillment and assurance perspective. 178 SDN can be deployed following a recursive model that involves 179 dedicated interfaces for both network and service optimization. 180 Indeed, [RFC8597] differentiates the control functions associated 181 with transport from those related to services in an approach called 182 Cooperating Layered Architecture for Software-Defined Networking 183 (CLAS). 185 In an SDN context, domain-specific controllers can be deployed with 186 specific interactions between them as discussed in Section 4 of 187 [RFC8309]. 189 3. Semantic Routing: Summary of Required Technical Elements 191 As described in [I-D.farrel-irtf-introduction-to-semantic-routing], 192 Semantic Routing is the process of achieving enhanced routing 193 decisions based on semantics added to IP headers to provide 194 differentiated paths for different packet flows distinct from simple 195 shortest path first routing. The additional information or 196 "semantics" may be placed in existing header fields (such as the IPv6 197 Traffic Class field or the destination address) or may be achieved by 198 adding fields to the header. Furthermore, it may be encoded in the 199 payload or additional headers (such as in the port number fields or 200 in an IPv6 Extension Header). 202 The application of Semantic Routing allows packets from different 203 flows (even between the same applications on the same devices) to be 204 marked for different treatment in the network. The packets may then 205 be routed onto different paths according to the capabilities and 206 states of the network links in order to meet the requirements of the 207 flows. For example, one flow may need low latency, while another may 208 require ultra low jitter, and a third may demand very high bandwidth. 210 Three elements are needed to achieve Semantic Routing: 212 * The capabilities and state of the network must be discovered. 214 * The packets must be marked (with semantic information) according 215 to their required delivery characteristics. 217 * The routers must be programmed to forward the traffic according to 218 how the packets are marked. 220 All these elements can be matched to the SDN functional domains 221 listed in Section 2. From that standpoint, this document provides 222 more details on how SDN can be used to satisfy specific Semantic 223 Routing needs. 225 4. Programmable Forwarding 227 Programmable Forwarding is the term applied to the use of control 228 techniques to instruct network devices how to forward packets in a 229 programmatic way. 231 4.1. Motivation 233 Modern networks are designed to carry traffic that belongs to a 234 variety of services/applications that have distinct traffic 235 performance requirements, reliability and robustness expectations, 236 and service-specific needs [RFC7665][RFC8517]. Such expectations, 237 and other forwarding requirements that can be captured in a Service 238 Level Agreement (SLA) [RFC7297], can be considered by providers when 239 designing their networks in order to be able to deliver 240 differentiated forwarding behaviors. However, conventional routing 241 and forwarding procedures do not always offer the required 242 functionalities for such differentiated service delivery. Thus, 243 additional means have to be enabled in these networks for the sake of 244 innovative service delivery while minimizing the induced complexity 245 to operate such networks. Also, these means should be tweaked to 246 ensure consistent forwarding behaviors network-wide. 248 The aforementioned means are not only extensions to routing 249 protocols, but include other mechanisms that affect the forwarding 250 behaviors within a network. An non-exhaustive list of sample 251 capabilities that can be offered by appropriately controlling 252 forwarding elements is provided below: 254 Resource Pooling: A network may host dedicated functions that 255 implement resource pooling among many available paths or control 256 which path is used to steer traffic as a function of the observed 257 RTT (e.g., enable MPTCP converters [RFC8803] in specific network 258 segments, including data centers as detailed in Section 2.1 of 259 [RFC8041]). 261 There is a need to interact with the underlying forwarding 262 elements to communicate a set forwarding policies that will ensure 263 that such a differentiated service is provided to the specific 264 flows. These forwarding policies include, for example, a set of 265 rules that characterize the flows that are eligible to the 266 resource pooling service or the scheduling policies (maximize link 267 utilization, grab extra resources only when needed, etc.). 269 These polices are then enforced by programmable forwarders. 271 Performance-based Route Selection: Some applications may have strict 272 traffic performance requirements (e.g., a low one-way delay 273 [RFC7679]), however the underlying network elements may not 274 support a mechanism to disseminate performance metrics associated 275 with specific paths and/or perform performance-based route 276 selection (e.g., [I-D.ietf-idr-performance-routing]). 278 As an alternative, an off-line Semantic Routing approach can be 279 used to collect measurement data to reach a given content (e.g., 280 one-way delay to reach specific data centers), perform route 281 selection based on this data, and then program the appropriate 282 forwarding elements accordingly. 284 Energy-efficient Forwarding: An important effort was made in the 285 past to optimize the energy consumption of network elements. 286 However, such optimization is node-specific and no standard means 287 are supported to optimize the energy consumption at the scale of 288 the network. For example, many nodes (also, service cards) are 289 deployed as backups. 291 A controller-based approach can be implemented so that the route 292 selection process optimizes the overall energy consumption of a 293 path. Such a process takes into account the current load, avoids 294 waking nodes/cards for handling "few" traffic (i.e., minor portion 295 of traffic), considers node-specific data (e.g., [RFC7460]), etc. 296 This off-line Semantic Routing approach will transition specific 297 cards/nodes to "idle", wake them, etc., without breaking service 298 objectives. Moreover, such an approach will have to maintain an 299 up-to-date topology even if a node is in an "idle" state (such 300 nodes may be removed from adjacency tables if they don't 301 participate to routing advertisements). 303 Network Partitioning: In order to rationalize the delivery of 304 advanced connectivity services, a network may need to be 305 partitioned in order to address specific forwarding requirements 306 of groups of services/applications. Network slicing 307 [I-D.ietf-teas-ietf-network-slices] can be considered to deliver 308 these services. However, an intelligence is needed to decide the 309 criteria to be used to partition the available resources, filter 310 them, decide whether network extensions are needed, ensure 311 whether/how resource preemption is adequately implemented, etc. 313 These tasks are better achieved using a central intelligence that 314 has direct visibility into the intents of applications, underlying 315 network capabilities, local policies and guidelines, etc. As an 316 output of processing these various inputs, a set of node-specific 317 policies are generated, and then pushed using available SDN 318 interface. 320 Alternative Forwarding: The programmability of SDN in the form of 321 forwarding actions defined on packet header fields allows for 322 realizing forwarding techniques beyond the typical longest-prefix 323 match used for IP-based reachability. Solutions like those in 324 [ICC2016], for instance, use a binary representation of links in a 325 network to realize a path-based forwarding action that purely acts 326 on node-local state, independent from the nature of the path or 327 the communications traversing over it. As discussed in Section 7, 328 the limitation of forwarding actions to only apply to defined (IP) 329 packet header fields results, however, in issues that need special 330 consideration when realizing such solutions in real-world 331 deployments. 333 The next subsection further details which elements are needed when 334 interacting with programmable forwarders in an SDN context. 336 4.2. SDN for Semantic Routing: The Intended Behavior 338 SDN minimizes the required changes to legacy (interior) routing 339 protocols. More concretely, SDN can be used to provide the intended 340 Semantic Routing behavior, especially: 342 * Identify the forwarding elements that can be safely involved in 343 providing the intended Semantic Routing features. 345 * Maintain abstract topologies that involve these elements and their 346 capabilities. 348 * Capture application-specific intents and derive the corresponding 349 forwarding requirements and, then, forwarding policies. 351 * Map these abstract topologies to (groups of) applications with 352 specific Semantic Routing needs. 354 * Program a subset of nodes (called boundary nodes) with the 355 required classification and marking policies to bind flows with 356 their intended Semantic Routing behavior. 358 In order to adequately process the application flows that require 359 specific differentiated forwarding, SDN controllers maintain a 360 table that allows to unambiguously identify such flows. The 361 content of that table is used to derive the appropriate 362 classification/match rules that are then communicated by an SDN 363 controller to a set of forwarding elements. 365 When volatile data (e.g., dynamic IP addresses) is used to build 366 such rules, it is the responsibility of the SDN controllers to 367 update the rules whenever a new identifier is used. Failure to 368 maintain "fresh" classification rules will lead to service 369 failure/degradation. 371 * Supply intermediate nodes (that is, nodes that are not boundary 372 nodes) with the appropriate rules to locate and interpret the bits 373 within the packet to proceed with forwarding actions that comprise 374 Semantic Routing. 376 * Automatically adjust, if possible, the network MTU to accommodate 377 the overhead that is required by any extra bits to signal semantic 378 routing behavior. 380 * Instruct egress boundary nodes about the required actions such as 381 stripping or setting any Semantic Routing bits. 383 * Interact with the underlying nodes to maintain, retrieve, and 384 disseminate the appropriate data that is used for assuring that 385 Semantic Routing policies are appropriately fulfilled. 387 * Configure OAM policies to measure the experience and adjust the 388 forwarding behavior. 390 * Monitor the network and detect parts of the network where such 391 policies are broken. 393 * Automate the overall procedure [RFC8969]. 395 At least three approaches can be considered by an SDN controller to 396 accomplish the above tasks: 398 * Compute (centrally) the differentiated paths and install the 399 required forwarding rules in involved nodes. Strict or loose 400 paths may be installed. This approach has the merit of 401 implementing new path selection algorithms without requiring them 402 to be supported by every involved node. 404 * Assign (centrally) differentiated link information and install the 405 required forwarding rules in the involved nodes. End-to-end paths 406 are constructed without involvement of the SDN controller, 407 utilizing the link information to establish path identification 408 information on which installed forwarding rules can act upon 409 without additional path-specific knowledge being required. See 410 [ICC2016] for an example of such approach. 412 * Rely upon a distributed routing protocol to customize the route 413 selection process ([I-D.ietf-lsr-flex-algo], for example). In 414 such case, the SDN controller is responsible for communicating the 415 parameters to be used for route selection process, select the 416 nodes that will participate in a given topology, and configure any 417 tunnels to interconnect these nodes. 419 A hierarchical SDN design can also be considered, where specific 420 controllers are enabled in each domain with dedicated interfaces to 421 share data (e.g., radio bottleneck, expectations). These domains do 422 not need to support the same technological implementation. The 423 interaction between the SDN controllers eases the delivery of 424 consistent Semantic Routing behaviors without requiring common domain 425 configuration. 427 5. Policy-Based Semantic Routing 429 TBD 431 **SDN techniques as a whole are an instantiation of the policy-based 432 management framework.*** 434 6. Network-Wide Coordination 436 TBD 438 7. Applying Semantic Information to Packets 440 Given the focus of SDN is the use within IP networks, semantic 441 information that can be used in SDN-based semantic routing is limited 442 to those fields being defined in related SDN specifications; see 443 Section 2 for more information. 445 With this, SDN aligns with the concept of semantic routing 446 [I-D.farrel-irtf-introduction-to-semantic-routing] in that it allows 447 for range of packet header fields beyond mere IP addresses to be used 448 in forwarding actions. 450 However, solutions have also been devised that "overwrite" existing 451 protocol fields in order for them to be used in an SDN forwarding 452 action outside their original semantics. [POINT2015][POINT2016] 453 outline an example for such solution in which SDN is used for a path- 454 based forwarding decision; while no "path" information is foreseen as 455 an actionable packet header field in IPv6. 457 Here, the path is constructed by a path-computation element (PCE) 458 that matches a given service name against previously announced 459 locations where said service name is located. The path is 460 represented as a concatenation of individual link information, which 461 in turn is used to SDN node locally forward the packet after arrival. 462 Given the binary structure of the end-to-end path information, the 463 SDN forwarding operation can be implemented in a standard-compliant 464 manner with its realization described in [ICC2016] as a arbitrary 465 wildcard matching operation. 467 However, the constraint of acting only on limited packet fields 468 requires that the path information needs transfer in one of those 469 standard-defined packet header fields; thereby overwriting any 470 existing packet header field. As described in [POINT2016], the IPv6 471 address fields are used for this purpose, representing the longest 472 continuous binary field in the IPv6 header (256 bit in total), 473 thereby allowing for representing topologies with up to 256 links. 475 Given the approach chosen in [POINT2016], any IPv6 address 476 information, if needed, is provided in the encapsulated payload, 477 leading to repetitive encapsulation overhead by carrying two IP 478 headers in a single packet, one used for path-based forwarding and 479 one for the operations in arriving endpoint. Only newer forwarding 480 plane architectures, such as P4, would allow for removing such 481 overhead by placing the path information into another packet header 482 field (or even the payload as an extended header of sort) to act 483 upon. 485 8. Benefits and Concerns with the Use of SDN for Semantic Routing 487 The programmability of SDN provides a fertile ground for forwarding 488 decision that go beyond the reachability information provided through 489 IPv4/v6 addresses, e.g., by using other packet header fields. This 490 not only allows for extending the simple reachability-driven 491 forwarding decision with richer, e.g., policy-based, decisions (as 492 discussed in Section 5), it may also enable new forwarding paradigms 493 per se, such as those in [POINT2016], which in turn may realize 494 forwarding behaviours like multicast at much lower cost points and 495 higher efficiency (see [ICC2016]). 497 However, SDN specifications have limited capabilities when it comes 498 to the additional packet header fields that may be used for 499 forwarding actions. As a consequence, "true" semantic routing on any 500 semantic enhancement, which is included in the packet, is only 501 possible in a manner limited to those fields. 503 Solutions such as those in [POINT2016], using methods outlined in 504 [ICC2016], attempt to break this limitation albeit by overwriting 505 standard-defined packet header fields, thereby changing the semantics 506 of those fields within the realm of where the "re-defined" semantics 507 are defined. 509 This limits any solution to a limited domain [RFC8799]. More 510 importantly, the redefinition of packet fields poses the danger of 511 exposing this (non standard compliant) semantic to elements outside 512 the limited domain; semantic leakage may occur, requiring appropriate 513 methods such as dedicated gateways for preventing such leakage. This 514 can be seen in [POINT2016], where the boundaries to IP-compliant end 515 devices and other domains alike are delimited by dedicated gateway 516 elements. Those gateways usually act at higher layers than the SDN 517 forwarding layer, thereby incurring complexity and often delay. 519 See also [I-D.king-irtf-challenges-in-routing] for a discussion of 520 issues and concerns that need to be examined when applying a new 521 routing or forwarding paradigm to a self-contained network or 522 Internet. 524 9. Security Considerations 526 SDN-related considerations are discussed in Section 5 of [RFC7149]. 528 10. IANA Considerations 530 This document makes no requests for IANA action. 532 11. Acknowledgements 534 Thanks to George Polyzos for helpful comments on this work. 536 12. Contributors 538 George Xylomenos 539 Email: xgeorge@aueb.gr 541 13. Informative References 543 [I-D.farrel-irtf-introduction-to-semantic-routing] 544 Farrel, A. and D. King, "An Introduction to Semantic 545 Routing", Work in Progress, Internet-Draft, draft-farrel- 546 irtf-introduction-to-semantic-routing-03, 22 January 2022, 547 . 550 [I-D.ietf-idr-performance-routing] 551 Xu, X., Hegde, S., Talaulikar, K., Boucadair, M., and C. 552 Jacquenet, "Performance-based BGP Routing Mechanism", Work 553 in Progress, Internet-Draft, draft-ietf-idr-performance- 554 routing-03, 22 December 2020, 555 . 558 [I-D.ietf-lsr-flex-algo] 559 Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and 560 A. Gulko, "IGP Flexible Algorithm", Work in Progress, 561 Internet-Draft, draft-ietf-lsr-flex-algo-18, 25 October 562 2021, . 565 [I-D.ietf-teas-ietf-network-slices] 566 Farrel, A., Gray, E., Drake, J., Rokui, R., Homma, S., 567 Makhijani, K., Contreras, L. M., and J. Tantsura, 568 "Framework for IETF Network Slices", Work in Progress, 569 Internet-Draft, draft-ietf-teas-ietf-network-slices-05, 25 570 October 2021, . 573 [I-D.king-irtf-challenges-in-routing] 574 King, D., Farrel, A., and C. Jacquenet, "Challenges for 575 the Internet Routing Infrastructure Introduced by Semantic 576 Routing", Work in Progress, Internet-Draft, draft-king- 577 irtf-challenges-in-routing-06, 22 January 2022, 578 . 581 [ICC2016] Reed, M., Al-Naday, M., Thomos, N., Trossen, D., 582 Petropoulos, G., and S. Spirou, "Stateless multicast 583 switching in software defined networks", Paper IEEE ICC 584 2016, 2016. 586 [POINT2015] 587 Trossen, D., Reed, M., Riihijarvi, J., Georgiades, M., 588 Xylomenos, G., and S. Fotiou, "IP Over ICN: The Better 589 IP?", Paper EuCNC (European Conference on Networks and 590 Communications), Paris, France, 2015. 592 [POINT2016] 593 Kim, S.-Y.., Robitzsch, S., Trossen, D., Reed, M., Al- 594 Naday, M., and J. Riihijarvi, "Realizing IP-based Services 595 over an Information-Centric Networking Transport Network", 596 Paper Proceedings of the 3rd ACM Conference on 597 Information-Centric Networking, Pages 215-216, 2016. 599 [RFC7149] Boucadair, M. and C. Jacquenet, "Software-Defined 600 Networking: A Perspective from within a Service Provider 601 Environment", RFC 7149, DOI 10.17487/RFC7149, March 2014, 602 . 604 [RFC7297] Boucadair, M., Jacquenet, C., and N. Wang, "IP 605 Connectivity Provisioning Profile (CPP)", RFC 7297, 606 DOI 10.17487/RFC7297, July 2014, 607 . 609 [RFC7426] Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S., 610 Hadi Salim, J., Meyer, D., and O. Koufopavlou, "Software- 611 Defined Networking (SDN): Layers and Architecture 612 Terminology", RFC 7426, DOI 10.17487/RFC7426, January 613 2015, . 615 [RFC7460] Chandramouli, M., Claise, B., Schoening, B., Quittek, J., 616 and T. Dietz, "Monitoring and Control MIB for Power and 617 Energy", RFC 7460, DOI 10.17487/RFC7460, March 2015, 618 . 620 [RFC7597] Troan, O., Ed., Dec, W., Li, X., Bao, C., Matsushima, S., 621 Murakami, T., and T. Taylor, Ed., "Mapping of Address and 622 Port with Encapsulation (MAP-E)", RFC 7597, 623 DOI 10.17487/RFC7597, July 2015, 624 . 626 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 627 Chaining (SFC) Architecture", RFC 7665, 628 DOI 10.17487/RFC7665, October 2015, 629 . 631 [RFC7679] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, 632 Ed., "A One-Way Delay Metric for IP Performance Metrics 633 (IPPM)", STD 81, RFC 7679, DOI 10.17487/RFC7679, January 634 2016, . 636 [RFC8041] Bonaventure, O., Paasch, C., and G. Detal, "Use Cases and 637 Operational Experience with Multipath TCP", RFC 8041, 638 DOI 10.17487/RFC8041, January 2017, 639 . 641 [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., 642 "Network Service Header (NSH)", RFC 8300, 643 DOI 10.17487/RFC8300, January 2018, 644 . 646 [RFC8309] Wu, Q., Liu, W., and A. Farrel, "Service Models 647 Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018, 648 . 650 [RFC8517] Dolson, D., Ed., Snellman, J., Boucadair, M., Ed., and C. 651 Jacquenet, "An Inventory of Transport-Centric Functions 652 Provided by Middleboxes: An Operator Perspective", 653 RFC 8517, DOI 10.17487/RFC8517, February 2019, 654 . 656 [RFC8597] Contreras, LM., Bernardos, CJ., Lopez, D., Boucadair, M., 657 and P. Iovanna, "Cooperating Layered Architecture for 658 Software-Defined Networking (CLAS)", RFC 8597, 659 DOI 10.17487/RFC8597, May 2019, 660 . 662 [RFC8799] Carpenter, B. and B. Liu, "Limited Domains and Internet 663 Protocols", RFC 8799, DOI 10.17487/RFC8799, July 2020, 664 . 666 [RFC8803] Bonaventure, O., Ed., Boucadair, M., Ed., Gundavelli, S., 667 Seo, S., and B. Hesmans, "0-RTT TCP Convert Protocol", 668 RFC 8803, DOI 10.17487/RFC8803, July 2020, 669 . 671 [RFC8926] Gross, J., Ed., Ganga, I., Ed., and T. Sridhar, Ed., 672 "Geneve: Generic Network Virtualization Encapsulation", 673 RFC 8926, DOI 10.17487/RFC8926, November 2020, 674 . 676 [RFC8969] Wu, Q., Ed., Boucadair, M., Ed., Lopez, D., Xie, C., and 677 L. Geng, "A Framework for Automating Service and Network 678 Management with YANG", RFC 8969, DOI 10.17487/RFC8969, 679 January 2021, . 681 Authors' Addresses 683 Mohamed Boucadair 684 Orange 685 Rennes 686 France 688 Email: mohamed.boucadair@orange.com 690 Dirk Trossen 691 Huawei 692 Munich 693 Germany 695 Email: dirk.trossen@huawei.com 696 Adrian Farrel 697 Old Dog Consulting 698 United Kingdom 700 Email: adrian@olddog.co.uk