idnits 2.17.1 draft-ietf-teas-sf-aware-topo-model-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 27, 2022) is 789 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-36) exists of draft-ietf-teas-yang-te-29 == Outdated reference: A later version (-24) exists of draft-ietf-teas-actn-vn-yang-13 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group I. Bryskin 3 Internet-Draft Individual 4 Intended status: Informational X. Liu 5 Expires: August 31, 2022 IBM Corporation 6 Y. Lee 7 Samsung Electronics 8 J. Guichard 9 Huawei Technologies 10 L. Contreras 11 Telefonica 12 D. Ceccarelli 13 Ericsson 14 J. Tantsura 15 Apstra Networks 16 D. Shytyi 17 SFR 18 February 27, 2022 20 SF Aware TE Topology YANG Model 21 draft-ietf-teas-sf-aware-topo-model-09 23 Abstract 25 This document describes a YANG data model for TE network topologies 26 that are network service and function aware. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on August 31, 2022. 45 Copyright Notice 47 Copyright (c) 2022 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (https://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 63 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 64 1.2. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 5 65 1.3. Prefixes in Data Node Names . . . . . . . . . . . . . . . 6 66 2. Modeling Considerations . . . . . . . . . . . . . . . . . . . 6 67 3. SF Aware TE Topology Model Structure . . . . . . . . . . . . 7 68 4. SF Aware TE Topology YANG Module . . . . . . . . . . . . . . 9 69 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 70 6. Security Considerations . . . . . . . . . . . . . . . . . . . 20 71 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 72 7.1. Normative References . . . . . . . . . . . . . . . . . . 22 73 7.2. Informative References . . . . . . . . . . . . . . . . . 25 74 Appendix A. Companion YANG Model for Non-NMDA Compliant 75 Implementations . . . . . . . . . . . . . . . . . . 26 76 A.1. SF Aware TE Topology State Module . . . . . . . . . . . . 26 77 Appendix B. Data Examples . . . . . . . . . . . . . . . . . . . 29 78 B.1. A Topology with Multiple Connected Network Functions . . 29 79 B.2. A Topology with an Encapsulated Network Service . . . . . 34 80 Appendix C. Use Cases for SF Aware Topology Models . . . . . . . 38 81 C.1. Exporting SF/NF Information to Network Clients and Other 82 Network SDN Controllers . . . . . . . . . . . . . . . . . 38 83 C.2. Flat End-to-end SFCs Managed on Multi-domain Networks . 39 84 C.3. Managing SFCs with TE Constraints . . . . . . . . . . . . 40 85 C.4. SFC Protection and Load Balancing . . . . . . . . . . . . 41 86 C.5. Network Clock Synchronization . . . . . . . . . . . . . . 44 87 C.6. Client - Provider Network Slicing Interface . . . . . . . 44 88 C.7. Dynamic Assignment of Regenerators for L0 Services . . . 44 89 C.8. Dynamic Assignment of OAM Functions for L1 Services . . . 46 90 C.9. SFC Abstraction and Scaling . . . . . . . . . . . . . . . 47 91 C.10. Dynamic Compute/VM/Storage Resource Assignment . . . . . 47 92 C.11. Application-aware Resource Operations and Management . . 48 93 C.12. Interconnection between Service Functions/Termination 94 Points in uCPE . . . . . . . . . . . . . . . . . . . . . 49 95 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 56 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 56 98 1. Introduction 100 RFC Ed.: In this document, please replace all occurrences of 'XXXX' 101 with the actual RFC number (and remove this note). 103 Normally network connectivity services are discussed as a means to 104 inter-connect various abstract or physical network topological 105 elements, such as ports, link termination points and nodes [RFC8795] 106 [I-D.ietf-teas-yang-te]. However, the connectivity services, 107 strictly speaking, interconnect not the network topology elements 108 per-se, rather, located on/associated with the various network and 109 service functions [RFC7498] [RFC7665]. In many scenarios it is 110 beneficial to decouple the service/network functions from the network 111 topology elements hosting them, describe them in some unambiguous and 112 identifiable way (so that it would be possible, for example, to auto- 113 discover on the network topology service/network functions with 114 identical or similar functionality and characteristics) and engineer 115 the connectivity between the service/network functions, rather than 116 between their current topological locations. 118 Today a network offers to its clients far more services than just 119 connectivity across the network. Large variety of physical, logical 120 and/or virtual service functions, network functions and transport 121 functions (collectively named in this document as SFs) could be 122 allocated for and assigned to a client. As described in the appendix 123 of this document, there are some important use cases, in which the 124 network needs to represent to the client SFs at the client's disposal 125 as topological elements in relation to other elements of a topology 126 (i.e. nodes, links, link and tunnel termination points) used by the 127 network to describe itself to the client. Not only would such 128 information allow for the client to auto-discover the network's SFs 129 available for the services provisioned for the client, it would also 130 allow for the client selecting the SFs, duel-optimizing the selection 131 on the SF location on the network and connectivity means (e.g. TE 132 tunnels) to inter-connect the SFs. Consequently thus would give to 133 both the network and the client powerful means for the service 134 function chain (SFC [RFC7498] [RFC7665]) negotiation to achieve most 135 efficient and cost effective (from the network point of view) and 136 most optimal yet satisfying all necessary constraints of SFCs (from 137 the client's point of view). 139 This document defines a YANG [RFC7950] data model that allows service 140 functions to be represented along with TE topology elements. 142 The YANG data model in this document conforms to the Network 143 Management Datastore Architecture (NMDA) [RFC8342]. 145 1.1. Terminology 147 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 148 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 149 "OPTIONAL" in this document are to be interpreted as described in BCP 150 14, [RFC2119] [RFC8174] when, and only when, they appear in all 151 capitals, as shown here. 153 o Network Function (NF): A functional block within a network 154 infrastructure that has well-defined external interfaces and well- 155 defined functional behaviour [ETSI-NFV-TERM]. Such functions 156 include message router, CDN, session border controller, WAN 157 cceleration, DPI, firewall, NAT, QoE monitor, PE router, BRAS, and 158 radio/fixed access network nodes. 160 o Network Service: Composition of Network Function(s) and/or Network 161 Service(s), defined by its functional and behavioural 162 specification. The Network Service contributes to the behaviour 163 of the higher layer service, which is characterized by at least 164 performance, dependability, and security specifications. The end- 165 to-end network service behaviour is the result of the combination 166 of the individual network function behaviours as well as the 167 behaviours of the network infrastructure composition mechanism 168 [ETSI-NFV-TERM]. 170 o Service Function (SF): A function that is responsible for specific 171 treatment of received packets. A service function can act at 172 various layers of a protocol stack (e.g., at the network layer or 173 other OSI layers). As a logical component, a service function can 174 be realized as a virtual element or be embedded in a physical 175 network element. One or more service functions can be embedded in 176 the same network element. Multiple occurrences of the service 177 function can exist in the same administrative domain. A non- 178 exhaustive list of service functions includes: firewalls, WAN and 179 application acceleration, Deep Packet Inspection (DPI), server 180 load balancers, NAT44 [RFC3022], NAT64 [RFC6146], HTTP header 181 enrichment functions, and TCP optimizers. The generic term "L4-L7 182 services" is often used to describe many service functions 183 [RFC7498]. 185 o Service Function Chain (SFC): A service function chain defines an 186 ordered or partially ordered set of abstract service functions and 187 ordering constraints that must be applied to packets, frames, and/ 188 or flows selected as a result of classification. An example of an 189 abstract service function is a firewall. The implied order may 190 not be a linear progression as the architecture allows for SFCs 191 that copy to more than one branch, and also allows for cases where 192 there is flexibility in the order in which service functions need 193 to be applied. The term "service chain" is often used as 194 shorthand for "service function chain" [RFC7498]. 196 o Connectivity Service: Any service between layer 0 and layer 3 197 aiming at delivering traffic among two or more end customer edge 198 nodes connected to provider edge nodes. Examples include L3VPN, 199 L2VPN etc. 201 o Link Termination Point (LTP): A conceptual point of connection of 202 a TE node to one of the TE links, terminated by the TE node. 203 Cardinality between an LTP and the associated TE link is 1:0..1 204 [RFC8795]. 206 o Tunnel Termination Point (TTP): An element of TE topology 207 representing one or several of potential transport service 208 termination points (i.e. service client adaptation points such as 209 WDM/OCh transponder). TTP is associated with (hosted by) exactly 210 one TE node. TTP is assigned with the TE node scope unique ID. 211 Depending on the TE node's internal constraints, a given TTP 212 hosted by the TE node could be accessed via one, several or all TE 213 links terminated by the TE node [RFC8795]. 215 o Topology and Orchestration Specification for Cloud Applications 216 (TOSCA): A language standard specified by OASIS, to describe 217 service components and their relationships using a service 218 topology, and management procedures using orchestration processes. 219 OASIS is a nonprofit consortium that drives the development, 220 convergence and adoption of open standards for the global 221 information society. 223 The following terms are defined in [RFC7950] and are not redefined 224 here: 226 o augment 228 o data model 230 o data node 232 1.2. Tree Diagrams 234 A simplified graphical representation of the data model is presented 235 in this document, by using the tree format defined in [RFC8340]. 237 1.3. Prefixes in Data Node Names 239 In this document, names of data nodes, actions, and other data model 240 objects are often used without a prefix, as long as it is clear from 241 the context in which YANG module each name is defined. Otherwise, 242 names are prefixed using the standard prefix associated with the 243 corresponding YANG module, as shown in Table 1. 245 +----------+------------------+------------------------------+ 246 | Prefix | YANG module | Reference | 247 +----------+------------------+------------------------------+ 248 | inet | ietf-inet-types | [RFC6991] | 249 | nw | ietf-network | [RFC8345] | 250 | nt | ietf-network- | [RFC8345] | 251 | | topology | | 252 | te-types | ietf-te-types | [RFC8776] | 253 | tet | ietf-te-topology | [RFC8795] | 254 | actn-vn | ietf-actn-vn | [I-D.ietf-teas-actn-vn-yang] | 255 +----------+------------------+------------------------------+ 257 Table 1: Prefixes and Corresponding YANG Modules 259 2. Modeling Considerations 261 The model introduced in this document is an augmentation of the TE 262 Topology model defined in [RFC8795]. SFs are modeled as child 263 elements of a TE node similarly to how Link Termination Points (LTPs) 264 and Tunnel Termination Points (TTPs) are modeled in the TE Topology 265 model. The SFs are defined as opaque objects identified via topology 266 unique service-function-id's. Each SF has one or more Connection 267 Points (CPs) identified via SF-unique sf-connection-point-id's, over 268 which the SF could be connected to other SFs resided on the same TE 269 node, as well as to other elements of the TE node, in particular, to 270 the node's LTPs and/or TTPs. An interested client may use service- 271 function-id's to look up the SFs in TOSCA or YANG data store(s) 272 defined by [ETSI-NFV-YANG] to retrieve the details of the SFs, for 273 example, to understand the SF's mutual substitutability. 275 The TE Topology model introduces a concept of Connectivity Matrix 276 (CM), and uses the CM to describe which and at what costs a TE node's 277 LTPs could be inter-connected internally across the TE node. The 278 model defined in this document heavily uses the same concept to 279 describe the SF connectivity via introducing 3 additional CMs: 281 1. SF2SF CM (SF to SF Connectivity Matrix). This CM describes which 282 pairs of SFs could be locally inter-connected, and, if yes, in 283 which direction, via which CPs and at what costs. In other 284 words, the SF2SF CM describes how SFs residing on the same TE 285 node could be inter-connected into local from the TE node's 286 perspective SFCs; 288 2. SF2LTP CM (SF to LTP Connectivity Matrix). This CM describes 289 how, in which direction and at what costs the TE node's SFs could 290 be connected to the TE node's LTPs and hence to SFs residing on 291 neighboring TE nodes that are connected to LTPs at the remote 292 ends of corresponding TE links; 294 3. SF2TTP CM (SF to TTP Connectivity Matrix). This CM describes 295 how, in which direction and at what costs the TE node's SFs could 296 be connected to the TE node's TTPs and hence to SFs residing on 297 other TE nodes on the topology that could be inter-connected with 298 the TE node in question via TE tunnels terminated by the 299 corresponding TTPs. 301 In addition to SF2SF CM, the local SF chaining could be described 302 with the help of ETSI models Virtual Links (VLs) [ETSI-NFV-YANG]. 303 This option is especially useful when the costs of the local chaining 304 are negligible as compared to ones of the end-to-end SFCs said local 305 SFCs are part of. 307 Section 3 and 4 provide the YANG model structure and the YANG module 308 for SF-aware Topology. Section 5 and 6 provide the YANG model 309 structure and the YANG module for Data Center Compute Node resource 310 abstraction. This provides an example of SF2LTP CM where DC compute 311 nodes are connected to LTPs at the remote ends of the corresponding 312 TE links. This use-case is described in Section 10 of Appendix C. 314 3. SF Aware TE Topology Model Structure 316 module: ietf-te-topology-sf 317 augment /nw:networks/nw:network/nw:network-types/tet:te-topology: 318 +--rw sf! 319 augment /nw:networks/nw:network/nw:node/tet:te 320 /tet:te-node-attributes: 321 +--rw service-function 322 +--rw connectivity-matrices 323 | +--rw connectivity-matrix* [id] 324 | +--rw id uint32 325 | +--rw from 326 | | +--rw service-function-id? leafref 327 | | +--rw sf-connection-point-id? leafref 328 | +--rw to 329 | | +--rw service-function-id? leafref 330 | | +--rw sf-connection-point-id? leafref 331 | +--rw enabled? boolean 332 | +--rw direction? connectivity-direction 333 | +--rw virtual-link-id? string 334 +--rw link-terminations 335 +--rw link-termination* [id] 336 +--rw id uint32 337 +--rw from 338 | +--rw tp-ref? leafref 339 +--rw to 340 | +--rw service-function-id? leafref 341 | +--rw sf-connection-point-id? leafref 342 +--rw enabled? boolean 343 +--rw direction? connectivity-direction 344 augment /nw:networks/nw:network/nw:node/tet:te 345 /tet:information-source-entry: 346 +--ro service-function 347 +--ro connectivity-matrices 348 | +--ro connectivity-matrix* [id] 349 | +--ro id uint32 350 | +--ro from 351 | | +--ro service-function-id? leafref 352 | | +--ro sf-connection-point-id? leafref 353 | +--ro to 354 | | +--ro service-function-id? leafref 355 | | +--ro sf-connection-point-id? leafref 356 | +--ro enabled? boolean 357 | +--ro direction? connectivity-direction 358 | +--ro virtual-link-id? string 359 +--ro link-terminations 360 +--ro link-termination* [id] 361 +--ro id uint32 362 +--ro from 363 | +--ro tp-ref? leafref 364 +--ro to 365 | +--ro service-function-id? leafref 366 | +--ro sf-connection-point-id? leafref 367 +--ro enabled? boolean 368 +--ro direction? connectivity-direction 369 augment /nw:networks/nw:network/nw:node/tet:te 370 /tet:tunnel-termination-point: 371 +--rw service-function 372 +--rw tunnel-terminations 373 +--rw tunnel-termination* [id] 374 +--rw id uint32 375 +--rw service-function-id? leafref 376 +--rw sf-connection-point-id? leafref 377 +--rw enabled? boolean 378 +--rw direction? connectivity-direction 379 augment /nw:networks/nw:network/nw:node: 381 +--rw service-functions 382 +--rw service-function* [id] 383 +--rw id string 384 +--rw type? identityref 385 +--rw te-metric? te-types:te-metric 386 +--rw priority? uint8 387 +--rw connection-points 388 +--rw connection-point* [id] 389 +--rw id string 390 +--rw type? identityref 392 4. SF Aware TE Topology YANG Module 394 This module references [RFC7665], [RFC8345], [RFC8776], [RFC8795], 395 [ETSI-NFV-YANG], and [ETSI-NFV-PACKAGE]. 397 file "ietf-te-topology-sf@2022-02-25.yang" 398 module ietf-te-topology-sf { 399 yang-version 1.1; 400 namespace "urn:ietf:params:xml:ns:yang:ietf-te-topology-sf"; 402 prefix "tet-sf"; 404 import ietf-network { 405 prefix "nw"; 406 reference 407 "RFC 8345: A YANG Data Model for Network Topologies"; 408 } 410 import ietf-network-topology { 411 prefix "nt"; 412 reference 413 "RFC 8345: A YANG Data Model for Network Topologies"; 414 } 416 import ietf-te-topology { 417 prefix "tet"; 418 reference 419 "RFC 8795: YANG Data Model for Traffic Engineering (TE) 420 Topologies"; 421 } 423 import ietf-te-types { 424 prefix "te-types"; 425 reference 426 "RFC8776: Common YANG Data Types for Traffic Engineering."; 428 } 430 organization 431 "Traffic Engineering Architecture and Signaling (TEAS) 432 Working Group"; 434 contact 435 "WG Web: 436 WG List: 438 Editors: Igor Bryskin 439 441 Xufeng Liu 442 "; 444 description 445 "Network service and function aware aware TE topology model. 447 Copyright (c) 2021 IETF Trust and the persons identified as 448 authors of the code. All rights reserved. 450 Redistribution and use in source and binary forms, with or 451 without modification, is permitted pursuant to, and subject to 452 the license terms contained in, the Simplified BSD License set 453 forth in Section 4.c of the IETF Trust's Legal Provisions 454 Relating to IETF Documents 455 (http://trustee.ietf.org/license-info). 457 This version of this YANG module is part of RFC XXXX; see the 458 RFC itself for full legal notices."; 460 revision 2022-02-25 { 461 description "Initial revision"; 462 reference "RFC XXXX: SF Aware TE Topology YANG Model"; 463 } 465 /* 466 * Identities 467 */ 468 identity sf-type { 469 description 470 "Base identity from which all service function types are 471 derived. The definitions of the derived identities are 472 left to the implementation. An example can be 'firewall'."; 473 } 474 identity cp-type { 475 description 476 "Base identity from which all connection point types are 477 derived. The definitions of the derived identities are 478 left to the implementation. Examples can be 'ethernet', 479 'mpls', or 'ipv4'."; 480 } 482 /* 483 * Typedefs 484 */ 485 typedef connectivity-direction { 486 type enumeration { 487 enum "to" { 488 description 489 "The direction is uni-directional, towards the 'to' 490 entity direction."; 491 } 492 enum "from" { 493 description 494 "The direction is uni-directional, from the 'to' 495 entity direction."; 496 } 497 enum "bidir" { 498 description 499 "The direction is bi-directional."; 500 } 501 } 502 description 503 "A type used to indicates whether a connectivity is 504 uni-directional, or bi-directional. If the relation is 505 uni-directional, the value of this type indicates the 506 direction."; 507 } // connectivity-direction 509 /* 510 * Groupings 511 */ 512 grouping service-function-connection-point-ref { 513 description 514 "Reference to a service function connection point."; 515 leaf service-function-id { 516 type leafref { 517 path "../../../../../../../service-functions/" 518 + "service-function/id"; 519 } 520 description 521 "Reference to a service function id."; 522 } 523 leaf sf-connection-point-id { 524 type leafref { 525 path "../../../../../../../service-functions/" 526 + "service-function[id=current()/../service-function-id]/" 527 + "connection-points/connection-point/id"; 528 } 529 description 530 "Reference to a SF(service function) connection point id."; 531 } 532 } // service-function-connection-point-ref 534 grouping service-function-node-augmentation { 535 description 536 "Augmenting a node to contain a list of available service 537 functions."; 538 container service-functions { 539 description 540 "Containing the service functions that are available on this 541 node. Any of these service functions can be referenced 542 and enabled in te-node-attributes"; 543 list service-function { 544 key "id"; 545 description 546 "A list of service functions on this node."; 547 leaf id { 548 type string; 549 description "Identifies the service function."; 550 } 551 leaf type { 552 type identityref { 553 base "sf-type"; 554 } 555 description 556 "The service function type, such as 'firewall'. 557 The parameters of each service function type are not 558 specified in this model, and may be speficied by other 559 models such as the one defined by ETSI GS NFV-IFA 011."; 560 reference 561 "ETSI-NFV-PACKAGE: ETSI GS NFV-IFA 011: 562 Network Functions Virtualisation (NFV) Release 4; 563 Management and Orchestration; 564 VNF Descriptor and Packaging Specification."; 565 } 566 leaf te-metric { 567 type te-types:te-metric; 568 description 569 "Specifies the TE (Traffic Engineering) metric for this 570 service function. The server uses this value as a 571 preference of selecting the given service function 572 instance."; 573 } 574 leaf priority { 575 type uint8; 576 default 0; 577 description 578 "Specifies the priority level at which the service 579 function instance is available. 580 A lower number indicates a higher priority. The highest 581 priority is 0."; 582 } 583 container connection-points { 584 description 585 "Containing the connection points that are available on 586 this service function. 587 node. Any of these connection points can be referenced 588 and enabled in te-node-attributes"; 589 list connection-point { 590 key "id"; 591 description 592 "A list of connection points on this node."; 593 leaf id { 594 type string; 595 description "Identifies the connection point."; 596 } 597 leaf type { 598 type identityref { 599 base "cp-type"; 600 } 601 description 602 "The connection point type, such as 'ethernet', 603 'mpls', or 'ipv4'. 604 The parameters of each service function type are not 605 specified in this model, and may be speficied by 606 other models such as the one defined by ETSI GS 607 NFV-IFA 011."; 608 reference 609 "ETSI-NFV-PACKAGE: ETSI GS NFV-IFA 011: 610 Network Functions Virtualisation (NFV) Release 4; 611 Management and Orchestration; 612 VNF Descriptor and Packaging Specification."; 613 } 614 } 615 } 616 } 617 } 618 } // service-function-node-augmentation 619 grouping service-function-node-te-augmentation { 620 description 621 "Augmenting a TE node to be network service and function 622 aware."; 623 container service-function { 624 description 625 "Containing attributes related to network services and 626 network functions"; 627 container connectivity-matrices { 628 description 629 "Connectivity relations between network services/functions 630 on a TE node, which can be either abstract or physical."; 631 reference 632 "ETSI-NFV-YANG: ETSI GS NFV-SOL 006: 633 Network Functions Virtualisation (NFV) Release 3; 634 Protocols and Data Models; 635 NFV descriptors based on YANG specification. 636 RFC7665: Service Function Chaining (SFC) Architecture."; 637 list connectivity-matrix { 638 key "id"; 639 description 640 "Represents the connectivity relations between network 641 services/functions on a TE node."; 642 leaf id { 643 type uint32; 644 description "Identifies the connectivity-matrix entry."; 645 } 647 container from { 648 description 649 "Reference to the source network service or 650 network function."; 651 uses service-function-connection-point-ref; 652 } // from 653 container to { 654 description 655 "Reference to the destination network service or 656 network function."; 657 uses service-function-connection-point-ref; 658 } // to 659 leaf enabled { 660 type boolean; 661 description 662 "'true' if this connectivity entry is enabled."; 663 } 664 leaf direction { 665 type connectivity-direction; 666 description 667 "Indicates whether this connectivity is 668 uni-directional, or bi-directional. If the 669 relation is uni-directional, the value of 670 this leaf indicates the direction."; 671 } 672 leaf virtual-link-id { 673 type string; 674 description 675 "Reference to a virtual link that models this 676 conectivity relation in the network function 677 model."; 678 } 679 } // connectivity-matrix 680 } // connectivity-matrices 682 container link-terminations { 683 description 684 "Connectivity relations between network services/functions 685 and link termination points on a TE node, which can be 686 either abstract or physical."; 687 reference 688 "ETSI-NFV-YANG: ETSI GS NFV-SOL 006: 689 Network Functions Virtualisation (NFV) Release 3; 690 Protocols and Data Models; 691 NFV descriptors based on YANG specification. 692 RFC7665: Service Function Chaining (SFC) Architecture."; 693 list link-termination { 694 key "id"; 695 description 696 "Each entry of the list represents the connectivity 697 relation between a network service/function and 698 a link termination point on a TE node."; 699 leaf id { 700 type uint32; 701 description "Identifies the termination entry."; 702 } 704 container from { 705 description 706 "Reference to the link termination point."; 707 } // from 708 container to { 709 description 710 "Reference to the network service or network 711 function."; 712 uses service-function-connection-point-ref; 713 } // to 714 leaf enabled { 715 type boolean; 716 description 717 "'true' if this connectivity entry is enabled."; 718 } 719 leaf direction { 720 type connectivity-direction; 721 description 722 "Indicates whether this connectivity is 723 uni-directional, or bi-directional. If the 724 relation is uni-directional, the value of 725 this leaf indicates the direction."; 726 } 727 } // link-termination 728 } 729 } 730 } // service-function-node-te-augmentation 732 grouping service-function-ttp-augmentation { 733 description 734 "Augmenting a tunnel termination point to be network service 735 aware."; 736 container service-function { 737 description 738 "Containing attributes related to network services and 739 network functions"; 740 container tunnel-terminations { 741 description 742 "Connectivity relations between network services/functions 743 and tunnel termination points on a TE node, which can be 744 either abstract or physical."; 745 reference 746 "ETSI-NFV-YANG: ETSI GS NFV-SOL 006: 747 Network Functions Virtualisation (NFV) Release 3; 748 Protocols and Data Models; 749 NFV descriptors based on YANG specification. 750 RFC7665: Service Function Chaining (SFC) Architecture."; 751 list tunnel-termination { 752 key "id"; 753 description 754 "Each entry of the list represents the connectivity 755 relation between a network service/function and 756 a tunnel termination point on a TE node."; 757 leaf id { 758 type uint32; 759 description "Identifies the termination entry."; 760 } 761 leaf service-function-id { 762 type leafref { 763 path "../../../../../../service-functions/" 764 + "service-function/id"; 765 } 766 description 767 "Reference to a service function id."; 768 } 769 leaf sf-connection-point-id { 770 type leafref { 771 path "../../../../../../service-functions/" 772 + "service-function[id=current()/../" 773 + "service-function-id]/connection-points/" 774 + "connection-point/id"; 775 } 776 description 777 "Reference to a SF(service function) connection point 778 id."; 779 } 780 leaf enabled { 781 type boolean; 782 description 783 "'true' if this connectivity entry is enabled."; 784 } 785 leaf direction { 786 type connectivity-direction; 787 description 788 "Indicates whether this connectivity is 789 uni-directional, or bi-directional. If the 790 relation is uni-directional, the value of 791 this leaf indicates the direction."; 792 } 793 } // link-termination 794 } 795 } 796 } // service-function-ttp-augmentation 798 grouping sf-topology-type { 799 description 800 "Identifies the SF aware TE topology type."; 801 container sf { 802 presence "Indidates that the TE topology is SF aware."; 803 description 804 "Its presence identifies that the TE topology is SF aware."; 805 } 806 } // sf-topology-type 808 grouping termination-point-ref { 809 description 810 "Reference to a link termination point."; 812 leaf tp-ref { 813 type leafref { 814 path "../../../../../../../nt:termination-point/" 815 + "nt:tp-id"; 816 } 817 description 818 "Reference to the link termination point."; 819 } 820 } // termination-point-ref 822 /* 823 * Augmentations 824 */ 825 /* Augmentations to network-types/te-topology */ 826 augment "/nw:networks/nw:network/nw:network-types/" 827 + "tet:te-topology" { 828 description 829 "Defines the SF aware TE topology type."; 830 uses sf-topology-type; 831 } 833 /* Augmentations to te-node-attributes */ 834 augment "/nw:networks/nw:network/nw:node/tet:te/" 835 + "tet:te-node-attributes" { 836 description 837 "Parameters for SF aware TE topology."; 838 uses service-function-node-te-augmentation; 839 } 841 /* Augmentations to information-source-entry */ 842 augment "/nw:networks/nw:network/nw:node/tet:te/" 843 + "tet:information-source-entry" { 844 description 845 "Parameters for SF aware TE topology."; 846 uses service-function-node-te-augmentation; 847 } 849 /* Augmentations to tunnel-termination-point */ 850 augment "/nw:networks/nw:network/nw:node/tet:te/" 851 + "tet:tunnel-termination-point" { 852 description 853 "Parameters for SF aware TE topology."; 854 uses service-function-ttp-augmentation; 855 } 857 /* Augmentations to link-termination under te-node-attributes */ 858 augment "/nw:networks/nw:network/nw:node/tet:te/" 859 + "tet:te-node-attributes/tet-sf:service-function/" 860 + "tet-sf:link-terminations/tet-sf:link-termination/" 861 + "tet-sf:from" { 862 description 863 "Add reference to the link termination point."; 864 uses termination-point-ref; 865 } 867 /* Augmentations to link-termination under 868 information-source-entry */ 869 augment "/nw:networks/nw:network/nw:node/tet:te/" 870 + "tet:information-source-entry/tet-sf:service-function/" 871 + "tet-sf:link-terminations/tet-sf:link-termination/" 872 + "tet-sf:from" { 873 description 874 "Add reference to the link termination point."; 875 uses termination-point-ref; 876 } 878 /* Augmentations to node */ 879 augment "/nw:networks/nw:network/nw:node" { 880 description 881 "Available service functions on the node."; 882 uses service-function-node-augmentation; 883 } 884 } 885 887 5. IANA Considerations 889 This document registers the following namespace URIs in the IETF XML 890 registry [RFC3688]: 892 -------------------------------------------------------------------- 893 URI: urn:ietf:params:xml:ns:yang:ietf-te-topology-sf 894 Registrant Contact: The IESG. 895 XML: N/A, the requested URI is an XML namespace. 896 -------------------------------------------------------------------- 898 -------------------------------------------------------------------- 899 URI: urn:ietf:params:xml:ns:yang:ietf-te-topology-sf-state 900 Registrant Contact: The IESG. 901 XML: N/A, the requested URI is an XML namespace. 902 -------------------------------------------------------------------- 904 This document registers the following YANG modules in the YANG Module 905 Names registry [RFC6020]: 907 -------------------------------------------------------------------- 908 name: ietf-te-topology-sf 909 namespace: urn:ietf:params:xml:ns:yang:ietf-te-topology-packet 910 prefix: tet-sf 911 reference: RFC XXXX 912 -------------------------------------------------------------------- 914 -------------------------------------------------------------------- 915 name: ietf-te-topology-sf-state 916 namespace: urn:ietf:params:xml:ns:yang:ietf-te-topology-packet-state 917 prefix: tet-sf-s 918 reference: RFC XXXX 919 -------------------------------------------------------------------- 921 6. Security Considerations 923 The YANG module specified in this document defines a schema for data 924 that is designed to be accessed via network management protocols such 925 as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer 926 is the secure transport layer, and the mandatory-to-implement secure 927 transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer 928 is HTTPS, and the mandatory-to-implement secure transport is TLS 929 [RFC8446]. 931 The Network Configuration Access Control Model (NACM) [RFC8341] 932 provides the means to restrict access for particular NETCONF or 933 RESTCONF users to a preconfigured subset of all available NETCONF or 934 RESTCONF protocol operations and content. 936 There are a number of data nodes defined in this YANG module that are 937 writable/creatable/deletable (i.e., config true, which is the 938 default). These data nodes may be considered sensitive or vulnerable 939 in some network environments. Write operations (e.g., edit-config) 940 to these data nodes without proper protection can have a negative 941 effect on network operations. These are the subtrees and data nodes 942 and their sensitivity/vulnerability: 944 /nw:networks/nw:network/nw:network-types/tet:te-topology/sf 945 This subtree specifies the topology type. Modifying the 946 configurations can make topology type invalid and cause 947 interruption to the specified SF Aware TE topology and the related 948 SF Aware TE topologies. 950 /nw:networks/nw:network/nw:node/tet:te/tet:te-node-attributes/ 951 service-function 952 This subtree specifies the configurations of service functions in 953 SF Aware TE nodes. Modifying the configurations in this subtree 954 can change the configurations of service functions in the 955 specified node, causing these service functions disabled or 956 misbehaving in the specified node. 958 /nw:networks/nw:network/nw:node/tet:te/tet:tunnel-termination-point/ 959 service-function 960 This subtree specifies the configurations of service functions on 961 a tunnel-termination-point in SF Aware TE nodes. Modifying the 962 configurations in this subtree can change the configurations of 963 service functions on the spcified tunnel-termination-point in the 964 specified node, causing these service functions disabled or 965 misbehaving. 967 /nw:networks/nw:network/nw:node/service-functions 968 This subtree specifies the available service functions in SF Aware 969 TE nodes. Modifying the configurations in this subtree can change 970 the configurations of the available service functions in the 971 specified node, causing these service functions disabled or 972 misbehaving in the specified node. 974 Some of the readable data nodes in this YANG module may be considered 975 sensitive or vulnerable in some network environments. It is thus 976 important to control read access (e.g., via get, get-config, or 977 notification) to these data nodes. These are the subtrees and data 978 nodes and their sensitivity/vulnerability: 980 /nw:networks/nw:network/nw:network-types/tet:te-topology/sf 981 Unauthorized access to this subtree can disclose the SF Aware TE 982 topology type. 984 /nw:networks/nw:network/nw:node/tet:te/tet:te-node-attributes/ 985 service-function 986 Unauthorized access to this subtree can disclose the operational 987 state information of the service functions in the specified SF 988 Aware TE node. 990 /nw:networks/nw:network/nw:node/tet:te/tet:information-source-entry/ 991 service-function 992 Unauthorized access to this subtree can disclose the operational 993 state information of the service functions in the specified SF 994 Aware TE node. 996 /nw:networks/nw:network/nw:node/tet:te/tet:tunnel-termination-point/ 997 service-function 998 Unauthorized access to this subtree can disclose the operational 999 state information of the service functions on the specified 1000 tunnel-termination-point in the specified SF Aware TE node. 1002 /nw:networks/nw:network/nw:node/service-functions 1003 Unauthorized access to this subtree can disclose the operational 1004 state information of the availble service functions in the 1005 specified node. 1007 7. References 1009 7.1. Normative References 1011 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1012 Requirement Levels", BCP 14, RFC 2119, 1013 DOI 10.17487/RFC2119, March 1997, 1014 . 1016 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1017 DOI 10.17487/RFC3688, January 2004, 1018 . 1020 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1021 the Network Configuration Protocol (NETCONF)", RFC 6020, 1022 DOI 10.17487/RFC6020, October 2010, 1023 . 1025 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1026 and A. Bierman, Ed., "Network Configuration Protocol 1027 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1028 . 1030 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 1031 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 1032 . 1034 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 1035 RFC 6991, DOI 10.17487/RFC6991, July 2013, 1036 . 1038 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1039 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1040 . 1042 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1043 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 1044 . 1046 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1047 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1048 May 2017, . 1050 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 1051 Access Control Model", STD 91, RFC 8341, 1052 DOI 10.17487/RFC8341, March 2018, 1053 . 1055 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 1056 and R. Wilton, "Network Management Datastore Architecture 1057 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 1058 . 1060 [RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N., 1061 Ananthakrishnan, H., and X. Liu, "A YANG Data Model for 1062 Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March 1063 2018, . 1065 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1066 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1067 . 1069 [RFC8529] Berger, L., Hopps, C., Lindem, A., Bogdanovic, D., and X. 1070 Liu, "YANG Data Model for Network Instances", RFC 8529, 1071 DOI 10.17487/RFC8529, March 2019, 1072 . 1074 [RFC8530] Berger, L., Hopps, C., Lindem, A., Bogdanovic, D., and X. 1075 Liu, "YANG Model for Logical Network Elements", RFC 8530, 1076 DOI 10.17487/RFC8530, March 2019, 1077 . 1079 [RFC8776] Saad, T., Gandhi, R., Liu, X., Beeram, V., and I. Bryskin, 1080 "Common YANG Data Types for Traffic Engineering", 1081 RFC 8776, DOI 10.17487/RFC8776, June 2020, 1082 . 1084 [RFC8795] Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and 1085 O. Gonzalez de Dios, "YANG Data Model for Traffic 1086 Engineering (TE) Topologies", RFC 8795, 1087 DOI 10.17487/RFC8795, August 2020, 1088 . 1090 [I-D.ietf-teas-yang-te] 1091 Saad, T., Gandhi, R., Liu, X., Beeram, V. P., Bryskin, I., 1092 and O. G. D. Dios, "A YANG Data Model for Traffic 1093 Engineering Tunnels, Label Switched Paths and Interfaces", 1094 draft-ietf-teas-yang-te-29 (work in progress), February 1095 2022. 1097 [I-D.ietf-teas-actn-vn-yang] 1098 Lee, Y., Dhody, D., Ceccarelli, D., Bryskin, I., and B. Y. 1099 Yoon, "A YANG Data Model for VN Operation", draft-ietf- 1100 teas-actn-vn-yang-13 (work in progress), October 2021. 1102 [ETSI-NFV-PACKAGE] 1103 ETSI, "Network Functions Virtualisation (NFV) Release 4; 1104 Management and Orchestration; VNF Descriptor and Packaging 1105 Specification", ETSI GR NFV-IFA 011 V4.2.1, May 2021, 1106 . 1109 [ETSI-NFV-TERM] 1110 ETSI, "Network Functions Virtualisation (NFV); Terminology 1111 for Main Concepts in NFV", ETSI GR NFV 003 V1.6.1, March 1112 2021, . 1115 [ETSI-NFV-YANG] 1116 ETSI, "Network Functions Virtualisation (NFV) Release 3; 1117 Protocols and Data Models; NFV descriptors based on YANG 1118 specification", ETSI GS NFV-SOL 006 V3.5.1, July 2021, 1119 . 1122 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 1123 Address Translator (Traditional NAT)", RFC 3022, 1124 DOI 10.17487/RFC3022, January 2001, 1125 . 1127 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 1128 NAT64: Network Address and Protocol Translation from IPv6 1129 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, 1130 April 2011, . 1132 [RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for 1133 Abstraction and Control of TE Networks (ACTN)", RFC 8453, 1134 DOI 10.17487/RFC8453, August 2018, 1135 . 1137 [RFC8459] Dolson, D., Homma, S., Lopez, D., and M. Boucadair, 1138 "Hierarchical Service Function Chaining (hSFC)", RFC 8459, 1139 DOI 10.17487/RFC8459, September 2018, 1140 . 1142 [_3GPP.28.801] 1143 3GPP, "Study on management and orchestration of network 1144 slicing for next generation network", 3GPP TR 28.801 1145 V2.0.0, September 2017, 1146 . 1148 7.2. Informative References 1150 [RFC7498] Quinn, P., Ed. and T. Nadeau, Ed., "Problem Statement for 1151 Service Function Chaining", RFC 7498, 1152 DOI 10.17487/RFC7498, April 2015, 1153 . 1155 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 1156 Chaining (SFC) Architecture", RFC 7665, 1157 DOI 10.17487/RFC7665, October 2015, 1158 . 1160 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 1161 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 1162 . 1164 [I-D.defoy-netslices-3gpp-network-slicing] 1165 Foy, X. D. and A. Rahman, "Network Slicing - 3GPP Use 1166 Case", draft-defoy-netslices-3gpp-network-slicing-02 (work 1167 in progress), October 2017. 1169 Appendix A. Companion YANG Model for Non-NMDA Compliant Implementations 1171 The YANG module ietf-te-topology-sf defined in this document is 1172 designed to be used in conjunction with implementations that support 1173 the Network Management Datastore Architecture (NMDA) defined in 1174 [RFC8342]. In order to allow implementations to use the model even 1175 in cases when NMDA is not supported, the following companion module, 1176 ietf-te-topology-sf-state, is defined as state model, which mirrors 1177 the module ietf-te-topology-sf defined earlier in this document. 1178 However, all data nodes in the companion module are non-configurable, 1179 to represent the applied configuration or the derived operational 1180 states. 1182 The companion module, ietf-te-topology-sf-state, is redundant and 1183 SHOULD NOT be supported by implementations that support NMDA. 1185 As the structure of the companion module mirrors that of the 1186 coorespinding NMDA model, the YANG tree of the companion module is 1187 not depicted separately. 1189 A.1. SF Aware TE Topology State Module 1191 file "ietf-te-topology-sf-state@2022-02-25.yang" 1192 module ietf-te-topology-sf-state { 1193 yang-version 1.1; 1194 namespace "urn:ietf:params:xml:ns:yang:ietf-te-topology-sf-state"; 1196 prefix "tet-sf-s"; 1198 import ietf-te-topology-sf { 1199 prefix "tet-sf"; 1200 reference 1201 "RFC XXXX: SF Aware TE Topology YANG Model"; 1202 } 1204 import ietf-network-state { 1205 prefix "nw-s"; 1206 reference 1207 "RFC 8345: A YANG Data Model for Network Topologies"; 1208 } 1210 import ietf-network-topology-state { 1211 prefix "nt-s"; 1212 reference 1213 "RFC 8345: A YANG Data Model for Network Topologies"; 1214 } 1215 import ietf-te-topology-state { 1216 prefix "tet-s"; 1217 reference 1218 "RFC 8795: YANG Data Model for Traffic Engineering (TE) 1219 Topologies"; 1220 } 1222 organization 1223 "Traffic Engineering Architecture and Signaling (TEAS) 1224 Working Group"; 1226 contact 1227 "WG Web: 1228 WG List: 1230 Editors: Igor Bryskin 1231 1233 Xufeng Liu 1234 "; 1236 description 1237 "Network service and function aware aware TE topology operational 1238 state model for non-NMDA compliant implementations. 1240 Copyright (c) 2021 IETF Trust and the persons identified as 1241 authors of the code. All rights reserved. 1243 Redistribution and use in source and binary forms, with or 1244 without modification, is permitted pursuant to, and subject to 1245 the license terms contained in, the Simplified BSD License set 1246 forth in Section 4.c of the IETF Trust's Legal Provisions 1247 Relating to IETF Documents 1248 (http://trustee.ietf.org/license-info). 1250 This version of this YANG module is part of RFC XXXX; see the 1251 RFC itself for full legal notices."; 1253 revision 2022-02-25 { 1254 description "Initial revision"; 1255 reference "RFC XXXX: SF Aware TE Topology YANG Model"; 1256 } 1258 /* 1259 * Groupings 1260 */ 1261 grouping state-termination-point-ref { 1262 description 1263 "Reference to a link termination point in this non-NMDA state 1264 module."; 1265 leaf tp-ref { 1266 type leafref { 1267 path "../../../../../../../nt-s:termination-point/" 1268 + "nt-s:tp-id"; 1269 } 1270 description 1271 "Reference to the link termination point."; 1272 } 1273 } // termination-point-ref 1275 /* 1276 * Augmentations 1277 */ 1278 /* Augmentations to network-types/te-topology */ 1279 augment "/nw-s:networks/nw-s:network/nw-s:network-types/" 1280 + "tet-s:te-topology" { 1281 description 1282 "Defines the SF aware TE topology type."; 1283 uses tet-sf:sf-topology-type; 1284 } 1286 /* Augmentations to te-node-attributes */ 1287 augment "/nw-s:networks/nw-s:network/nw-s:node/tet-s:te/" 1288 + "tet-s:te-node-attributes" { 1289 description 1290 "Parameters for SF aware TE topology."; 1291 uses tet-sf:service-function-node-te-augmentation; 1292 } 1294 /* Augmentations to information-source-entry */ 1295 augment "/nw-s:networks/nw-s:network/nw-s:node/tet-s:te/" 1296 + "tet-s:information-source-entry" { 1297 description 1298 "Parameters for SF aware TE topology."; 1299 uses tet-sf:service-function-node-te-augmentation; 1300 } 1302 /* Augmentations to tunnel-termination-point */ 1303 augment "/nw-s:networks/nw-s:network/nw-s:node/tet-s:te/" 1304 + "tet-s:tunnel-termination-point" { 1305 description 1306 "Parameters for SF aware TE topology."; 1307 uses tet-sf:service-function-ttp-augmentation; 1308 } 1310 /* Augmentations to link-termination under te-node-attributes */ 1311 augment "/nw-s:networks/nw-s:network/nw-s:node/tet-s:te/" 1312 + "tet-s:te-node-attributes/tet-sf-s:service-function/" 1313 + "tet-sf-s:link-terminations/tet-sf-s:link-termination/" 1314 + "tet-sf-s:from" { 1315 description 1316 "Add reference to the link termination point."; 1317 uses state-termination-point-ref; 1318 } 1320 /* Augmentations to link-termination under 1321 information-source-entry */ 1322 augment "/nw-s:networks/nw-s:network/nw-s:node/tet-s:te/" 1323 + "tet-s:information-source-entry/tet-sf-s:service-function/" 1324 + "tet-sf-s:link-terminations/tet-sf-s:link-termination/" 1325 + "tet-sf-s:from" { 1326 description 1327 "Add reference to the link termination point."; 1328 uses state-termination-point-ref; 1329 } 1331 /* Augmentations to node */ 1332 augment "/nw-s:networks/nw-s:network/nw-s:node" { 1333 description 1334 "Available service functions on the node."; 1335 uses tet-sf:service-function-node-augmentation; 1336 } 1337 } 1338 1340 Appendix B. Data Examples 1342 B.1. A Topology with Multiple Connected Network Functions 1343 Node-1 1344 +----o--o--------------------------o-------+ 1345 | | | | | 1346 | \__/ \__ | 1347 | *\/ TTP-1 * * * * * * * * * *\/* | 1348 LTP-4 |* * * * TTP-2 * | LTP-1 1349 o------------*-----------------------------o 1350 | * * | 1351 LTP-3 |* * * * * *| LTP-2 1352 o--- -----o 1353 | \ / | 1354 | \ / | 1355 | \ CP01 CP02/ | 1356 | +----o--------------------------o------+ | 1357 | | VL1| VL4| | | 1358 | | |CP11 |CP33 | | 1359 | | +-o--+ +----+ +-o--+ | | 1360 | | |VNF1| |VNF2| |VNF3| | | 1361 | | +-o-o+ VL2 +--o-+ VL2 +-o-o+ | | 1362 | |CP12| |\----------/ \---------/| |CP32| | 1363 | | | |CP13 CP21 CP31| | | | 1364 | | | | VL2 | | | | 1365 | | | +------------------------+ | | | 1366 | | +----------------------------+ | | 1367 | | VL3 | | 1368 | | Network Service 1 | | 1369 | +--------------------------------------+ | 1370 +------------------------------------------+ 1372 The configuration instance data for Node-1 in the above figure could 1373 be as follows: 1375 { 1376 "networks": { 1377 "network": [ 1378 { 1379 "network-types": { 1380 "te-topology": { 1381 "sf": {} 1382 } 1383 }, 1384 "network-id": "network-sf-aware", 1385 "provider-id": 201, 1386 "client-id": 300, 1387 "te-topology-id": "te-topology:network-sf-aware", 1388 "node": [ 1389 { 1390 "node-id": "Node-1", 1391 "te-node-id": "2.0.1.1", 1392 "te": { 1393 "te-node-attributes": { 1394 "domain-id": 1, 1395 "is-abstract": [null], 1396 "connectivity-matrices": { 1397 }, 1398 "service-function": { 1399 "connectivity-matrices": { 1400 "connectivity-matrix": [ 1401 { 1402 "id": 10, 1403 "from": { 1404 "service-function-id": "Network Service 1", 1405 "sf-connection-point-id": "CP01" 1406 }, 1407 "to": { 1408 "service-function-id": "VNF1", 1409 "sf-connection-point-id": "CP11" 1410 } 1411 "direction": "bidir", 1412 "virtual-link-id": "VL1" 1413 }, 1414 { 1415 "id": 13, 1416 "from": { 1417 "service-function-id": "VNF1", 1418 "sf-connection-point-id": "CP12" 1419 }, 1420 "to": { 1421 "service-function-id": "VNF3", 1422 "sf-connection-point-id": "CP32" 1423 } 1424 "direction": "bidir", 1425 "virtual-link-id": "VL3" 1426 }, 1427 { 1428 "id": 12, 1429 "from": { 1430 "service-function-id": "VNF1", 1431 "sf-connection-point-id": "CP13" 1432 }, 1433 "to": { 1434 "service-function-id": "VNF2", 1435 "sf-connection-point-id": "CP21" 1436 } 1437 "direction": "bidir", 1438 "virtual-link-id": "VL2" 1440 }, 1441 { 1442 "id": 23, 1443 "from": { 1444 "service-function-id": "VNF2", 1445 "sf-connection-point-id": "CP21" 1446 }, 1447 "to": { 1448 "service-function-id": "VNF3" 1449 "sf-connection-point-id": "CP31" 1450 } 1451 "direction": "bidir", 1452 "virtual-link-id": "VL2" 1453 }, 1454 { 1455 "id": 30, 1456 "from": { 1457 "service-function-id": "Network Service 1", 1458 "sf-connection-point-id": "CP02" 1459 }, 1460 "to": { 1461 "service-function-id": "VNF3", 1462 "sf-connection-point-id": "CP33" 1463 } 1464 "direction": "bidir", 1465 "virtual-link-id": "VL4" 1466 } 1467 ] 1468 }, 1469 "link-terminations": { 1470 "link-termination": [ 1471 { 1472 "id": 2, 1473 "from": { 1474 "tp-ref": "LTP-2" 1475 }, 1476 "to": { 1477 "service-function-id": "Network Service 1", 1478 "sf-connection-point-id": "CP02" 1479 } 1480 "direction": "bidir" 1481 }, 1482 { 1483 "id": 3, 1484 "from": { 1485 "tp-ref": "LTP-3" 1486 }, 1487 "to": { 1488 "service-function-id": "Network Service 1", 1489 "sf-connection-point-id": "CP01" 1490 } 1491 "direction": "bidir" 1492 } 1493 ] 1494 } 1495 } 1496 } 1497 "tunnel-termination-point": [ 1498 { 1499 "tunnel-tp-id": 10001, 1500 "name": "TTP-1", 1501 "service-function-terminations": { 1502 } 1503 }, 1504 { 1505 "tunnel-tp-id": 10002, 1506 "name": "TTP-2", 1507 "service-function-terminations": { 1508 } 1509 } 1510 ] 1511 }, 1512 "termination-point": [ 1513 { 1514 "tp-id": "LTP-1", 1515 "te-tp-id": 10001 1516 "te": { 1517 "interface-switching-capability": [ 1518 { 1519 "switching-capability": "switching-l2sc", 1520 "encoding": "lsp-encoding-ethernet" 1521 } 1522 ] 1523 } 1524 }, 1525 { 1526 "tp-id": "LTP-2", 1527 "te-tp-id": 10002 1528 "te": { 1529 "interface-switching-capability": [ 1530 { 1531 "switching-capability": "switching-l2sc", 1532 "encoding": "lsp-encoding-ethernet" 1533 } 1534 ] 1535 } 1537 }, 1538 { 1539 "tp-id": "LTP-3", 1540 "te-tp-id": 10003 1541 "te": { 1542 "interface-switching-capability": [ 1543 { 1544 "switching-capability": "switching-l2sc", 1545 "encoding": "lsp-encoding-ethernet" 1546 } 1547 ] 1548 } 1549 }, 1550 { 1551 "tp-id": "LTP-4", 1552 "te-tp-id": 10004 1553 "te": { 1554 "interface-switching-capability": [ 1555 { 1556 "switching-capability": "switching-l2sc", 1557 "encoding": "lsp-encoding-ethernet" 1558 } 1559 ] 1560 } 1561 } 1562 ] 1563 } 1564 ] 1565 } 1566 ] 1567 } 1568 } 1570 B.2. A Topology with an Encapsulated Network Service 1572 In this example, a network service consists of several inter- 1573 connected network functions (NFs), and is represented by this model 1574 as an encapsulated opaque object without the details between its 1575 internals. 1577 Node-1 1578 +----o--o--------------------------o-------+ 1579 | | | | | 1580 | \__/ \__ | 1581 | *\/ TTP-1 * * * * * * * * * *\/* | 1582 LTP-4 |* * * * TTP-2 * | LTP-1 1583 o------------*-----------------------------o 1584 | * * | 1585 LTP-3 |* * * * * *| LTP-2 1586 o--- -----o 1587 | \ / | 1588 | \ / | 1589 | \ CP01 CP02/ | 1590 | +----o--------------------------o------+ | 1591 | | | | 1592 | | Network Service 1 | | 1593 | +--------------------------------------+ | 1594 +------------------------------------------+ 1596 The configuration instance data for Node-1 in the above figure could 1597 be as follows: 1599 { 1600 "networks": { 1601 "network": [ 1602 { 1603 "network-types": { 1604 "te-topology": { 1605 "sf": {} 1606 } 1607 }, 1608 "network-id": "network-sf-aware", 1609 "provider-id": 201, 1610 "client-id": 300, 1611 "te-topology-id": "te-topology:network-sf-aware", 1612 "node": [ 1613 { 1614 "node-id": "Node-1", 1615 "te-node-id": "2.0.1.1", 1616 "te": { 1617 "te-node-attributes": { 1618 "domain-id": 1, 1619 "is-abstract": [null], 1620 "connectivity-matrices": { 1621 }, 1622 "service-function": { 1623 "connectivity-matrices": { 1624 }, 1625 "link-terminations": { 1626 "link-termination": [ 1627 { 1628 "id": 2, 1629 "from": { 1630 "tp-ref": "LTP-2" 1631 }, 1632 "to": { 1633 "service-function-id": "Network Service 1", 1634 "sf-connection-point-id": "CP02" 1635 } 1636 "direction": "bidir" 1637 }, 1638 { 1639 "id": 3, 1640 "from": { 1641 "tp-ref": "LTP-3" 1642 }, 1643 "to": { 1644 "service-function-id": "Network Service 1", 1645 "sf-connection-point-id": "CP01" 1646 } 1647 "direction": "bidir" 1648 } 1649 ] 1650 } 1651 } 1652 } 1653 "tunnel-termination-point": [ 1654 { 1655 "tunnel-tp-id": 10001, 1656 "name": "TTP-1", 1657 "service-function-terminations": { 1658 } 1659 }, 1660 { 1661 "tunnel-tp-id": 10002, 1662 "name": "TTP-2", 1663 "service-function-terminations": { 1664 } 1665 } 1666 ] 1667 }, 1668 "termination-point": [ 1669 { 1670 "tp-id": "LTP-1", 1671 "te-tp-id": 10001 1672 "te": { 1673 "interface-switching-capability": [ 1674 { 1675 "switching-capability": "switching-l2sc", 1676 "encoding": "lsp-encoding-ethernet" 1677 } 1678 ] 1679 } 1680 }, 1681 { 1682 "tp-id": "LTP-2", 1683 "te-tp-id": 10002 1684 "te": { 1685 "interface-switching-capability": [ 1686 { 1687 "switching-capability": "switching-l2sc", 1688 "encoding": "lsp-encoding-ethernet" 1689 } 1690 ] 1691 } 1692 }, 1693 { 1694 "tp-id": "LTP-3", 1695 "te-tp-id": 10003 1696 "te": { 1697 "interface-switching-capability": [ 1698 { 1699 "switching-capability": "switching-l2sc", 1700 "encoding": "lsp-encoding-ethernet" 1701 } 1702 ] 1703 } 1704 }, 1705 { 1706 "tp-id": "LTP-4", 1707 "te-tp-id": 10004 1708 "te": { 1709 "interface-switching-capability": [ 1710 { 1711 "switching-capability": "switching-l2sc", 1712 "encoding": "lsp-encoding-ethernet" 1713 } 1714 ] 1715 } 1716 } 1717 ] 1718 } 1719 ] 1720 } 1722 ] 1723 } 1724 } 1726 Appendix C. Use Cases for SF Aware Topology Models 1728 C.1. Exporting SF/NF Information to Network Clients and Other Network 1729 SDN Controllers 1731 In the context of Service Function Chain (SFC) orchestration one 1732 existing problem is that there is no way to formally describe a 1733 Service or Network Function in a standard way (recognizable/ 1734 understood by a third party) as a resource of a network topology 1735 node. 1737 One implication of this is that there is no way for the orchestrator 1738 to give a network client even a ball-park idea as to which network's 1739 SFs/NFs are available for the client's use/control and where they are 1740 located in the network even in terms of abstract topologies/virtual 1741 networks configured and managed specifically for the client. 1742 Consequently, the client has no say on how the SFCs provided for the 1743 client by the network should be set up and managed (which SFs are to 1744 be used and how they should be chained together, optimized, 1745 manipulated, protected, etc.). 1747 Likewise, there is no way for the orchestrator to export SF/NF 1748 information to other network controllers. The SFC orchestrator may 1749 serve, for example, a higher level controller (such as Network 1750 Slicing Orchestrator), with the latter wanting at least some level of 1751 control as to which SFs/NFs it wants on its SFCs and how the Service 1752 Function Paths (SFPs) are to be routed and provisioned, especially, 1753 if it uses services of more than one SFC orchestrator. 1755 The issue of exporting of SF/NF information could be addressed by 1756 defining a model, in which formally described/recognizable SF/NF 1757 instances are presented as topological elements, for example, hosted 1758 by TE, L3 or L2 topology nodes (see Figure 1). The model could 1759 describe whether, how and at what costs the SFs/NFs hosted by a given 1760 node could be chained together, how these intra-node SFCs could be 1761 connected to the node's Service Function Forwarders (SFFs, entities 1762 dealing with SFC NSHs and metadata), and how the SFFs could be 1763 connected to the node's Tunnel and Link Termination Points (TTPs and 1764 LTPs) to chain the intra-node SFCs across the network topology. 1766 The figure is available in the PDF format. 1768 Figure 1: SF/NF aware TE topology 1770 C.2. Flat End-to-end SFCs Managed on Multi-domain Networks 1772 SFCs may span multiple administrative domains, each of which 1773 controlled by a separate SFC controller. The usual solution for such 1774 a scenario is the Hierarchical SFCs (H-SFCs) [RFC8459], in which the 1775 higher level orchestrator controls only SFs located on domain border 1776 nodes. Said higher level SFs are chained together into higher level 1777 SFCs via lower level (intra-domain) SFCs provisioned and controlled 1778 independently by respective domain controllers. The decision as to 1779 which higher level SFCs are connected to which lower level SFCs is 1780 driven by packet re-classification every time the packet enters a 1781 given domain. Said packet re-classification is a very time-consuming 1782 operation. Furthermore, the independent nature of higher and lower 1783 level SFC control is prone to configuration errors, which may lead to 1784 long lasting loops and congestions. It is highly desirable to be 1785 able to set up and manage SFCs spanning multiple domains in a flat 1786 way as far as the data plane is concerned (i.e. with a single packet 1787 classification at the ingress into the multi-domain network but 1788 without re-classifications on domain ingress nodes). 1790 One way to achieve this is to have the domain controllers expose SF/ 1791 NF- aware topologies, and have the higher level orchestrator operate 1792 on the network-wide topology, the product of merging of the 1793 topologies catered by the domain controllers. This is similar in 1794 spirit to setting up, coordinating and managing the transport 1795 connectivity (TE tunnels) on a multi-domain multi-vendor transport 1796 network. 1798 C.3. Managing SFCs with TE Constraints 1800 Some SFCs require per SFC link/element and end-to-end TE constrains 1801 (bandwidth, delay/jitter, fate sharing/diversity. etc.). Said 1802 constraints could be ensured via carrying SFPs inside overlays that 1803 are traffic engineered with the constrains in mind. A good analogy 1804 would be orchestrating delay constrained L3 VPNs. One way to support 1805 such L3 VPNs is to carry MPLS LSPs interconnecting per-VPN VRFs 1806 inside delay constrained TE tunnels interconnecting the PEs hosting 1807 the VRFs. 1809 The figure is available in the PDF format. 1811 Figure 2: L3 VPN with delay constraints 1813 Planning, computing and provisioning of TE overlays to constrain 1814 arbitrary SFCs, especially those that span multiple administrative 1815 domains with each domain controlled by a separate controller, is a 1816 very difficult challenge. Currently it is addressed by pre- 1817 provisioning on the network of multiple TE tunnels with various TE 1818 characteristics, and "nailing down" SFs/NFs to "strategic" locations 1819 (e.g. nodes terminating many of such tunnels) in a hope that an 1820 adequate set of tunnels could be found to carry the SFP of a given 1821 TE-constrained SFC. Such an approach is especially awkward in the 1822 case when some or all of the SFs/NFs are VNFs (i.e. could be 1823 instantiated at multiple network locations). 1825 SF/NF-aware TE topology model in combination with TE tunnel model 1826 will allow for the network orchestrator (or a client controller) to 1827 compute, set up and manipulate the TE overlays in the form of TE 1828 tunnel chains (see Figure 3). 1830 Said chains could be duel-optimized compromising on optimal SF/NF 1831 locations with optimal TE tunnels interconnecting them. The TE 1832 tunnel chains (carrying multiple similarly constrained SFPs) could be 1833 adequately constrained both at individual TE tunnel level and at the 1834 chain end-to-end level. 1836 The figure is available in the PDF format. 1838 Figure 3: SFC with TE constraints 1840 C.4. SFC Protection and Load Balancing 1842 Currently the combination of TE topology & tunnel models offers to a 1843 network controller various capabilities to recover an individual TE 1844 tunnel from network failures occurred on one or more network links or 1845 transit nodes on the TE paths taken by the TE tunnel's connection(s). 1846 However, there is no simple way to recover a TE tunnel from a failure 1847 affecting its source or destination node. SF/NF-aware TE topology 1848 model can decouple the association of a given SF/NF with its location 1849 on the network topology by presenting multiple, identifiable as 1850 mutually substitutable SFs/NFs hosted by different TE topology nodes. 1851 So, for example, if it is detected that a given TE tunnel destination 1852 node is malfunctioning or has gone out of service, the TE tunnel 1853 could be re-routed to terminate on a different node hosting 1854 functionally the same SFs/NFs as ones hosted by the failed node (see 1855 Figures 6). 1857 This is in line with the ACTN edge migration and function mobility 1858 concepts [RFC8453]. It is important to note that the described 1859 strategy works much better for the stateless SFs/NFs. This is 1860 because getting the alternative stateful SFs/NFs into the same 1861 respective states as the current (i.e. active, affected by failure) 1862 are is a very difficult challenge. 1864 The figure is available in the PDF format. 1866 Figure 4: SFC recovery: SF2 on node NE1 fails 1868 At the SFC level the SF/NF-aware TE topology model can offer SFC 1869 dynamic restoration capabilities against failed/malfunctioning SFs/ 1870 NFs by identifying and provisioning detours to a TE tunnel chain, so 1871 that it starts carrying the SFC's SFPs towards healthy SFs/NFs that 1872 are functionally the same as the failed ones. Furthermore, multiple 1873 parallel TE tunnel chains could be pre-provisioned for the purpose of 1874 SFC load balancing and end-to-end protection. In the latter case 1875 said parallel TE tunnel chains could be placed to be sufficiently 1876 disjoint from each other. 1878 The figure is available in the PDF format. 1880 Figure 5: SFC recovery: SFC SF1-SF2-SF6 is recovered after SF2 on 1881 node N1 has failed 1883 The figure is available in the PDF format. 1885 Figure 6: SFC recovery: SFC SF1-SF2-SF6 is recovered after node N1 1886 has failed 1888 C.5. Network Clock Synchronization 1890 Many current and future network applications (including 5g and IoT 1891 applications) require very accurate time services (PTP level, ns 1892 resolution). One way to implement the adequate network clock 1893 synchronization for such services is via describing network clocks as 1894 NFs on an NF-aware TE topology optimized to have best possible delay 1895 variation characteristics. Because such a topology will contain 1896 delay/delay variation metrics of topology links and node cross- 1897 connects, as well as costs in terms of delay/delay variation of 1898 connecting clocks to hosting them node link and tunnel termination 1899 points, it will be possible to dynamically select and provision bi- 1900 directional time-constrained deterministic paths or trees connecting 1901 clocks (e.g. grand master and boundary clocks) for the purpose of 1902 exchange of clock synchronization information. Note that network 1903 clock aware TE topologies separately provided by domain controllers 1904 will enable multi-domain network orchestrator to set up and 1905 manipulate the clock synchronization paths/trees spanning multiple 1906 network domains. 1908 C.6. Client - Provider Network Slicing Interface 1910 3GPP defines network slice as "a set of network functions and the 1911 resources for these network functions which are arranged and 1912 configured, forming a complete logical network to meet certain 1913 network characteristics" [I-D.defoy-netslices-3gpp-network-slicing] 1914 [_3GPP.28.801]. Network slice could be also defined as a logical 1915 partition of a provider's network that is owned and managed by a 1916 tenant. SF/NF-aware TE topology model has a potential to support a 1917 very important interface between network slicing clients and 1918 providers because, on the one hand, the model can describe 1919 holistically and hierarchically the client's requirements and 1920 preferences with respect to a network slice functional, topological 1921 and traffic engineering aspects, as well as of the degree of resource 1922 separation/ sharing between the slices, thus allowing for the client 1923 (up to agreed upon extent) to dynamically (re-)configure the slice or 1924 (re-)schedule said (re-)configurations in time, while, on the other 1925 hand, allowing for the provider to convey to the client the slice's 1926 operational state information and telemetry the client has expressed 1927 interest in. 1929 C.7. Dynamic Assignment of Regenerators for L0 Services 1931 On large optical networks, some of provided to their clients L0 1932 services could not be provisioned as single OCh trails, rather, as 1933 chains of such trails interconnected via regenerators, such as 3R 1934 regenerators. Current practice of the provisioning of such services 1935 requires configuration of explicit paths (EROs) describing identity 1936 and location of regenerators to be used. A solution is highly 1937 desirable that could: 1939 o Identify such services based, for example, on optical impairment 1940 computations; 1942 o Assign adequate for the services regenerators dynamically out of 1943 the regenerators that are grouped together in pools and 1944 strategically scattered over the network topology nodes; 1946 o Compute and provision supporting the services chains of optical 1947 trails interconnected via so selected regenerators, optimizing the 1948 chains to use minimal number of regenerators, their optimal 1949 locations, as well as optimality of optical paths interconnecting 1950 them; 1952 o Ensure recovery of such chains from any failures that could happen 1953 on links, nodes or regenerators along the chain path. 1955 NF-aware TE topology model (in this case L1 NF-aware L0 topology 1956 model) is just the model that could provide a network controller (or 1957 even a client controller operating on abstract NF-aware topologies 1958 provided by the network) to realize described above computations and 1959 orchestrate the service provisioning and network failure recovery 1960 operations (see Figure 7). 1962 The figure is available in the PDF format. 1964 Figure 7: Optical tunnel as TE-constrained SFC of 3R regenerators. 1965 Red trail (not regenerated) is not optically reachable, but blue 1966 trail (twice regenerated) is 1968 C.8. Dynamic Assignment of OAM Functions for L1 Services 1970 OAM functionality is normally managed by configuring and manipulating 1971 TCM/MEP functions on network ports terminating connections or their 1972 segments over which OAM operations, such as performance monitoring, 1973 are required to be performed. In some layer networks (e.g. 1974 Ethernet) said TCMs/MEPs could be configured on any network ports. 1975 In others (e.g. OTN/ODUk) the TCMs/MEPs could be configured on some 1976 (but not all network ports) due to the fact that the OAM 1977 functionality (i.e. recognizing and processing of OAM messages, 1978 supporting OAM protocols and FSMs) requires in these layer networks 1979 certain support in the data plane, which is not available on all 1980 network nodes. This makes TCMs/MEPs good candidates to be modeled as 1981 NFs. This also makes TCM/MEP aware topology model a good basis for 1982 placing dynamically an ODUk connection to pass through optimal OAM 1983 locations without mandating the client to specify said locations 1984 explicitly. 1986 The figure is available in the PDF format. 1988 Figure 8: Compute/storage resource aware topology 1990 C.9. SFC Abstraction and Scaling 1992 SF/NF-aware topology may contain information on native SFs/NFs (i.e. 1993 SFs/NFs as known to the provider itself) and/or abstract SFs/NFs 1994 (i.e. logical/macro SFs/NFs representing one or more SFCs each made 1995 of native and/or lower level abstract SFs/NFs). As in the case of 1996 abstracting topology nodes, abstracting SFs/NFs is hierarchical in 1997 nature - the higher level of SF/NF-aware topology, the "larger" 1998 abstract SFs/NFs are, i.e. the larger data plane SFCs they represent. 1999 This allows for managing large scale networks with great number of 2000 SFs/NFs (such as Data Center interconnects) in a hierarchical, highly 2001 scalable manner resulting in control of very large number of flat in 2002 the data plane SFCs that span multiple domains. 2004 C.10. Dynamic Compute/VM/Storage Resource Assignment 2006 In a distributed data center network, virtual machines for compute 2007 resources may need to be dynamically re-allocated due to various 2008 reasons such as DCI network failure, compute resource load balancing, 2009 etc. In many cases, the DCI connectivity for the source and the 2010 destination is not predetermined. There may be a pool of sources and 2011 a pool of destination data centers associated with re-allocation of 2012 compute/VM/storage resources. There is no good mechanism to date to 2013 capture this dynamicity nature of compute/VM/storage resource 2014 reallocation. Generic Compute/VM/Storage resources can be described 2015 and announced as a SF, where a DC hosting these resources can be 2016 modeled as an abstract node. Topology interconnecting these abstract 2017 nodes (DCs) in general is of multi-domain nature. Thus, SF-aware 2018 topology model can facilitate a joint optimization of TE network 2019 resources and Compute/VM/Storage resources and solve Compute/VM/ 2020 Storage mobility problem within and between DCs (see Figure 8). 2022 C.11. Application-aware Resource Operations and Management 2024 Application stratum is the functional grouping which encompasses 2025 application resources and the control and management of these 2026 resources. These application resources are used along with network 2027 services to provide an application service to clients/end-users. 2028 Application resources are non-network resources critical to achieving 2029 the application service functionality. Examples of application 2030 resources include: caches, mirrors, application specific servers, 2031 content, large data sets, and computing power. Application service 2032 is a networked application offered to a variety of clients (e.g., 2033 server backup, VM migration, video cache, virtual network on-demand, 2034 5G network slicing, etc.). The application servers that host these 2035 application resources can be modeled as an abstract node. There may 2036 be a variety of server types depending on the resources they host. 2037 Figure 9 shows one example application aware topology for video cache 2038 server distribution. 2040 The figure is available in the PDF format. 2042 Figure 9: Application aware topology 2044 C.12. Interconnection between Service Functions/Termination Points in 2045 uCPE 2047 Universal Customer Premises Equipment (uCPE) enables Virtual Network 2048 Functions (VNFs) at the client site. uCPE is based on the Network 2049 Function Virtualization Infrastructure (NFVI) - generally Linux 2050 distribution with integrated software that offers: 2052 o Virtual Switch functionality 2054 o Full virtualization/containerization solution 2056 o Data path acceleration tool-kits 2058 o Management layer 2060 The sf-aware-topo-model placed in the controller controls via the 2061 management layer of uCPE the interconnection between: 2063 o virtual ports of VNFs 2065 o virtual ports of Virtual Switch abstraction elements 2067 o physical ports of uCPE 2069 Figure 10 shows an example application aware topology for 2070 interconnection between Logical Network Elements [RFC8530], Network 2071 Instances [RFC8529], uCPE node Termination Points [RFC8345]. In 2072 Figure 10 the following elements are presented: 2074 o 3 Logical Network Elements (vCPEL3_WAN1,vCPEL3_WAN2,vSD-WAN) 2076 o 4 Network Instances (vCPEL2) 2078 o 4 Termination Points (Physical Ports) 2080 There are two types of access provided to the client. 2082 The 1st access "Internet" topology part: 1st uCPE Termination Point 2083 "WAN1_port_internet" -- NI (vCPEL2) -- LNE (vCPEL3_telco_internet) -- 2084 NI (vCPEL2) -- vSD-WAN_port_internet. 2086 The 2nd access "MPLS" topology part: 2nd Termination Point 2087 "WAN2_port_mpls" -- NI (vCPEL2) -- LNE (vCPEL3_telco_mpls) -- NI 2088 (vCPEL2) -- vSD-WAN_port_mpls. 2090 Finally SD-WAN balances the traffic via two WAN ports (Termination 2091 Points) of uCPE and shares the connection to LAN ports (Termination 2092 Points). 2094 The figure is available in the PDF format. 2096 Figure 10: uCPE Service Functions topology 2098 An example of an instance data tree in the XML format is presented in 2099 Figure 12, following the uCPE Service Functions topology presented in 2100 Figure 11. 2102 For this example, the interconnection goes as follows: Network-facing 2103 Provider Edge (N-PE) router -- User-facing Provider Edge (U-PE) 2104 router -- uCPE ( Termination Point WAN -- NI (vCPEL2) -- LNE (vCPEL3) 2105 ) 2107 In uCPE, Termination Point (WAN) has id 1. On the NNI 2108 (connectionpoint_id == 10) port of NI the trunk mode is configured. 2109 On UNI ports of NI (cp_id == 13) access mode is configured. Port 2110 with cp_id == 13 is connected to LNE cp_id = 1. 2112 The figure is available in the PDF format. 2114 Figure 11: uCPE Service Functions topology (simple) 2116 2117 2118 2119 network1 2120 2121 2123 2125 2126 2127 2128 uCPE1 2129 2132 1 2133 2136 2137 full 2138 2139 1500 2140 dpdk 2141 2143 2144 2147 2 2148 2149 2152 3 2153 2154 0.0.0.0 2157 2158 2159 2162 2163 2164 1 2165 2166 CPEL3 2167 1 2169 2170 2171 CPEL2 2172 13 2174 2175 true 2176 l10 2177 2178 2179 2180 2181 2 2182 2183 1 2184 2185 2186 CPEL2 2187 10 2189 2190 l11 2194 2195 2196 2197 2198 2199 ucpe 2203 2204 2205 N-PE 2206 2209 1 2210 2211 2214 2 2215 2216 2219 3 2220 2221 2224 4 2225 2226 2227 2228 U-PE 2229 2232 1 2233 2234 2237 2 2238 2239 2242 3 2243 2244 2247 4 2248 2249 2250 2252 1 2253 2254 N-PE 2255 2 2256 2257 2258 U-PE 2259 1 2260 2261 2262 2264 2 2265 2266 U-PE 2267 2 2268 2269 2270 uCPE1 2271 1 2272 2273 2274 2275 2276 2279 2280 CPEL3 2281 2284 2285 CPEL3 2286 small 2288 2289 uCPE1 2290 2291 2292 2293 2295 2296 CPEL2 2297 2300 2301 10 2302 2303 X 2304 Y 2305 Z 2306 2307 2308 2309 11 2310 2311 X 2312 2313 2314 2315 12 2316 2317 Z 2318 2319 2320 2321 13 2322 2323 Y 2324 2325 2326 wan 2327 uCPE1 2328 2329 2330 2331 2333 Figure 12: uCPE Service Funcitons topology YIN example 2335 Acknowledgements 2337 The authors would like to thank Maarten Vissers, Joel Halpern, and 2338 Greg Mirsky for their helpful comments and valuable contributions. 2340 Authors' Addresses 2342 Igor Bryskin 2343 Individual 2345 EMail: i_bryskin@yahoo.com 2347 Xufeng Liu 2348 IBM Corporation 2350 EMail: xufeng.liu.ietf@gmail.com 2352 Young Lee 2353 Samsung Electronics 2355 EMail: younglee.tx@gmail.com 2357 Jim Guichard 2358 Huawei Technologies 2360 EMail: james.n.guichard@huawei.com 2362 Luis Miguel Contreras Murillo 2363 Telefonica 2365 EMail: luismiguel.contrerasmurillo@telefonica.com 2367 Daniele Ceccarelli 2368 Ericsson 2370 EMail: daniele.ceccarelli@ericsson.com 2372 Jeff Tantsura 2373 Apstra Networks 2375 EMail: jefftant.ietf@gmail.com 2376 Dmytro Shytyi 2377 SFR 2378 Paris 2379 France 2381 EMail: ietf.dmytro@shytyi.net