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