idnits 2.17.00 (12 Aug 2021) /tmp/idnits52064/draft-ietf-teas-sf-aware-topo-model-08.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 (July 9, 2021) is 316 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 (-29) exists of draft-ietf-teas-yang-te-26 == Outdated reference: A later version (-14) exists of draft-ietf-teas-actn-vn-yang-11 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: January 10, 2022 Volta Networks 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 July 9, 2021 20 SF Aware TE Topology YANG Model 21 draft-ietf-teas-sf-aware-topo-model-08 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 January 10, 2022. 45 Copyright Notice 47 Copyright (c) 2021 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 . . . . . . . . . . . . . . . . . . . . . . . . . 21 72 7.1. Normative References . . . . . . . . . . . . . . . . . . 21 73 7.2. Informative References . . . . . . . . . . . . . . . . . 24 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 . . . . . 33 80 Appendix C. Use Cases for SF Aware Topology Models . . . . . . . 37 81 C.1. Exporting SF/NF Information to Network Clients and Other 82 Network SDN Controllers . . . . . . . . . . . . . . . . . 37 83 C.2. Flat End-to-end SFCs Managed on Multi-domain Networks . 38 84 C.3. Managing SFCs with TE Constraints . . . . . . . . . . . . 39 85 C.4. SFC Protection and Load Balancing . . . . . . . . . . . . 40 86 C.5. Network Clock Synchronization . . . . . . . . . . . . . . 43 87 C.6. Client - Provider Network Slicing Interface . . . . . . . 43 88 C.7. Dynamic Assignment of Regenerators for L0 Services . . . 43 89 C.8. Dynamic Assignment of OAM Functions for L1 Services . . . 45 90 C.9. SFC Abstraction and Scaling . . . . . . . . . . . . . . . 46 91 C.10. Dynamic Compute/VM/Storage Resource Assignment . . . . . 46 92 C.11. Application-aware Resource Operations and Management . . 47 93 C.12. Interconnection between Service Functions/Termination 94 Points in uCPE . . . . . . . . . . . . . . . . . . . . . 48 95 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 55 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 55 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? string 327 | | +--rw sf-connection-point-id? string 328 | +--rw to 329 | | +--rw service-function-id? string 330 | | +--rw sf-connection-point-id? string 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? string 341 | +--rw sf-connection-point-id? string 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? string 352 | | +--ro sf-connection-point-id? string 353 | +--ro to 354 | | +--ro service-function-id? string 355 | | +--ro sf-connection-point-id? string 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 to 364 | +--ro service-function-id? string 365 | +--ro sf-connection-point-id? string 366 +--ro enabled? boolean 367 +--ro direction? connectivity-direction 368 augment /nw:networks/nw:network/nw:node/tet:te 369 /tet:tunnel-termination-point: 370 +--rw service-function 371 +--rw tunnel-terminations 372 +--rw tunnel-termination* [id] 373 +--rw id uint32 374 +--rw service-function-id? string 375 +--rw sf-connection-point-id? string 376 +--rw enabled? boolean 377 +--rw direction? connectivity-direction 378 augment /nw:networks/nw:network/nw:node: 380 +--rw service-functions 381 +--rw service-function* [id] 382 +--rw id string 383 +--rw type? identityref 384 +--rw te-metric? te-types:te-metric 385 +--rw priority? uint8 386 +--rw connection-points 387 +--rw connection-point* [id] 388 +--rw id string 389 +--rw type? identityref 391 4. SF Aware TE Topology YANG Module 393 This module references [RFC7665], [RFC8345], [RFC8776], [RFC8795], 394 [ETSI-NFV-YANG], and [ETSI-NFV-PACKAGE]. 396 file "ietf-te-topology-sf@2021-06-28.yang" 397 module ietf-te-topology-sf { 398 yang-version 1.1; 399 namespace "urn:ietf:params:xml:ns:yang:ietf-te-topology-sf"; 401 prefix "tet-sf"; 403 import ietf-network { 404 prefix "nw"; 405 reference 406 "RFC 8345: A YANG Data Model for Network Topologies"; 407 } 409 import ietf-network-topology { 410 prefix "nt"; 411 reference 412 "RFC 8345: A YANG Data Model for Network Topologies"; 413 } 415 import ietf-te-topology { 416 prefix "tet"; 417 reference 418 "RFC 8795: YANG Data Model for Traffic Engineering (TE) 419 Topologies"; 420 } 422 import ietf-te-types { 423 prefix "te-types"; 424 reference 425 "RFC8776: Common YANG Data Types for Traffic Engineering."; 426 } 428 organization 429 "Traffic Engineering Architecture and Signaling (TEAS) 430 Working Group"; 432 contact 433 "WG Web: 434 WG List: 436 Editors: Igor Bryskin 437 439 Xufeng Liu 440 "; 442 description 443 "Network service and function aware aware TE topology model. 445 Copyright (c) 2021 IETF Trust and the persons identified as 446 authors of the code. All rights reserved. 448 Redistribution and use in source and binary forms, with or 449 without modification, is permitted pursuant to, and subject to 450 the license terms contained in, the Simplified BSD License set 451 forth in Section 4.c of the IETF Trust's Legal Provisions 452 Relating to IETF Documents 453 (http://trustee.ietf.org/license-info). 455 This version of this YANG module is part of RFC XXXX; see the 456 RFC itself for full legal notices."; 458 revision 2021-06-28 { 459 description "Initial revision"; 460 reference "RFC XXXX: SF Aware TE Topology YANG Model"; 461 } 463 /* 464 * Identities 465 */ 466 identity sf-type { 467 description 468 "Base identity from which all service function types are 469 derived. The definitions of the derived identities are 470 left to the implementation. An example can be 'firewall'."; 471 } 472 identity cp-type { 473 description 474 "Base identity from which all connection point types are 475 derived. The definitions of the derived identities are 476 left to the implementation. Examples can be 'ethernet', 477 'mpls', or 'ipv4'."; 478 } 480 /* 481 * Typedefs 482 */ 483 typedef connectivity-direction { 484 type enumeration { 485 enum "to" { 486 description 487 "The direction is uni-directional, towards the 'to' 488 entity direction."; 489 } 490 enum "from" { 491 description 492 "The direction is uni-directional, from the 'to' 493 entity direction."; 494 } 495 enum "bidir" { 496 description 497 "The direction is bi-directional."; 498 } 499 } 500 description 501 "A type used to indicates whether a connectivity is 502 uni-directional, or bi-directional. If the relation is 503 uni-directional, the value of this type indicates the 504 direction."; 505 } // connectivity-direction 507 /* 508 * Groupings 509 */ 510 grouping service-function-node-augmentation { 511 description 512 "Augmenting a TE node to be network service and function 513 aware."; 514 container service-function { 515 description 516 "Containing attributes related to network services and 517 network functions"; 518 container connectivity-matrices { 519 description 520 "Connectivity relations between network services/functions 521 on a TE node, which can be either abstract or physical."; 522 reference 523 "ETSI-NFV-YANG: ETSI GS NFV-SOL 006: 524 Network Functions Virtualisation (NFV) Release 3; 525 Protocols and Data Models; 526 NFV descriptors based on YANG specification. 527 RFC7665: Service Function Chaining (SFC) Architecture."; 528 list connectivity-matrix { 529 key "id"; 530 description 531 "Represents the connectivity relations between network 532 services/functions on a TE node."; 533 leaf id { 534 type uint32; 535 description "Identifies the connectivity-matrix entry."; 536 } 538 container from { 539 description 540 "Reference to the source network service or 541 network function."; 542 leaf service-function-id { 543 type string; 544 description 545 "Reference to a network service or a network 546 function."; 547 } 548 leaf sf-connection-point-id { 549 type string; 550 description 551 "Reference to a connection point on a network 552 service or a network function."; 553 } 554 } // from 555 container to { 556 description 557 "Reference to the destination network service or 558 network function."; 559 leaf service-function-id { 560 type string; 561 description 562 "Reference to a network service or a network 563 function."; 564 } 565 leaf sf-connection-point-id { 566 type string; 567 description 568 "Reference to a connection point on a network 569 service or a network function."; 570 } 571 } // to 572 leaf enabled { 573 type boolean; 574 description 575 "'true' if this connectivity entry is enabled."; 576 } 577 leaf direction { 578 type connectivity-direction; 579 description 580 "Indicates whether this connectivity is 581 uni-directional, or bi-directional. If the 582 relation is uni-directional, the value of 583 this leaf indicates the direction."; 584 } 585 leaf virtual-link-id { 586 type string; 587 description 588 "Reference to a virtual link that models this 589 conectivity relation in the network function 590 model."; 591 } 592 } // connectivity-matrix 593 } // connectivity-matrices 595 container link-terminations { 596 description 597 "Connectivity relations between network services/functions 598 and link termination points on a TE node, which can be 599 either abstract or physical."; 600 reference 601 "ETSI-NFV-YANG: ETSI GS NFV-SOL 006: 602 Network Functions Virtualisation (NFV) Release 3; 603 Protocols and Data Models; 604 NFV descriptors based on YANG specification. 605 RFC7665: Service Function Chaining (SFC) Architecture."; 606 list link-termination { 607 key "id"; 608 description 609 "Each entry of the list represents the connectivity 610 relation between a network service/function and 611 a link termination point on a TE node."; 612 leaf id { 613 type uint32; 614 description "Identifies the termination entry."; 615 } 616 container from { 617 description 618 "Reference to the link termination point."; 619 } // from 620 container to { 621 description 622 "Reference to the network service or network 623 function."; 624 leaf service-function-id { 625 type string; 626 description 627 "Reference to a network service or a network 628 function."; 629 } 630 leaf sf-connection-point-id { 631 type string; 632 description 633 "Reference to a connection point on a network 634 service or a network function."; 635 } 636 } // to 637 leaf enabled { 638 type boolean; 639 description 640 "'true' if this connectivity entry is enabled."; 641 } 642 leaf direction { 643 type connectivity-direction; 644 description 645 "Indicates whether this connectivity is 646 uni-directional, or bi-directional. If the 647 relation is uni-directional, the value of 648 this leaf indicates the direction."; 649 } 650 } // link-termination 651 } 652 } 653 } // service-function-node-augmentation 655 grouping service-function-ttp-augmentation { 656 description 657 "Augmenting a tunnel termination point to be network service 658 aware."; 659 container service-function { 660 description 661 "Containing attributes related to network services and 662 network functions"; 663 container tunnel-terminations { 664 description 665 "Connectivity relations between network services/functions 666 and tunnel termination points on a TE node, which can be 667 either abstract or physical."; 668 reference 669 "ETSI-NFV-YANG: ETSI GS NFV-SOL 006: 670 Network Functions Virtualisation (NFV) Release 3; 671 Protocols and Data Models; 672 NFV descriptors based on YANG specification. 673 RFC7665: Service Function Chaining (SFC) Architecture."; 674 list tunnel-termination { 675 key "id"; 676 description 677 "Each entry of the list represents the connectivity 678 relation between a network service/function and 679 a tunnel termination point on a TE node."; 680 leaf id { 681 type uint32; 682 description "Identifies the termination entry."; 683 } 685 leaf service-function-id { 686 type string; 687 description 688 "Reference to a network service or a network 689 function."; 690 } 691 leaf sf-connection-point-id { 692 type string; 693 description 694 "Reference to a connection point on a network 695 service or a network function."; 696 } 697 leaf enabled { 698 type boolean; 699 description 700 "'true' if this connectivity entry is enabled."; 701 } 702 leaf direction { 703 type connectivity-direction; 704 description 705 "Indicates whether this connectivity is 706 uni-directional, or bi-directional. If the 707 relation is uni-directional, the value of 708 this leaf indicates the direction."; 709 } 710 } // link-termination 711 } 713 } 714 } // service-function-ttp-augmentation 716 grouping sf-topology-type { 717 description 718 "Identifies the SF aware TE topology type."; 719 container sf { 720 presence "Indidates that the TE topology is SF aware."; 721 description 722 "Its presence identifies that the TE topology is SF aware."; 723 } 724 } // sf-topology-type 726 /* 727 * Augmentations 728 */ 729 /* Augmentations to network-types/te-topology */ 730 augment "/nw:networks/nw:network/nw:network-types/" 731 + "tet:te-topology" { 732 description 733 "Defines the SF aware TE topology type."; 734 uses sf-topology-type; 735 } 737 /* Augmentations to te-node-attributes */ 738 augment "/nw:networks/nw:network/nw:node/tet:te/" 739 + "tet:te-node-attributes" { 740 description 741 "Parameters for SF aware TE topology."; 742 uses service-function-node-augmentation; 743 } 745 augment "/nw:networks/nw:network/nw:node/tet:te/" 746 + "tet:information-source-entry" { 747 description 748 "Parameters for SF aware TE topology."; 749 uses service-function-node-augmentation; 750 } 752 /* Augmentations to tunnel-termination-point */ 753 augment "/nw:networks/nw:network/nw:node/tet:te/" 754 + "tet:tunnel-termination-point" { 755 description 756 "Parameters for SF aware TE topology."; 757 uses service-function-ttp-augmentation; 758 } 760 /* Augmentations to connectivity-matrix */ 761 augment "/nw:networks/nw:network/nw:node/tet:te/" 762 + "tet:te-node-attributes/tet-sf:service-function/" 763 + "tet-sf:link-terminations/tet-sf:link-termination/" 764 + "tet-sf:from" { 765 description 766 "Add reference to the link termination point. 767 This portion cannot be shared with the state module."; 768 leaf tp-ref { 769 type leafref { 770 path "../../../../../../../nt:termination-point/" 771 + "nt:tp-id"; 772 } 773 description 774 "Reference to the link termination point."; 775 } 776 } 778 /* Augmentations to node */ 779 augment "/nw:networks/nw:network/nw:node" { 780 description 781 "Available service functions on the node."; 782 container service-functions { 783 description 784 "Containing the service functions that are available on this 785 node. Any of these service functions can be referenced 786 and enabled in te-node-attributes"; 787 list service-function { 788 key "id"; 789 description 790 "A list of service functions on this node."; 791 leaf id { 792 type string; 793 description "Identifies the service function."; 794 } 795 leaf type { 796 type identityref { 797 base "sf-type"; 798 } 799 description 800 "The service function type, such as 'firewall'. 801 The parameters of each service function type are not 802 specified in this model, and may be speficied by other 803 models such as the one defined by ETSI GS NFV-IFA 011."; 804 reference 805 "ETSI-NFV-PACKAGE: ETSI GS NFV-IFA 011: 806 Network Functions Virtualisation (NFV) Release 4; 807 Management and Orchestration; 808 VNF Descriptor and Packaging Specification."; 810 } 811 leaf te-metric { 812 type te-types:te-metric; 813 description 814 "Specifies the TE (Traffic Engineering) metric for this 815 service function. The server uses this value as a 816 preference of selecting the given service function 817 instance."; 818 } 819 leaf priority { 820 type uint8; 821 default 0; 822 description 823 "Specifies the priority level at which the service 824 function instance is available. 825 A lower number indicates a higher priority. The highest 826 priority is 0."; 827 } 828 container connection-points { 829 description 830 "Containing the connection points that are available on 831 this service function. 832 node. Any of these connection points can be referenced 833 and enabled in te-node-attributes"; 834 list connection-point { 835 key "id"; 836 description 837 "A list of connection points on this node."; 838 leaf id { 839 type string; 840 description "Identifies the connection point."; 841 } 842 leaf type { 843 type identityref { 844 base "cp-type"; 845 } 846 description 847 "The connection point type, such as 'ethernet', 848 'mpls', or 'ipv4'. 849 The parameters of each service function type are not 850 specified in this model, and may be speficied by 851 other models such as the one defined by ETSI GS 852 NFV-IFA 011."; 853 reference 854 "ETSI-NFV-PACKAGE: ETSI GS NFV-IFA 011: 855 Network Functions Virtualisation (NFV) Release 4; 856 Management and Orchestration; 857 VNF Descriptor and Packaging Specification."; 859 } 860 } 861 } 862 } 863 } 864 } 865 } 866 868 5. IANA Considerations 870 This document registers the following namespace URIs in the IETF XML 871 registry [RFC3688]: 873 -------------------------------------------------------------------- 874 URI: urn:ietf:params:xml:ns:yang:ietf-te-topology-sf 875 Registrant Contact: The IESG. 876 XML: N/A, the requested URI is an XML namespace. 877 -------------------------------------------------------------------- 879 -------------------------------------------------------------------- 880 URI: urn:ietf:params:xml:ns:yang:ietf-te-topology-sf-state 881 Registrant Contact: The IESG. 882 XML: N/A, the requested URI is an XML namespace. 883 -------------------------------------------------------------------- 885 This document registers the following YANG modules in the YANG Module 886 Names registry [RFC6020]: 888 -------------------------------------------------------------------- 889 name: ietf-te-topology-sf 890 namespace: urn:ietf:params:xml:ns:yang:ietf-te-topology-packet 891 prefix: tet-sf 892 reference: RFC XXXX 893 -------------------------------------------------------------------- 895 -------------------------------------------------------------------- 896 name: ietf-te-topology-sf-state 897 namespace: urn:ietf:params:xml:ns:yang:ietf-te-topology-packet-state 898 prefix: tet-sf-s 899 reference: RFC XXXX 900 -------------------------------------------------------------------- 902 6. Security Considerations 904 The YANG module specified in this document defines a schema for data 905 that is designed to be accessed via network management protocols such 906 as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer 907 is the secure transport layer, and the mandatory-to-implement secure 908 transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer 909 is HTTPS, and the mandatory-to-implement secure transport is TLS 910 [RFC8446]. 912 The Network Configuration Access Control Model (NACM) [RFC8341] 913 provides the means to restrict access for particular NETCONF or 914 RESTCONF users to a preconfigured subset of all available NETCONF or 915 RESTCONF protocol operations and content. 917 There are a number of data nodes defined in this YANG module that are 918 writable/creatable/deletable (i.e., config true, which is the 919 default). These data nodes may be considered sensitive or vulnerable 920 in some network environments. Write operations (e.g., edit-config) 921 to these data nodes without proper protection can have a negative 922 effect on network operations. These are the subtrees and data nodes 923 and their sensitivity/vulnerability: 925 /nw:networks/nw:network/nw:network-types/tet:te-topology/sf 926 This subtree specifies the topology type. Modifying the 927 configurations can make topology type invalid and cause 928 interruption to the specified SF Aware TE topology and the related 929 SF Aware TE topologies. 931 /nw:networks/nw:network/nw:node/tet:te/tet:te-node-attributes/ 932 service-function 933 This subtree specifies the configurations of service functions in 934 SF Aware TE nodes. Modifying the configurations in this subtree 935 can change the configurations of service functions in the 936 specified node, causing these service functions disabled or 937 misbehaving in the specified node. 939 /nw:networks/nw:network/nw:node/tet:te/tet:tunnel-termination-point/ 940 service-function 941 This subtree specifies the configurations of service functions on 942 a tunnel-termination-point in SF Aware TE nodes. Modifying the 943 configurations in this subtree can change the configurations of 944 service functions on the spcified tunnel-termination-point in the 945 specified node, causing these service functions disabled or 946 misbehaving. 948 /nw:networks/nw:network/nw:node/service-functions 949 This subtree specifies the available service functions in SF Aware 950 TE nodes. Modifying the configurations in this subtree can change 951 the configurations of the available service functions in the 952 specified node, causing these service functions disabled or 953 misbehaving in the specified node. 955 Some of the readable data nodes in this YANG module may be considered 956 sensitive or vulnerable in some network environments. It is thus 957 important to control read access (e.g., via get, get-config, or 958 notification) to these data nodes. These are the subtrees and data 959 nodes and their sensitivity/vulnerability: 961 /nw:networks/nw:network/nw:network-types/tet:te-topology/sf 962 Unauthorized access to this subtree can disclose the SF Aware TE 963 topology type. 965 /nw:networks/nw:network/nw:node/tet:te/tet:te-node-attributes/ 966 service-function 967 Unauthorized access to this subtree can disclose the operational 968 state information of the service functions in the specified SF 969 Aware TE node. 971 /nw:networks/nw:network/nw:node/tet:te/tet:information-source-entry/ 972 service-function 973 Unauthorized access to this subtree can disclose the operational 974 state information of the service functions in the specified SF 975 Aware TE node. 977 /nw:networks/nw:network/nw:node/tet:te/tet:tunnel-termination-point/ 978 service-function 979 Unauthorized access to this subtree can disclose the operational 980 state information of the service functions on the specified 981 tunnel-termination-point in the specified SF Aware TE node. 983 /nw:networks/nw:network/nw:node/service-functions 984 Unauthorized access to this subtree can disclose the operational 985 state information of the availble service functions in the 986 specified node. 988 7. References 990 7.1. Normative References 992 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 993 Requirement Levels", BCP 14, RFC 2119, 994 DOI 10.17487/RFC2119, March 1997, 995 . 997 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 998 DOI 10.17487/RFC3688, January 2004, 999 . 1001 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1002 the Network Configuration Protocol (NETCONF)", RFC 6020, 1003 DOI 10.17487/RFC6020, October 2010, 1004 . 1006 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1007 and A. Bierman, Ed., "Network Configuration Protocol 1008 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1009 . 1011 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 1012 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 1013 . 1015 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 1016 RFC 6991, DOI 10.17487/RFC6991, July 2013, 1017 . 1019 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1020 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1021 . 1023 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1024 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 1025 . 1027 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1028 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1029 May 2017, . 1031 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 1032 Access Control Model", STD 91, RFC 8341, 1033 DOI 10.17487/RFC8341, March 2018, 1034 . 1036 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 1037 and R. Wilton, "Network Management Datastore Architecture 1038 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 1039 . 1041 [RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N., 1042 Ananthakrishnan, H., and X. Liu, "A YANG Data Model for 1043 Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March 1044 2018, . 1046 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1047 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1048 . 1050 [RFC8529] Berger, L., Hopps, C., Lindem, A., Bogdanovic, D., and X. 1051 Liu, "YANG Data Model for Network Instances", RFC 8529, 1052 DOI 10.17487/RFC8529, March 2019, 1053 . 1055 [RFC8530] Berger, L., Hopps, C., Lindem, A., Bogdanovic, D., and X. 1056 Liu, "YANG Model for Logical Network Elements", RFC 8530, 1057 DOI 10.17487/RFC8530, March 2019, 1058 . 1060 [RFC8776] Saad, T., Gandhi, R., Liu, X., Beeram, V., and I. Bryskin, 1061 "Common YANG Data Types for Traffic Engineering", 1062 RFC 8776, DOI 10.17487/RFC8776, June 2020, 1063 . 1065 [RFC8795] Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and 1066 O. Gonzalez de Dios, "YANG Data Model for Traffic 1067 Engineering (TE) Topologies", RFC 8795, 1068 DOI 10.17487/RFC8795, August 2020, 1069 . 1071 [I-D.ietf-teas-yang-te] 1072 Saad, T., Gandhi, R., Liu, X., Beeram, V. P., Bryskin, I., 1073 and O. G. D. Dios, "A YANG Data Model for Traffic 1074 Engineering Tunnels, Label Switched Paths and Interfaces", 1075 draft-ietf-teas-yang-te-26 (work in progress), February 1076 2021. 1078 [I-D.ietf-teas-actn-vn-yang] 1079 Lee, Y., Dhody, D., Ceccarelli, D., Bryskin, I., and B. Y. 1080 Yoon, "A YANG Data Model for VN Operation", draft-ietf- 1081 teas-actn-vn-yang-11 (work in progress), February 2021. 1083 [ETSI-NFV-PACKAGE] 1084 ETSI, "Network Functions Virtualisation (NFV) Release 4; 1085 Management and Orchestration; VNF Descriptor and Packaging 1086 Specification", ETSI GR NFV-IFA 011 V4.2.1, May 2021, 1087 . 1090 [ETSI-NFV-TERM] 1091 ETSI, "Network Functions Virtualisation (NFV); Terminology 1092 for Main Concepts in NFV", ETSI GR NFV 003 V1.6.1, March 1093 2021, . 1096 [ETSI-NFV-YANG] 1097 ETSI, "Network Functions Virtualisation (NFV) Release 3; 1098 Protocols and Data Models; NFV descriptors based on YANG 1099 specification", ETSI GS NFV-SOL 006 V3.5.1, July 2021, 1100 . 1103 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 1104 Address Translator (Traditional NAT)", RFC 3022, 1105 DOI 10.17487/RFC3022, January 2001, 1106 . 1108 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 1109 NAT64: Network Address and Protocol Translation from IPv6 1110 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, 1111 April 2011, . 1113 [RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for 1114 Abstraction and Control of TE Networks (ACTN)", RFC 8453, 1115 DOI 10.17487/RFC8453, August 2018, 1116 . 1118 [RFC8459] Dolson, D., Homma, S., Lopez, D., and M. Boucadair, 1119 "Hierarchical Service Function Chaining (hSFC)", RFC 8459, 1120 DOI 10.17487/RFC8459, September 2018, 1121 . 1123 [_3GPP.28.801] 1124 3GPP, "Study on management and orchestration of network 1125 slicing for next generation network", 3GPP TR 28.801 1126 V2.0.0, September 2017, 1127 . 1129 7.2. Informative References 1131 [RFC7498] Quinn, P., Ed. and T. Nadeau, Ed., "Problem Statement for 1132 Service Function Chaining", RFC 7498, 1133 DOI 10.17487/RFC7498, April 2015, 1134 . 1136 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 1137 Chaining (SFC) Architecture", RFC 7665, 1138 DOI 10.17487/RFC7665, October 2015, 1139 . 1141 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 1142 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 1143 . 1145 [I-D.defoy-netslices-3gpp-network-slicing] 1146 Foy, X. D. and A. Rahman, "Network Slicing - 3GPP Use 1147 Case", draft-defoy-netslices-3gpp-network-slicing-02 (work 1148 in progress), October 2017. 1150 Appendix A. Companion YANG Model for Non-NMDA Compliant Implementations 1152 The YANG module ietf-te-topology-sf defined in this document is 1153 designed to be used in conjunction with implementations that support 1154 the Network Management Datastore Architecture (NMDA) defined in 1155 [RFC8342]. In order to allow implementations to use the model even 1156 in cases when NMDA is not supported, the following companion module, 1157 ietf-te-topology-sf-state, is defined as state model, which mirrors 1158 the module ietf-te-topology-sf defined earlier in this document. 1159 However, all data nodes in the companion module are non-configurable, 1160 to represent the applied configuration or the derived operational 1161 states. 1163 The companion module, ietf-te-topology-sf-state, is redundant and 1164 SHOULD NOT be supported by implementations that support NMDA. 1166 As the structure of the companion module mirrors that of the 1167 coorespinding NMDA model, the YANG tree of the companion module is 1168 not depicted separately. 1170 A.1. SF Aware TE Topology State Module 1172 file "ietf-te-topology-sf-state@2021-06-28.yang" 1173 module ietf-te-topology-sf-state { 1174 yang-version 1.1; 1175 namespace "urn:ietf:params:xml:ns:yang:ietf-te-topology-sf-state"; 1177 prefix "tet-sf-s"; 1179 import ietf-te-topology-sf { 1180 prefix "tet-sf"; 1181 reference 1182 "RFC XXXX: SF Aware TE Topology YANG Model"; 1183 } 1185 import ietf-network-state { 1186 prefix "nw-s"; 1187 reference 1188 "RFC 8345: A YANG Data Model for Network Topologies"; 1189 } 1191 import ietf-network-topology-state { 1192 prefix "nt-s"; 1193 reference 1194 "RFC 8345: A YANG Data Model for Network Topologies"; 1195 } 1196 import ietf-te-topology-state { 1197 prefix "tet-s"; 1198 reference 1199 "RFC 8795: YANG Data Model for Traffic Engineering (TE) 1200 Topologies"; 1201 } 1203 organization 1204 "Traffic Engineering Architecture and Signaling (TEAS) 1205 Working Group"; 1207 contact 1208 "WG Web: 1209 WG List: 1211 Editors: Igor Bryskin 1212 1214 Xufeng Liu 1215 "; 1217 description 1218 "Network service and function aware aware TE topology operational 1219 state model for non-NMDA compliant implementations. 1221 Copyright (c) 2021 IETF Trust and the persons identified as 1222 authors of the code. All rights reserved. 1224 Redistribution and use in source and binary forms, with or 1225 without modification, is permitted pursuant to, and subject to 1226 the license terms contained in, the Simplified BSD License set 1227 forth in Section 4.c of the IETF Trust's Legal Provisions 1228 Relating to IETF Documents 1229 (http://trustee.ietf.org/license-info). 1231 This version of this YANG module is part of RFC XXXX; see the 1232 RFC itself for full legal notices."; 1234 revision 2021-06-28 { 1235 description "Initial revision"; 1236 reference "RFC XXXX: SF Aware TE Topology YANG Model"; 1237 } 1239 /* 1240 * Augmentations 1241 */ 1242 /* Augmentations to network-types/te-topology */ 1243 augment "/nw-s:networks/nw-s:network/nw-s:network-types/" 1244 + "tet-s:te-topology" { 1245 description 1246 "Defines the SF aware TE topology type."; 1247 uses tet-sf:sf-topology-type; 1248 } 1250 /* Augmentations to connectivity-matrix */ 1251 augment "/nw-s:networks/nw-s:network/nw-s:node/tet-s:te/" 1252 + "tet-s:te-node-attributes" { 1253 description 1254 "Parameters for SF aware TE topology."; 1255 uses tet-sf:service-function-node-augmentation; 1256 } 1258 augment "/nw-s:networks/nw-s:network/nw-s:node/tet-s:te/" 1259 + "tet-s:information-source-entry" { 1260 description 1261 "Parameters for SF aware TE topology."; 1262 uses tet-sf:service-function-node-augmentation; 1263 } 1265 /* Augmentations to tunnel-termination-point */ 1266 augment "/nw-s:networks/nw-s:network/nw-s:node/tet-s:te/" 1267 + "tet-s:tunnel-termination-point" { 1268 description 1269 "Parameters for SF aware TE topology."; 1270 uses tet-sf:service-function-ttp-augmentation; 1271 } 1273 /* Augmentations to connectivity-matrix */ 1274 augment "/nw-s:networks/nw-s:network/nw-s:node/tet-s:te/" 1275 + "tet-s:te-node-attributes/tet-sf-s:service-function/" 1276 + "tet-sf-s:link-terminations/tet-sf-s:link-termination/" 1277 + "tet-sf-s:from" { 1278 description 1279 "Add reference to the link termination point. 1280 This portion cannot be shared with the state module."; 1281 leaf tp-ref { 1282 type leafref { 1283 path "../../../../../../../nt-s:termination-point/" 1284 + "nt-s:tp-id"; 1285 } 1286 description 1287 "Reference to the link termination point."; 1288 } 1289 } 1290 } 1291 1293 Appendix B. Data Examples 1295 B.1. A Topology with Multiple Connected Network Functions 1297 Node-1 1298 +----o--o--------------------------o-------+ 1299 | | | | | 1300 | \__/ \__ | 1301 | *\/ TTP-1 * * * * * * * * * *\/* | 1302 LTP-4 |* * * * TTP-2 * | LTP-1 1303 o------------*-----------------------------o 1304 | * * | 1305 LTP-3 |* * * * * *| LTP-2 1306 o--- -----o 1307 | \ / | 1308 | \ / | 1309 | \ CP01 CP02/ | 1310 | +----o--------------------------o------+ | 1311 | | VL1| VL4| | | 1312 | | |CP11 |CP33 | | 1313 | | +-o--+ +----+ +-o--+ | | 1314 | | |VNF1| |VNF2| |VNF3| | | 1315 | | +-o-o+ VL2 +--o-+ VL2 +-o-o+ | | 1316 | |CP12| |\----------/ \---------/| |CP32| | 1317 | | | |CP13 CP21 CP31| | | | 1318 | | | | VL2 | | | | 1319 | | | +------------------------+ | | | 1320 | | +----------------------------+ | | 1321 | | VL3 | | 1322 | | Network Service 1 | | 1323 | +--------------------------------------+ | 1324 +------------------------------------------+ 1326 The configuration instance data for Node-1 in the above figure could 1327 be as follows: 1329 { 1330 "networks": { 1331 "network": [ 1332 { 1333 "network-types": { 1334 "te-topology": { 1335 "sf": {} 1336 } 1337 }, 1338 "network-id": "network-sf-aware", 1339 "provider-id": 201, 1340 "client-id": 300, 1341 "te-topology-id": "te-topology:network-sf-aware", 1342 "node": [ 1343 { 1344 "node-id": "Node-1", 1345 "te-node-id": "2.0.1.1", 1346 "te": { 1347 "te-node-attributes": { 1348 "domain-id": 1, 1349 "is-abstract": [null], 1350 "connectivity-matrices": { 1351 }, 1352 "service-function": { 1353 "connectivity-matrices": { 1354 "connectivity-matrix": [ 1355 { 1356 "id": 10, 1357 "from": { 1358 "service-function-id": "Network Service 1", 1359 "sf-connection-point-id": "CP01" 1360 }, 1361 "to": { 1362 "service-function-id": "VNF1", 1363 "sf-connection-point-id": "CP11" 1364 } 1365 "direction": "bidir", 1366 "virtual-link-id": "VL1" 1367 }, 1368 { 1369 "id": 13, 1370 "from": { 1371 "service-function-id": "VNF1", 1372 "sf-connection-point-id": "CP12" 1373 }, 1374 "to": { 1375 "service-function-id": "VNF3", 1376 "sf-connection-point-id": "CP32" 1377 } 1378 "direction": "bidir", 1379 "virtual-link-id": "VL3" 1380 }, 1381 { 1382 "id": 12, 1383 "from": { 1384 "service-function-id": "VNF1", 1385 "sf-connection-point-id": "CP13" 1386 }, 1387 "to": { 1388 "service-function-id": "VNF2", 1389 "sf-connection-point-id": "CP21" 1390 } 1391 "direction": "bidir", 1392 "virtual-link-id": "VL2" 1393 }, 1394 { 1395 "id": 23, 1396 "from": { 1397 "service-function-id": "VNF2", 1398 "sf-connection-point-id": "CP21" 1399 }, 1400 "to": { 1401 "service-function-id": "VNF3" 1402 "sf-connection-point-id": "CP31" 1403 } 1404 "direction": "bidir", 1405 "virtual-link-id": "VL2" 1406 }, 1407 { 1408 "id": 30, 1409 "from": { 1410 "service-function-id": "Network Service 1", 1411 "sf-connection-point-id": "CP02" 1412 }, 1413 "to": { 1414 "service-function-id": "VNF3", 1415 "sf-connection-point-id": "CP33" 1416 } 1417 "direction": "bidir", 1418 "virtual-link-id": "VL4" 1419 } 1420 ] 1421 }, 1422 "link-terminations": { 1423 "link-termination": [ 1424 { 1425 "id": 2, 1426 "from": { 1427 "tp-ref": "LTP-2" 1428 }, 1429 "to": { 1430 "service-function-id": "Network Service 1", 1431 "sf-connection-point-id": "CP02" 1432 } 1433 "direction": "bidir" 1434 }, 1435 { 1436 "id": 3, 1437 "from": { 1438 "tp-ref": "LTP-3" 1439 }, 1440 "to": { 1441 "service-function-id": "Network Service 1", 1442 "sf-connection-point-id": "CP01" 1443 } 1444 "direction": "bidir" 1445 } 1446 ] 1447 } 1448 } 1449 } 1450 "tunnel-termination-point": [ 1451 { 1452 "tunnel-tp-id": 10001, 1453 "name": "TTP-1", 1454 "service-function-terminations": { 1455 } 1456 }, 1457 { 1458 "tunnel-tp-id": 10002, 1459 "name": "TTP-2", 1460 "service-function-terminations": { 1461 } 1462 } 1463 ] 1464 }, 1465 "termination-point": [ 1466 { 1467 "tp-id": "LTP-1", 1468 "te-tp-id": 10001 1469 "te": { 1470 "interface-switching-capability": [ 1471 { 1472 "switching-capability": "switching-l2sc", 1473 "encoding": "lsp-encoding-ethernet" 1474 } 1475 ] 1476 } 1477 }, 1478 { 1479 "tp-id": "LTP-2", 1480 "te-tp-id": 10002 1481 "te": { 1482 "interface-switching-capability": [ 1483 { 1484 "switching-capability": "switching-l2sc", 1485 "encoding": "lsp-encoding-ethernet" 1486 } 1487 ] 1488 } 1489 }, 1490 { 1491 "tp-id": "LTP-3", 1492 "te-tp-id": 10003 1493 "te": { 1494 "interface-switching-capability": [ 1495 { 1496 "switching-capability": "switching-l2sc", 1497 "encoding": "lsp-encoding-ethernet" 1498 } 1499 ] 1500 } 1501 }, 1502 { 1503 "tp-id": "LTP-4", 1504 "te-tp-id": 10004 1505 "te": { 1506 "interface-switching-capability": [ 1507 { 1508 "switching-capability": "switching-l2sc", 1509 "encoding": "lsp-encoding-ethernet" 1510 } 1511 ] 1512 } 1513 } 1514 ] 1515 } 1516 ] 1517 } 1518 ] 1519 } 1520 } 1522 B.2. A Topology with an Encapsulated Network Service 1524 In this example, a network service consists of several inter- 1525 connected network functions (NFs), and is represented by this model 1526 as an encapsulated opaque object without the details between its 1527 internals. 1529 Node-1 1530 +----o--o--------------------------o-------+ 1531 | | | | | 1532 | \__/ \__ | 1533 | *\/ TTP-1 * * * * * * * * * *\/* | 1534 LTP-4 |* * * * TTP-2 * | LTP-1 1535 o------------*-----------------------------o 1536 | * * | 1537 LTP-3 |* * * * * *| LTP-2 1538 o--- -----o 1539 | \ / | 1540 | \ / | 1541 | \ CP01 CP02/ | 1542 | +----o--------------------------o------+ | 1543 | | | | 1544 | | Network Service 1 | | 1545 | +--------------------------------------+ | 1546 +------------------------------------------+ 1548 The configuration instance data for Node-1 in the above figure could 1549 be as follows: 1551 { 1552 "networks": { 1553 "network": [ 1554 { 1555 "network-types": { 1556 "te-topology": { 1557 "sf": {} 1558 } 1559 }, 1560 "network-id": "network-sf-aware", 1561 "provider-id": 201, 1562 "client-id": 300, 1563 "te-topology-id": "te-topology:network-sf-aware", 1564 "node": [ 1565 { 1566 "node-id": "Node-1", 1567 "te-node-id": "2.0.1.1", 1568 "te": { 1569 "te-node-attributes": { 1570 "domain-id": 1, 1571 "is-abstract": [null], 1572 "connectivity-matrices": { 1573 }, 1574 "service-function": { 1575 "connectivity-matrices": { 1576 }, 1577 "link-terminations": { 1578 "link-termination": [ 1579 { 1580 "id": 2, 1581 "from": { 1582 "tp-ref": "LTP-2" 1583 }, 1584 "to": { 1585 "service-function-id": "Network Service 1", 1586 "sf-connection-point-id": "CP02" 1587 } 1588 "direction": "bidir" 1589 }, 1590 { 1591 "id": 3, 1592 "from": { 1593 "tp-ref": "LTP-3" 1594 }, 1595 "to": { 1596 "service-function-id": "Network Service 1", 1597 "sf-connection-point-id": "CP01" 1598 } 1599 "direction": "bidir" 1600 } 1601 ] 1602 } 1603 } 1604 } 1605 "tunnel-termination-point": [ 1606 { 1607 "tunnel-tp-id": 10001, 1608 "name": "TTP-1", 1609 "service-function-terminations": { 1610 } 1611 }, 1612 { 1613 "tunnel-tp-id": 10002, 1614 "name": "TTP-2", 1615 "service-function-terminations": { 1616 } 1617 } 1618 ] 1619 }, 1620 "termination-point": [ 1621 { 1622 "tp-id": "LTP-1", 1623 "te-tp-id": 10001 1624 "te": { 1625 "interface-switching-capability": [ 1626 { 1627 "switching-capability": "switching-l2sc", 1628 "encoding": "lsp-encoding-ethernet" 1629 } 1630 ] 1631 } 1632 }, 1633 { 1634 "tp-id": "LTP-2", 1635 "te-tp-id": 10002 1636 "te": { 1637 "interface-switching-capability": [ 1638 { 1639 "switching-capability": "switching-l2sc", 1640 "encoding": "lsp-encoding-ethernet" 1641 } 1642 ] 1643 } 1644 }, 1645 { 1646 "tp-id": "LTP-3", 1647 "te-tp-id": 10003 1648 "te": { 1649 "interface-switching-capability": [ 1650 { 1651 "switching-capability": "switching-l2sc", 1652 "encoding": "lsp-encoding-ethernet" 1653 } 1654 ] 1655 } 1656 }, 1657 { 1658 "tp-id": "LTP-4", 1659 "te-tp-id": 10004 1660 "te": { 1661 "interface-switching-capability": [ 1662 { 1663 "switching-capability": "switching-l2sc", 1664 "encoding": "lsp-encoding-ethernet" 1665 } 1666 ] 1667 } 1668 } 1669 ] 1670 } 1671 ] 1672 } 1674 ] 1675 } 1676 } 1678 Appendix C. Use Cases for SF Aware Topology Models 1680 C.1. Exporting SF/NF Information to Network Clients and Other Network 1681 SDN Controllers 1683 In the context of Service Function Chain (SFC) orchestration one 1684 existing problem is that there is no way to formally describe a 1685 Service or Network Function in a standard way (recognizable/ 1686 understood by a third party) as a resource of a network topology 1687 node. 1689 One implication of this is that there is no way for the orchestrator 1690 to give a network client even a ball-park idea as to which network's 1691 SFs/NFs are available for the client's use/control and where they are 1692 located in the network even in terms of abstract topologies/virtual 1693 networks configured and managed specifically for the client. 1694 Consequently, the client has no say on how the SFCs provided for the 1695 client by the network should be set up and managed (which SFs are to 1696 be used and how they should be chained together, optimized, 1697 manipulated, protected, etc.). 1699 Likewise, there is no way for the orchestrator to export SF/NF 1700 information to other network controllers. The SFC orchestrator may 1701 serve, for example, a higher level controller (such as Network 1702 Slicing Orchestrator), with the latter wanting at least some level of 1703 control as to which SFs/NFs it wants on its SFCs and how the Service 1704 Function Paths (SFPs) are to be routed and provisioned, especially, 1705 if it uses services of more than one SFC orchestrator. 1707 The issue of exporting of SF/NF information could be addressed by 1708 defining a model, in which formally described/recognizable SF/NF 1709 instances are presented as topological elements, for example, hosted 1710 by TE, L3 or L2 topology nodes (see Figure 1). The model could 1711 describe whether, how and at what costs the SFs/NFs hosted by a given 1712 node could be chained together, how these intra-node SFCs could be 1713 connected to the node's Service Function Forwarders (SFFs, entities 1714 dealing with SFC NSHs and metadata), and how the SFFs could be 1715 connected to the node's Tunnel and Link Termination Points (TTPs and 1716 LTPs) to chain the intra-node SFCs across the network topology. 1718 The figure is available in the PDF format. 1720 Figure 1: SF/NF aware TE topology 1722 C.2. Flat End-to-end SFCs Managed on Multi-domain Networks 1724 SFCs may span multiple administrative domains, each of which 1725 controlled by a separate SFC controller. The usual solution for such 1726 a scenario is the Hierarchical SFCs (H-SFCs) [RFC8459], in which the 1727 higher level orchestrator controls only SFs located on domain border 1728 nodes. Said higher level SFs are chained together into higher level 1729 SFCs via lower level (intra-domain) SFCs provisioned and controlled 1730 independently by respective domain controllers. The decision as to 1731 which higher level SFCs are connected to which lower level SFCs is 1732 driven by packet re-classification every time the packet enters a 1733 given domain. Said packet re-classification is a very time-consuming 1734 operation. Furthermore, the independent nature of higher and lower 1735 level SFC control is prone to configuration errors, which may lead to 1736 long lasting loops and congestions. It is highly desirable to be 1737 able to set up and manage SFCs spanning multiple domains in a flat 1738 way as far as the data plane is concerned (i.e. with a single packet 1739 classification at the ingress into the multi-domain network but 1740 without re-classifications on domain ingress nodes). 1742 One way to achieve this is to have the domain controllers expose SF/ 1743 NF- aware topologies, and have the higher level orchestrator operate 1744 on the network-wide topology, the product of merging of the 1745 topologies catered by the domain controllers. This is similar in 1746 spirit to setting up, coordinating and managing the transport 1747 connectivity (TE tunnels) on a multi-domain multi-vendor transport 1748 network. 1750 C.3. Managing SFCs with TE Constraints 1752 Some SFCs require per SFC link/element and end-to-end TE constrains 1753 (bandwidth, delay/jitter, fate sharing/diversity. etc.). Said 1754 constraints could be ensured via carrying SFPs inside overlays that 1755 are traffic engineered with the constrains in mind. A good analogy 1756 would be orchestrating delay constrained L3 VPNs. One way to support 1757 such L3 VPNs is to carry MPLS LSPs interconnecting per-VPN VRFs 1758 inside delay constrained TE tunnels interconnecting the PEs hosting 1759 the VRFs. 1761 The figure is available in the PDF format. 1763 Figure 2: L3 VPN with delay constraints 1765 Planning, computing and provisioning of TE overlays to constrain 1766 arbitrary SFCs, especially those that span multiple administrative 1767 domains with each domain controlled by a separate controller, is a 1768 very difficult challenge. Currently it is addressed by pre- 1769 provisioning on the network of multiple TE tunnels with various TE 1770 characteristics, and "nailing down" SFs/NFs to "strategic" locations 1771 (e.g. nodes terminating many of such tunnels) in a hope that an 1772 adequate set of tunnels could be found to carry the SFP of a given 1773 TE-constrained SFC. Such an approach is especially awkward in the 1774 case when some or all of the SFs/NFs are VNFs (i.e. could be 1775 instantiated at multiple network locations). 1777 SF/NF-aware TE topology model in combination with TE tunnel model 1778 will allow for the network orchestrator (or a client controller) to 1779 compute, set up and manipulate the TE overlays in the form of TE 1780 tunnel chains (see Figure 3). 1782 Said chains could be duel-optimized compromising on optimal SF/NF 1783 locations with optimal TE tunnels interconnecting them. The TE 1784 tunnel chains (carrying multiple similarly constrained SFPs) could be 1785 adequately constrained both at individual TE tunnel level and at the 1786 chain end-to-end level. 1788 The figure is available in the PDF format. 1790 Figure 3: SFC with TE constraints 1792 C.4. SFC Protection and Load Balancing 1794 Currently the combination of TE topology & tunnel models offers to a 1795 network controller various capabilities to recover an individual TE 1796 tunnel from network failures occurred on one or more network links or 1797 transit nodes on the TE paths taken by the TE tunnel's connection(s). 1798 However, there is no simple way to recover a TE tunnel from a failure 1799 affecting its source or destination node. SF/NF-aware TE topology 1800 model can decouple the association of a given SF/NF with its location 1801 on the network topology by presenting multiple, identifiable as 1802 mutually substitutable SFs/NFs hosted by different TE topology nodes. 1803 So, for example, if it is detected that a given TE tunnel destination 1804 node is malfunctioning or has gone out of service, the TE tunnel 1805 could be re-routed to terminate on a different node hosting 1806 functionally the same SFs/NFs as ones hosted by the failed node (see 1807 Figures 6). 1809 This is in line with the ACTN edge migration and function mobility 1810 concepts [RFC8453]. It is important to note that the described 1811 strategy works much better for the stateless SFs/NFs. This is 1812 because getting the alternative stateful SFs/NFs into the same 1813 respective states as the current (i.e. active, affected by failure) 1814 are is a very difficult challenge. 1816 The figure is available in the PDF format. 1818 Figure 4: SFC recovery: SF2 on node NE1 fails 1820 At the SFC level the SF/NF-aware TE topology model can offer SFC 1821 dynamic restoration capabilities against failed/malfunctioning SFs/ 1822 NFs by identifying and provisioning detours to a TE tunnel chain, so 1823 that it starts carrying the SFC's SFPs towards healthy SFs/NFs that 1824 are functionally the same as the failed ones. Furthermore, multiple 1825 parallel TE tunnel chains could be pre-provisioned for the purpose of 1826 SFC load balancing and end-to-end protection. In the latter case 1827 said parallel TE tunnel chains could be placed to be sufficiently 1828 disjoint from each other. 1830 The figure is available in the PDF format. 1832 Figure 5: SFC recovery: SFC SF1-SF2-SF6 is recovered after SF2 on 1833 node N1 has failed 1835 The figure is available in the PDF format. 1837 Figure 6: SFC recovery: SFC SF1-SF2-SF6 is recovered after node N1 1838 has failed 1840 C.5. Network Clock Synchronization 1842 Many current and future network applications (including 5g and IoT 1843 applications) require very accurate time services (PTP level, ns 1844 resolution). One way to implement the adequate network clock 1845 synchronization for such services is via describing network clocks as 1846 NFs on an NF-aware TE topology optimized to have best possible delay 1847 variation characteristics. Because such a topology will contain 1848 delay/delay variation metrics of topology links and node cross- 1849 connects, as well as costs in terms of delay/delay variation of 1850 connecting clocks to hosting them node link and tunnel termination 1851 points, it will be possible to dynamically select and provision bi- 1852 directional time-constrained deterministic paths or trees connecting 1853 clocks (e.g. grand master and boundary clocks) for the purpose of 1854 exchange of clock synchronization information. Note that network 1855 clock aware TE topologies separately provided by domain controllers 1856 will enable multi-domain network orchestrator to set up and 1857 manipulate the clock synchronization paths/trees spanning multiple 1858 network domains. 1860 C.6. Client - Provider Network Slicing Interface 1862 3GPP defines network slice as "a set of network functions and the 1863 resources for these network functions which are arranged and 1864 configured, forming a complete logical network to meet certain 1865 network characteristics" [I-D.defoy-netslices-3gpp-network-slicing] 1866 [_3GPP.28.801]. Network slice could be also defined as a logical 1867 partition of a provider's network that is owned and managed by a 1868 tenant. SF/NF-aware TE topology model has a potential to support a 1869 very important interface between network slicing clients and 1870 providers because, on the one hand, the model can describe 1871 holistically and hierarchically the client's requirements and 1872 preferences with respect to a network slice functional, topological 1873 and traffic engineering aspects, as well as of the degree of resource 1874 separation/ sharing between the slices, thus allowing for the client 1875 (up to agreed upon extent) to dynamically (re-)configure the slice or 1876 (re-)schedule said (re-)configurations in time, while, on the other 1877 hand, allowing for the provider to convey to the client the slice's 1878 operational state information and telemetry the client has expressed 1879 interest in. 1881 C.7. Dynamic Assignment of Regenerators for L0 Services 1883 On large optical networks, some of provided to their clients L0 1884 services could not be provisioned as single OCh trails, rather, as 1885 chains of such trails interconnected via regenerators, such as 3R 1886 regenerators. Current practice of the provisioning of such services 1887 requires configuration of explicit paths (EROs) describing identity 1888 and location of regenerators to be used. A solution is highly 1889 desirable that could: 1891 o Identify such services based, for example, on optical impairment 1892 computations; 1894 o Assign adequate for the services regenerators dynamically out of 1895 the regenerators that are grouped together in pools and 1896 strategically scattered over the network topology nodes; 1898 o Compute and provision supporting the services chains of optical 1899 trails interconnected via so selected regenerators, optimizing the 1900 chains to use minimal number of regenerators, their optimal 1901 locations, as well as optimality of optical paths interconnecting 1902 them; 1904 o Ensure recovery of such chains from any failures that could happen 1905 on links, nodes or regenerators along the chain path. 1907 NF-aware TE topology model (in this case L1 NF-aware L0 topology 1908 model) is just the model that could provide a network controller (or 1909 even a client controller operating on abstract NF-aware topologies 1910 provided by the network) to realize described above computations and 1911 orchestrate the service provisioning and network failure recovery 1912 operations (see Figure 7). 1914 The figure is available in the PDF format. 1916 Figure 7: Optical tunnel as TE-constrained SFC of 3R regenerators. 1917 Red trail (not regenerated) is not optically reachable, but blue 1918 trail (twice regenerated) is 1920 C.8. Dynamic Assignment of OAM Functions for L1 Services 1922 OAM functionality is normally managed by configuring and manipulating 1923 TCM/MEP functions on network ports terminating connections or their 1924 segments over which OAM operations, such as performance monitoring, 1925 are required to be performed. In some layer networks (e.g. 1926 Ethernet) said TCMs/MEPs could be configured on any network ports. 1927 In others (e.g. OTN/ODUk) the TCMs/MEPs could be configured on some 1928 (but not all network ports) due to the fact that the OAM 1929 functionality (i.e. recognizing and processing of OAM messages, 1930 supporting OAM protocols and FSMs) requires in these layer networks 1931 certain support in the data plane, which is not available on all 1932 network nodes. This makes TCMs/MEPs good candidates to be modeled as 1933 NFs. This also makes TCM/MEP aware topology model a good basis for 1934 placing dynamically an ODUk connection to pass through optimal OAM 1935 locations without mandating the client to specify said locations 1936 explicitly. 1938 The figure is available in the PDF format. 1940 Figure 8: Compute/storage resource aware topology 1942 C.9. SFC Abstraction and Scaling 1944 SF/NF-aware topology may contain information on native SFs/NFs (i.e. 1945 SFs/NFs as known to the provider itself) and/or abstract SFs/NFs 1946 (i.e. logical/macro SFs/NFs representing one or more SFCs each made 1947 of native and/or lower level abstract SFs/NFs). As in the case of 1948 abstracting topology nodes, abstracting SFs/NFs is hierarchical in 1949 nature - the higher level of SF/NF-aware topology, the "larger" 1950 abstract SFs/NFs are, i.e. the larger data plane SFCs they represent. 1951 This allows for managing large scale networks with great number of 1952 SFs/NFs (such as Data Center interconnects) in a hierarchical, highly 1953 scalable manner resulting in control of very large number of flat in 1954 the data plane SFCs that span multiple domains. 1956 C.10. Dynamic Compute/VM/Storage Resource Assignment 1958 In a distributed data center network, virtual machines for compute 1959 resources may need to be dynamically re-allocated due to various 1960 reasons such as DCI network failure, compute resource load balancing, 1961 etc. In many cases, the DCI connectivity for the source and the 1962 destination is not predetermined. There may be a pool of sources and 1963 a pool of destination data centers associated with re-allocation of 1964 compute/VM/storage resources. There is no good mechanism to date to 1965 capture this dynamicity nature of compute/VM/storage resource 1966 reallocation. Generic Compute/VM/Storage resources can be described 1967 and announced as a SF, where a DC hosting these resources can be 1968 modeled as an abstract node. Topology interconnecting these abstract 1969 nodes (DCs) in general is of multi-domain nature. Thus, SF-aware 1970 topology model can facilitate a joint optimization of TE network 1971 resources and Compute/VM/Storage resources and solve Compute/VM/ 1972 Storage mobility problem within and between DCs (see Figure 8). 1974 C.11. Application-aware Resource Operations and Management 1976 Application stratum is the functional grouping which encompasses 1977 application resources and the control and management of these 1978 resources. These application resources are used along with network 1979 services to provide an application service to clients/end-users. 1980 Application resources are non-network resources critical to achieving 1981 the application service functionality. Examples of application 1982 resources include: caches, mirrors, application specific servers, 1983 content, large data sets, and computing power. Application service 1984 is a networked application offered to a variety of clients (e.g., 1985 server backup, VM migration, video cache, virtual network on-demand, 1986 5G network slicing, etc.). The application servers that host these 1987 application resources can be modeled as an abstract node. There may 1988 be a variety of server types depending on the resources they host. 1989 Figure 9 shows one example application aware topology for video cache 1990 server distribution. 1992 The figure is available in the PDF format. 1994 Figure 9: Application aware topology 1996 C.12. Interconnection between Service Functions/Termination Points in 1997 uCPE 1999 Universal Customer Premises Equipment (uCPE) enables Virtual Network 2000 Functions (VNFs) at the client site. uCPE is based on the Network 2001 Function Virtualization Infrastructure (NFVI) - generally Linux 2002 distribution with integrated software that offers: 2004 o Virtual Switch functionality 2006 o Full virtualization/containerization solution 2008 o Data path acceleration tool-kits 2010 o Management layer 2012 The sf-aware-topo-model placed in the controller controls via the 2013 management layer of uCPE the interconnection between: 2015 o virtual ports of VNFs 2017 o virtual ports of Virtual Switch abstraction elements 2019 o physical ports of uCPE 2021 Figure 10 shows an example application aware topology for 2022 interconnection between Logical Network Elements [RFC8530], Network 2023 Instances [RFC8529], uCPE node Termination Points [RFC8345]. In 2024 Figure 10 the following elements are presented: 2026 o 3 Logical Network Elements (vCPEL3_WAN1,vCPEL3_WAN2,vSD-WAN) 2028 o 4 Network Instances (vCPEL2) 2030 o 4 Termination Points (Physical Ports) 2032 There are two types of access provided to the client. 2034 The 1st access "Internet" topology part: 1st uCPE Termination Point 2035 "WAN1_port_internet" -- NI (vCPEL2) -- LNE (vCPEL3_telco_internet) -- 2036 NI (vCPEL2) -- vSD-WAN_port_internet. 2038 The 2nd access "MPLS" topology part: 2nd Termination Point 2039 "WAN2_port_mpls" -- NI (vCPEL2) -- LNE (vCPEL3_telco_mpls) -- NI 2040 (vCPEL2) -- vSD-WAN_port_mpls. 2042 Finally SD-WAN balances the traffic via two WAN ports (Termination 2043 Points) of uCPE and shares the connection to LAN ports (Termination 2044 Points). 2046 The figure is available in the PDF format. 2048 Figure 10: uCPE Service Functions topology 2050 An example of an instance data tree in the XML format is presented in 2051 Figure 12, following the uCPE Service Functions topology presented in 2052 Figure 11. 2054 For this example, the interconnection goes as follows: Network-facing 2055 Provider Edge (N-PE) router -- User-facing Provider Edge (U-PE) 2056 router -- uCPE ( Termination Point WAN -- NI (vCPEL2) -- LNE (vCPEL3) 2057 ) 2059 In uCPE, Termination Point (WAN) has id 1. On the NNI 2060 (connectionpoint_id == 10) port of NI the trunk mode is configured. 2061 On UNI ports of NI (cp_id == 13) access mode is configured. Port 2062 with cp_id == 13 is connected to LNE cp_id = 1. 2064 The figure is available in the PDF format. 2066 Figure 11: uCPE Service Functions topology (simple) 2068 2069 2070 2071 network1 2072 2073 2075 2077 2078 2079 2080 uCPE1 2081 2084 1 2085 2088 2089 full 2090 2091 1500 2092 dpdk 2093 2095 2096 2099 2 2100 2101 2104 3 2105 2106 0.0.0.0 2109 2110 2111 2114 2115 2116 1 2117 2118 CPEL3 2119 1 2121 2122 2123 CPEL2 2124 13 2126 2127 true 2128 l10 2129 2130 2131 2132 2133 2 2134 2135 1 2136 2137 2138 CPEL2 2139 10 2141 2142 l11 2146 2147 2148 2149 2150 2151 ucpe 2155 2156 2157 N-PE 2158 2161 1 2162 2163 2166 2 2167 2168 2171 3 2172 2173 2176 4 2177 2178 2179 2180 U-PE 2181 2184 1 2185 2186 2189 2 2190 2191 2194 3 2195 2196 2199 4 2200 2201 2202 2204 1 2205 2206 N-PE 2207 2 2208 2209 2210 U-PE 2211 1 2212 2213 2214 2216 2 2217 2218 U-PE 2219 2 2220 2221 2222 uCPE1 2223 1 2224 2225 2226 2227 2228 2231 2232 CPEL3 2233 2236 2237 CPEL3 2238 small 2240 2241 uCPE1 2242 2243 2244 2245 2247 2248 CPEL2 2249 2252 2253 10 2254 2255 X 2256 Y 2257 Z 2258 2259 2260 2261 11 2262 2263 X 2264 2265 2266 2267 12 2268 2269 Z 2270 2271 2272 2273 13 2274 2275 Y 2276 2277 2278 wan 2279 uCPE1 2280 2281 2282 2283 2285 Figure 12: uCPE Service Funcitons topology YIN example 2287 Acknowledgements 2289 The authors would like to thank Maarten Vissers, Joel Halpern, and 2290 Greg Mirsky for their helpful comments and valuable contributions. 2292 Authors' Addresses 2294 Igor Bryskin 2295 Individual 2297 EMail: i_bryskin@yahoo.com 2299 Xufeng Liu 2300 Volta Networks 2302 EMail: xufeng.liu.ietf@gmail.com 2304 Young Lee 2305 Samsung Electronics 2307 EMail: younglee.tx@gmail.com 2309 Jim Guichard 2310 Huawei Technologies 2312 EMail: james.n.guichard@huawei.com 2314 Luis Miguel Contreras Murillo 2315 Telefonica 2317 EMail: luismiguel.contrerasmurillo@telefonica.com 2319 Daniele Ceccarelli 2320 Ericsson 2322 EMail: daniele.ceccarelli@ericsson.com 2324 Jeff Tantsura 2325 Apstra Networks 2327 EMail: jefftant.ietf@gmail.com 2328 Dmytro Shytyi 2329 SFR 2330 Paris 2331 France 2333 EMail: ietf.dmytro@shytyi.net