idnits 2.17.1 draft-ietf-teas-sf-aware-topo-model-07.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 21, 2021) is 1161 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-25 == Outdated reference: A later version (-24) exists of draft-ietf-teas-actn-vn-yang-10 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 25, 2021 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 February 21, 2021 20 SF Aware TE Topology YANG Model 21 draft-ietf-teas-sf-aware-topo-model-07 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 25, 2021. 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 . . . . . . . . . . . . . . . . . . . . . 16 70 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 71 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 72 7.1. Normative References . . . . . . . . . . . . . . . . . . 18 73 7.2. Informative References . . . . . . . . . . . . . . . . . 21 74 Appendix A. Companion YANG Model for Non-NMDA Compliant 75 Implementations . . . . . . . . . . . . . . . . . . 22 76 A.1. SF Aware TE Topology State Module . . . . . . . . . . . . 22 77 Appendix B. Data Examples . . . . . . . . . . . . . . . . . . . 25 78 B.1. A Topology with Multiple Connected Network Functions . . 25 79 B.2. A Topology with an Encapsulated Network Service . . . . . 29 80 Appendix C. Use Cases for SF Aware Topology Models . . . . . . . 33 81 C.1. Exporting SF/NF Information to Network Clients and Other 82 Network SDN Controllers . . . . . . . . . . . . . . . . . 33 83 C.2. Flat End-to-end SFCs Managed on Multi-domain Networks . 34 84 C.3. Managing SFCs with TE Constraints . . . . . . . . . . . . 35 85 C.4. SFC Protection and Load Balancing . . . . . . . . . . . . 36 86 C.5. Network Clock Synchronization . . . . . . . . . . . . . . 39 87 C.6. Client - Provider Network Slicing Interface . . . . . . . 39 88 C.7. Dynamic Assignment of Regenerators for L0 Services . . . 39 89 C.8. Dynamic Assignment of OAM Functions for L1 Services . . . 41 90 C.9. SFC Abstraction and Scaling . . . . . . . . . . . . . . . 42 91 C.10. Dynamic Compute/VM/Storage Resource Assignment . . . . . 42 92 C.11. Application-aware Resource Operations and Management . . 43 93 C.12. Interconnection between Service Functions/Termination 94 Points in uCPE . . . . . . . . . . . . . . . . . . . . . 44 95 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 51 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 51 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 | tet | ietf-te-topology | [RFC8795] | 253 | actn-vn | ietf-actn-vn | [I-D.ietf-teas-actn-vn-yang] | 254 +---------+------------------+------------------------------+ 256 Table 1: Prefixes and Corresponding YANG Modules 258 2. Modeling Considerations 260 The model introduced in this document is an augmentation of the TE 261 Topology model defined in [RFC8795]. SFs are modeled as child 262 elements of a TE node similarly to how Link Termination Points (LTPs) 263 and Tunnel Termination Points (TTPs) are modeled in the TE Topology 264 model. The SFs are defined as opaque objects identified via topology 265 unique service-function-id's. Each SF has one or more Connection 266 Points (CPs) identified via SF-unique sf-connection-point-id's, over 267 which the SF could be connected to other SFs resided on the same TE 268 node, as well as to other elements of the TE node, in particular, to 269 the node's LTPs and/or TTPs. An interested client may use service- 270 function-id's to look up the SFs in TOSCA or YANG data store(s) 271 defined by [ETSI-NFV-MAN] to retrieve the details of the SFs, for 272 example, to understand the SF's mutual substitutability. 274 The TE Topology model introduces a concept of Connectivity Matrix 275 (CM), and uses the CM to describe which and at what costs a TE node's 276 LTPs could be inter-connected internally across the TE node. The 277 model defined in this document heavily uses the same concept to 278 describe the SF connectivity via introducing 3 additional CMs: 280 1. SF2SF CM (SF to SF Connectivity Matrix). This CM describes which 281 pairs of SFs could be locally inter-connected, and, if yes, in 282 which direction, via which CPs and at what costs. In other 283 words, the SF2SF CM describes how SFs residing on the same TE 284 node could be inter-connected into local from the TE node's 285 perspective SFCs; 287 2. SF2LTP CM (SF to LTP Connectivity Matrix). This CM describes 288 how, in which direction and at what costs the TE node's SFs could 289 be connected to the TE node's LTPs and hence to SFs residing on 290 neighboring TE nodes that are connected to LTPs at the remote 291 ends of corresponding TE links; 293 3. SF2TTP CM (SF to TTP Connectivity Matrix). This CM describes 294 how, in which direction and at what costs the TE node's SFs could 295 be connected to the TE node's TTPs and hence to SFs residing on 296 other TE nodes on the topology that could be inter-connected with 297 the TE node in question via TE tunnels terminated by the 298 corresponding TTPs. 300 In addition to SF2SF CM, the local SF chaining could be described 301 with the help of ETSI models Virtual Links (VLs) [ETSI-NFV-MAN]. 302 This option is especially useful when the costs of the local chaining 303 are negligible as compared to ones of the end-to-end SFCs said local 304 SFCs are part of. 306 Section 3 and 4 provide the YANG model structure and the YANG module 307 for SF-aware Topology. Section 5 and 6 provide the YANG model 308 structure and the YANG module for Data Center Compute Node resource 309 abstraction. This provides an example of SF2LTP CM where DC compute 310 nodes are connected to LTPs at the remote ends of the corresponding 311 TE links. This use-case is described in Section 10 of Appendix C. 313 3. SF Aware TE Topology Model Structure 315 module: ietf-te-topology-sf 316 augment /nw:networks/nw:network/nw:network-types/tet:te-topology: 317 +--rw sf! 318 augment /nw:networks/nw:network/nw:node/tet:te 319 /tet:te-node-attributes: 320 +--rw service-function 321 +--rw connectivity-matrices 322 | +--rw connectivity-matrix* [id] 323 | +--rw id uint32 324 | +--rw from 325 | | +--rw service-function-id? string 326 | | +--rw sf-connection-point-id? string 327 | +--rw to 328 | | +--rw service-function-id? string 329 | | +--rw sf-connection-point-id? string 330 | +--rw enabled? boolean 331 | +--rw direction? connectivity-direction 332 | +--rw virtual-link-id? string 333 +--rw link-terminations 334 +--rw link-termination* [id] 335 +--rw id uint32 336 +--rw from 337 | +--rw tp-ref? -> ../../../../../../.. 338 /nt:termination-point/tp-id 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 379 4. SF Aware TE Topology YANG Module 381 file "ietf-te-topology-sf@2021-02-15.yang" 382 module ietf-te-topology-sf { 383 yang-version 1.1; 384 namespace "urn:ietf:params:xml:ns:yang:ietf-te-topology-sf"; 386 prefix "tet-sf"; 388 import ietf-network { 389 prefix "nw"; 390 reference 391 "RFC 8345: A YANG Data Model for Network Topologies"; 392 } 394 import ietf-network-topology { 395 prefix "nt"; 396 reference 397 "RFC 8345: A YANG Data Model for Network Topologies"; 398 } 400 import ietf-te-topology { 401 prefix "tet"; 402 reference 403 "RFC 8795: YANG Data Model for Traffic Engineering (TE) 404 Topologies"; 405 } 407 organization 408 "Traffic Engineering Architecture and Signaling (TEAS) 409 Working Group"; 411 contact 412 "WG Web: 413 WG List: 415 Editors: Igor Bryskin 416 418 Xufeng Liu 419 "; 421 description 422 "Network service and function aware aware TE topology model. 424 Copyright (c) 2021 IETF Trust and the persons identified as 425 authors of the code. All rights reserved. 427 Redistribution and use in source and binary forms, with or 428 without modification, is permitted pursuant to, and subject to 429 the license terms contained in, the Simplified BSD License set 430 forth in Section 4.c of the IETF Trust's Legal Provisions 431 Relating to IETF Documents 432 (http://trustee.ietf.org/license-info). 434 This version of this YANG module is part of RFC XXXX; see the 435 RFC itself for full legal notices."; 437 revision 2021-02-15 { 438 description "Initial revision"; 439 reference "RFC XXXX: SF Aware TE Topology YANG Model"; 440 } 442 /* 443 * Typedefs 444 */ 445 typedef connectivity-direction { 446 type enumeration { 447 enum "to" { 448 description 449 "The direction is uni-directional, towards the 'to' 450 entity direction."; 451 } 452 enum "from" { 453 description 454 "The direction is uni-directional, from the 'to' 455 entity direction."; 456 } 457 enum "bidir" { 458 description 459 "The direction is bi-directional."; 460 } 461 } 462 description 463 "A type used to indicates whether a connectivity is 464 uni-directional, or bi-directional. If the relation is 465 uni-directional, the value of this type indicates the 466 direction."; 467 } // connectivity-direction 469 /* 470 * Groupings 471 */ 472 grouping service-function-node-augmentation { 473 description 474 "Augmenting a TE node to be network service and function 475 aware."; 476 container service-function { 477 description 478 "Containing attributes related to network services and 479 network functions"; 480 container connectivity-matrices { 481 description 482 "Connectivity relations between network services/functions 483 on a TE node, which can be either abstract or physical."; 484 reference 485 "ETSI GS NFV-SOL 006: Network Functions Virtualisation 486 (NFV) Release 3; Protocols and Data Models; 487 NFV descriptors based on YANG specification. 488 RFC7665: Service Function Chaining (SFC) Architecture."; 489 list connectivity-matrix { 490 key "id"; 491 description 492 "Represents the connectivity relations between network 493 services/functions on a TE node."; 494 leaf id { 495 type uint32; 496 description "Identifies the connectivity-matrix entry."; 497 } 499 container from { 500 description 501 "Reference to the source network service or 502 network function."; 503 leaf service-function-id { 504 type string; 505 description 506 "Reference to a network service or a network 507 function."; 508 } 509 leaf sf-connection-point-id { 510 type string; 511 description 512 "Reference to a connection point on a network 513 service or a network function."; 514 } 515 } // from 516 container to { 517 description 518 "Reference to the destination network service or 519 network function."; 520 leaf service-function-id { 521 type string; 522 description 523 "Reference to a network service or a network 524 function."; 525 } 526 leaf sf-connection-point-id { 527 type string; 528 description 529 "Reference to a connection point on a network 530 service or a network function."; 531 } 532 } // to 533 leaf enabled { 534 type boolean; 535 description 536 "'true' if this connectivity entry is enabled."; 537 } 538 leaf direction { 539 type connectivity-direction; 540 description 541 "Indicates whether this connectivity is 542 uni-directional, or bi-directional. If the 543 relation is uni-directional, the value of 544 this leaf indicates the direction."; 545 } 546 leaf virtual-link-id { 547 type string; 548 description 549 "Reference to a virtual link that models this 550 conectivity relation in the network function 551 model."; 552 } 553 } // connectivity-matrix 554 } // connectivity-matrices 556 container link-terminations { 557 description 558 "Connectivity relations between network services/functions 559 and link termination points on a TE node, which can be 560 either abstract or physical."; 561 reference 562 "ETSI GS NFV-SOL 006: Network Functions Virtualisation 563 (NFV) Release 3; Protocols and Data Models; 564 NFV descriptors based on YANG specification. 565 RFC7665: Service Function Chaining (SFC) Architecture."; 566 list link-termination { 567 key "id"; 568 description 569 "Each entry of the list represents the connectivity 570 relation between a network service/function and 571 a link termination point on a TE node."; 572 leaf id { 573 type uint32; 574 description "Identifies the termination entry."; 575 } 577 container from { 578 description 579 "Reference to the link termination point."; 580 } // from 581 container to { 582 description 583 "Reference to the network service or network 584 function."; 585 leaf service-function-id { 586 type string; 587 description 588 "Reference to a network service or a network 589 function."; 590 } 591 leaf sf-connection-point-id { 592 type string; 593 description 594 "Reference to a connection point on a network 595 service or a network function."; 596 } 597 } // to 598 leaf enabled { 599 type boolean; 600 description 601 "'true' if this connectivity entry is enabled."; 602 } 603 leaf direction { 604 type connectivity-direction; 605 description 606 "Indicates whether this connectivity is 607 uni-directional, or bi-directional. If the 608 relation is uni-directional, the value of 609 this leaf indicates the direction."; 610 } 611 } // link-termination 612 } 613 } 614 } // service-function-node-augmentation 616 grouping service-function-ttp-augmentation { 617 description 618 "Augmenting a tunnel termination point to be network service 619 aware."; 620 container service-function { 621 description 622 "Containing attributes related to network services and 623 network functions"; 624 container tunnel-terminations { 625 description 626 "Connectivity relations between network services/functions 627 and tunnel termination points on a TE node, which can be 628 either abstract or physical."; 629 reference 630 "ETSI GS NFV-SOL 006: Network Functions Virtualisation 631 (NFV) Release 3; Protocols and Data Models; 632 NFV descriptors based on YANG specification. 633 RFC7665: Service Function Chaining (SFC) Architecture."; 634 list tunnel-termination { 635 key "id"; 636 description 637 "Each entry of the list represents the connectivity 638 relation between a network service/function and 639 a tunnel termination point on a TE node."; 640 leaf id { 641 type uint32; 642 description "Identifies the termination entry."; 643 } 645 leaf service-function-id { 646 type string; 647 description 648 "Reference to a network service or a network 649 function."; 650 } 651 leaf sf-connection-point-id { 652 type string; 653 description 654 "Reference to a connection point on a network 655 service or a network function."; 656 } 657 leaf enabled { 658 type boolean; 659 description 660 "'true' if this connectivity entry is enabled."; 661 } 662 leaf direction { 663 type connectivity-direction; 664 description 665 "Indicates whether this connectivity is 666 uni-directional, or bi-directional. If the 667 relation is uni-directional, the value of 668 this leaf indicates the direction."; 669 } 670 } // link-termination 671 } 672 } 673 } // service-function-ttp-augmentation 675 grouping sf-topology-type { 676 description 677 "Identifies the SF aware TE topology type."; 678 container sf { 679 presence "Indidates that the TE topology is SF aware."; 680 description 681 "Its presence identifies that the TE topology is SF aware."; 682 } 683 } // sf-topology-type 685 /* 686 * Augmentations 687 */ 688 /* Augmentations to network-types/te-topology */ 689 augment "/nw:networks/nw:network/nw:network-types/" 690 + "tet:te-topology" { 691 description 692 "Defines the SF aware TE topology type."; 693 uses sf-topology-type; 694 } 696 /* Augmentations to te-node-attributes */ 697 augment "/nw:networks/nw:network/nw:node/tet:te/" 698 + "tet:te-node-attributes" { 699 description 700 "Parameters for SF aware TE topology."; 701 uses service-function-node-augmentation; 702 } 704 augment "/nw:networks/nw:network/nw:node/tet:te/" 705 + "tet:information-source-entry" { 706 description 707 "Parameters for SF aware TE topology."; 708 uses service-function-node-augmentation; 709 } 711 /* Augmentations to tunnel-termination-point */ 712 augment "/nw:networks/nw:network/nw:node/tet:te/" 713 + "tet:tunnel-termination-point" { 714 description 715 "Parameters for SF aware TE topology."; 716 uses service-function-ttp-augmentation; 717 } 719 /* Augmentations to connectivity-matrix */ 720 augment "/nw:networks/nw:network/nw:node/tet:te/" 721 + "tet:te-node-attributes/tet-sf:service-function/" 722 + "tet-sf:link-terminations/tet-sf:link-termination/" 723 + "tet-sf:from" { 724 description 725 "Add reference to the link termination point. 726 This portion cannot be shared with the state module."; 727 leaf tp-ref { 728 type leafref { 729 path "../../../../../../../nt:termination-point/" 730 + "nt:tp-id"; 731 } 732 description 733 "Reference to the link termination point."; 734 } 735 } 736 } 737 739 5. IANA Considerations 741 This document registers the following namespace URIs in the IETF XML 742 registry [RFC3688]: 744 -------------------------------------------------------------------- 745 URI: urn:ietf:params:xml:ns:yang:ietf-te-topology-sf 746 Registrant Contact: The IESG. 747 XML: N/A, the requested URI is an XML namespace. 748 -------------------------------------------------------------------- 750 -------------------------------------------------------------------- 751 URI: urn:ietf:params:xml:ns:yang:ietf-te-topology-sf-state 752 Registrant Contact: The IESG. 753 XML: N/A, the requested URI is an XML namespace. 754 -------------------------------------------------------------------- 756 This document registers the following YANG modules in the YANG Module 757 Names registry [RFC6020]: 759 -------------------------------------------------------------------- 760 name: ietf-te-topology-sf 761 namespace: urn:ietf:params:xml:ns:yang:ietf-te-topology-packet 762 prefix: tet-sf 763 reference: RFC XXXX 764 -------------------------------------------------------------------- 766 -------------------------------------------------------------------- 767 name: ietf-te-topology-sf-state 768 namespace: urn:ietf:params:xml:ns:yang:ietf-te-topology-packet-state 769 prefix: tet-sf-s 770 reference: RFC XXXX 771 -------------------------------------------------------------------- 773 6. Security Considerations 775 The YANG module specified in this document defines a schema for data 776 that is designed to be accessed via network management protocols such 777 as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer 778 is the secure transport layer, and the mandatory-to-implement secure 779 transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer 780 is HTTPS, and the mandatory-to-implement secure transport is TLS 781 [RFC8446]. 783 The Network Configuration Access Control Model (NACM) [RFC8341] 784 provides the means to restrict access for particular NETCONF or 785 RESTCONF users to a preconfigured subset of all available NETCONF or 786 RESTCONF protocol operations and content. 788 There are a number of data nodes defined in this YANG module that are 789 writable/creatable/deletable (i.e., config true, which is the 790 default). These data nodes may be considered sensitive or vulnerable 791 in some network environments. Write operations (e.g., edit-config) 792 to these data nodes without proper protection can have a negative 793 effect on network operations. These are the subtrees and data nodes 794 and their sensitivity/vulnerability: 796 /nw:networks/nw:network/nw:network-types/tet:te-topology/sf 797 This subtree specifies the topology type. Modifying the 798 configurations can make topology type invalid and cause 799 interruption to the specified SF Aware TE topology and the related 800 SF Aware TE topologies. 802 /nw:networks/nw:network/nw:node/tet:te/tet:te-node-attributes/ 803 service-function 804 This subtree specifies the configurations of service functions in 805 SF Aware TE nodes. Modifying the configurations in this subtree 806 can change the configurations of service functions in the 807 specified node, causing these service functions disabled or 808 misbehaving in the specified node. 810 /nw:networks/nw:network/nw:node/tet:te/tet:tunnel-termination-point/ 811 service-function 812 This subtree specifies the configurations of service functions on 813 a tunnel-termination-point in SF Aware TE nodes. Modifying the 814 configurations in this subtree can change the configurations of 815 service functions on the spcified tunnel-termination-point in the 816 specified node, causing these service functions disabled or 817 misbehaving. 819 Some of the readable data nodes in this YANG module may be considered 820 sensitive or vulnerable in some network environments. It is thus 821 important to control read access (e.g., via get, get-config, or 822 notification) to these data nodes. These are the subtrees and data 823 nodes and their sensitivity/vulnerability: 825 /nw:networks/nw:network/nw:network-types/tet:te-topology/sf 826 Unauthorized access to this subtree can disclose the SF Aware TE 827 topology type. 829 /nw:networks/nw:network/nw:node/tet:te/tet:te-node-attributes/ 830 service-function 831 Unauthorized access to this subtree can disclose the operational 832 state information of the service functions in the specified SF 833 Aware TE node. 835 /nw:networks/nw:network/nw:node/tet:te/tet:information-source-entry/ 836 service-function 837 Unauthorized access to this subtree can disclose the operational 838 state information of the service functions in the specified SF 839 Aware TE node. 841 /nw:networks/nw:network/nw:node/tet:te/tet:tunnel-termination-point/ 842 service-function 843 Unauthorized access to this subtree can disclose the operational 844 state information of the service functions on the specified 845 tunnel-termination-point in the specified SF Aware TE node. 847 7. References 849 7.1. Normative References 851 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 852 Requirement Levels", BCP 14, RFC 2119, 853 DOI 10.17487/RFC2119, March 1997, 854 . 856 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 857 DOI 10.17487/RFC3688, January 2004, 858 . 860 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 861 the Network Configuration Protocol (NETCONF)", RFC 6020, 862 DOI 10.17487/RFC6020, October 2010, 863 . 865 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 866 and A. Bierman, Ed., "Network Configuration Protocol 867 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 868 . 870 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 871 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 872 . 874 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 875 RFC 6991, DOI 10.17487/RFC6991, July 2013, 876 . 878 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 879 RFC 7950, DOI 10.17487/RFC7950, August 2016, 880 . 882 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 883 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 884 . 886 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 887 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 888 May 2017, . 890 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 891 Access Control Model", STD 91, RFC 8341, 892 DOI 10.17487/RFC8341, March 2018, 893 . 895 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 896 and R. Wilton, "Network Management Datastore Architecture 897 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 898 . 900 [RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N., 901 Ananthakrishnan, H., and X. Liu, "A YANG Data Model for 902 Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March 903 2018, . 905 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 906 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 907 . 909 [RFC8529] Berger, L., Hopps, C., Lindem, A., Bogdanovic, D., and X. 910 Liu, "YANG Data Model for Network Instances", RFC 8529, 911 DOI 10.17487/RFC8529, March 2019, 912 . 914 [RFC8530] Berger, L., Hopps, C., Lindem, A., Bogdanovic, D., and X. 915 Liu, "YANG Model for Logical Network Elements", RFC 8530, 916 DOI 10.17487/RFC8530, March 2019, 917 . 919 [RFC8795] Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and 920 O. Gonzalez de Dios, "YANG Data Model for Traffic 921 Engineering (TE) Topologies", RFC 8795, 922 DOI 10.17487/RFC8795, August 2020, 923 . 925 [I-D.ietf-teas-yang-te] 926 Saad, T., Gandhi, R., Liu, X., Beeram, V., and I. Bryskin, 927 "A YANG Data Model for Traffic Engineering Tunnels, Label 928 Switched Paths and Interfaces", draft-ietf-teas-yang-te-25 929 (work in progress), July 2020. 931 [I-D.ietf-teas-actn-vn-yang] 932 Lee, Y., Dhody, D., Ceccarelli, D., Bryskin, I., and B. 933 Yoon, "A YANG Data Model for VN Operation", draft-ietf- 934 teas-actn-vn-yang-10 (work in progress), November 2020. 936 [ETSI-NFV-MAN] 937 ETSI, "Network Functions Virtualisation (NFV) Release 3; 938 Protocols and Data Models; NFV descriptors based on YANG 939 specification", ETSI GS NFV-SOL 006 V3.3.1, August 2020, 940 . 943 [ETSI-NFV-TERM] 944 ETSI, "Network Functions Virtualisation (NFV); Terminology 945 for Main Concepts in NFV", ETSI GR NFV 003 V1.5.1, January 946 2020, . 949 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 950 Address Translator (Traditional NAT)", RFC 3022, 951 DOI 10.17487/RFC3022, January 2001, 952 . 954 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 955 NAT64: Network Address and Protocol Translation from IPv6 956 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, 957 April 2011, . 959 [RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for 960 Abstraction and Control of TE Networks (ACTN)", RFC 8453, 961 DOI 10.17487/RFC8453, August 2018, 962 . 964 [RFC8459] Dolson, D., Homma, S., Lopez, D., and M. Boucadair, 965 "Hierarchical Service Function Chaining (hSFC)", RFC 8459, 966 DOI 10.17487/RFC8459, September 2018, 967 . 969 [_3GPP.28.801] 970 3GPP, "Study on management and orchestration of network 971 slicing for next generation network", 3GPP TR 28.801 972 V2.0.0, September 2017, 973 . 975 7.2. Informative References 977 [RFC7498] Quinn, P., Ed. and T. Nadeau, Ed., "Problem Statement for 978 Service Function Chaining", RFC 7498, 979 DOI 10.17487/RFC7498, April 2015, 980 . 982 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 983 Chaining (SFC) Architecture", RFC 7665, 984 DOI 10.17487/RFC7665, October 2015, 985 . 987 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 988 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 989 . 991 [I-D.defoy-netslices-3gpp-network-slicing] 992 Foy, X. and A. Rahman, "Network Slicing - 3GPP Use Case", 993 draft-defoy-netslices-3gpp-network-slicing-02 (work in 994 progress), October 2017. 996 Appendix A. Companion YANG Model for Non-NMDA Compliant Implementations 998 The YANG module ietf-te-topology-sf defined in this document is 999 designed to be used in conjunction with implementations that support 1000 the Network Management Datastore Architecture (NMDA) defined in 1001 [RFC8342]. In order to allow implementations to use the model even 1002 in cases when NMDA is not supported, the following companion module, 1003 ietf-te-topology-sf-state, is defined as state model, which mirrors 1004 the module ietf-te-topology-sf defined earlier in this document. 1005 However, all data nodes in the companion module are non-configurable, 1006 to represent the applied configuration or the derived operational 1007 states. 1009 The companion module, ietf-te-topology-sf-state, is redundant and 1010 SHOULD NOT be supported by implementations that support NMDA. 1012 As the structure of the companion module mirrors that of the 1013 coorespinding NMDA model, the YANG tree of the companion module is 1014 not depicted separately. 1016 A.1. SF Aware TE Topology State Module 1018 file "ietf-te-topology-sf-state@2021-02-15.yang" 1019 module ietf-te-topology-sf-state { 1020 yang-version 1.1; 1021 namespace "urn:ietf:params:xml:ns:yang:ietf-te-topology-sf-state"; 1023 prefix "tet-sf-s"; 1025 import ietf-te-topology-sf { 1026 prefix "tet-sf"; 1027 reference 1028 "RFC XXXX: SF Aware TE Topology YANG Model"; 1029 } 1031 import ietf-network-state { 1032 prefix "nw-s"; 1033 reference 1034 "RFC 8345: A YANG Data Model for Network Topologies"; 1035 } 1037 import ietf-network-topology-state { 1038 prefix "nt-s"; 1039 reference 1040 "RFC 8345: A YANG Data Model for Network Topologies"; 1041 } 1042 import ietf-te-topology-state { 1043 prefix "tet-s"; 1044 reference 1045 "RFC 8795: YANG Data Model for Traffic Engineering (TE) 1046 Topologies"; 1047 } 1049 organization 1050 "Traffic Engineering Architecture and Signaling (TEAS) 1051 Working Group"; 1053 contact 1054 "WG Web: 1055 WG List: 1057 Editors: Igor Bryskin 1058 1060 Xufeng Liu 1061 "; 1063 description 1064 "Network service and function aware aware TE topology operational 1065 state model for non-NMDA compliant implementations. 1067 Copyright (c) 2021 IETF Trust and the persons identified as 1068 authors of the code. All rights reserved. 1070 Redistribution and use in source and binary forms, with or 1071 without modification, is permitted pursuant to, and subject to 1072 the license terms contained in, the Simplified BSD License set 1073 forth in Section 4.c of the IETF Trust's Legal Provisions 1074 Relating to IETF Documents 1075 (http://trustee.ietf.org/license-info). 1077 This version of this YANG module is part of RFC XXXX; see the 1078 RFC itself for full legal notices."; 1080 revision 2021-02-15 { 1081 description "Initial revision"; 1082 reference "RFC XXXX: SF Aware TE Topology YANG Model"; 1083 } 1085 /* 1086 * Augmentations 1087 */ 1088 /* Augmentations to network-types/te-topology */ 1089 augment "/nw-s:networks/nw-s:network/nw-s:network-types/" 1090 + "tet-s:te-topology" { 1091 description 1092 "Defines the SF aware TE topology type."; 1093 uses tet-sf:sf-topology-type; 1094 } 1096 /* Augmentations to connectivity-matrix */ 1097 augment "/nw-s:networks/nw-s:network/nw-s:node/tet-s:te/" 1098 + "tet-s:te-node-attributes" { 1099 description 1100 "Parameters for SF aware TE topology."; 1101 uses tet-sf:service-function-node-augmentation; 1102 } 1104 augment "/nw-s:networks/nw-s:network/nw-s:node/tet-s:te/" 1105 + "tet-s:information-source-entry" { 1106 description 1107 "Parameters for SF aware TE topology."; 1108 uses tet-sf:service-function-node-augmentation; 1109 } 1111 /* Augmentations to tunnel-termination-point */ 1112 augment "/nw-s:networks/nw-s:network/nw-s:node/tet-s:te/" 1113 + "tet-s:tunnel-termination-point" { 1114 description 1115 "Parameters for SF aware TE topology."; 1116 uses tet-sf:service-function-ttp-augmentation; 1117 } 1119 /* Augmentations to connectivity-matrix */ 1120 augment "/nw-s:networks/nw-s:network/nw-s:node/tet-s:te/" 1121 + "tet-s:te-node-attributes/tet-sf-s:service-function/" 1122 + "tet-sf-s:link-terminations/tet-sf-s:link-termination/" 1123 + "tet-sf-s:from" { 1124 description 1125 "Add reference to the link termination point. 1126 This portion cannot be shared with the state module."; 1127 leaf tp-ref { 1128 type leafref { 1129 path "../../../../../../../nt-s:termination-point/" 1130 + "nt-s:tp-id"; 1131 } 1132 description 1133 "Reference to the link termination point."; 1134 } 1135 } 1136 } 1137 1139 Appendix B. Data Examples 1141 B.1. A Topology with Multiple Connected Network Functions 1143 Node-1 1144 +----o--o--------------------------o-------+ 1145 | | | | | 1146 | \__/ \__ | 1147 | *\/ TTP-1 * * * * * * * * * *\/* | 1148 LTP-4 |* * * * TTP-2 * | LTP-1 1149 o------------*-----------------------------o 1150 | * * | 1151 LTP-3 |* * * * * *| LTP-2 1152 o--- -----o 1153 | \ / | 1154 | \ / | 1155 | \ CP01 CP02/ | 1156 | +----o--------------------------o------+ | 1157 | | VL1| VL4| | | 1158 | | |CP11 |CP33 | | 1159 | | +-o--+ +----+ +-o--+ | | 1160 | | |VNF1| |VNF2| |VNF3| | | 1161 | | +-o-o+ VL2 +--o-+ VL2 +-o-o+ | | 1162 | |CP12| |\----------/ \---------/| |CP32| | 1163 | | | |CP13 CP21 CP31| | | | 1164 | | | | VL2 | | | | 1165 | | | +------------------------+ | | | 1166 | | +----------------------------+ | | 1167 | | VL3 | | 1168 | | Network Service 1 | | 1169 | +--------------------------------------+ | 1170 +------------------------------------------+ 1172 The configuration instance data for Node-1 in the above figure could 1173 be as follows: 1175 { 1176 "networks": { 1177 "network": [ 1178 { 1179 "network-types": { 1180 "te-topology": { 1181 "sf": {} 1182 } 1183 }, 1184 "network-id": "network-sf-aware", 1185 "provider-id": 201, 1186 "client-id": 300, 1187 "te-topology-id": "te-topology:network-sf-aware", 1188 "node": [ 1189 { 1190 "node-id": "Node-1", 1191 "te-node-id": "2.0.1.1", 1192 "te": { 1193 "te-node-attributes": { 1194 "domain-id": 1, 1195 "is-abstract": [null], 1196 "connectivity-matrices": { 1197 }, 1198 "service-function": { 1199 "connectivity-matrices": { 1200 "connectivity-matrix": [ 1201 { 1202 "id": 10, 1203 "from": { 1204 "service-function-id": "Network Service 1", 1205 "sf-connection-point-id": "CP01" 1206 }, 1207 "to": { 1208 "service-function-id": "VNF1", 1209 "sf-connection-point-id": "CP11" 1210 } 1211 "direction": "bidir", 1212 "virtual-link-id": "VL1" 1213 }, 1214 { 1215 "id": 13, 1216 "from": { 1217 "service-function-id": "VNF1", 1218 "sf-connection-point-id": "CP12" 1219 }, 1220 "to": { 1221 "service-function-id": "VNF3", 1222 "sf-connection-point-id": "CP32" 1223 } 1224 "direction": "bidir", 1225 "virtual-link-id": "VL3" 1226 }, 1227 { 1228 "id": 12, 1229 "from": { 1230 "service-function-id": "VNF1", 1231 "sf-connection-point-id": "CP13" 1232 }, 1233 "to": { 1234 "service-function-id": "VNF2", 1235 "sf-connection-point-id": "CP21" 1236 } 1237 "direction": "bidir", 1238 "virtual-link-id": "VL2" 1239 }, 1240 { 1241 "id": 23, 1242 "from": { 1243 "service-function-id": "VNF2", 1244 "sf-connection-point-id": "CP21" 1245 }, 1246 "to": { 1247 "service-function-id": "VNF3" 1248 "sf-connection-point-id": "CP31" 1249 } 1250 "direction": "bidir", 1251 "virtual-link-id": "VL2" 1252 }, 1253 { 1254 "id": 30, 1255 "from": { 1256 "service-function-id": "Network Service 1", 1257 "sf-connection-point-id": "CP02" 1258 }, 1259 "to": { 1260 "service-function-id": "VNF3", 1261 "sf-connection-point-id": "CP33" 1262 } 1263 "direction": "bidir", 1264 "virtual-link-id": "VL4" 1265 } 1266 ] 1267 }, 1268 "link-terminations": { 1269 "link-termination": [ 1270 { 1271 "id": 2, 1272 "from": { 1273 "tp-ref": "LTP-2" 1274 }, 1275 "to": { 1276 "service-function-id": "Network Service 1", 1277 "sf-connection-point-id": "CP02" 1278 } 1279 "direction": "bidir" 1280 }, 1281 { 1282 "id": 3, 1283 "from": { 1284 "tp-ref": "LTP-3" 1285 }, 1286 "to": { 1287 "service-function-id": "Network Service 1", 1288 "sf-connection-point-id": "CP01" 1289 } 1290 "direction": "bidir" 1291 } 1292 ] 1293 } 1294 } 1295 } 1296 "tunnel-termination-point": [ 1297 { 1298 "tunnel-tp-id": 10001, 1299 "name": "TTP-1", 1300 "service-function-terminations": { 1301 } 1302 }, 1303 { 1304 "tunnel-tp-id": 10002, 1305 "name": "TTP-2", 1306 "service-function-terminations": { 1307 } 1308 } 1309 ] 1310 }, 1311 "termination-point": [ 1312 { 1313 "tp-id": "LTP-1", 1314 "te-tp-id": 10001 1315 "te": { 1316 "interface-switching-capability": [ 1317 { 1318 "switching-capability": "switching-l2sc", 1319 "encoding": "lsp-encoding-ethernet" 1320 } 1321 ] 1322 } 1323 }, 1324 { 1325 "tp-id": "LTP-2", 1326 "te-tp-id": 10002 1327 "te": { 1328 "interface-switching-capability": [ 1329 { 1330 "switching-capability": "switching-l2sc", 1331 "encoding": "lsp-encoding-ethernet" 1332 } 1333 ] 1334 } 1335 }, 1336 { 1337 "tp-id": "LTP-3", 1338 "te-tp-id": 10003 1339 "te": { 1340 "interface-switching-capability": [ 1341 { 1342 "switching-capability": "switching-l2sc", 1343 "encoding": "lsp-encoding-ethernet" 1344 } 1345 ] 1346 } 1347 }, 1348 { 1349 "tp-id": "LTP-4", 1350 "te-tp-id": 10004 1351 "te": { 1352 "interface-switching-capability": [ 1353 { 1354 "switching-capability": "switching-l2sc", 1355 "encoding": "lsp-encoding-ethernet" 1356 } 1357 ] 1358 } 1359 } 1360 ] 1361 } 1362 ] 1363 } 1364 ] 1365 } 1366 } 1368 B.2. A Topology with an Encapsulated Network Service 1370 In this example, a network service consists of several inter- 1371 connected network functions (NFs), and is represented by this model 1372 as an encapsulated opaque object without the details between its 1373 internals. 1375 Node-1 1376 +----o--o--------------------------o-------+ 1377 | | | | | 1378 | \__/ \__ | 1379 | *\/ TTP-1 * * * * * * * * * *\/* | 1380 LTP-4 |* * * * TTP-2 * | LTP-1 1381 o------------*-----------------------------o 1382 | * * | 1383 LTP-3 |* * * * * *| LTP-2 1384 o--- -----o 1385 | \ / | 1386 | \ / | 1387 | \ CP01 CP02/ | 1388 | +----o--------------------------o------+ | 1389 | | | | 1390 | | Network Service 1 | | 1391 | +--------------------------------------+ | 1392 +------------------------------------------+ 1394 The configuration instance data for Node-1 in the above figure could 1395 be as follows: 1397 { 1398 "networks": { 1399 "network": [ 1400 { 1401 "network-types": { 1402 "te-topology": { 1403 "sf": {} 1404 } 1405 }, 1406 "network-id": "network-sf-aware", 1407 "provider-id": 201, 1408 "client-id": 300, 1409 "te-topology-id": "te-topology:network-sf-aware", 1410 "node": [ 1411 { 1412 "node-id": "Node-1", 1413 "te-node-id": "2.0.1.1", 1414 "te": { 1415 "te-node-attributes": { 1416 "domain-id": 1, 1417 "is-abstract": [null], 1418 "connectivity-matrices": { 1419 }, 1420 "service-function": { 1421 "connectivity-matrices": { 1422 }, 1423 "link-terminations": { 1424 "link-termination": [ 1425 { 1426 "id": 2, 1427 "from": { 1428 "tp-ref": "LTP-2" 1429 }, 1430 "to": { 1431 "service-function-id": "Network Service 1", 1432 "sf-connection-point-id": "CP02" 1433 } 1434 "direction": "bidir" 1435 }, 1436 { 1437 "id": 3, 1438 "from": { 1439 "tp-ref": "LTP-3" 1440 }, 1441 "to": { 1442 "service-function-id": "Network Service 1", 1443 "sf-connection-point-id": "CP01" 1444 } 1445 "direction": "bidir" 1446 } 1447 ] 1448 } 1449 } 1450 } 1451 "tunnel-termination-point": [ 1452 { 1453 "tunnel-tp-id": 10001, 1454 "name": "TTP-1", 1455 "service-function-terminations": { 1456 } 1457 }, 1458 { 1459 "tunnel-tp-id": 10002, 1460 "name": "TTP-2", 1461 "service-function-terminations": { 1462 } 1463 } 1464 ] 1465 }, 1466 "termination-point": [ 1467 { 1468 "tp-id": "LTP-1", 1469 "te-tp-id": 10001 1470 "te": { 1471 "interface-switching-capability": [ 1472 { 1473 "switching-capability": "switching-l2sc", 1474 "encoding": "lsp-encoding-ethernet" 1475 } 1476 ] 1477 } 1478 }, 1479 { 1480 "tp-id": "LTP-2", 1481 "te-tp-id": 10002 1482 "te": { 1483 "interface-switching-capability": [ 1484 { 1485 "switching-capability": "switching-l2sc", 1486 "encoding": "lsp-encoding-ethernet" 1487 } 1488 ] 1489 } 1490 }, 1491 { 1492 "tp-id": "LTP-3", 1493 "te-tp-id": 10003 1494 "te": { 1495 "interface-switching-capability": [ 1496 { 1497 "switching-capability": "switching-l2sc", 1498 "encoding": "lsp-encoding-ethernet" 1499 } 1500 ] 1501 } 1502 }, 1503 { 1504 "tp-id": "LTP-4", 1505 "te-tp-id": 10004 1506 "te": { 1507 "interface-switching-capability": [ 1508 { 1509 "switching-capability": "switching-l2sc", 1510 "encoding": "lsp-encoding-ethernet" 1511 } 1512 ] 1513 } 1514 } 1515 ] 1516 } 1517 ] 1518 } 1520 ] 1521 } 1522 } 1524 Appendix C. Use Cases for SF Aware Topology Models 1526 C.1. Exporting SF/NF Information to Network Clients and Other Network 1527 SDN Controllers 1529 In the context of Service Function Chain (SFC) orchestration one 1530 existing problem is that there is no way to formally describe a 1531 Service or Network Function in a standard way (recognizable/ 1532 understood by a third party) as a resource of a network topology 1533 node. 1535 One implication of this is that there is no way for the orchestrator 1536 to give a network client even a ball-park idea as to which network's 1537 SFs/NFs are available for the client's use/control and where they are 1538 located in the network even in terms of abstract topologies/virtual 1539 networks configured and managed specifically for the client. 1540 Consequently, the client has no say on how the SFCs provided for the 1541 client by the network should be set up and managed (which SFs are to 1542 be used and how they should be chained together, optimized, 1543 manipulated, protected, etc.). 1545 Likewise, there is no way for the orchestrator to export SF/NF 1546 information to other network controllers. The SFC orchestrator may 1547 serve, for example, a higher level controller (such as Network 1548 Slicing Orchestrator), with the latter wanting at least some level of 1549 control as to which SFs/NFs it wants on its SFCs and how the Service 1550 Function Paths (SFPs) are to be routed and provisioned, especially, 1551 if it uses services of more than one SFC orchestrator. 1553 The issue of exporting of SF/NF information could be addressed by 1554 defining a model, in which formally described/recognizable SF/NF 1555 instances are presented as topological elements, for example, hosted 1556 by TE, L3 or L2 topology nodes (see Figure 1). The model could 1557 describe whether, how and at what costs the SFs/NFs hosted by a given 1558 node could be chained together, how these intra-node SFCs could be 1559 connected to the node's Service Function Forwarders (SFFs, entities 1560 dealing with SFC NSHs and metadata), and how the SFFs could be 1561 connected to the node's Tunnel and Link Termination Points (TTPs and 1562 LTPs) to chain the intra-node SFCs across the network topology. 1564 The figure is available in the PDF format. 1566 Figure 1: SF/NF aware TE topology 1568 C.2. Flat End-to-end SFCs Managed on Multi-domain Networks 1570 SFCs may span multiple administrative domains, each of which 1571 controlled by a separate SFC controller. The usual solution for such 1572 a scenario is the Hierarchical SFCs (H-SFCs) [RFC8459], in which the 1573 higher level orchestrator controls only SFs located on domain border 1574 nodes. Said higher level SFs are chained together into higher level 1575 SFCs via lower level (intra-domain) SFCs provisioned and controlled 1576 independently by respective domain controllers. The decision as to 1577 which higher level SFCs are connected to which lower level SFCs is 1578 driven by packet re-classification every time the packet enters a 1579 given domain. Said packet re-classification is a very time-consuming 1580 operation. Furthermore, the independent nature of higher and lower 1581 level SFC control is prone to configuration errors, which may lead to 1582 long lasting loops and congestions. It is highly desirable to be 1583 able to set up and manage SFCs spanning multiple domains in a flat 1584 way as far as the data plane is concerned (i.e. with a single packet 1585 classification at the ingress into the multi-domain network but 1586 without re-classifications on domain ingress nodes). 1588 One way to achieve this is to have the domain controllers expose SF/ 1589 NF- aware topologies, and have the higher level orchestrator operate 1590 on the network-wide topology, the product of merging of the 1591 topologies catered by the domain controllers. This is similar in 1592 spirit to setting up, coordinating and managing the transport 1593 connectivity (TE tunnels) on a multi-domain multi-vendor transport 1594 network. 1596 C.3. Managing SFCs with TE Constraints 1598 Some SFCs require per SFC link/element and end-to-end TE constrains 1599 (bandwidth, delay/jitter, fate sharing/diversity. etc.). Said 1600 constraints could be ensured via carrying SFPs inside overlays that 1601 are traffic engineered with the constrains in mind. A good analogy 1602 would be orchestrating delay constrained L3 VPNs. One way to support 1603 such L3 VPNs is to carry MPLS LSPs interconnecting per-VPN VRFs 1604 inside delay constrained TE tunnels interconnecting the PEs hosting 1605 the VRFs. 1607 The figure is available in the PDF format. 1609 Figure 2: L3 VPN with delay constraints 1611 Planning, computing and provisioning of TE overlays to constrain 1612 arbitrary SFCs, especially those that span multiple administrative 1613 domains with each domain controlled by a separate controller, is a 1614 very difficult challenge. Currently it is addressed by pre- 1615 provisioning on the network of multiple TE tunnels with various TE 1616 characteristics, and "nailing down" SFs/NFs to "strategic" locations 1617 (e.g. nodes terminating many of such tunnels) in a hope that an 1618 adequate set of tunnels could be found to carry the SFP of a given 1619 TE-constrained SFC. Such an approach is especially awkward in the 1620 case when some or all of the SFs/NFs are VNFs (i.e. could be 1621 instantiated at multiple network locations). 1623 SF/NF-aware TE topology model in combination with TE tunnel model 1624 will allow for the network orchestrator (or a client controller) to 1625 compute, set up and manipulate the TE overlays in the form of TE 1626 tunnel chains (see Figure 3). 1628 Said chains could be duel-optimized compromising on optimal SF/NF 1629 locations with optimal TE tunnels interconnecting them. The TE 1630 tunnel chains (carrying multiple similarly constrained SFPs) could be 1631 adequately constrained both at individual TE tunnel level and at the 1632 chain end-to-end level. 1634 The figure is available in the PDF format. 1636 Figure 3: SFC with TE constraints 1638 C.4. SFC Protection and Load Balancing 1640 Currently the combination of TE topology & tunnel models offers to a 1641 network controller various capabilities to recover an individual TE 1642 tunnel from network failures occurred on one or more network links or 1643 transit nodes on the TE paths taken by the TE tunnel's connection(s). 1644 However, there is no simple way to recover a TE tunnel from a failure 1645 affecting its source or destination node. SF/NF-aware TE topology 1646 model can decouple the association of a given SF/NF with its location 1647 on the network topology by presenting multiple, identifiable as 1648 mutually substitutable SFs/NFs hosted by different TE topology nodes. 1649 So, for example, if it is detected that a given TE tunnel destination 1650 node is malfunctioning or has gone out of service, the TE tunnel 1651 could be re-routed to terminate on a different node hosting 1652 functionally the same SFs/NFs as ones hosted by the failed node (see 1653 Figures 6). 1655 This is in line with the ACTN edge migration and function mobility 1656 concepts [RFC8453]. It is important to note that the described 1657 strategy works much better for the stateless SFs/NFs. This is 1658 because getting the alternative stateful SFs/NFs into the same 1659 respective states as the current (i.e. active, affected by failure) 1660 are is a very difficult challenge. 1662 The figure is available in the PDF format. 1664 Figure 4: SFC recovery: SF2 on node NE1 fails 1666 At the SFC level the SF/NF-aware TE topology model can offer SFC 1667 dynamic restoration capabilities against failed/malfunctioning SFs/ 1668 NFs by identifying and provisioning detours to a TE tunnel chain, so 1669 that it starts carrying the SFC's SFPs towards healthy SFs/NFs that 1670 are functionally the same as the failed ones. Furthermore, multiple 1671 parallel TE tunnel chains could be pre-provisioned for the purpose of 1672 SFC load balancing and end-to-end protection. In the latter case 1673 said parallel TE tunnel chains could be placed to be sufficiently 1674 disjoint from each other. 1676 The figure is available in the PDF format. 1678 Figure 5: SFC recovery: SFC SF1-SF2-SF6 is recovered after SF2 on 1679 node N1 has failed 1681 The figure is available in the PDF format. 1683 Figure 6: SFC recovery: SFC SF1-SF2-SF6 is recovered after node N1 1684 has failed 1686 C.5. Network Clock Synchronization 1688 Many current and future network applications (including 5g and IoT 1689 applications) require very accurate time services (PTP level, ns 1690 resolution). One way to implement the adequate network clock 1691 synchronization for such services is via describing network clocks as 1692 NFs on an NF-aware TE topology optimized to have best possible delay 1693 variation characteristics. Because such a topology will contain 1694 delay/delay variation metrics of topology links and node cross- 1695 connects, as well as costs in terms of delay/delay variation of 1696 connecting clocks to hosting them node link and tunnel termination 1697 points, it will be possible to dynamically select and provision bi- 1698 directional time-constrained deterministic paths or trees connecting 1699 clocks (e.g. grand master and boundary clocks) for the purpose of 1700 exchange of clock synchronization information. Note that network 1701 clock aware TE topologies separately provided by domain controllers 1702 will enable multi-domain network orchestrator to set up and 1703 manipulate the clock synchronization paths/trees spanning multiple 1704 network domains. 1706 C.6. Client - Provider Network Slicing Interface 1708 3GPP defines network slice as "a set of network functions and the 1709 resources for these network functions which are arranged and 1710 configured, forming a complete logical network to meet certain 1711 network characteristics" [I-D.defoy-netslices-3gpp-network-slicing] 1712 [_3GPP.28.801]. Network slice could be also defined as a logical 1713 partition of a provider's network that is owned and managed by a 1714 tenant. SF/NF-aware TE topology model has a potential to support a 1715 very important interface between network slicing clients and 1716 providers because, on the one hand, the model can describe 1717 holistically and hierarchically the client's requirements and 1718 preferences with respect to a network slice functional, topological 1719 and traffic engineering aspects, as well as of the degree of resource 1720 separation/ sharing between the slices, thus allowing for the client 1721 (up to agreed upon extent) to dynamically (re-)configure the slice or 1722 (re-)schedule said (re-)configurations in time, while, on the other 1723 hand, allowing for the provider to convey to the client the slice's 1724 operational state information and telemetry the client has expressed 1725 interest in. 1727 C.7. Dynamic Assignment of Regenerators for L0 Services 1729 On large optical networks, some of provided to their clients L0 1730 services could not be provisioned as single OCh trails, rather, as 1731 chains of such trails interconnected via regenerators, such as 3R 1732 regenerators. Current practice of the provisioning of such services 1733 requires configuration of explicit paths (EROs) describing identity 1734 and location of regenerators to be used. A solution is highly 1735 desirable that could: 1737 o Identify such services based, for example, on optical impairment 1738 computations; 1740 o Assign adequate for the services regenerators dynamically out of 1741 the regenerators that are grouped together in pools and 1742 strategically scattered over the network topology nodes; 1744 o Compute and provision supporting the services chains of optical 1745 trails interconnected via so selected regenerators, optimizing the 1746 chains to use minimal number of regenerators, their optimal 1747 locations, as well as optimality of optical paths interconnecting 1748 them; 1750 o Ensure recovery of such chains from any failures that could happen 1751 on links, nodes or regenerators along the chain path. 1753 NF-aware TE topology model (in this case L1 NF-aware L0 topology 1754 model) is just the model that could provide a network controller (or 1755 even a client controller operating on abstract NF-aware topologies 1756 provided by the network) to realize described above computations and 1757 orchestrate the service provisioning and network failure recovery 1758 operations (see Figure 7). 1760 The figure is available in the PDF format. 1762 Figure 7: Optical tunnel as TE-constrained SFC of 3R regenerators. 1763 Red trail (not regenerated) is not optically reachable, but blue 1764 trail (twice regenerated) is 1766 C.8. Dynamic Assignment of OAM Functions for L1 Services 1768 OAM functionality is normally managed by configuring and manipulating 1769 TCM/MEP functions on network ports terminating connections or their 1770 segments over which OAM operations, such as performance monitoring, 1771 are required to be performed. In some layer networks (e.g. 1772 Ethernet) said TCMs/MEPs could be configured on any network ports. 1773 In others (e.g. OTN/ODUk) the TCMs/MEPs could be configured on some 1774 (but not all network ports) due to the fact that the OAM 1775 functionality (i.e. recognizing and processing of OAM messages, 1776 supporting OAM protocols and FSMs) requires in these layer networks 1777 certain support in the data plane, which is not available on all 1778 network nodes. This makes TCMs/MEPs good candidates to be modeled as 1779 NFs. This also makes TCM/MEP aware topology model a good basis for 1780 placing dynamically an ODUk connection to pass through optimal OAM 1781 locations without mandating the client to specify said locations 1782 explicitly. 1784 The figure is available in the PDF format. 1786 Figure 8: Compute/storage resource aware topology 1788 C.9. SFC Abstraction and Scaling 1790 SF/NF-aware topology may contain information on native SFs/NFs (i.e. 1791 SFs/NFs as known to the provider itself) and/or abstract SFs/NFs 1792 (i.e. logical/macro SFs/NFs representing one or more SFCs each made 1793 of native and/or lower level abstract SFs/NFs). As in the case of 1794 abstracting topology nodes, abstracting SFs/NFs is hierarchical in 1795 nature - the higher level of SF/NF-aware topology, the "larger" 1796 abstract SFs/NFs are, i.e. the larger data plane SFCs they represent. 1797 This allows for managing large scale networks with great number of 1798 SFs/NFs (such as Data Center interconnects) in a hierarchical, highly 1799 scalable manner resulting in control of very large number of flat in 1800 the data plane SFCs that span multiple domains. 1802 C.10. Dynamic Compute/VM/Storage Resource Assignment 1804 In a distributed data center network, virtual machines for compute 1805 resources may need to be dynamically re-allocated due to various 1806 reasons such as DCI network failure, compute resource load balancing, 1807 etc. In many cases, the DCI connectivity for the source and the 1808 destination is not predetermined. There may be a pool of sources and 1809 a pool of destination data centers associated with re-allocation of 1810 compute/VM/storage resources. There is no good mechanism to date to 1811 capture this dynamicity nature of compute/VM/storage resource 1812 reallocation. Generic Compute/VM/Storage resources can be described 1813 and announced as a SF, where a DC hosting these resources can be 1814 modeled as an abstract node. Topology interconnecting these abstract 1815 nodes (DCs) in general is of multi-domain nature. Thus, SF-aware 1816 topology model can facilitate a joint optimization of TE network 1817 resources and Compute/VM/Storage resources and solve Compute/VM/ 1818 Storage mobility problem within and between DCs (see Figure 8). 1820 C.11. Application-aware Resource Operations and Management 1822 Application stratum is the functional grouping which encompasses 1823 application resources and the control and management of these 1824 resources. These application resources are used along with network 1825 services to provide an application service to clients/end-users. 1826 Application resources are non-network resources critical to achieving 1827 the application service functionality. Examples of application 1828 resources include: caches, mirrors, application specific servers, 1829 content, large data sets, and computing power. Application service 1830 is a networked application offered to a variety of clients (e.g., 1831 server backup, VM migration, video cache, virtual network on-demand, 1832 5G network slicing, etc.). The application servers that host these 1833 application resources can be modeled as an abstract node. There may 1834 be a variety of server types depending on the resources they host. 1835 Figure 9 shows one example application aware topology for video cache 1836 server distribution. 1838 The figure is available in the PDF format. 1840 Figure 9: Application aware topology 1842 C.12. Interconnection between Service Functions/Termination Points in 1843 uCPE 1845 Universal Customer Premises Equipment (uCPE) enables Virtual Network 1846 Functions (VNFs) at the client site. uCPE is based on the Network 1847 Function Virtualization Infrastructure (NFVI) - generally Linux 1848 distribution with integrated software that offers: 1850 o Virtual Switch functionality 1852 o Full virtualization/containerization solution 1854 o Data path acceleration tool-kits 1856 o Management layer 1858 The sf-aware-topo-model placed in the controller controls via the 1859 management layer of uCPE the interconnection between: 1861 o virtual ports of VNFs 1863 o virtual ports of Virtual Switch abstraction elements 1865 o physical ports of uCPE 1867 Figure 10 shows an example application aware topology for 1868 interconnection between Logical Network Elements [RFC8530], Network 1869 Instances [RFC8529], uCPE node Termination Points [RFC8345]. In 1870 Figure 10 the following elements are presented: 1872 o 3 Logical Network Elements (vCPEL3_WAN1,vCPEL3_WAN2,vSD-WAN) 1874 o 4 Network Instances (vCPEL2) 1876 o 4 Termination Points (Physical Ports) 1878 There are two types of access provided to the client. 1880 The 1st access "Internet" topology part: 1st uCPE Termination Point 1881 "WAN1_port_internet" -- NI (vCPEL2) -- LNE (vCPEL3_telco_internet) -- 1882 NI (vCPEL2) -- vSD-WAN_port_internet. 1884 The 2nd access "MPLS" topology part: 2nd Termination Point 1885 "WAN2_port_mpls" -- NI (vCPEL2) -- LNE (vCPEL3_telco_mpls) -- NI 1886 (vCPEL2) -- vSD-WAN_port_mpls. 1888 Finally SD-WAN balances the traffic via two WAN ports (Termination 1889 Points) of uCPE and shares the connection to LAN ports (Termination 1890 Points). 1892 The figure is available in the PDF format. 1894 Figure 10: uCPE Service Functions topology 1896 An example of an instance data tree in the XML format is presented in 1897 Figure 12, following the uCPE Service Functions topology presented in 1898 Figure 11. 1900 For this example, the interconnection goes as follows: Network-facing 1901 Provider Edge (N-PE) router -- User-facing Provider Edge (U-PE) 1902 router -- uCPE ( Termination Point WAN -- NI (vCPEL2) -- LNE (vCPEL3) 1903 ) 1905 In uCPE, Termination Point (WAN) has id 1. On the NNI 1906 (connectionpoint_id == 10) port of NI the trunk mode is configured. 1907 On UNI ports of NI (cp_id == 13) access mode is configured. Port 1908 with cp_id == 13 is connected to LNE cp_id = 1. 1910 The figure is available in the PDF format. 1912 Figure 11: uCPE Service Functions topology (simple) 1914 1915 1916 1917 network1 1918 1919 1921 1923 1924 1925 1926 uCPE1 1927 1930 1 1931 1934 1935 full 1936 1937 1500 1938 dpdk 1939 1941 1942 1945 2 1946 1947 1950 3 1951 1952 0.0.0.0 1955 1956 1957 1960 1961 1962 1 1963 1964 CPEL3 1965 1 1967 1968 1969 CPEL2 1970 13 1972 1973 true 1974 l10 1975 1976 1977 1978 1979 2 1980 1981 1 1982 1983 1984 CPEL2 1985 10 1987 1988 l11 1992 1993 1994 1995 1996 1997 ucpe 2001 2002 2003 N-PE 2004 2007 1 2008 2009 2012 2 2013 2014 2017 3 2018 2019 2022 4 2023 2024 2025 2026 U-PE 2027 2030 1 2031 2032 2035 2 2036 2037 2040 3 2041 2042 2045 4 2046 2047 2048 2050 1 2051 2052 N-PE 2053 2 2054 2055 2056 U-PE 2057 1 2058 2059 2060 2062 2 2063 2064 U-PE 2065 2 2066 2067 2068 uCPE1 2069 1 2070 2071 2072 2073 2074 2077 2078 CPEL3 2079 2082 2083 CPEL3 2084 small 2086 2087 uCPE1 2088 2089 2090 2091 2093 2094 CPEL2 2095 2098 2099 10 2100 2101 X 2102 Y 2103 Z 2104 2105 2106 2107 11 2108 2109 X 2110 2111 2112 2113 12 2114 2115 Z 2116 2117 2118 2119 13 2120 2121 Y 2122 2123 2124 wan 2125 uCPE1 2126 2127 2128 2129 2131 Figure 12: uCPE Service Funcitons topology YIN example 2133 Acknowledgements 2135 The authors would like to thank Maarten Vissers, Joel Halpern, and 2136 Greg Mirsky for their helpful comments and valuable contributions. 2138 Authors' Addresses 2140 Igor Bryskin 2141 Individual 2143 EMail: i_bryskin@yahoo.com 2145 Xufeng Liu 2146 Volta Networks 2148 EMail: xufeng.liu.ietf@gmail.com 2150 Young Lee 2151 Samsung Electronics 2153 EMail: younglee.tx@gmail.com 2155 Jim Guichard 2156 Huawei Technologies 2158 EMail: james.n.guichard@huawei.com 2160 Luis Miguel Contreras Murillo 2161 Telefonica 2163 EMail: luismiguel.contrerasmurillo@telefonica.com 2165 Daniele Ceccarelli 2166 Ericsson 2168 EMail: daniele.ceccarelli@ericsson.com 2170 Jeff Tantsura 2171 Apstra Networks 2173 EMail: jefftant.ietf@gmail.com 2174 Dmytro Shytyi 2175 SFR 2176 Paris 2177 France 2179 EMail: ietf.dmytro@shytyi.net