idnits 2.17.1 draft-ietf-teas-sf-aware-topo-model-05.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 (March 9, 2020) is 1509 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-22 == Outdated reference: A later version (-24) exists of draft-ietf-teas-actn-vn-yang-08 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: September 10, 2020 Volta Networks 6 Y. Lee 7 Sung Kyun Kwan University 8 J. Guichard 9 Huawei Technologies 10 L. Contreras 11 Telefonica 12 D. Ceccarelli 13 Ericsson 14 J. Tantsura 15 Apstra Networks 16 March 9, 2020 18 SF Aware TE Topology YANG Model 19 draft-ietf-teas-sf-aware-topo-model-05 21 Abstract 23 This document describes a YANG data model for TE network topologies 24 that are network service and function aware. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on September 10, 2020. 43 Copyright Notice 45 Copyright (c) 2020 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 61 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 62 1.2. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 5 63 1.3. Prefixes in Data Node Names . . . . . . . . . . . . . . . 6 64 2. Modeling Considerations . . . . . . . . . . . . . . . . . . . 6 65 3. SF Aware TE Topology Model Structure . . . . . . . . . . . . 7 66 4. SF Aware TE Topology YANG Module . . . . . . . . . . . . . . 9 67 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 68 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 69 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 70 7.1. Normative References . . . . . . . . . . . . . . . . . . 17 71 7.2. Informative References . . . . . . . . . . . . . . . . . 19 72 Appendix A. Companion YANG Model for Non-NMDA Compliant 73 Implementations . . . . . . . . . . . . . . . . . . 20 74 A.1. SF Aware TE Topology State Module . . . . . . . . . . . . 20 75 Appendix B. Data Examples . . . . . . . . . . . . . . . . . . . 23 76 B.1. A Topology with Multiple Connected Network Functions . . 23 77 B.2. A Topology with an Encapsulated Network Service . . . . . 27 78 Appendix C. Use Cases for SF Aware Topology Models . . . . . . . 31 79 C.1. Exporting SF/NF Information to Network Clients and Other 80 Network SDN Controllers . . . . . . . . . . . . . . . . . 31 81 C.2. Flat End-to-end SFCs Managed on Multi-domain Networks . 32 82 C.3. Managing SFCs with TE Constraints . . . . . . . . . . . . 33 83 C.4. SFC Protection and Load Balancing . . . . . . . . . . . . 34 84 C.5. Network Clock Synchronization . . . . . . . . . . . . . . 37 85 C.6. Client - Provider Network Slicing Interface . . . . . . . 37 86 C.7. Dynamic Assignment of Regenerators for L0 Services . . . 37 87 C.8. Dynamic Assignment of OAM Functions for L1 Services . . . 39 88 C.9. SFC Abstraction and Scaling . . . . . . . . . . . . . . . 40 89 C.10. Dynamic Compute/VM/Storage Resource Assignment . . . . . 40 90 C.11. Application-aware Resource Operations and Management . . 41 91 C.12. IANA Considerations . . . . . . . . . . . . . . . . . . . 42 92 C.13. Security Considerations . . . . . . . . . . . . . . . . . 42 93 C.14. Acknowledgements . . . . . . . . . . . . . . . . . . . . 42 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42 96 1. Introduction 98 RFC Ed.: In this document, please replace all occurrences of 'XXXX' 99 with the actual RFC number (and remove this note). 101 Normally network connectivity services are discussed as a means to 102 inter-connect various abstract or physical network topological 103 elements, such as ports, link termination points and nodes 104 [I-D.ietf-teas-yang-te-topo] [I-D.ietf-teas-yang-te]. However, the 105 connectivity services, strictly speaking, interconnect not the 106 network topology elements per-se, rather, located on/associated with 107 the various network and service functions [RFC7498] [RFC7665]. In 108 many scenarios it is beneficial to decouple the service/network 109 functions from the network topology elements hosting them, describe 110 them in some unambiguous and identifiable way (so that it would be 111 possible, for example, to auto-discover on the network topology 112 service/network functions with identical or similar functionality and 113 characteristics) and engineer the connectivity between the service/ 114 network functions, rather than between their current topological 115 locations. 117 Today a network offers to its clients far more services than just 118 connectivity across the network. Large variety of physical, logical 119 and/or virtual service functions, network functions and transport 120 functions (collectively named in this document as SFs) could be 121 allocated for and assigned to a client. As described in the appendix 122 of this document, there are some important use cases, in which the 123 network needs to represent to the client SFs at the client's disposal 124 as topological elements in relation to other elements of a topology 125 (i.e. nodes, links, link and tunnel termination points) used by the 126 network to describe itself to the client. Not only would such 127 information allow for the client to auto-discover the network's SFs 128 available for the services provisioned for the client, it would also 129 allow for the client selecting the SFs, duel-optimizing the selection 130 on the SF location on the network and connectivity means (e.g. TE 131 tunnels) to inter-connect the SFs. Consequently thus would give to 132 both the network and the client powerful means for the service 133 function chain (SFC [RFC7498] [RFC7665]) negotiation to achieve most 134 efficient and cost effective (from the network point of view) and 135 most optimal yet satisfying all necessary constraints of SFCs (from 136 the client's point of view). 138 This document defines a YANG [RFC7950] data model that allows service 139 functions to be represented along with TE topology elements. 141 The YANG data model in this document conforms to the Network 142 Management Datastore Architecture (NMDA) [RFC8342]. 144 1.1. Terminology 146 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 147 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 148 "OPTIONAL" in this document are to be interpreted as described in BCP 149 14, [RFC2119] [RFC8174] when, and only when, they appear in all 150 capitals, as shown here. 152 o Network Function (NF): A functional block within a network 153 infrastructure that has well-defined external interfaces and well- 154 defined functional behaviour [ETSI-NFV-TERM]. Such functions 155 include message router, CDN, session border controller, WAN 156 cceleration, DPI, firewall, NAT, QoE monitor, PE router, BRAS, and 157 radio/fixed access network nodes. 159 o Network Service: Composition of Network Functions and defined by 160 its functional and behavioural specification. The Network Service 161 contributes to the behaviour of the higher layer service, which is 162 characterized by at least performance, dependability, and security 163 specifications. The end-to-end network service behaviour is the 164 result of the combination of the individual network function 165 behaviours as well as the behaviours of the network infrastructure 166 composition mechanism [ETSI-NFV-TERM]. 168 o Service Function (SF): A function that is responsible for specific 169 treatment of received packets. A service function can act at 170 various layers of a protocol stack (e.g., at the network layer or 171 other OSI layers). As a logical component, a service function can 172 be realized as a virtual element or be embedded in a physical 173 network element. One or more service functions can be embedded in 174 the same network element. Multiple occurrences of the service 175 function can exist in the same administrative domain. A non- 176 exhaustive list of service functions includes: firewalls, WAN and 177 application acceleration, Deep Packet Inspection (DPI), server 178 load balancers, NAT44 [RFC3022], NAT64 [RFC6146], HTTP header 179 enrichment functions, and TCP optimizers. The generic term "L4-L7 180 services" is often used to describe many service functions 181 [RFC7498]. 183 o Service Function Chain (SFC): A service function chain defines an 184 ordered or partially ordered set of abstract service functions and 185 ordering constraints that must be applied to packets, frames, and/ 186 or flows selected as a result of classification. An example of an 187 abstract service function is a firewall. The implied order may 188 not be a linear progression as the architecture allows for SFCs 189 that copy to more than one branch, and also allows for cases where 190 there is flexibility in the order in which service functions need 191 to be applied. The term "service chain" is often used as 192 shorthand for "service function chain" [RFC7498]. 194 o Connectivity Service: Any service between layer 0 and layer 3 195 aiming at delivering traffic among two or more end customer edge 196 nodes connected to provider edge nodes. Examples include L3VPN, 197 L2VPN etc. 199 o Link Termination Point (LTP): A conceptual point of connection of 200 a TE node to one of the TE links, terminated by the TE node. 201 Cardinality between an LTP and the associated TE link is 1:0..1 202 [I-D.ietf-teas-yang-te-topo]. 204 o Tunnel Termination Point (TTP): An element of TE topology 205 representing one or several of potential transport service 206 termination points (i.e. service client adaptation points such as 207 WDM/OCh transponder). TTP is associated with (hosted by) exactly 208 one TE node. TTP is assigned with the TE node scope unique ID. 209 Depending on the TE node's internal constraints, a given TTP 210 hosted by the TE node could be accessed via one, several or all TE 211 links terminated by the TE node [I-D.ietf-teas-yang-te-topo]. 213 o Topology and Orchestration Specification for Cloud Applications 214 (TOSCA): A language standard specified by OASIS, to describe 215 service components and their relationships using a service 216 topology, and management procedures using orchestration processes. 217 OASIS is a nonprofit consortium that drives the development, 218 convergence and adoption of open standards for the global 219 information society. 221 The following terms are defined in [RFC7950] and are not redefined 222 here: 224 o augment 226 o data model 228 o data node 230 1.2. Tree Diagrams 232 A simplified graphical representation of the data model is presented 233 in this document, by using the tree format defined in [RFC8340]. 235 1.3. Prefixes in Data Node Names 237 In this document, names of data nodes, actions, and other data model 238 objects are often used without a prefix, as long as it is clear from 239 the context in which YANG module each name is defined. Otherwise, 240 names are prefixed using the standard prefix associated with the 241 corresponding YANG module, as shown in Table 1. 243 +---------+------------------+------------------------------+ 244 | Prefix | YANG module | Reference | 245 +---------+------------------+------------------------------+ 246 | inet | ietf-inet-types | [RFC6991] | 247 | nw | ietf-network | [RFC8345] | 248 | nt | ietf-network- | [RFC8345] | 249 | | topology | | 250 | tet | ietf-te-topology | [I-D.ietf-teas-yang-te-topo] | 251 | actn-vn | ietf-actn-vn | [I-D.ietf-teas-actn-vn-yang] | 252 +---------+------------------+------------------------------+ 254 Table 1: Prefixes and Corresponding YANG Modules 256 2. Modeling Considerations 258 The model introduced in this document is an augmentation of the TE 259 Topology model defined in [I-D.ietf-teas-yang-te-topo]. SFs are 260 modeled as child elements of a TE node similarly to how Link 261 Termination Points (LTPs) and Tunnel Termination Points (TTPs) are 262 modeled in the TE Topology model. The SFs are defined as opaque 263 objects identified via topology unique service-function-id's. Each 264 SF has one or more Connection Points (CPs) identified via SF-unique 265 sf-connection-point-id's, over which the SF could be connected to 266 other SFs resided on the same TE node, as well as to other elements 267 of the TE node, in particular, to the node's LTPs and/or TTPs. An 268 interested client may use service-function-id's to look up the SFs in 269 TOSCA or YANG data store(s) defined by [ETSI-NFV-MAN] to retrieve the 270 details of the SFs, for example, to understand the SF's mutual 271 substitutability. 273 The TE Topology model introduces a concept of Connectivity Matrix 274 (CM), and uses the CM to describe which and at what costs a TE node's 275 LTPs could be inter-connected internally across the TE node. The 276 model defined in this document heavily uses the same concept to 277 describe the SF connectivity via introducing 3 additional CMs: 279 1. SF2SF CM (SF to SF Connectivity Matrix). This CM describes which 280 pairs of SFs could be locally inter-connected, and, if yes, in 281 which direction, via which CPs and at what costs. In other 282 words, the SF2SF CM describes how SFs residing on the same TE 283 node could be inter-connected into local from the TE node's 284 perspective SFCs; 286 2. SF2LTP CM (SF to LTP Connectivity Matrix). This CM describes 287 how, in which direction and at what costs the TE node's SFs could 288 be connected to the TE node's LTPs and hence to SFs residing on 289 neighboring TE nodes that are connected to LTPs at the remote 290 ends of corresponding TE links; 292 3. SF2TTP CM (SF to TTP Connectivity Matrix). This CM describes 293 how, in which direction and at what costs the TE node's SFs could 294 be connected to the TE node's TTPs and hence to SFs residing on 295 other TE nodes on the topology that could be inter-connected with 296 the TE node in question via TE tunnels terminated by the 297 corresponding TTPs. 299 In addition to SF2SF CM, the local SF chaining could be described 300 with the help of ETSI models Virtual Links (VLs) [ETSI-NFV-MAN]. 301 This option is especially useful when the costs of the local chaining 302 are negligible as compared to ones of the end-to-end SFCs said local 303 SFCs are part of. 305 Section 3 and 4 provide the YANG model structure and the YANG module 306 for SF-aware Topology. Section 5 and 6 provide the YANG model 307 structure and the YANG module for Data Center Compute Node resource 308 abstraction. This provides an example of SF2LTP CM where DC compute 309 nodes are connected to LTPs at the remote ends of the corresponding 310 TE links. This use-case is described in Section 10 of Appendix C. 312 3. SF Aware TE Topology Model Structure 314 module: ietf-te-topology-sf 315 augment /nw:networks/nw:network/nw:network-types/tet:te-topology: 316 +--rw sf! 317 augment /nw:networks/nw:network/nw:node/tet:te 318 /tet:te-node-attributes: 319 +--rw service-function 320 +--rw connectivity-matrices 321 | +--rw connectivity-matrix* [id] 322 | +--rw id uint32 323 | +--rw from 324 | | +--rw service-function-id? string 325 | | +--rw sf-connection-point-id? string 326 | +--rw to 327 | | +--rw service-function-id? string 328 | | +--rw sf-connection-point-id? string 329 | +--rw enabled? boolean 330 | +--rw direction? connectivity-direction 331 | +--rw virtual-link-id? string 332 +--rw link-terminations 333 +--rw link-termination* [id] 334 +--rw id uint32 335 +--rw from 336 | +--rw tp-ref? -> ../../../../../../.. 337 /nt:termination-point/tp-id 338 +--rw to 339 | +--rw service-function-id? string 340 | +--rw sf-connection-point-id? string 341 +--rw enabled? boolean 342 +--rw direction? connectivity-direction 343 augment /nw:networks/nw:network/nw:node/tet:te 344 /tet:information-source-entry: 345 +--ro service-function 346 +--ro connectivity-matrices 347 | +--ro connectivity-matrix* [id] 348 | +--ro id uint32 349 | +--ro from 350 | | +--ro service-function-id? string 351 | | +--ro sf-connection-point-id? string 352 | +--ro to 353 | | +--ro service-function-id? string 354 | | +--ro sf-connection-point-id? string 355 | +--ro enabled? boolean 356 | +--ro direction? connectivity-direction 357 | +--ro virtual-link-id? string 358 +--ro link-terminations 359 +--ro link-termination* [id] 360 +--ro id uint32 361 +--ro from 362 +--ro to 363 | +--ro service-function-id? string 364 | +--ro sf-connection-point-id? string 365 +--ro enabled? boolean 366 +--ro direction? connectivity-direction 367 augment /nw:networks/nw:network/nw:node/tet:te 368 /tet:tunnel-termination-point: 369 +--rw service-function 370 +--rw tunnel-terminations 371 +--rw tunnel-termination* [id] 372 +--rw id uint32 373 +--rw service-function-id? string 374 +--rw sf-connection-point-id? string 375 +--rw enabled? boolean 376 +--rw direction? connectivity-direction 378 4. SF Aware TE Topology YANG Module 380 file "ietf-te-topology-sf@2019-11-03.yang" 381 module ietf-te-topology-sf { 382 yang-version 1.1; 383 namespace "urn:ietf:params:xml:ns:yang:ietf-te-topology-sf"; 385 prefix "tet-sf"; 387 import ietf-network { 388 prefix "nw"; 389 reference "RFC 8345: A YANG Data Model for Network Topologies"; 390 } 392 import ietf-network-topology { 393 prefix "nt"; 394 reference "RFC 8345: A YANG Data Model for Network Topologies"; 395 } 397 import ietf-te-topology { 398 prefix "tet"; 399 reference 400 "I-D.ietf-teas-yang-te-topo: YANG Data Model for Traffic 401 Engineering (TE) Topologies"; 402 } 404 organization 405 "Traffic Engineering Architecture and Signaling (TEAS) 406 Working Group"; 408 contact 409 "WG Web: 410 WG List: 412 Editors: Igor Bryskin 413 415 Xufeng Liu 416 "; 418 description 419 "Network service and function aware aware TE topology model. 421 Copyright (c) 2019 IETF Trust and the persons identified as 422 authors of the code. All rights reserved. 424 Redistribution and use in source and binary forms, with or 425 without modification, is permitted pursuant to, and subject to 426 the license terms contained in, the Simplified BSD License set 427 forth in Section 4.c of the IETF Trust's Legal Provisions 428 Relating to IETF Documents 429 (http://trustee.ietf.org/license-info). 431 This version of this YANG module is part of RFC XXXX; see the 432 RFC itself for full legal notices."; 434 revision 2019-11-03 { 435 description "Initial revision"; 436 reference "RFC XXXX: SF Aware TE Topology YANG Model"; 437 } 439 /* 440 * Typedefs 441 */ 442 typedef connectivity-direction { 443 type enumeration { 444 enum "to" { 445 description 446 "The direction is uni-directional, towards the 'to' 447 entity direction."; 448 } 449 enum "from" { 450 description 451 "The direction is uni-directional, from the 'to' 452 entity direction."; 453 } 454 enum "bidir" { 455 description 456 "The direction is bi-directional."; 457 } 458 } 459 description 460 "A type used to indicates whether a connectivity is 461 uni-directional, or bi-directional. If the relation is 462 uni-directional, the value of this type indicates the 463 direction."; 464 } // connectivity-direction 466 /* 467 * Groupings 468 */ 469 grouping service-function-node-augmentation { 470 description 471 "Augmenting a TE node to be network service and function 472 aware."; 474 container service-function { 475 description 476 "Containing attributes related to network services and 477 network functions"; 478 container connectivity-matrices { 479 description 480 "Connectivity relations between network services/functions 481 on a TE node, which can be either abstract or physical."; 482 reference 483 "ETSI GS NFV-MAN 01: Network Functions Virtualisation 484 (NFV); Management and Orchestration. 485 RFC7665: Service Function Chaining (SFC) Architecture."; 486 list connectivity-matrix { 487 key "id"; 488 description 489 "Represents the connectivity relations between network 490 services/functions on a TE node."; 491 leaf id { 492 type uint32; 493 description "Identifies the connectivity-matrix entry."; 494 } 496 container from { 497 description 498 "Reference to the source network service or 499 network function."; 500 leaf service-function-id { 501 type string; 502 description 503 "Reference to a network service or a network 504 function."; 505 } 506 leaf sf-connection-point-id { 507 type string; 508 description 509 "Reference to a connection point on a network 510 service or a network function."; 511 } 512 } // from 513 container to { 514 description 515 "Reference to the destination network service or 516 network function."; 517 leaf service-function-id { 518 type string; 519 description 520 "Reference to a network service or a network 521 function."; 523 } 524 leaf sf-connection-point-id { 525 type string; 526 description 527 "Reference to a connection point on a network 528 service or a network function."; 529 } 530 } // to 531 leaf enabled { 532 type boolean; 533 description 534 "'true' if this connectivity entry is enabled."; 535 } 536 leaf direction { 537 type connectivity-direction; 538 description 539 "Indicates whether this connectivity is 540 uni-directional, or bi-directional. If the 541 relation is uni-directional, the value of 542 this leaf indicates the direction."; 543 } 544 leaf virtual-link-id { 545 type string; 546 description 547 "Reference to a virtual link that models this 548 conectivity relation in the network function 549 model."; 550 } 551 } // connectivity-matrix 552 } // connectivity-matrices 554 container link-terminations { 555 description 556 "Connectivity relations between network services/functions 557 and link termination points on a TE node, which can be 558 either abstract or physical."; 559 reference 560 "ETSI GS NFV-MAN 01: Network Functions Virtualisation 561 (NFV); Management and Orchestration. 562 RFC7665: Service Function Chaining (SFC) Architecture."; 563 list link-termination { 564 key "id"; 565 description 566 "Each entry of the list represents the connectivity 567 relation between a network service/function and 568 a link termination point on a TE node."; 569 leaf id { 570 type uint32; 571 description "Identifies the termination entry."; 572 } 574 container from { 575 description 576 "Reference to the link termination point."; 577 } // from 578 container to { 579 description 580 "Reference to the network service or network 581 function."; 582 leaf service-function-id { 583 type string; 584 description 585 "Reference to a network service or a network 586 function."; 587 } 588 leaf sf-connection-point-id { 589 type string; 590 description 591 "Reference to a connection point on a network 592 service or a network function."; 593 } 594 } // to 595 leaf enabled { 596 type boolean; 597 description 598 "'true' if this connectivity entry is enabled."; 599 } 600 leaf direction { 601 type connectivity-direction; 602 description 603 "Indicates whether this connectivity is 604 uni-directional, or bi-directional. If the 605 relation is uni-directional, the value of 606 this leaf indicates the direction."; 607 } 608 } // link-termination 609 } 610 } 611 } // service-function-node-augmentation 613 grouping service-function-ttp-augmentation { 614 description 615 "Augmenting a tunnel termination point to be network service 616 aware."; 617 container service-function { 618 description 619 "Containing attributes related to network services and 620 network functions"; 621 container tunnel-terminations { 622 description 623 "Connectivity relations between network services/functions 624 and tunnel termination points on a TE node, which can be 625 either abstract or physical."; 626 reference 627 "ETSI GS NFV-MAN 01: Network Functions Virtualisation 628 (NFV); Management and Orchestration. 629 RFC7665: Service Function Chaining (SFC) Architecture."; 630 list tunnel-termination { 631 key "id"; 632 description 633 "Each entry of the list represents the connectivity 634 relation between a network service/function and 635 a tunnel termination point on a TE node."; 636 leaf id { 637 type uint32; 638 description "Identifies the termination entry."; 639 } 641 leaf service-function-id { 642 type string; 643 description 644 "Reference to a network service or a network 645 function."; 646 } 647 leaf sf-connection-point-id { 648 type string; 649 description 650 "Reference to a connection point on a network 651 service or a network function."; 652 } 653 leaf enabled { 654 type boolean; 655 description 656 "'true' if this connectivity entry is enabled."; 657 } 658 leaf direction { 659 type connectivity-direction; 660 description 661 "Indicates whether this connectivity is 662 uni-directional, or bi-directional. If the 663 relation is uni-directional, the value of 664 this leaf indicates the direction."; 665 } 666 } // link-termination 668 } 669 } 670 } // service-function-ttp-augmentation 672 grouping sf-topology-type { 673 description 674 "Identifies the SF aware TE topology type."; 675 container sf { 676 presence "Indidates that the TE topology is SF aware."; 677 description 678 "Its presence identifies that the TE topology is SF aware."; 679 } 680 } // sf-topology-type 682 /* 683 * Augmentations 684 */ 685 /* Augmentations to network-types/te-topology */ 686 augment "/nw:networks/nw:network/nw:network-types/" 687 + "tet:te-topology" { 688 description 689 "Defines the SF aware TE topology type."; 690 uses sf-topology-type; 691 } 693 /* Augmentations to te-node-attributes */ 694 augment "/nw:networks/nw:network/nw:node/tet:te/" 695 + "tet:te-node-attributes" { 696 description 697 "Parameters for SF aware TE topology."; 698 uses service-function-node-augmentation; 699 } 701 augment "/nw:networks/nw:network/nw:node/tet:te/" 702 + "tet:information-source-entry" { 703 description 704 "Parameters for SF aware TE topology."; 705 uses service-function-node-augmentation; 706 } 708 /* Augmentations to tunnel-termination-point */ 709 augment "/nw:networks/nw:network/nw:node/tet:te/" 710 + "tet:tunnel-termination-point" { 711 description 712 "Parameters for SF aware TE topology."; 713 uses service-function-ttp-augmentation; 714 } 715 /* Augmentations to connectivity-matrix */ 716 augment "/nw:networks/nw:network/nw:node/tet:te/" 717 + "tet:te-node-attributes/tet-sf:service-function/" 718 + "tet-sf:link-terminations/tet-sf:link-termination/" 719 + "tet-sf:from" { 720 description 721 "Add reference to the link termination point. 722 This portion cannot be shared with the state module."; 723 leaf tp-ref { 724 type leafref { 725 path "../../../../../../../nt:termination-point/" 726 + "nt:tp-id"; 727 } 728 description 729 "Reference to the link termination point."; 730 } 731 } 732 } 733 735 5. IANA Considerations 737 This document registers the following namespace URIs in the IETF XML 738 registry [RFC3688]: 740 -------------------------------------------------------------------- 741 URI: urn:ietf:params:xml:ns:yang:ietf-te-topology-sf 742 Registrant Contact: The IESG. 743 XML: N/A, the requested URI is an XML namespace. 744 -------------------------------------------------------------------- 746 -------------------------------------------------------------------- 747 URI: urn:ietf:params:xml:ns:yang:ietf-te-topology-sf-state 748 Registrant Contact: The IESG. 749 XML: N/A, the requested URI is an XML namespace. 750 -------------------------------------------------------------------- 752 This document registers the following YANG modules in the YANG Module 753 Names registry [RFC6020]: 755 -------------------------------------------------------------------- 756 name: ietf-te-topology-sf 757 namespace: urn:ietf:params:xml:ns:yang:ietf-te-topology-packet 758 prefix: tet-sf 759 reference: RFC XXXX 760 -------------------------------------------------------------------- 761 -------------------------------------------------------------------- 762 name: ietf-te-topology-sf-state 763 namespace: urn:ietf:params:xml:ns:yang:ietf-te-topology-packet-state 764 prefix: tet-sf-s 765 reference: RFC XXXX 766 -------------------------------------------------------------------- 768 6. Security Considerations 770 The configuration, state, action and notification data defined in 771 this document are designed to be accessed via the NETCONF protocol 772 [RFC6241]. The data-model by itself does not create any security 773 implications. The security considerations for the NETCONF protocol 774 are applicable. The NETCONF protocol used for sending the data 775 supports authentication and encryption. 777 7. References 779 7.1. Normative References 781 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 782 Requirement Levels", BCP 14, RFC 2119, 783 DOI 10.17487/RFC2119, March 1997, 784 . 786 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 787 DOI 10.17487/RFC3688, January 2004, 788 . 790 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 791 the Network Configuration Protocol (NETCONF)", RFC 6020, 792 DOI 10.17487/RFC6020, October 2010, 793 . 795 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 796 and A. Bierman, Ed., "Network Configuration Protocol 797 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 798 . 800 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 801 RFC 6991, DOI 10.17487/RFC6991, July 2013, 802 . 804 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 805 RFC 7950, DOI 10.17487/RFC7950, August 2016, 806 . 808 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 809 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 810 May 2017, . 812 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 813 and R. Wilton, "Network Management Datastore Architecture 814 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 815 . 817 [RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N., 818 Ananthakrishnan, H., and X. Liu, "A YANG Data Model for 819 Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March 820 2018, . 822 [I-D.ietf-teas-yang-te-topo] 823 Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and 824 O. Dios, "YANG Data Model for Traffic Engineering (TE) 825 Topologies", draft-ietf-teas-yang-te-topo-22 (work in 826 progress), June 2019. 828 [I-D.ietf-teas-yang-te] 829 Saad, T., Gandhi, R., Liu, X., Beeram, V., and I. Bryskin, 830 "A YANG Data Model for Traffic Engineering Tunnels and 831 Interfaces", draft-ietf-teas-yang-te-22 (work in 832 progress), November 2019. 834 [I-D.ietf-teas-actn-vn-yang] 835 Lee, Y., Dhody, D., Ceccarelli, D., Bryskin, I., and B. 836 Yoon, "A Yang Data Model for VN Operation", draft-ietf- 837 teas-actn-vn-yang-08 (work in progress), March 2020. 839 [ETSI-NFV-MAN] 840 ETSI, "Network Functions Virtualisation (NFV); Management 841 and Orchestration", ETSI GS NFV-MAN 001 V1.1.1, December 842 2014. 844 [ETSI-NFV-TERM] 845 ETSI, "Network Functions Virtualisation (NFV); Terminology 846 for Main Concepts in NFV", ETSI GS NFV 003 V1.2.1, 847 December 2014. 849 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 850 Address Translator (Traditional NAT)", RFC 3022, 851 DOI 10.17487/RFC3022, January 2001, 852 . 854 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 855 NAT64: Network Address and Protocol Translation from IPv6 856 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, 857 April 2011, . 859 [RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for 860 Abstraction and Control of TE Networks (ACTN)", RFC 8453, 861 DOI 10.17487/RFC8453, August 2018, 862 . 864 [RFC8459] Dolson, D., Homma, S., Lopez, D., and M. Boucadair, 865 "Hierarchical Service Function Chaining (hSFC)", RFC 8459, 866 DOI 10.17487/RFC8459, September 2018, 867 . 869 [I-D.defoy-netslices-3gpp-network-slicing] 870 Foy, X. and A. Rahman, "Network Slicing - 3GPP Use Case", 871 draft-defoy-netslices-3gpp-network-slicing-02 (work in 872 progress), October 2017. 874 [_3GPP.28.801] 875 3GPP, "Study on management and orchestration of network 876 slicing for next generation network", 3GPP TR 28.801 877 V2.0.0, September 2017, 878 . 880 7.2. Informative References 882 [RFC7498] Quinn, P., Ed. and T. Nadeau, Ed., "Problem Statement for 883 Service Function Chaining", RFC 7498, 884 DOI 10.17487/RFC7498, April 2015, 885 . 887 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 888 Chaining (SFC) Architecture", RFC 7665, 889 DOI 10.17487/RFC7665, October 2015, 890 . 892 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 893 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 894 . 896 Appendix A. Companion YANG Model for Non-NMDA Compliant Implementations 898 The YANG module ietf-te-topology-sf defined in this document is 899 designed to be used in conjunction with implementations that support 900 the Network Management Datastore Architecture (NMDA) defined in 901 [RFC8342]. In order to allow implementations to use the model even 902 in cases when NMDA is not supported, the following companion module, 903 ietf-te-topology-sf-state, is defined as state model, which mirrors 904 the module ietf-te-topology-sf defined earlier in this document. 905 However, all data nodes in the companion module are non-configurable, 906 to represent the applied configuration or the derived operational 907 states. 909 The companion module, ietf-te-topology-sf-state, is redundant and 910 SHOULD NOT be supported by implementations that support NMDA. 912 As the structure of the companion module mirrors that of the 913 coorespinding NMDA model, the YANG tree of the companion module is 914 not depicted separately. 916 A.1. SF Aware TE Topology State Module 918 file "ietf-te-topology-sf-state@2019-11-03.yang" 919 module ietf-te-topology-sf-state { 920 yang-version 1.1; 921 namespace "urn:ietf:params:xml:ns:yang:ietf-te-topology-sf-state"; 923 prefix "tet-sf-s"; 925 import ietf-te-topology-sf { 926 prefix "tet-sf"; 927 reference "RFC XXXX: SF Aware TE Topology YANG Model"; 928 } 930 import ietf-network-state { 931 prefix "nw-s"; 932 reference "RFC 8345: A YANG Data Model for Network Topologies"; 933 } 935 import ietf-network-topology-state { 936 prefix "nt-s"; 937 reference "RFC 8345: A YANG Data Model for Network Topologies"; 938 } 940 import ietf-te-topology-state { 941 prefix "tet-s"; 942 reference 943 "I-D.ietf-teas-yang-te-topo: YANG Data Model for Traffic 944 Engineering (TE) Topologies"; 945 } 947 organization 948 "Traffic Engineering Architecture and Signaling (TEAS) 949 Working Group"; 951 contact 952 "WG Web: 953 WG List: 955 Editors: Igor Bryskin 956 958 Xufeng Liu 959 "; 961 description 962 "Network service and function aware aware TE topology operational 963 state model for non-NMDA compliant implementations. 965 Copyright (c) 2019 IETF Trust and the persons identified as 966 authors of the code. All rights reserved. 968 Redistribution and use in source and binary forms, with or 969 without modification, is permitted pursuant to, and subject to 970 the license terms contained in, the Simplified BSD License set 971 forth in Section 4.c of the IETF Trust's Legal Provisions 972 Relating to IETF Documents 973 (http://trustee.ietf.org/license-info). 975 This version of this YANG module is part of RFC XXXX; see the 976 RFC itself for full legal notices."; 978 revision 2019-11-03 { 979 description "Initial revision"; 980 reference "RFC XXXX: SF Aware TE Topology YANG Model"; 981 } 983 /* 984 * Augmentations 985 */ 986 /* Augmentations to network-types/te-topology */ 987 augment "/nw-s:networks/nw-s:network/nw-s:network-types/" 988 + "tet-s:te-topology" { 989 description 990 "Defines the SF aware TE topology type."; 992 uses tet-sf:sf-topology-type; 993 } 995 /* Augmentations to connectivity-matrix */ 996 augment "/nw-s:networks/nw-s:network/nw-s:node/tet-s:te/" 997 + "tet-s:te-node-attributes" { 998 description 999 "Parameters for SF aware TE topology."; 1000 uses tet-sf:service-function-node-augmentation; 1001 } 1003 augment "/nw-s:networks/nw-s:network/nw-s:node/tet-s:te/" 1004 + "tet-s:information-source-entry" { 1005 description 1006 "Parameters for SF aware TE topology."; 1007 uses tet-sf:service-function-node-augmentation; 1008 } 1010 /* Augmentations to tunnel-termination-point */ 1011 augment "/nw-s:networks/nw-s:network/nw-s:node/tet-s:te/" 1012 + "tet-s:tunnel-termination-point" { 1013 description 1014 "Parameters for SF aware TE topology."; 1015 uses tet-sf:service-function-ttp-augmentation; 1016 } 1018 /* Augmentations to connectivity-matrix */ 1019 augment "/nw-s:networks/nw-s:network/nw-s:node/tet-s:te/" 1020 + "tet-s:te-node-attributes/tet-sf-s:service-function/" 1021 + "tet-sf-s:link-terminations/tet-sf-s:link-termination/" 1022 + "tet-sf-s:from" { 1023 description 1024 "Add reference to the link termination point. 1025 This portion cannot be shared with the state module."; 1026 leaf tp-ref { 1027 type leafref { 1028 path "../../../../../../../nt-s:termination-point/" 1029 + "nt-s:tp-id"; 1030 } 1031 description 1032 "Reference to the link termination point."; 1033 } 1034 } 1035 } 1036 1038 Appendix B. Data Examples 1040 B.1. A Topology with Multiple Connected Network Functions 1042 Node-1 1043 +----o--o--------------------------o-------+ 1044 | | | | | 1045 | \__/ \__ | 1046 | *\/ TTP-1 * * * * * * * * * *\/* | 1047 LTP-4 |* * * * TTP-2 * | LTP-1 1048 o------------*-----------------------------o 1049 | * * | 1050 LTP-3 |* * * * * *| LTP-2 1051 o--- -----o 1052 | \ / | 1053 | \ / | 1054 | \ CP01 CP02/ | 1055 | +----o--------------------------o------+ | 1056 | | VL1| VL4| | | 1057 | | |CP11 |CP33 | | 1058 | | +-o--+ +----+ +-o--+ | | 1059 | | |VNF1| |VNF2| |VNF3| | | 1060 | | +-o-o+ VL2 +--o-+ VL2 +-o-o+ | | 1061 | |CP12| |\----------/ \---------/| |CP32| | 1062 | | | |CP13 CP21 CP31| | | | 1063 | | | | VL2 | | | | 1064 | | | +------------------------+ | | | 1065 | | +----------------------------+ | | 1066 | | VL3 | | 1067 | | Network Service 1 | | 1068 | +--------------------------------------+ | 1069 +------------------------------------------+ 1071 The configuration instance data for Node-1 in the above figure could 1072 be as follows: 1074 { 1075 "networks": { 1076 "network": [ 1077 { 1078 "network-types": { 1079 "te-topology": { 1080 "sf": {} 1081 } 1082 }, 1083 "network-id": "network-sf-aware", 1084 "provider-id": 201, 1085 "client-id": 300, 1086 "te-topology-id": "te-topology:network-sf-aware", 1087 "node": [ 1088 { 1089 "node-id": "Node-1", 1090 "te-node-id": "2.0.1.1", 1091 "te": { 1092 "te-node-attributes": { 1093 "domain-id": 1, 1094 "is-abstract": [null], 1095 "connectivity-matrices": { 1096 }, 1097 "service-function": { 1098 "connectivity-matrices": { 1099 "connectivity-matrix": [ 1100 { 1101 "id": 10, 1102 "from": { 1103 "service-function-id": "Network Service 1", 1104 "sf-connection-point-id": "CP01" 1105 }, 1106 "to": { 1107 "service-function-id": "VNF1", 1108 "sf-connection-point-id": "CP11" 1109 } 1110 "direction": "bidir", 1111 "virtual-link-id": "VL1" 1112 }, 1113 { 1114 "id": 13, 1115 "from": { 1116 "service-function-id": "VNF1", 1117 "sf-connection-point-id": "CP12" 1118 }, 1119 "to": { 1120 "service-function-id": "VNF3", 1121 "sf-connection-point-id": "CP32" 1122 } 1123 "direction": "bidir", 1124 "virtual-link-id": "VL3" 1125 }, 1126 { 1127 "id": 12, 1128 "from": { 1129 "service-function-id": "VNF1", 1130 "sf-connection-point-id": "CP13" 1131 }, 1132 "to": { 1133 "service-function-id": "VNF2", 1134 "sf-connection-point-id": "CP21" 1135 } 1136 "direction": "bidir", 1137 "virtual-link-id": "VL2" 1138 }, 1139 { 1140 "id": 23, 1141 "from": { 1142 "service-function-id": "VNF2", 1143 "sf-connection-point-id": "CP21" 1144 }, 1145 "to": { 1146 "service-function-id": "VNF3" 1147 "sf-connection-point-id": "CP31" 1148 } 1149 "direction": "bidir", 1150 "virtual-link-id": "VL2" 1151 }, 1152 { 1153 "id": 30, 1154 "from": { 1155 "service-function-id": "Network Service 1", 1156 "sf-connection-point-id": "CP02" 1157 }, 1158 "to": { 1159 "service-function-id": "VNF3", 1160 "sf-connection-point-id": "CP33" 1161 } 1162 "direction": "bidir", 1163 "virtual-link-id": "VL4" 1164 } 1165 ] 1166 }, 1167 "link-terminations": { 1168 "link-termination": [ 1169 { 1170 "id": 2, 1171 "from": { 1172 "tp-ref": "LTP-2" 1173 }, 1174 "to": { 1175 "service-function-id": "Network Service 1", 1176 "sf-connection-point-id": "CP02" 1177 } 1178 "direction": "bidir" 1179 }, 1180 { 1181 "id": 3, 1182 "from": { 1183 "tp-ref": "LTP-3" 1184 }, 1185 "to": { 1186 "service-function-id": "Network Service 1", 1187 "sf-connection-point-id": "CP01" 1188 } 1189 "direction": "bidir" 1190 } 1191 ] 1192 } 1193 } 1194 } 1195 "tunnel-termination-point": [ 1196 { 1197 "tunnel-tp-id": 10001, 1198 "name": "TTP-1", 1199 "service-function-terminations": { 1200 } 1201 }, 1202 { 1203 "tunnel-tp-id": 10002, 1204 "name": "TTP-2", 1205 "service-function-terminations": { 1206 } 1207 } 1208 ] 1209 }, 1210 "termination-point": [ 1211 { 1212 "tp-id": "LTP-1", 1213 "te-tp-id": 10001 1214 "te": { 1215 "interface-switching-capability": [ 1216 { 1217 "switching-capability": "switching-l2sc", 1218 "encoding": "lsp-encoding-ethernet" 1219 } 1220 ] 1221 } 1222 }, 1223 { 1224 "tp-id": "LTP-2", 1225 "te-tp-id": 10002 1226 "te": { 1227 "interface-switching-capability": [ 1228 { 1229 "switching-capability": "switching-l2sc", 1230 "encoding": "lsp-encoding-ethernet" 1231 } 1232 ] 1233 } 1234 }, 1235 { 1236 "tp-id": "LTP-3", 1237 "te-tp-id": 10003 1238 "te": { 1239 "interface-switching-capability": [ 1240 { 1241 "switching-capability": "switching-l2sc", 1242 "encoding": "lsp-encoding-ethernet" 1243 } 1244 ] 1245 } 1246 }, 1247 { 1248 "tp-id": "LTP-4", 1249 "te-tp-id": 10004 1250 "te": { 1251 "interface-switching-capability": [ 1252 { 1253 "switching-capability": "switching-l2sc", 1254 "encoding": "lsp-encoding-ethernet" 1255 } 1256 ] 1257 } 1258 } 1259 ] 1260 } 1261 ] 1262 } 1263 ] 1264 } 1265 } 1267 B.2. A Topology with an Encapsulated Network Service 1269 In this example, a network service consists of several inter- 1270 connected network functions (NFs), and is represented by this model 1271 as an encapsulated opaque object without the details between its 1272 internals. 1274 Node-1 1275 +----o--o--------------------------o-------+ 1276 | | | | | 1277 | \__/ \__ | 1278 | *\/ TTP-1 * * * * * * * * * *\/* | 1279 LTP-4 |* * * * TTP-2 * | LTP-1 1280 o------------*-----------------------------o 1281 | * * | 1282 LTP-3 |* * * * * *| LTP-2 1283 o--- -----o 1284 | \ / | 1285 | \ / | 1286 | \ CP01 CP02/ | 1287 | +----o--------------------------o------+ | 1288 | | | | 1289 | | Network Service 1 | | 1290 | +--------------------------------------+ | 1291 +------------------------------------------+ 1293 The configuration instance data for Node-1 in the above figure could 1294 be as follows: 1296 { 1297 "networks": { 1298 "network": [ 1299 { 1300 "network-types": { 1301 "te-topology": { 1302 "sf": {} 1303 } 1304 }, 1305 "network-id": "network-sf-aware", 1306 "provider-id": 201, 1307 "client-id": 300, 1308 "te-topology-id": "te-topology:network-sf-aware", 1309 "node": [ 1310 { 1311 "node-id": "Node-1", 1312 "te-node-id": "2.0.1.1", 1313 "te": { 1314 "te-node-attributes": { 1315 "domain-id": 1, 1316 "is-abstract": [null], 1317 "connectivity-matrices": { 1318 }, 1319 "service-function": { 1320 "connectivity-matrices": { 1321 }, 1322 "link-terminations": { 1323 "link-termination": [ 1324 { 1325 "id": 2, 1326 "from": { 1327 "tp-ref": "LTP-2" 1328 }, 1329 "to": { 1330 "service-function-id": "Network Service 1", 1331 "sf-connection-point-id": "CP02" 1332 } 1333 "direction": "bidir" 1334 }, 1335 { 1336 "id": 3, 1337 "from": { 1338 "tp-ref": "LTP-3" 1339 }, 1340 "to": { 1341 "service-function-id": "Network Service 1", 1342 "sf-connection-point-id": "CP01" 1343 } 1344 "direction": "bidir" 1345 } 1346 ] 1347 } 1348 } 1349 } 1350 "tunnel-termination-point": [ 1351 { 1352 "tunnel-tp-id": 10001, 1353 "name": "TTP-1", 1354 "service-function-terminations": { 1355 } 1356 }, 1357 { 1358 "tunnel-tp-id": 10002, 1359 "name": "TTP-2", 1360 "service-function-terminations": { 1361 } 1362 } 1363 ] 1364 }, 1365 "termination-point": [ 1366 { 1367 "tp-id": "LTP-1", 1368 "te-tp-id": 10001 1369 "te": { 1370 "interface-switching-capability": [ 1371 { 1372 "switching-capability": "switching-l2sc", 1373 "encoding": "lsp-encoding-ethernet" 1374 } 1375 ] 1376 } 1377 }, 1378 { 1379 "tp-id": "LTP-2", 1380 "te-tp-id": 10002 1381 "te": { 1382 "interface-switching-capability": [ 1383 { 1384 "switching-capability": "switching-l2sc", 1385 "encoding": "lsp-encoding-ethernet" 1386 } 1387 ] 1388 } 1389 }, 1390 { 1391 "tp-id": "LTP-3", 1392 "te-tp-id": 10003 1393 "te": { 1394 "interface-switching-capability": [ 1395 { 1396 "switching-capability": "switching-l2sc", 1397 "encoding": "lsp-encoding-ethernet" 1398 } 1399 ] 1400 } 1401 }, 1402 { 1403 "tp-id": "LTP-4", 1404 "te-tp-id": 10004 1405 "te": { 1406 "interface-switching-capability": [ 1407 { 1408 "switching-capability": "switching-l2sc", 1409 "encoding": "lsp-encoding-ethernet" 1410 } 1411 ] 1412 } 1413 } 1414 ] 1415 } 1416 ] 1417 } 1419 ] 1420 } 1421 } 1423 Appendix C. Use Cases for SF Aware Topology Models 1425 C.1. Exporting SF/NF Information to Network Clients and Other Network 1426 SDN Controllers 1428 In the context of Service Function Chain (SFC) orchestration one 1429 existing problem is that there is no way to formally describe a 1430 Service or Network Function in a standard way (recognizable/ 1431 understood by a third party) as a resource of a network topology 1432 node. 1434 One implication of this is that there is no way for the orchestrator 1435 to give a network client even a ball-park idea as to which network's 1436 SFs/NFs are available for the client's use/control and where they are 1437 located in the network even in terms of abstract topologies/virtual 1438 networks configured and managed specifically for the client. 1439 Consequently, the client has no say on how the SFCs provided for the 1440 client by the network should be set up and managed (which SFs are to 1441 be used and how they should be chained together, optimized, 1442 manipulated, protected, etc.). 1444 Likewise, there is no way for the orchestrator to export SF/NF 1445 information to other network controllers. The SFC orchestrator may 1446 serve, for example, a higher level controller (such as Network 1447 Slicing Orchestrator), with the latter wanting at least some level of 1448 control as to which SFs/NFs it wants on its SFCs and how the Service 1449 Function Paths (SFPs) are to be routed and provisioned, especially, 1450 if it uses services of more than one SFC orchestrator. 1452 The issue of exporting of SF/NF information could be addressed by 1453 defining a model, in which formally described/recognizable SF/NF 1454 instances are presented as topological elements, for example, hosted 1455 by TE, L3 or L2 topology nodes (see Figure 1). The model could 1456 describe whether, how and at what costs the SFs/NFs hosted by a given 1457 node could be chained together, how these intra-node SFCs could be 1458 connected to the node's Service Function Forwarders (SFFs, entities 1459 dealing with SFC NSHs and metadata), and how the SFFs could be 1460 connected to the node's Tunnel and Link Termination Points (TTPs and 1461 LTPs) to chain the intra-node SFCs across the network topology. 1463 The figure is available in the PDF format. 1465 Figure 1: SF/NF aware TE topology 1467 C.2. Flat End-to-end SFCs Managed on Multi-domain Networks 1469 SFCs may span multiple administrative domains, each of which 1470 controlled by a separate SFC controller. The usual solution for such 1471 a scenario is the Hierarchical SFCs (H-SFCs) [RFC8459], in which the 1472 higher level orchestrator controls only SFs located on domain border 1473 nodes. Said higher level SFs are chained together into higher level 1474 SFCs via lower level (intra-domain) SFCs provisioned and controlled 1475 independently by respective domain controllers. The decision as to 1476 which higher level SFCs are connected to which lower level SFCs is 1477 driven by packet re-classification every time the packet enters a 1478 given domain. Said packet re-classification is a very time-consuming 1479 operation. Furthermore, the independent nature of higher and lower 1480 level SFC control is prone to configuration errors, which may lead to 1481 long lasting loops and congestions. It is highly desirable to be 1482 able to set up and manage SFCs spanning multiple domains in a flat 1483 way as far as the data plane is concerned (i.e. with a single packet 1484 classification at the ingress into the multi-domain network but 1485 without re-classifications on domain ingress nodes). 1487 One way to achieve this is to have the domain controllers expose SF/ 1488 NF- aware topologies, and have the higher level orchestrator operate 1489 on the network-wide topology, the product of merging of the 1490 topologies catered by the domain controllers. This is similar in 1491 spirit to setting up, coordinating and managing the transport 1492 connectivity (TE tunnels) on a multi-domain multi-vendor transport 1493 network. 1495 C.3. Managing SFCs with TE Constraints 1497 Some SFCs require per SFC link/element and end-to-end TE constrains 1498 (bandwidth, delay/jitter, fate sharing/diversity. etc.). Said 1499 constraints could be ensured via carrying SFPs inside overlays that 1500 are traffic engineered with the constrains in mind. A good analogy 1501 would be orchestrating delay constrained L3 VPNs. One way to support 1502 such L3 VPNs is to carry MPLS LSPs interconnecting per-VPN VRFs 1503 inside delay constrained TE tunnels interconnecting the PEs hosting 1504 the VRFs. 1506 _ 1508 Figure 2: L3 VPN with delay constraints 1510 Planning, computing and provisioning of TE overlays to constrain 1511 arbitrary SFCs, especially those that span multiple administrative 1512 domains with each domain controlled by a separate controller, is a 1513 very difficult challenge. Currently it is addressed by pre- 1514 provisioning on the network of multiple TE tunnels with various TE 1515 characteristics, and "nailing down" SFs/NFs to "strategic" locations 1516 (e.g. nodes terminating many of such tunnels) in a hope that an 1517 adequate set of tunnels could be found to carry the SFP of a given 1518 TE-constrained SFC. Such an approach is especially awkward in the 1519 case when some or all of the SFs/NFs are VNFs (i.e. could be 1520 instantiated at multiple network locations). 1522 SF/NF-aware TE topology model in combination with TE tunnel model 1523 will allow for the network orchestrator (or a client controller) to 1524 compute, set up and manipulate the TE overlays in the form of TE 1525 tunnel chains (see Figure 3). 1527 Said chains could be duel-optimized compromising on optimal SF/NF 1528 locations with optimal TE tunnels interconnecting them. The TE 1529 tunnel chains (carrying multiple similarly constrained SFPs) could be 1530 adequately constrained both at individual TE tunnel level and at the 1531 chain end-to-end level. 1533 _ 1535 Figure 3: SFC with TE constraints 1537 C.4. SFC Protection and Load Balancing 1539 Currently the combination of TE topology & tunnel models offers to a 1540 network controller various capabilities to recover an individual TE 1541 tunnel from network failures occurred on one or more network links or 1542 transit nodes on the TE paths taken by the TE tunnel's connection(s). 1543 However, there is no simple way to recover a TE tunnel from a failure 1544 affecting its source or destination node. SF/NF-aware TE topology 1545 model can decouple the association of a given SF/NF with its location 1546 on the network topology by presenting multiple, identifiable as 1547 mutually substitutable SFs/NFs hosted by different TE topology nodes. 1548 So, for example, if it is detected that a given TE tunnel destination 1549 node is malfunctioning or has gone out of service, the TE tunnel 1550 could be re-routed to terminate on a different node hosting 1551 functionally the same SFs/NFs as ones hosted by the failed node (see 1552 Figures 6). 1554 This is in line with the ACTN edge migration and function mobility 1555 concepts [RFC8453]. It is important to note that the described 1556 strategy works much better for the stateless SFs/NFs. This is 1557 because getting the alternative stateful SFs/NFs into the same 1558 respective states as the current (i.e. active, affected by failure) 1559 are is a very difficult challenge. 1561 _ 1563 Figure 4: SFC recovery: SF2 on node NE1 fails 1565 At the SFC level the SF/NF-aware TE topology model can offer SFC 1566 dynamic restoration capabilities against failed/malfunctioning SFs/ 1567 NFs by identifying and provisioning detours to a TE tunnel chain, so 1568 that it starts carrying the SFC's SFPs towards healthy SFs/NFs that 1569 are functionally the same as the failed ones. Furthermore, multiple 1570 parallel TE tunnel chains could be pre-provisioned for the purpose of 1571 SFC load balancing and end-to-end protection. In the latter case 1572 said parallel TE tunnel chains could be placed to be sufficiently 1573 disjoint from each other. 1575 _ 1577 Figure 5: SFC recovery: SFC SF1-SF2-SF6 is recovered after SF2 on 1578 node N1 has failed 1580 _ 1582 Figure 6: SFC recovery: SFC SF1-SF2-SF6 is recovered after node N1 1583 has failed 1585 C.5. Network Clock Synchronization 1587 Many current and future network applications (including 5g and IoT 1588 applications) require very accurate time services (PTP level, ns 1589 resolution). One way to implement the adequate network clock 1590 synchronization for such services is via describing network clocks as 1591 NFs on an NF-aware TE topology optimized to have best possible delay 1592 variation characteristics. Because such a topology will contain 1593 delay/delay variation metrics of topology links and node cross- 1594 connects, as well as costs in terms of delay/delay variation of 1595 connecting clocks to hosting them node link and tunnel termination 1596 points, it will be possible to dynamically select and provision bi- 1597 directional time-constrained deterministic paths or trees connecting 1598 clocks (e.g. grand master and boundary clocks) for the purpose of 1599 exchange of clock synchronization information. Note that network 1600 clock aware TE topologies separately provided by domain controllers 1601 will enable multi-domain network orchestrator to set up and 1602 manipulate the clock synchronization paths/trees spanning multiple 1603 network domains. 1605 C.6. Client - Provider Network Slicing Interface 1607 3GPP defines network slice as "a set of network functions and the 1608 resources for these network functions which are arranged and 1609 configured, forming a complete logical network to meet certain 1610 network characteristics" [I-D.defoy-netslices-3gpp-network-slicing] 1611 [_3GPP.28.801]. Network slice could be also defined as a logical 1612 partition of a provider's network that is owned and managed by a 1613 tenant. SF/NF-aware TE topology model has a potential to support a 1614 very important interface between network slicing clients and 1615 providers because, on the one hand, the model can describe 1616 holistically and hierarchically the client's requirements and 1617 preferences with respect to a network slice functional, topological 1618 and traffic engineering aspects, as well as of the degree of resource 1619 separation/ sharing between the slices, thus allowing for the client 1620 (up to agreed upon extent) to dynamically (re-)configure the slice or 1621 (re-)schedule said (re-)configurations in time, while, on the other 1622 hand, allowing for the provider to convey to the client the slice's 1623 operational state information and telemetry the client has expressed 1624 interest in. 1626 C.7. Dynamic Assignment of Regenerators for L0 Services 1628 On large optical networks, some of provided to their clients L0 1629 services could not be provisioned as single OCh trails, rather, as 1630 chains of such trails interconnected via regenerators, such as 3R 1631 regenerators. Current practice of the provisioning of such services 1632 requires configuration of explicit paths (EROs) describing identity 1633 and location of regenerators to be used. A solution is highly 1634 desirable that could: 1636 o Identify such services based, for example, on optical impairment 1637 computations; 1639 o Assign adequate for the services regenerators dynamically out of 1640 the regenerators that are grouped together in pools and 1641 strategically scattered over the network topology nodes; 1643 o Compute and provision supporting the services chains of optical 1644 trails interconnected via so selected regenerators, optimizing the 1645 chains to use minimal number of regenerators, their optimal 1646 locations, as well as optimality of optical paths interconnecting 1647 them; 1649 o Ensure recovery of such chains from any failures that could happen 1650 on links, nodes or regenerators along the chain path. 1652 NF-aware TE topology model (in this case L1 NF-aware L0 topology 1653 model) is just the model that could provide a network controller (or 1654 even a client controller operating on abstract NF-aware topologies 1655 provided by the network) to realize described above computations and 1656 orchestrate the service provisioning and network failure recovery 1657 operations (see Figure 7). 1659 _ 1661 Figure 7: Optical tunnel as TE-constrained SFC of 3R regenerators. 1662 Red trail (not regenerated) is not optically reachable, but blue 1663 trail (twice regenerated) is 1665 C.8. Dynamic Assignment of OAM Functions for L1 Services 1667 OAM functionality is normally managed by configuring and manipulating 1668 TCM/MEP functions on network ports terminating connections or their 1669 segments over which OAM operations, such as performance monitoring, 1670 are required to be performed. In some layer networks (e.g. 1671 Ethernet) said TCMs/MEPs could be configured on any network ports. 1672 In others (e.g. OTN/ODUk) the TCMs/MEPs could be configured on some 1673 (but not all network ports) due to the fact that the OAM 1674 functionality (i.e. recognizing and processing of OAM messages, 1675 supporting OAM protocols and FSMs) requires in these layer networks 1676 certain support in the data plane, which is not available on all 1677 network nodes. This makes TCMs/MEPs good candidates to be modeled as 1678 NFs. This also makes TCM/MEP aware topology model a good basis for 1679 placing dynamically an ODUk connection to pass through optimal OAM 1680 locations without mandating the client to specify said locations 1681 explicitly. 1683 _ 1685 Figure 8: Compute/storage resource aware topology 1687 C.9. SFC Abstraction and Scaling 1689 SF/NF-aware topology may contain information on native SFs/NFs (i.e. 1690 SFs/NFs as known to the provider itself) and/or abstract SFs/NFs 1691 (i.e. logical/macro SFs/NFs representing one or more SFCs each made 1692 of native and/or lower level abstract SFs/NFs). As in the case of 1693 abstracting topology nodes, abstracting SFs/NFs is hierarchical in 1694 nature - the higher level of SF/NF-aware topology, the "larger" 1695 abstract SFs/NFs are, i.e. the larger data plane SFCs they represent. 1696 This allows for managing large scale networks with great number of 1697 SFs/NFs (such as Data Center interconnects) in a hierarchical, highly 1698 scalable manner resulting in control of very large number of flat in 1699 the data plane SFCs that span multiple domains. 1701 C.10. Dynamic Compute/VM/Storage Resource Assignment 1703 In a distributed data center network, virtual machines for compute 1704 resources may need to be dynamically re-allocated due to various 1705 reasons such as DCI network failure, compute resource load balancing, 1706 etc. In many cases, the DCI connectivity for the source and the 1707 destination is not predetermined. There may be a pool of sources and 1708 a pool of destination data centers associated with re-allocation of 1709 compute/VM/storage resources. There is no good mechanism to date to 1710 capture this dynamicity nature of compute/VM/storage resource 1711 reallocation. Generic Compute/VM/Storage resources can be described 1712 and announced as a SF, where a DC hosting these resources can be 1713 modeled as an abstract node. Topology interconnecting these abstract 1714 nodes (DCs) in general is of multi-domain nature. Thus, SF-aware 1715 topology model can facilitate a joint optimization of TE network 1716 resources and Compute/VM/Storage resources and solve Compute/VM/ 1717 Storage mobility problem within and between DCs (see Figure 8). 1719 C.11. Application-aware Resource Operations and Management 1721 Application stratum is the functional grouping which encompasses 1722 application resources and the control and management of these 1723 resources. These application resources are used along with network 1724 services to provide an application service to clients/end-users. 1725 Application resources are non-network resources critical to achieving 1726 the application service functionality. Examples of application 1727 resources include: caches, mirrors, application specific servers, 1728 content, large data sets, and computing power. Application service 1729 is a networked application offered to a variety of clients (e.g., 1730 server backup, VM migration, video cache, virtual network on-demand, 1731 5G network slicing, etc.). The application servers that host these 1732 application resources can be modeled as an abstract node. There may 1733 be a variety of server types depending on the resources they host. 1734 Figure 9 shows one example application aware topology for video cache 1735 server distribution. 1737 _ 1739 Figure 9: Application aware topology 1741 C.12. IANA Considerations 1743 This document has no actions for IANA. 1745 C.13. Security Considerations 1747 This document does not define networking protocols and data, hence is 1748 not directly responsible for security risks. 1750 C.14. Acknowledgements 1752 The authors would like to thank Maarten Vissers, Joel Halpern, and 1753 Greg Mirsky for their helpful comments and valuable contributions. 1755 Authors' Addresses 1757 Igor Bryskin 1758 Individual 1760 EMail: i_bryskin@yahoo.com 1762 Xufeng Liu 1763 Volta Networks 1765 EMail: xufeng.liu.ietf@gmail.com 1767 Young Lee 1768 Sung Kyun Kwan University 1770 EMail: younglee.tx@gmail.com 1772 Jim Guichard 1773 Huawei Technologies 1775 EMail: james.n.guichard@huawei.com 1777 Luis Miguel Contreras Murillo 1778 Telefonica 1780 EMail: luismiguel.contrerasmurillo@telefonica.com 1781 Daniele Ceccarelli 1782 Ericsson 1784 EMail: daniele.ceccarelli@ericsson.com 1786 Jeff Tantsura 1787 Apstra Networks 1789 EMail: jefftant.ietf@gmail.com