idnits 2.17.1 draft-ietf-teas-sf-aware-topo-model-03.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 (March 11, 2019) is 1873 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 1151, 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. -------------------------------------------------------------------------------- 1 Network Working Group I. Bryskin 2 Internet-Draft Huawei Technologies 3 Intended status: Informational X. Liu 4 Expires: September 12, 2019 Volta Networks 5 Y. Lee 6 J. Guichard 7 Huawei Technologies 8 L. Contreras 9 Telefonica 10 D. Ceccarelli 11 Ericsson 12 J. Tantsura 13 Apstra Networks 15 March 11, 2019 17 SF Aware TE Topology YANG Model 18 draft-ietf-teas-sf-aware-topo-model-03 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 September 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 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 [ETSI-NFV-TERM] 1131 ETSI, "Network Functions Virtualisation (NFV); Terminology 1132 for Main Concepts in NFV", ETSI GS NFV 003 V1.2.1, 1133 December 2014. 1135 [I-D.ietf-teas-yang-te] 1136 Saad, T., Gandhi, R., Liu, X., Beeram, V., Shah, H., and 1137 I. Bryskin, "A YANG Data Model for Traffic Engineering 1138 Tunnels and Interfaces", draft-ietf-teas-yang-te-16 (work 1139 in progress), July 2018. 1141 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 1142 Address Translator (Traditional NAT)", RFC 3022, 1143 DOI 10.17487/RFC3022, January 2001, 1144 . 1146 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 1147 NAT64: Network Address and Protocol Translation from IPv6 1148 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, 1149 April 2011, . 1151 [I-D.ietf-sfc-hierarchical] 1152 Dolson, D., Homma, S., Lopez, D., and M. Boucadair, 1153 "Hierarchical Service Function Chaining (hSFC)", draft- 1154 ietf-sfc-hierarchical-11 (work in progress), June 2018. 1156 [I-D.defoy-netslices-3gpp-network-slicing] 1157 Foy, X. and A. Rahman, "Network Slicing - 3GPP Use Case", 1158 draft-defoy-netslices-3gpp-network-slicing-02 (work in 1159 progress), October 2017. 1161 [_3GPP.28.801] 1162 3GPP, "Study on management and orchestration of network 1163 slicing for next generation network", 3GPP TR 28.801 1164 V2.0.0, September 2017, 1165 . 1167 [RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for 1168 Abstraction and Control of TE Networks (ACTN)", RFC 8453, 1169 DOI 10.17487/RFC8453, August 2018, 1170 . 1172 9.2. Informative References 1174 [RFC7498] Quinn, P., Ed. and T. Nadeau, Ed., "Problem Statement for 1175 Service Function Chaining", RFC 7498, 1176 DOI 10.17487/RFC7498, April 2015, 1177 . 1179 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 1180 Chaining (SFC) Architecture", RFC 7665, 1181 DOI 10.17487/RFC7665, October 2015, 1182 1184 [I-D.ietf-netmod-yang-tree-diagrams] 1185 Bjorklund, M. and L. Berger, "YANG Tree Diagrams", draft- 1186 ietf-netmod-yang-tree-diagrams-06 (work in progress), 1187 February 2018. 1189 Appendix A. Companion YANG Model for Non-NMDA Compliant Implementations 1191 The YANG module ietf-te-topology-sf defined in this document is 1192 designed to be used in conjunction with implementations that support 1193 the Network Management Datastore Architecture (NMDA) defined in 1194 [I-D.ietf-netmod-revised-datastores]. In order to allow 1195 implementations to use the model even in cases when NMDA is not 1196 supported, the following companion module, ietf-te-topology-sf-state, 1197 is defined as state model, which mirrors the module ietf-te-topology- 1198 sf defined earlier in this document. However, all data nodes in the 1199 companion module are non-configurable, to represent the applied 1200 configuration or the derived operational states. 1202 The companion module, ietf-te-topology-sf-state, is redundant and 1203 SHOULD NOT be supported by implementations that support NMDA. 1205 As the structure of the companion module mirrors that of the 1206 coorespinding NMDA model, the YANG tree of the companion module is 1207 not depicted separately. 1209 A.1. SF Aware TE Topology State Module 1211 file "ietf-te-topology-sf-state@2018-02-27.yang" 1212 module ietf-te-topology-sf-state { 1213 yang-version 1; 1214 namespace "urn:ietf:params:xml:ns:yang:ietf-te-topology-sf-state"; 1216 prefix "tet-sf-s"; 1218 import ietf-te-topology-sf { 1219 prefix "tet-sf"; 1220 } 1222 import ietf-network-state { 1223 prefix "nw-s"; 1224 } 1226 import ietf-network-topology-state { 1227 prefix "nt-s"; 1228 } 1230 import ietf-te-topology-state { 1231 prefix "tet-s"; 1232 } 1234 organization 1235 "Traffic Engineering Architecture and Signaling (TEAS) 1236 Working Group"; 1238 contact 1239 "WG Web: 1240 WG List: 1242 Editors: Igor Bryskin 1243 1245 Xufeng Liu 1246 "; 1248 description 1249 "Network service and function aware aware TE topology operational 1250 state model for non-NMDA compliant implementations. 1252 Copyright (c) 2018 IETF Trust and the persons identified as 1253 authors of the code. All rights reserved. 1255 Redistribution and use in source and binary forms, with or 1256 without modification, is permitted pursuant to, and subject to 1257 the license terms contained in, the Simplified BSD License set 1258 forth in Section 4.c of the IETF Trust's Legal Provisions 1259 Relating to IETF Documents 1260 (http://trustee.ietf.org/license-info)."; 1262 revision 2018-02-27 { 1263 description "Initial revision"; 1264 reference "TBD"; 1265 } 1267 /* 1268 * Augmentations 1269 */ 1270 /* Augmentations to network-types/te-topology */ 1271 augment "/nw-s:networks/nw-s:network/nw-s:network-types/" 1272 + "tet-s:te-topology" { 1273 description 1274 "Defines the SF aware TE topology type."; 1275 uses tet-sf:sf-topology-type; 1276 } 1278 /* Augmentations to connectivity-matrix */ 1279 augment "/nw-s:networks/nw-s:network/nw-s:node/tet-s:te/" 1280 + "tet-s:te-node-attributes" { 1281 description 1282 "Parameters for SF aware TE topology."; 1283 uses tet-sf:service-function-node-augmentation; 1285 } 1287 augment "/nw-s:networks/nw-s:network/nw-s:node/tet-s:te/" 1288 + "tet-s:information-source-entry" { 1289 description 1290 "Parameters for SF aware TE topology."; 1291 uses tet-sf:service-function-node-augmentation; 1292 } 1294 /* Augmentations to tunnel-termination-point */ 1295 augment "/nw-s:networks/nw-s:network/nw-s:node/tet-s:te/" 1296 + "tet-s:tunnel-termination-point" { 1297 description 1298 "Parameters for SF aware TE topology."; 1299 uses tet-sf:service-function-ttp-augmentation; 1300 } 1302 /* Augmentations to connectivity-matrix */ 1303 augment "/nw-s:networks/nw-s:network/nw-s:node/tet-s:te/" 1304 + "tet-s:te-node-attributes/tet-sf-s:service-function/" 1305 + "tet-sf-s:link-terminations/tet-sf-s:link-termination/" 1306 + "tet-sf-s:from" { 1307 description 1308 "Add reference to the link termination point. 1309 This portion cannot be shared with the state module."; 1310 leaf tp-ref { 1311 type leafref { 1312 path "../../../../../../../nt-s:termination-point/" 1313 + "nt-s:tp-id"; 1314 } 1315 description 1316 "Reference to the link termination point."; 1317 } 1318 } 1319 } 1320 1322 Appendix B. Data Examples 1324 B.1. A Topology with Multiple Connected Network Functions 1325 Node-1 1326 +----o--o--------------------------o-------+ 1327 | | | | | 1328 | \__/ \__ | 1329 | *\/ TTP-1 * * * * * * * * * *\/* | 1330 LTP-4 |* * * * TTP-2 * | LTP-1 1331 o------------*-----------------------------o 1332 | * * | 1333 LTP-3 |* * * * * *| LTP-2 1334 o--- -----o 1335 | \ / | 1336 | \ / | 1337 | \ CP01 CP02/ | 1338 | +----o--------------------------o------+ | 1339 | | VL1| VL4| | | 1340 | | |CP11 |CP33 | | 1341 | | +-o--+ +----+ +-o--+ | | 1342 | | |VNF1| |VNF2| |VNF3| | | 1343 | | +-o-o+ VL2 +--o-+ VL2 +-o-o+ | | 1344 | |CP12| |\----------/ \---------/| |CP32| | 1345 | | | |CP13 CP21 CP31| | | | 1346 | | | | VL2 | | | | 1347 | | | +------------------------+ | | | 1348 | | +----------------------------+ | | 1349 | | VL3 | | 1350 | | Network Service 1 | | 1351 | +--------------------------------------+ | 1352 +------------------------------------------+ 1354 The configuration instance data for Node-1 in the above figure could 1355 be as follows: 1357 { 1358 "networks": { 1359 "network": [ 1360 { 1361 "network-types": { 1362 "te-topology": { 1363 "sf": {} 1364 } 1365 }, 1366 "network-id": "network-sf-aware", 1367 "provider-id": 201, 1368 "client-id": 300, 1369 "te-topology-id": "te-topology:network-sf-aware", 1370 "node": [ 1371 { 1372 "node-id": "Node-1", 1373 "te-node-id": "2.0.1.1", 1374 "te": { 1375 "te-node-attributes": { 1376 "domain-id": 1, 1377 "is-abstract": [null], 1378 "connectivity-matrices": { 1379 }, 1380 "service-function": { 1381 "connectivity-matrices": { 1382 "connectivity-matrix": [ 1383 { 1384 "id": 10, 1385 "from": { 1386 "service-function-id": "Network Service 1", 1387 "sf-connection-point-id": "CP01" 1388 }, 1389 "to": { 1390 "service-function-id": "VNF1", 1391 "sf-connection-point-id": "CP11" 1392 } 1393 "direction": "bidir", 1394 "virtual-link-id": "VL1" 1395 }, 1396 { 1397 "id": 13, 1398 "from": { 1399 "service-function-id": "VNF1", 1400 "sf-connection-point-id": "CP12" 1401 }, 1402 "to": { 1403 "service-function-id": "VNF3", 1404 "sf-connection-point-id": "CP32" 1405 } 1406 "direction": "bidir", 1407 "virtual-link-id": "VL3" 1408 }, 1409 { 1410 "id": 12, 1411 "from": { 1412 "service-function-id": "VNF1", 1413 "sf-connection-point-id": "CP13" 1414 }, 1415 "to": { 1416 "service-function-id": "VNF2", 1417 "sf-connection-point-id": "CP21" 1418 } 1419 "direction": "bidir", 1420 "virtual-link-id": "VL2" 1422 }, 1423 { 1424 "id": 23, 1425 "from": { 1426 "service-function-id": "VNF2", 1427 "sf-connection-point-id": "CP21" 1428 }, 1429 "to": { 1430 "service-function-id": "VNF3" 1431 "sf-connection-point-id": "CP31" 1432 } 1433 "direction": "bidir", 1434 "virtual-link-id": "VL2" 1435 }, 1436 { 1437 "id": 30, 1438 "from": { 1439 "service-function-id": "Network Service 1", 1440 "sf-connection-point-id": "CP02" 1441 }, 1442 "to": { 1443 "service-function-id": "VNF3", 1444 "sf-connection-point-id": "CP33" 1445 } 1446 "direction": "bidir", 1447 "virtual-link-id": "VL4" 1448 } 1449 ] 1450 }, 1451 "link-terminations": { 1452 "link-termination": [ 1453 { 1454 "id": 2, 1455 "from": { 1456 "tp-ref": "LTP-2" 1457 }, 1458 "to": { 1459 "service-function-id": "Network Service 1", 1460 "sf-connection-point-id": "CP02" 1461 } 1462 "direction": "bidir" 1463 }, 1464 { 1465 "id": 3, 1466 "from": { 1467 "tp-ref": "LTP-3" 1468 }, 1469 "to": { 1470 "service-function-id": "Network Service 1", 1471 "sf-connection-point-id": "CP01" 1472 } 1473 "direction": "bidir" 1474 } 1475 ] 1476 } 1477 } 1478 } 1479 "tunnel-termination-point": [ 1480 { 1481 "tunnel-tp-id": 10001, 1482 "name": "TTP-1", 1483 "service-function-terminations": { 1484 } 1485 }, 1486 { 1487 "tunnel-tp-id": 10002, 1488 "name": "TTP-2", 1489 "service-function-terminations": { 1490 } 1491 } 1492 ] 1493 }, 1494 "termination-point": [ 1495 { 1496 "tp-id": "LTP-1", 1497 "te-tp-id": 10001 1498 "te": { 1499 "interface-switching-capability": [ 1500 { 1501 "switching-capability": "switching-l2sc", 1502 "encoding": "lsp-encoding-ethernet" 1503 } 1504 ] 1505 } 1506 }, 1507 { 1508 "tp-id": "LTP-2", 1509 "te-tp-id": 10002 1510 "te": { 1511 "interface-switching-capability": [ 1512 { 1513 "switching-capability": "switching-l2sc", 1514 "encoding": "lsp-encoding-ethernet" 1515 } 1516 ] 1517 } 1519 }, 1520 { 1521 "tp-id": "LTP-3", 1522 "te-tp-id": 10003 1523 "te": { 1524 "interface-switching-capability": [ 1525 { 1526 "switching-capability": "switching-l2sc", 1527 "encoding": "lsp-encoding-ethernet" 1528 } 1529 ] 1530 } 1531 }, 1532 { 1533 "tp-id": "LTP-4", 1534 "te-tp-id": 10004 1535 "te": { 1536 "interface-switching-capability": [ 1537 { 1538 "switching-capability": "switching-l2sc", 1539 "encoding": "lsp-encoding-ethernet" 1540 } 1541 ] 1542 } 1543 } 1544 ] 1545 } 1546 ] 1547 } 1548 ] 1549 } 1550 } 1552 B.2. A Topology with an Encapsulated Network Service 1554 In this example, a network service consists of several inter- 1555 connected network functions (NFs), and is represented by this model 1556 as an encapsulated opaque object without the details between its 1557 internals. 1559 Node-1 1560 +----o--o--------------------------o-------+ 1561 | | | | | 1562 | \__/ \__ | 1563 | *\/ TTP-1 * * * * * * * * * *\/* | 1564 LTP-4 |* * * * TTP-2 * | LTP-1 1565 o------------*-----------------------------o 1566 | * * | 1567 LTP-3 |* * * * * *| LTP-2 1568 o--- -----o 1569 | \ / | 1570 | \ / | 1571 | \ CP01 CP02/ | 1572 | +----o--------------------------o------+ | 1573 | | | | 1574 | | Network Service 1 | | 1575 | +--------------------------------------+ | 1576 +------------------------------------------+ 1578 The configuration instance data for Node-1 in the above figure could 1579 be as follows: 1581 { 1582 "networks": { 1583 "network": [ 1584 { 1585 "network-types": { 1586 "te-topology": { 1587 "sf": {} 1588 } 1589 }, 1590 "network-id": "network-sf-aware", 1591 "provider-id": 201, 1592 "client-id": 300, 1593 "te-topology-id": "te-topology:network-sf-aware", 1594 "node": [ 1595 { 1596 "node-id": "Node-1", 1597 "te-node-id": "2.0.1.1", 1598 "te": { 1599 "te-node-attributes": { 1600 "domain-id": 1, 1601 "is-abstract": [null], 1602 "connectivity-matrices": { 1603 }, 1604 "service-function": { 1605 "connectivity-matrices": { 1606 }, 1607 "link-terminations": { 1608 "link-termination": [ 1609 { 1610 "id": 2, 1611 "from": { 1612 "tp-ref": "LTP-2" 1613 }, 1614 "to": { 1615 "service-function-id": "Network Service 1", 1616 "sf-connection-point-id": "CP02" 1617 } 1618 "direction": "bidir" 1619 }, 1620 { 1621 "id": 3, 1622 "from": { 1623 "tp-ref": "LTP-3" 1624 }, 1625 "to": { 1626 "service-function-id": "Network Service 1", 1627 "sf-connection-point-id": "CP01" 1628 } 1629 "direction": "bidir" 1630 } 1631 ] 1632 } 1633 } 1634 } 1635 "tunnel-termination-point": [ 1636 { 1637 "tunnel-tp-id": 10001, 1638 "name": "TTP-1", 1639 "service-function-terminations": { 1640 } 1641 }, 1642 { 1643 "tunnel-tp-id": 10002, 1644 "name": "TTP-2", 1645 "service-function-terminations": { 1646 } 1647 } 1648 ] 1649 }, 1650 "termination-point": [ 1651 { 1652 "tp-id": "LTP-1", 1653 "te-tp-id": 10001 1654 "te": { 1655 "interface-switching-capability": [ 1656 { 1657 "switching-capability": "switching-l2sc", 1658 "encoding": "lsp-encoding-ethernet" 1659 } 1660 ] 1661 } 1662 }, 1663 { 1664 "tp-id": "LTP-2", 1665 "te-tp-id": 10002 1666 "te": { 1667 "interface-switching-capability": [ 1668 { 1669 "switching-capability": "switching-l2sc", 1670 "encoding": "lsp-encoding-ethernet" 1671 } 1672 ] 1673 } 1674 }, 1675 { 1676 "tp-id": "LTP-3", 1677 "te-tp-id": 10003 1678 "te": { 1679 "interface-switching-capability": [ 1680 { 1681 "switching-capability": "switching-l2sc", 1682 "encoding": "lsp-encoding-ethernet" 1683 } 1684 ] 1685 } 1686 }, 1687 { 1688 "tp-id": "LTP-4", 1689 "te-tp-id": 10004 1690 "te": { 1691 "interface-switching-capability": [ 1692 { 1693 "switching-capability": "switching-l2sc", 1694 "encoding": "lsp-encoding-ethernet" 1695 } 1696 ] 1697 } 1698 } 1699 ] 1700 } 1701 ] 1702 } 1704 ] 1705 } 1706 } 1708 Appendix C. Use Cases for SF Aware Topology Models 1710 C.1. Exporting SF/NF Information to Network Clients and Other Network 1711 SDN Controllers 1713 In the context of Service Function Chain (SFC) orchestration one 1714 existing problem is that there is no way to formally describe a 1715 Service or Network Function in a standard way (recognizable/ 1716 understood by a third party) as a resource of a network topology 1717 node. 1719 One implication of this is that there is no way for the orchestrator 1720 to give a network client even a ball-park idea as to which network's 1721 SFs/NFs are available for the client's use/control and where they are 1722 located in the network even in terms of abstract topologies/virtual 1723 networks configured and managed specifically for the client. 1724 Consequently, the client has no say on how the SFCs provided for the 1725 client by the network should be set up and managed (which SFs are to 1726 be used and how they should be chained together, optimized, 1727 manipulated, protected, etc.). 1729 Likewise, there is no way for the orchestrator to export SF/NF 1730 information to other network controllers. The SFC orchestrator may 1731 serve, for example, a higher level controller (such as Network 1732 Slicing Orchestrator), with the latter wanting at least some level of 1733 control as to which SFs/NFs it wants on its SFCs and how the Service 1734 Function Paths (SFPs) are to be routed and provisioned, especially, 1735 if it uses services of more than one SFC orchestrator. 1737 The issue of exporting of SF/NF information could be addressed by 1738 defining a model, in which formally described/recognizable SF/NF 1739 instances are presented as topological elements, for example, hosted 1740 by TE, L3 or L2 topology nodes (see Figure 1). The model could 1741 describe whether, how and at what costs the SFs/NFs hosted by a given 1742 node could be chained together, how these intra-node SFCs could be 1743 connected to the node's Service Function Forwarders (SFFs, entities 1744 dealing with SFC NSHs and metadata), and how the SFFs could be 1745 connected to the node's Tunnel and Link Termination Points (TTPs and 1746 LTPs) to chain the intra-node SFCs across the network topology. 1748 Figure 1: SF/NF aware TE topology 1750 C.2. Flat End-to-end SFCs Managed on Multi-domain Networks 1752 SFCs may span multiple administrative domains, each of which 1753 controlled by a separate SFC controller. The usual solution for such 1754 a scenario is the Hierarchical SFCs (H-SFCs), in which the higher 1755 level orchestrator controls only SFs located on domain border nodes. 1756 Said higher level SFs are chained together into higher level SFCs via 1757 lower level (intra-domain) SFCs provisioned and controlled 1758 independently by respective domain controllers. The decision as to 1759 which higher level SFCs are connected to which lower level SFCs is 1760 driven by packet re-classification every time the packet enters a 1761 given domain. Said packet re-classification is a very time-consuming 1762 operation. Furthermore, the independent nature of higher and lower 1763 level SFC control is prone to configuration errors, which may lead to 1764 long lasting loops and congestions. It is highly desirable to be 1765 able to set up and manage SFCs spanning multiple domains in a flat 1766 way as far as the data plane is concerned (i.e. with a single packet 1767 classification at the ingress into the multi-domain network but 1768 without re-classifications on domain ingress nodes). 1770 One way to achieve this is to have the domain controllers expose SF/ 1771 NF- aware topologies, and have the higher level orchestrator operate 1772 on the network-wide topology, the product of merging of the 1773 topologies catered by the domain controllers. This is similar in 1774 spirit to setting up, coordinating and managing the transport 1775 connectivity (TE tunnels) on a multi-domain multi-vendor transport 1776 network. 1778 C.3. Managing SFCs with TE Constraints 1780 Some SFCs require per SFC link/element and end-to-end TE constrains 1781 (bandwidth, delay/jitter, fate sharing/diversity. etc.). Said 1782 constraints could be ensured via carrying SFPs inside overlays that 1783 are traffic engineered with the constrains in mind. A good analogy 1784 would be orchestrating delay constrained L3 VPNs. One way to support 1785 such L3 VPNs is to carry MPLS LSPs interconnecting per-VPN VRFs 1786 inside delay constrained TE tunnels interconnecting the PEs hosting 1787 the VRFs. 1789 Figure 2: L3 VPN with delay constraints 1791 Planning, computing and provisioning of TE overlays to constrain 1792 arbitrary SFCs, especially those that span multiple administrative 1793 domains with each domain controlled by a separate controller, is a 1794 very difficult challenge. Currently it is addressed by pre- 1795 provisioning on the network of multiple TE tunnels with various TE 1796 characteristics, and "nailing down" SFs/NFs to "strategic" locations 1797 (e.g. nodes terminating many of such tunnels) in a hope that an 1798 adequate set of tunnels could be found to carry the SFP of a given 1799 TE-constrained SFC. Such an approach is especially awkward in the 1800 case when some or all of the SFs/NFs are VNFs (i.e. could be 1801 instantiated at multiple network locations). 1803 SF/NF-aware TE topology model in combination with TE tunnel model 1804 will allow for the network orchestrator (or a client controller) to 1805 compute, set up and manipulate the TE overlays in the form of TE 1806 tunnel chains (see Figure 3). 1808 Said chains could be duel-optimized compromising on optimal SF/NF 1809 locations with optimal TE tunnels interconnecting them. The TE 1810 tunnel chains (carrying multiple similarly constrained SFPs) could be 1811 adequately constrained both at individual TE tunnel level and at the 1812 chain end-to-end level. 1814 Figure 3: SFC with TE constraints 1816 C.4. SFC Protection and Load Balancing 1818 Currently the combination of TE topology & tunnel models offers to a 1819 network controller various capabilities to recover an individual TE 1820 tunnel from network failures occurred on one or more network links or 1821 transit nodes on the TE paths taken by the TE tunnel's connection(s). 1822 However, there is no simple way to recover a TE tunnel from a failure 1823 affecting its source or destination node. SF/NF-aware TE topology 1824 model can decouple the association of a given SF/NF with its location 1825 on the network topology by presenting multiple, identifiable as 1826 mutually substitutable SFs/NFs hosted by different TE topology nodes. 1827 So, for example, if it is detected that a given TE tunnel destination 1828 node is malfunctioning or has gone out of service, the TE tunnel 1829 could be re-routed to terminate on a different node hosting 1830 functionally the same SFs/NFs as ones hosted by the failed node (see 1831 Figures 6). 1833 This is in line with the ACTN edge migration and function mobility 1834 concepts [RFC8453]. It is important to note that the described 1835 strategy works much better for the stateless SFs/NFs. This is 1836 because getting the alternative stateful SFs/NFs into the same 1837 respective states as the current (i.e. active, affected by failure) 1838 are is a very difficult challenge. 1840 Figure 4: SFC recovery: SF2 on node NE1 fails 1842 At the SFC level the SF/NF-aware TE topology model can offer SFC 1843 dynamic restoration capabilities against failed/malfunctioning SFs/ 1844 NFs by identifying and provisioning detours to a TE tunnel chain, so 1845 that it starts carrying the SFC's SFPs towards healthy SFs/NFs that 1846 are functionally the same as the failed ones. Furthermore, multiple 1847 parallel TE tunnel chains could be pre-provisioned for the purpose of 1848 SFC load balancing and end-to-end protection. In the latter case 1849 said parallel TE tunnel chains could be placed to be sufficiently 1850 disjoint from each other. 1852 Figure 5: SFC recovery: SFC SF1-SF2-SF6 is recovered after SF2 on 1853 node N1 has failed 1855 Figure 6: SFC recovery: SFC SF1-SF2-SF6 is recovered after node N1 1856 has failed 1858 C.5. Network Clock Synchronization 1860 Many current and future network applications (including 5g and IoT 1861 applications) require very accurate time services (PTP level, ns 1862 resolution). One way to implement the adequate network clock 1863 synchronization for such services is via describing network clocks as 1864 NFs on an NF-aware TE topology optimized to have best possible delay 1865 variation characteristics. Because such a topology will contain 1866 delay/delay variation metrics of topology links and node cross- 1867 connects, as well as costs in terms of delay/delay variation of 1868 connecting clocks to hosting them node link and tunnel termination 1869 points, it will be possible to dynamically select and provision bi- 1870 directional time-constrained deterministic paths or trees connecting 1871 clocks (e.g. grand master and boundary clocks) for the purpose of 1872 exchange of clock synchronization information. Note that network 1873 clock aware TE topologies separately provided by domain controllers 1874 will enable multi-domain network orchestrator to set up and 1875 manipulate the clock synchronization paths/trees spanning multiple 1876 network domains. 1878 C.6. Client - Provider Network Slicing Interface 1880 3GPP defines network slice as "a set of network functions and the 1881 resources for these network functions which are arranged and 1882 configured, forming a complete logical network to meet certain 1883 network characteristics" [I-D.defoy-netslices-3gpp-network-slicing] 1884 [_3GPP.28.801]. Network slice could be also defined as a logical 1885 partition of a provider's network that is owned and managed by a 1886 tenant. SF/NF-aware TE topology model has a potential to support a 1887 very important interface between network slicing clients and 1888 providers because, on the one hand, the model can describe 1889 holistically and hierarchically the client's requirements and 1890 preferences with respect to a network slice functional, topological 1891 and traffic engineering aspects, as well as of the degree of resource 1892 separation/ sharing between the slices, thus allowing for the client 1893 (up to agreed upon extent) to dynamically (re-)configure the slice or 1894 (re-)schedule said (re-)configurations in time, while, on the other 1895 hand, allowing for the provider to convey to the client the slice's 1896 operational state information and telemetry the client has expressed 1897 interest in. 1899 C.7. Dynamic Assignment of Regenerators for L0 Services 1901 On large optical networks, some of provided to their clients L0 1902 services could not be provisioned as single OCh trails, rather, as 1903 chains of such trails interconnected via regenerators, such as 3R 1904 regenerators. Current practice of the provisioning of such services 1905 requires configuration of explicit paths (EROs) describing identity 1906 and location of regenerators to be used. A solution is highly 1907 desirable that could: 1909 o Identify such services based, for example, on optical impairment 1910 computations; 1912 o Assign adequate for the services regenerators dynamically out of 1913 the regenerators that are grouped together in pools and 1914 strategically scattered over the network topology nodes; 1916 o Compute and provision supporting the services chains of optical 1917 trails interconnected via so selected regenerators, optimizing the 1918 chains to use minimal number of regenerators, their optimal 1919 locations, as well as optimality of optical paths interconnecting 1920 them; 1922 o Ensure recovery of such chains from any failures that could happen 1923 on links, nodes or regenerators along the chain path. 1925 NF-aware TE topology model (in this case L1 NF-aware L0 topology 1926 model) is just the model that could provide a network controller (or 1927 even a client controller operating on abstract NF-aware topologies 1928 provided by the network) to realize described above computations and 1929 orchestrate the service provisioning and network failure recovery 1930 operations (see Figure 7). 1932 Figure 7: Optical tunnel as TE-constrained SFC of 3R regenerators. 1933 Red trail (not regenerated) is not optically reachable, but blue 1934 trail (twice regenerated) is 1936 C.8. Dynamic Assignment of OAM Functions for L1 Services 1938 OAM functionality is normally managed by configuring and manipulating 1939 TCM/MEP functions on network ports terminating connections or their 1940 segments over which OAM operations, such as performance monitoring, 1941 are required to be performed. In some layer networks (e.g. 1942 Ethernet) said TCMs/MEPs could be configured on any network ports. 1943 In others (e.g. OTN/ODUk) the TCMs/MEPs could be configured on some 1944 (but not all network ports) due to the fact that the OAM 1945 functionality (i.e. recognizing and processing of OAM messages, 1946 supporting OAM protocols and FSMs) requires in these layer networks 1947 certain support in the data plane, which is not available on all 1948 network nodes. This makes TCMs/MEPs good candidates to be modeled as 1949 NFs. This also makes TCM/MEP aware topology model a good basis for 1950 placing dynamically an ODUk connection to pass through optimal OAM 1951 locations without mandating the client to specify said locations 1952 explicitly. 1954 Figure 8: Compute/storage resource aware topology 1956 C.9. SFC Abstraction and Scaling 1958 SF/NF-aware topology may contain information on native SFs/NFs (i.e. 1959 SFs/NFs as known to the provider itself) and/or abstract SFs/NFs 1960 (i.e. logical/macro SFs/NFs representing one or more SFCs each made 1961 of native and/or lower level abstract SFs/NFs). As in the case of 1962 abstracting topology nodes, abstracting SFs/NFs is hierarchical in 1963 nature - the higher level of SF/NF-aware topology, the "larger" 1964 abstract SFs/NFs are, i.e. the larger data plane SFCs they represent. 1965 This allows for managing large scale networks with great number of 1966 SFs/NFs (such as Data Center interconnects) in a hierarchical, highly 1967 scalable manner resulting in control of very large number of flat in 1968 the data plane SFCs that span multiple domains. 1970 C.10. Dynamic Compute/VM/Storage Resource Assignment 1972 In a distributed data center network, virtual machines for compute 1973 resources may need to be dynamically re-allocated due to various 1974 reasons such as DCI network failure, compute resource load balancing, 1975 etc. In many cases, the DCI connectivity for the source and the 1976 destination is not predetermined. There may be a pool of sources and 1977 a pool of destination data centers associated with re-allocation of 1978 compute/VM/storage resources. There is no good mechanism to date to 1979 capture this dynamicity nature of compute/VM/storage resource 1980 reallocation. Generic Compute/VM/Storage resources can be described 1981 and announced as a SF, where a DC hosting these resources can be 1982 modeled as an abstract node. Topology interconnecting these abstract 1983 nodes (DCs) in general is of multi-domain nature. Thus, SF-aware 1984 topology model can facilitate a joint optimization of TE network 1985 resources and Compute/VM/Storage resources and solve Compute/VM/ 1986 Storage mobility problem within and between DCs (see Figure 8). 1988 C.11. Application-aware Resource Operations and Management 1990 Application stratum is the functional grouping which encompasses 1991 application resources and the control and management of these 1992 resources. These application resources are used along with network 1993 services to provide an application service to clients/end-users. 1994 Application resources are non-network resources critical to achieving 1995 the application service functionality. Examples of application 1996 resources include: caches, mirrors, application specific servers, 1997 content, large data sets, and computing power. Application service 1998 is a networked application offered to a variety of clients (e.g., 1999 server backup, VM migration, video cache, virtual network on-demand, 2000 5G network slicing, etc.). The application servers that host these 2001 application resources can be modeled as an abstract node. There may 2002 be a variety of server types depending on the resources they host. 2003 Figure 9 shows one example application aware topology for video cache 2004 server distribution. 2006 Figure 9: Application aware topology 2008 C.12. IANA Considerations 2010 This document has no actions for IANA. 2012 C.13. Security Considerations 2014 This document does not define networking protocols and data, hence is 2015 not directly responsible for security risks. 2017 C.14. Acknowledgements 2019 The authors would like to thank Maarten Vissers, Joel Halpern, and 2020 Greg Mirsky for their helpful comments and valuable contributions. 2022 Authors' Addresses 2024 Igor Bryskin 2025 Huawei Technologies 2027 EMail: Igor.Bryskin@huawei.com 2029 Xufeng Liu 2030 Volta Networks 2032 EMail: xufeng.liu.ietf@gmail.com 2034 Young Lee 2035 Huawei Technologies 2037 EMail: leeyoung@huawei.com 2039 Jim Guichard 2040 Huawei Technologies 2042 EMail: james.n.guichard@huawei.com 2044 Luis Miguel Contreras Murillo 2045 Telefonica 2047 EMail: luismiguel.contrerasmurillo@telefonica.com 2048 Daniele Ceccarelli 2049 Ericsson 2051 EMail: daniele.ceccarelli@ericsson.com 2053 Jeff Tantsura 2054 Apstra Networks 2056 EMail: jefftant.ietf@gmail.com