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