idnits 2.17.1 draft-wd-teas-transport-slice-yang-01.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 : ---------------------------------------------------------------------------- ** There are 7 instances of too long lines in the document, the longest one being 23 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 278 has weird spacing: '...ic-type ide...' == Line 302 has weird spacing: '...ch-type ide...' == 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 (April 17, 2020) is 1469 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: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'I-D.liu-teas-transport-network-slice-yang' is defined on line 1385, but no explicit reference was found in the text == Unused Reference: 'RFC6991' is defined on line 1416, but no explicit reference was found in the text == Unused Reference: 'RFC7317' is defined on line 1420, but no explicit reference was found in the text == Unused Reference: 'RFC8299' is defined on line 1436, but no explicit reference was found in the text == Unused Reference: 'RFC8466' is defined on line 1459, but no explicit reference was found in the text == Outdated reference: A later version (-24) exists of draft-ietf-teas-actn-vn-yang-08 == Outdated reference: A later version (-09) exists of draft-liu-teas-transport-network-slice-yang-00 == Outdated reference: A later version (-05) exists of draft-nsdt-teas-ns-framework-02 ** Downref: Normative reference to an Informational draft: draft-nsdt-teas-ns-framework (ref. 'I-D.nsdt-teas-ns-framework') == Outdated reference: A later version (-04) exists of draft-nsdt-teas-transport-slice-definition-01 ** Downref: Normative reference to an Informational draft: draft-nsdt-teas-transport-slice-definition (ref. 'I-D.nsdt-teas-transport-slice-definition') Summary: 3 errors (**), 0 flaws (~~), 13 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Wu 3 Internet-Draft D. Dhody 4 Intended status: Standards Track Huawei Technologies 5 Expires: October 19, 2020 L. Han 6 China Mobile 7 R. Rokui 8 Nokia Canada 9 April 17, 2020 11 A Yang Data Model for Transport Slice 12 draft-wd-teas-transport-slice-yang-01 14 Abstract 16 This document provides a YANG data model for the transport slice 17 service. The model can be used by a client management system of the 18 transport slice controller to request, configure, and manage the 19 components of an transport slice service. 21 The YANG modules in this document conforms to the Network Management 22 Datastore Architecture (NMDA) defined in RFC 8342. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on October 19, 2020. 41 Copyright Notice 43 Copyright (c) 2020 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Conventions used in this document . . . . . . . . . . . . . . 3 60 2.1. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 4 61 3. Transport Slice Model Usage . . . . . . . . . . . . . . . . . 4 62 4. Transport Slice Model Overview . . . . . . . . . . . . . . . 4 63 5. Transport Slice Topology . . . . . . . . . . . . . . . . . . 8 64 5.1. Transport Slice End Point . . . . . . . . . . . . . . . . 8 65 5.2. Transport Slice Connection Pattern . . . . . . . . . . . 9 66 5.3. Transport Slice SLO . . . . . . . . . . . . . . . . . . . 9 67 6. Transport Slice Monitoring . . . . . . . . . . . . . . . . . 11 68 7. Transport Slice Module . . . . . . . . . . . . . . . . . . . 11 69 8. Security Considerations . . . . . . . . . . . . . . . . . . . 28 70 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 71 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29 72 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 73 11.1. Normative References . . . . . . . . . . . . . . . . . . 29 74 11.2. Informative References . . . . . . . . . . . . . . . . . 31 75 Appendix A. Appendix A Comparison with Other Possible Transport 76 Slice Models . . . . . . . . . . . . . . . . . . . . 32 77 Appendix B. Appendix B Transporst Slice Traffic Criteria . . . . 33 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34 80 1. Introduction 82 This document provides a YANG[RFC7950] data model for transport Slice 83 Service. 85 The YANG model discussed in this document is defined based on the 86 description of the transport slice in 87 [I-D.nsdt-teas-transport-slice-definition] and 88 [I-D.nsdt-teas-ns-framework], which is used to operate customer- 89 driven transport Slice during the transport Slice Network 90 instantiation, and the operations includes service creation, 91 modification, deletion, and monitoring. 93 The YANG model discussed in this document suggests an abstract, 94 technology independent model, which includes four major constructs: 96 o Transport Slice (TS): A TS is a logical network that interconnects 97 Transport Slice End Points and the connection between EPs has 98 specified service level objectives (SLOs), which are represented 99 by TS-SLO-Group. 101 o Ts-Endpoint (TS-EP): TS-EP is a logical identifier to identify the 102 logical access point of a Transport Slice. 104 o TS-Member: that describes how each link association between any 105 slice endpoint, and per connection SLO requirement could be 106 applied. 108 o TS-SLO-Group: Indicates a group of TS-members with same SLOs in 109 one TS. 111 It will be up to the management system or TSC(Transport Slice 112 controller) to take this model as input and use other management 113 system or specific configuration models to configure the different 114 network elements to deliver the transport slice service. The YANG 115 models can be used with network management protocols such as 116 NETCONF[RFC6241] or RESTCONF[RFC8040]. How the configuration of 117 network elements is done is out of scope for this document. 119 The transport Slice Network operational state is included in the same 120 tree as the configuration consistent with Network Management 121 Datastore Architecture[RFC8342]. 123 2. Conventions used in this document 125 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 126 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 127 "OPTIONAL" in this document are to be interpreted as described in 128 BCP14, [RFC2119], [RFC8174] when, and only when, they appear in all 129 capitals, as shown here. 131 The following terms are defined in [RFC6241] and are used in this 132 specification: 134 o client 136 o configuration data 138 o server 140 o state data 142 The following terms are defined in [RFC7950] and are used in this 143 specification: 145 o augment 147 o data model 149 o data node 151 The terminology for describing YANG data models is found in 152 [RFC7950]. 154 2.1. Tree Diagrams 156 Tree diagrams used in this document follow the notation defined in 157 [RFC8340]. 159 3. Transport Slice Model Usage 161 The intention of the transport slice model is to allow the consumers, 162 e.g. A higher level management system, to request and monitor 163 transport slices. In particular, the model allows consumers to 164 operate in an abstract, technology-agnostic manner, with 165 implementation details hidden. 167 In the use case of 5G transport application, E2E network slice 168 orchestrator acts as the higher layer system to request the transport 169 slices. The interface is used to support dynamic transport slice 170 creation and its lifecycle management to facilitate end-to-end 171 network slice services. 173 +----------------------------------------+ 174 | A higher level system | 175 | | 176 +----------------+-----------------------+ 177 | 178 | transport slice YANG 179 | 180 | 181 +---------------------+--------------------------+ 182 | Transport Slice Controller | 183 +------------------------------------------------+ 185 Figure 1 Transport Slice Model Context 187 4. Transport Slice Model Overview 189 From a consumer perspective, an example of transport slice service 190 network is shown in figure 2. 192 +--------------------------+ 193 +--------+ | | 194 |Customer| /--\ | | /--\ +-------+ 195 | Site1 |-+ EP1--+ +-+ EP3+--+ | 196 +--------+ \--/ | | \--/ |Customer 197 | | | Site3 | 198 +--------+ /--\ | | /--\ | | 199 |Customer|-+ EP2--+ +-+ EP4+--+ | 200 | Site2 | \--/ | Transport Network | \--/ +-------+ 201 +--------+ | | 202 | | 203 +--------------------------+ 205 | | 206 |<-------------Transport------------>| 207 | Slice 1 | 209 TS-SLO-Group Red TS-SLO-Group Blue 210 TS-Member 2 EP1-EP3 TS-Member 1 EP1-EP2 211 TS-Member 3 EP1-EP4 212 TS-Member 4 EP2-EP3 213 TS-Member 5 EP2-EP4 215 Figure 2: An example of TS-Endpoints and TS-Members of a transport slice 217 As shown in Figure 2, a Transport Slice(TS) links together End Points 218 at external Interfaces to the sites, which are customer endpoints 219 that request a transport slicing service. 221 At each external site, one or multiple TS End Points could be 222 connected to the Transport Slice. In the example above, when a site 223 is connected to the transport network via two interfaces in one 224 Transport Slice, two End Points are created. 226 TS is a connectivity service with specific SLO characteristics, 227 including bandwidth, QoS metric, etc. The connectivity service is a 228 combination of logical connections, represented by TS-member. When 229 some parts of a slice have different SLO requirements, a group of TS- 230 Members with the same SLO is described by TS-SLO-Group. 232 The modeling of this model assumes that the higher level system has a 233 consistent topology, including at least the topology of the 234 interconnection between the transport network external interfaces and 235 the customer network. The upper-layer system needs to communicate 236 the endpoint information related to the topology of the transport 237 slice based on the topology of the customer network connected to the 238 transport slice nework. 240 Based on this design, the Transport Slice YANG module consists of the 241 main containers: "transport-slice", "ts-endpoint", "ts-member",and 242 "ts-slo-group". 244 The figure below describes the overall structure of the YANG module: 246 module: ietf-transport-slice 247 +--rw transport-slices 248 +--rw slice-templates 249 | +--rw slice-template* [id] 250 | +--rw id string 251 | +--rw template-description? string 252 +--rw transport-slice* [ts-id] 253 +--rw ts-id uint32 254 +--rw ts-name? string 255 +--rw ts-topology* identityref 256 +--rw ts-slo-group* [slo-group-name] 257 | +--rw slo-group-name string 258 | +--rw default-slo-group? boolean 259 | +--rw slo-tag? string 260 | +--rw (slo-template)? 261 | | +--:(standard) 262 | | | +--rw template? -> /transport-slices/slice-templates/slice-template/id 263 | | +--:(custom) 264 | | +--rw ts-slo-policy 265 | | +--rw isolation-type? identityref 266 | | +--rw bandwidth? te-types:te-bandwidth 267 | | +--rw latency 268 | | | +--rw one-way-latency? uint32 269 | | | +--rw two-way-latency? uint32 270 | | +--rw jitter 271 | | | +--rw one-way-jitter? uint32 272 | | | +--rw two-way-jitter? uint32 273 | | +--rw loss 274 | | | +--rw one-way-loss? decimal64 275 | | | +--rw two-way-loss? decimal64 276 | | +--rw ts-metric-bounds 277 | | | +--rw ts-metric-bound* [metric-type] 278 | | | +--rw metric-type identityref 279 | | | +--rw upper-bound? uint64 280 | | +--rw availability-type? identityref 281 | +--rw ts-member-group* [ts-member-id] 282 | | +--rw ts-member-id -> /transport-slices/transport-slice/ts-member/ts-member-id 283 | +--ro slo-group-monitoring 284 | +--ro latency? uint32 285 | +--ro jitter? uint32 286 | +--ro loss? decimal64 287 +--rw status 288 | +--rw admin-enabled? boolean 289 | +--ro oper-status? operational-type 290 +--rw ts-endpoint* [ep-id] 291 | +--rw ep-id uint32 292 | +--rw ep-name? string 293 | +--rw ep-role* identityref 294 | +--rw geolocation 295 | | +--rw altitude? int64 296 | | +--rw latitude? geographic-coordinate-degree 297 | | +--rw longitude? geographic-coordinate-degree 298 | +--rw node-id? string 299 | +--rw tp-id? string 300 | +--rw ts-traffic-criteria 301 | | +--rw ts-traffic-criteria* [match-type] 302 | | +--rw match-type identityref 303 | | +--rw value? string 304 | +--rw site-access-parameters 305 | | +--rw site-name? string 306 | | +--rw availability-priority? uint32 307 | +--rw bandwidth-slo 308 | | +--rw incoming-bandwidth 309 | | | +--rw guaranteed-bandwidth? te-types:te-bandwidth 310 | | | +--rw max-bandwidth? te-types:te-bandwidth 311 | | +--rw outgoing-bandwidth 312 | | +--rw guaranteed-bandwidth? te-types:te-bandwidth 313 | | +--rw max-bandwidth? te-types:te-bandwidth 314 | +--rw mtu uint16 315 | +--rw protocol 316 | | +--rw vrrp 317 | | | +--rw float-ipv4? inet:ipv4-prefix 318 | | | +--rw float-ipv6? inet:ipv6-prefix 319 | | +--rw bgp 320 | | | +--rw bgp-peer-ipv4* inet:ipv4-prefix 321 | | | +--rw bgp-peer-ipv6* inet:ipv6-prefix 322 | | +--rw static 323 | | +--rw static-route-ipv4* inet:ipv4-prefix 324 | | +--rw static-route-ipv6* inet:ipv6-prefix 325 | +--rw status 326 | | +--rw admin-enabled? boolean 327 | | +--ro oper-status? operational-type 328 | +--ro ep-monitoring 329 | +--ro incoming-utilized-bandwidth? te-types:te-bandwidth 330 | +--ro incoming-bw-utilization decimal64 331 | +--ro outgoing-utilized-bandwidth? te-types:te-bandwidth 332 | +--ro outgoing-bw-utilization decimal64 333 +--rw ts-member* [ts-member-id] 334 +--rw ts-member-id uint32 335 +--rw src 336 | +--rw src-ts-ep-id? -> /transport-slices/transport-slice/ts-endpoint/ep-id 337 +--rw dest 338 | +--rw dest-ts-ep-id? -> /transport-slices/transport-slice/ts-endpoint/ep-id 339 +--rw monitoring-type? ts-monitoring-type 340 +--ro ts-member-monitoring 341 +--ro latency? uint32 342 +--ro jitter? uint32 343 +--ro loss? decimal64 345 5. Transport Slice Topology 347 A transport slice topology consists of a group of interconnected 348 transport slice End Points, and the connections between EPs may have 349 different SLO requirements, including symmetrical or asymmetrical 350 traffic throughput, different traffic delay, etc. 352 5.1. Transport Slice End Point 354 A TS End Point is a logical entity at an external Interface of the 355 transport network to a customer site. And there are multiple 356 connection methods as follows: 358 o a distinct physical connection 360 o a logical Layer 2 connection 362 o An IP(e.g. using GRE Tunnel) or Ethernet tunnel 364 Based on this, the end point in this model could represents the 365 following options: 367 o A slice interface of a customer site: the "node-id" and "tp-id" 368 under the "ts-endpoint" can be specified 370 o A slice interface of the transport network: the "node-id" and "tp- 371 id" under the "ts-endpoint" can be specified, and "site-access- 372 parameters" can be used to specify the attached customer site. 374 o The subset of traffic through the particular inteface connected to 375 the transport network, either at the customer site or the 376 transport network: besides the the "node-id" and "tp-id", the "ts- 377 traffic-criteria" is needed 379 A number of slice interconnection parameters must be agreed with a 380 customer site and the transport slice, and one TS End Point's 381 attributes may not be same with another TS End Point's. The 382 attributes may include some technology specific parameters, such as 383 connections, encapsulation, and routing protocols, etc. This model 384 can be augmented based on the requirements. 386 Note: The definition of the current Endpoint mainly focus on the 387 common interconnection parameters, but a number of technology- 388 specific parameters of slice interconnection must also be agreed with 389 each customer site and the transport network. This model needs to 390 give some guidance on how to deal with them, such as 391 encapsulation,routing, etc. 393 5.2. Transport Slice Connection Pattern 395 A TS service can be point-to-point (P2P), point-to-multipoint (P2MP), 396 multipoint-to-point (MP2P), or multipoint-to-multipoint (MP2MP) based 397 on the customer's service traffic pattern requirements. 399 Therefore, the "ts-topology" is required for configuration. The 400 model supports any-to-any, Hub and Spoke (where Hubs can exchange 401 traffic), and the different combinations, which are supported through 402 the order-list of topology. New topologies could be added via 403 augmentation. By default, the any-to-any VPN service topology is 404 used. 406 In addition, "ep-role" also needs to be defined, which specifies the 407 role of the end point in a particular TS topology. In the any-to-any 408 VPN service topology, all end points MUST have the same role, which 409 will be "any-to-any-role". In the Hub-and-Spoke topology, end points 410 MUST have a Hub role or a Spoke role. 412 5.3. Transport Slice SLO 414 As defined in , [I-D.nsdt-teas-transport-slice-definition] 416 The common Transport Slice SLO attributes are as follows: 418 o Guaranteed bandwidth: indicates the assurance of minimum or range 419 of the bandwidth requirement. Requested unidirectionally 421 o Guaranteed latency: indicates the latency constraint of the slice 423 o Minimal permissible jitter: indicates the jitter constraint of the 424 slice 426 o Packet loss rate: indicates reliability constraint, which 427 specifies permissible packet loss rate between two endpoints 429 o Isolation: indicates that a transport slice can be enforced as 430 physical resource isolation or logical resource allocations. For 431 physical resource isolation, it implies that the forwarding, 432 policy and address spaces are local with in a transport slice and 433 instantiation of one slice does not conflict with another slice. 434 For logical isolation, only policy and address spaces are isolated 435 from another slice 437 o Availability: Availability is a probabilistic measure of the 438 length of time that a slice instance functions without a network 439 failure. The availability level will need to be translated into 440 network specific policies such as the protection policy associated 441 with the slice 443 o MTU: Specifies the maximum packet length that the slice gurantee 444 to be able to carry across 446 Note: About the definition of SLO parameters, the author is 447 discussing to reuse the TE-Types grouping definition as much as 448 possible, to avoid duplication of definitions. 450 The customer's services may be quite different, e.g. some slice 451 services has the same SLO requirements of connections, some slice 452 services has the different SLO requirements for different parts of 453 the slice. In some slices, the bandwidth of one endpoint is 454 different from that of other endpoints, for example, one is central 455 endpoint, the other endpoints are access endpoints. 457 The list "ts-slo-group" defines a group of different SLOs, which are 458 used to describe that different parts of the slice have different 459 SLOs. The specific SLO of the slice SLO group may use a standard SLO 460 template, or may use different customized parameters. A group of 461 "ts-member" is used to describe which connections of the slice use 462 the SLO. 464 For the simplest slice services, only one category SLO of "ts-slo- 465 group" needs to be defined, also with the "ts-topology" specified. 466 If the traffic bandwidth is asymmetric for some endpoints, the 467 bandwidth constraint should be specified at each End Point of a 468 Transport Slice. The "bandwidth-slo" container under the "ts- 469 endpoint" is used to define a guaranteed amount of bandwidth and also 470 a maximum bandwidth for the transport slice. 472 For the complicated slices, in addition to the configurations above, 473 multiple "ts-slo-group" needs to be defined, and "ts-member-group" 474 under the "ts-slo-group" or "slo-group" under the "ts-member" 475 describe details of the per-connection SLO. 477 Note: In some use cases, the number of connections represented by 478 "ts-member-group" may be huge, which may lead to configuration 479 issues, for example, the scalability or error-prone. 481 6. Transport Slice Monitoring 483 This model also describes performance status of a transport slice. 484 The statistics are described in the following granularity: 486 o Per TS SLO group: specified in 'ts-member-group-monitoring' under 487 the "ts-slo-groupr" 489 o Per TS connection: specified in 'ts-member-monitoring' under the 490 "ts-member" 492 o Per TS Endpoint: specified in 'ep-monitoring' under the "ts- 493 endpoint" 495 This model does not define monitoring enabling methods. The 496 mechanism defined in [RFC8640] and [RFC8641] can be used for either 497 periodic or on-demand subscription. 499 By specifying subtree filters or xpath filters to 'ts-member' or 500 'endpoint' ,so that only interested contents will be sent. These 501 mechanisms can be used for monitoring the transport slice performance 502 status so that the client management system could initiate 503 modification based on the transport slice running status. 505 7. Transport Slice Module 507 file "ietf-transport-slice@2020-04-15.yang" 509 module ietf-transport-slice { 510 yang-version 1.1; 511 namespace "urn:ietf:params:xml:ns:yang:ietf-transport-slice"; 512 prefix ts; 514 import ietf-inet-types { 515 prefix inet; 516 } 517 import ietf-te-types { 518 prefix te-types; 519 } 521 organization 522 "IETF Traffic Engineering Architecture and Signaling (TEAS) 523 Working Group"; 524 contact 525 "WG Web: 526 WG List: 527 Editor: Bo Wu 528 : Dhruv Dhody "; 529 description 530 "This module contains a YANG module for the Transport Slice. 532 Copyright (c) 2020 IETF Trust and the persons identified as 533 authors of the code. All rights reserved. 535 Redistribution and use in source and binary forms, with or 536 without modification, is permitted pursuant to, and subject to 537 the license terms contained in, the Simplified BSD License set 538 forth in Section 4.c of the IETF Trust's Legal Provisions 539 Relating to IETF Documents 540 (http://trustee.ietf.org/license-info). 542 This version of this YANG module is part of RFC XXXX; see the 543 RFC itself for full legal notices."; 545 revision 2020-04-15 { 546 description 547 "initial version."; 548 reference 549 "RFC XXXX: A Yang Data Model for Transport Slice Operation"; 550 } 552 /* Features */ 553 /* Identities */ 555 identity ts-topology { 556 description 557 "Base identity for Transport Slice topology."; 558 } 560 identity any-to-any { 561 base ts-topology; 562 description 563 "Identity for any-to-any Transport Slice topology."; 564 } 566 identity hub-spoke { 567 base ts-topology; 568 description 569 "Identity for Hub-and-Spoke Transport Slice topology."; 570 } 571 identity ep-role { 572 description 573 "Site Role in a Transport Slice topology "; 574 } 576 identity any-to-any-role { 577 base ep-role; 578 description 579 "Site in an any-to-any Transport Slice."; 580 } 582 identity hub { 583 base ep-role; 584 description 585 "Hub Role in a Hub-and-Spoke Transport Slice."; 586 } 588 identity spoke { 589 base ep-role; 590 description 591 "Spoke Role in a Hub-and-Spoke transport slice."; 592 } 594 identity isolation-type { 595 description 596 "Base identity from which specific isolation types are derived."; 597 } 599 identity physical-isolation { 600 base isolation-type; 601 description 602 "physical isolation."; 603 } 605 identity logical-isolation { 606 base isolation-type; 607 description 608 "logical-isolation."; 609 } 611 identity ts-slo-metric-type { 612 description 613 "Base identity for TS SLO metric type"; 614 } 616 identity ts-match-type { 617 description 618 "Base identity for TS metric type"; 620 } 622 identity ts-vlan-match { 623 base ts-match-type; 624 description 625 "logical-isolation."; 626 } 628 /* 629 * Identity for availability-type 630 */ 632 identity availability-type { 633 description 634 "Base identity from which specific map types are derived."; 635 } 637 identity level-1 { 638 base availability-type; 639 description 640 "level 1: 99.9999%"; 641 } 643 identity level-2 { 644 base availability-type; 645 description 646 "level 2: 99.999%"; 647 } 649 identity level-3 { 650 base availability-type; 651 description 652 "level 3: 99.99%"; 653 } 655 identity level-4 { 656 base availability-type; 657 description 658 "level 4: 99.9%"; 659 } 661 identity level-5 { 662 base availability-type; 663 description 664 "level 5: 99%"; 665 } 667 /* typedef */ 668 typedef operational-type { 669 type enumeration { 670 enum up { 671 value 0; 672 description 673 "Operational status UP."; 674 } 675 enum down { 676 value 1; 677 description 678 "Operational status DOWN"; 679 } 680 enum unknown { 681 value 2; 682 description 683 "Operational status UNKNOWN"; 684 } 685 } 686 description 687 "This is a read-only attribute used to determine the 688 status of a particular element"; 689 } 691 typedef ts-monitoring-type { 692 type enumeration { 693 enum one-way { 694 description 695 "represents one-way monitoring type"; 696 } 697 enum two-way { 698 description 699 "represents two-way monitoring type"; 700 } 701 } 702 description 703 "enumerated type of monitoring on a ts-member "; 704 } 706 /* Groupings */ 708 grouping status-params { 709 description 710 "Grouping used to join operational and administrative status 711 is re used in the Site Network Acess and in the VPN-Node"; 712 container status { 713 description 714 "Container for status of administration and operational"; 715 leaf admin-enabled { 716 type boolean; 717 description 718 "Administrative Status UP/DOWN"; 719 } 720 leaf oper-status { 721 type operational-type; 722 config false; 723 description 724 "Operations status"; 725 } 726 } 727 } 729 grouping ts-traffic-criteria { 730 description 731 "Grouping for traffic definition."; 732 container ts-traffic-criteria { 733 description 734 "Describes traffic-matching criteria."; 735 list ts-traffic-criteria { 736 key "match-type"; 737 description 738 "List of TS traffic criteria"; 739 leaf match-type { 740 type identityref { 741 base ts-match-type; 742 } 743 description 744 "Identifies an entry in the list of match-type for the TS."; 745 } 746 leaf value { 747 type string; 748 description 749 "Describes traffic-matching criteria,e.g. IP adress, 750 VLAN, etc."; 751 } 752 } 753 } 754 } 756 grouping routing-protocols { 757 description 758 "Grouping for endpoint protocols definition."; 759 container protocol { 760 description 761 "Describes protocal between access potin and site."; 762 container vrrp { 763 description 764 "Configuration specific to VRRP routing."; 765 leaf float-ipv4 { 766 type inet:ipv4-prefix; 767 description 768 "vrrp ipv4 float-ip."; 769 } 770 leaf float-ipv6 { 771 type inet:ipv6-prefix; 772 description 773 "vrrp ipv6 float ip."; 774 } 775 } 776 container bgp { 777 description 778 "BGP-specific configuration."; 779 leaf-list bgp-peer-ipv4 { 780 type inet:ipv4-prefix; 781 description 782 "BGP peer ipv4 address."; 783 } 784 leaf-list bgp-peer-ipv6 { 785 type inet:ipv6-prefix; 786 description 787 "BGP peer ipv6 address."; 788 } 789 } 790 container static { 791 description 792 "Only applies when protocol is static."; 793 leaf-list static-route-ipv4 { 794 type inet:ipv4-prefix; 795 description 796 "ipv4 static route"; 797 } 798 leaf-list static-route-ipv6 { 799 type inet:ipv6-prefix; 800 description 801 "ipv6 static route"; 802 } 803 } 804 } 805 } 807 grouping ep-monitoring-parameters { 808 description 809 "Grouping for ep-monitoring-parameters."; 810 container ep-monitoring { 811 config false; 812 description 813 "Container for ep-monitoring-parameters."; 814 leaf incoming-utilized-bandwidth { 815 type te-types:te-bandwidth; 816 description 817 "Bandwidth utilization that represents the actual 818 utilization of the incoming endpoint."; 819 } 820 leaf incoming-bw-utilization { 821 type decimal64 { 822 fraction-digits 5; 823 range "0..100"; 824 } 825 units "percent"; 826 mandatory true; 827 description 828 "To be used to define the bandwidth utilization 829 as a percentage of the available service bandwidth."; 830 } 831 leaf outgoing-utilized-bandwidth { 832 type te-types:te-bandwidth; 833 description 834 "Bandwidth utilization that represents the actual 835 utilization of the incoming endpoint."; 836 } 837 leaf outgoing-bw-utilization { 838 type decimal64 { 839 fraction-digits 5; 840 range "0..100"; 841 } 842 units "percent"; 843 mandatory true; 844 description 845 "To be used to define the bandwidth utilization 846 as a percentage of the available service bandwidth."; 847 } 848 } 849 } 851 grouping common-monitoring-parameters { 852 description 853 "Grouping for link-monitoring-parameters."; 854 leaf latency { 855 type uint32; 856 units "usec"; 857 description 858 "The latency statistics per TS member."; 859 } 860 leaf jitter { 861 type uint32 { 862 range "0..16777215"; 863 } 864 description 865 "The jitter statistics per TS member."; 866 } 867 leaf loss { 868 type decimal64 { 869 fraction-digits 6; 870 range "0 .. 50.331642"; 871 } 872 description 873 "Packet loss as a percentage of the total traffic 874 sent over a configurable interval. The finest precision is 875 0.000003%. where the maximum 50.331642%."; 876 reference 877 "RFC 7810, section-4.4"; 878 } 879 } 881 grouping geolocation-container { 882 description 883 "A grouping containing a GPS location."; 884 container geolocation { 885 description 886 "A container containing a GPS location."; 887 leaf altitude { 888 type int64; 889 units "millimeter"; 890 description 891 "Distance above the sea level."; 892 } 893 leaf latitude { 894 type decimal64 { 895 fraction-digits 8; 896 range "-90..90"; 897 } 898 description 899 "Relative position north or south on the Earth's surface."; 900 } 901 leaf longitude { 902 type decimal64 { 903 fraction-digits 8; 904 range "-180..180"; 905 } 906 description 907 "Angular distance east or west on the Earth's surface."; 909 } 910 } 911 // gps-location 912 } 914 // geolocation-container 916 grouping endpoint { 917 description 918 "Transport Slice endpoint related information"; 919 leaf ep-id { 920 type uint32; 921 description 922 "unique identifier for the referred Transport Slice endpoint"; 923 } 924 leaf ep-name { 925 type string; 926 description 927 "ep name"; 928 } 929 leaf-list ep-role { 930 type identityref { 931 base ep-role; 932 } 933 default "any-to-any-role"; 934 description 935 "Role of the endpoint in the Transport Slice."; 936 } 937 uses geolocation-container; 938 leaf node-id { 939 type string; 940 description 941 "Uniquely identifies an edge node within the transport 942 network."; 943 } 944 leaf tp-id { 945 type string; 946 description 947 "Termination point identifier of an edge node."; 948 } 949 uses ts-traffic-criteria; 950 container site-access-parameters { 951 leaf site-name { 952 type string; 953 description 954 "The Site that the endpoint is attached with"; 955 } 956 leaf availability-priority { 957 type uint32; 958 default "100"; 959 description 960 "In multihoming access of one site, the priority for 961 this Endpoint is specified . The higher the value, the higher 962 the preference of the Endpoint will be."; 963 } 964 description 965 "Site specific parameters."; 966 } 967 container bandwidth-slo { 968 container incoming-bandwidth { 969 leaf guaranteed-bandwidth { 970 type te-types:te-bandwidth; 971 description 972 "If guaranteed-bandwidth is 0, it means best effort, no 973 minimum throughput is guaranteed."; 974 } 975 leaf max-bandwidth { 976 type te-types:te-bandwidth; 977 description 978 "max bandwidth "; 979 } 980 description 981 "Container for the incoming bandwidth policy"; 982 } 983 container outgoing-bandwidth { 984 leaf guaranteed-bandwidth { 985 type te-types:te-bandwidth; 986 description 987 "If guaranteed-bandwidth is 0, it means best effort, no 988 minimum throughput is guaranteed."; 989 } 990 leaf max-bandwidth { 991 type te-types:te-bandwidth; 992 description 993 "max bandwidth "; 994 } 995 description 996 "Container for the bandwidth policy"; 997 } 998 description 999 "Container for the bandwidth SLO policy"; 1000 } 1001 leaf mtu { 1002 type uint16; 1003 units "bytes"; 1004 mandatory true; 1005 description 1006 "MTU at service level. If the service is IP, 1007 it refers to the IP MTU. If the service is Ethertype, 1008 will refer to the Ethernet MTU. "; 1009 } 1010 uses routing-protocols; 1011 uses status-params; 1012 uses ep-monitoring-parameters; 1013 } 1015 //ts-ep 1017 grouping ts-member { 1018 description 1019 "ts-member is described by this container"; 1020 leaf ts-member-id { 1021 type uint32; 1022 description 1023 "ts-member identifier"; 1024 } 1025 container src { 1026 description 1027 "the source of TS link"; 1028 leaf src-ts-ep-id { 1029 type leafref { 1030 path "/transport-slices/transport-slice/ts-endpoint/ep-id"; 1031 } 1032 description 1033 "reference to source TS endpoint"; 1034 } 1035 } 1036 container dest { 1037 description 1038 "the destination of TS link "; 1039 leaf dest-ts-ep-id { 1040 type leafref { 1041 path "/transport-slices/transport-slice/ts-endpoint/ep-id"; 1042 } 1043 description 1044 "reference to dest TS endpoint"; 1045 } 1046 } 1047 leaf monitoring-type { 1048 type ts-monitoring-type; 1049 description 1050 "One way or two way monitoring type."; 1051 } 1052 container ts-member-monitoring { 1053 config false; 1054 description 1055 "SLO status Per ts endpoint to endpoint "; 1056 uses common-monitoring-parameters; 1057 } 1058 } 1060 //ts-member 1062 grouping ts-metric-bounds { 1063 description 1064 "TS metric bounds grouping"; 1065 container ts-metric-bounds { 1066 description 1067 "TS metric bounds container"; 1068 list ts-metric-bound { 1069 key "metric-type"; 1070 description 1071 "List of TS metric bounds"; 1072 leaf metric-type { 1073 type identityref { 1074 base ts-slo-metric-type; 1075 } 1076 description 1077 "Identifies an entry in the list of metric-types 1078 bound for the TS."; 1079 } 1080 leaf upper-bound { 1081 type uint64; 1082 default "0"; 1083 description 1084 "Upper bound on ts-member metric. A zero indicate 1085 an unbounded upper limit for the specific metric-type"; 1086 } 1087 } 1088 } 1089 } 1091 grouping transport-slice-slo-group { 1092 description 1093 "Grouping for SLO definition of TS"; 1094 list ts-slo-group { 1095 key "slo-group-name"; 1096 description 1097 "List of TS SLO groups, the SLO group is used to 1098 support different SLO objectives between different ts-members 1099 in the same slice."; 1100 leaf slo-group-name { 1101 type string; 1102 description 1103 "Identifies an entry in the list of SLO group for the TS."; 1104 } 1105 leaf default-slo-group { 1106 type boolean; 1107 default "false"; 1108 description 1109 "Is the SLO group is selected as the default-slo-group"; 1110 } 1111 leaf slo-tag { 1112 type string; 1113 description 1114 "slo tag for operational management"; 1115 } 1116 choice slo-template { 1117 description 1118 "Choice for SLO template. 1119 Can be standard template or customized template."; 1120 case standard { 1121 description 1122 "Standard SLO template."; 1123 leaf template { 1124 type leafref { 1125 path "/transport-slices/slice-templates/slice-template/id"; 1126 } 1127 description 1128 "QoS template to be used."; 1129 } 1130 } 1131 case custom { 1132 description 1133 "Customized SLO template."; 1134 container ts-slo-policy { 1135 leaf isolation-type { 1136 type identityref { 1137 base isolation-type; 1138 } 1139 default "logical-isolation"; 1140 description 1141 "TS service isolation-level."; 1142 } 1143 leaf bandwidth { 1144 type te-types:te-bandwidth; 1145 description 1146 "max bandwidth "; 1147 } 1148 container latency { 1149 leaf one-way-latency { 1150 type uint32 { 1151 range "0..16777215"; 1152 } 1153 units "usec"; 1154 description 1155 "lowest latency in micro seconds."; 1156 } 1157 leaf two-way-latency { 1158 type uint32 { 1159 range "0..16777215"; 1160 } 1161 description 1162 "lowest-way delay or latency in micro seconds."; 1163 } 1164 description 1165 "Latency constraint on the traffic class."; 1166 } 1167 container jitter { 1168 leaf one-way-jitter { 1169 type uint32 { 1170 range "0..16777215"; 1171 } 1172 description 1173 "lowest latency in micro seconds."; 1174 } 1175 leaf two-way-jitter { 1176 type uint32 { 1177 range "0..16777215"; 1178 } 1179 description 1180 "lowest-way delay or latency in micro seconds."; 1181 } 1182 description 1183 "Jitter constraint on the traffic class."; 1184 } 1185 container loss { 1186 leaf one-way-loss { 1187 type decimal64 { 1188 fraction-digits 6; 1189 range "0 .. 50.331642"; 1190 } 1191 description 1192 "Packet loss as a percentage of the total traffic sent 1193 over a configurable interval. The finest precision is 1194 0.000003%. where the maximum 50.331642%."; 1195 reference 1196 "RFC 7810, section-4.4"; 1198 } 1199 leaf two-way-loss { 1200 type decimal64 { 1201 fraction-digits 6; 1202 range "0 .. 50.331642"; 1203 } 1204 description 1205 "Packet loss as a percentage of the total traffic sent 1206 over a configurable interval. The finest precision is 1207 0.000003%. where the maximum 50.331642%."; 1208 reference 1209 "RFC 7810, section-4.4"; 1210 } 1211 description 1212 "Loss constraint on the traffic class."; 1213 } 1214 uses ts-metric-bounds; 1215 leaf availability-type { 1216 type identityref { 1217 base availability-type; 1218 } 1219 description 1220 "Availability Requirement for the Service"; 1221 } 1222 description 1223 "container for customized policy constraint on the slice 1224 traffic."; 1225 } 1226 } 1227 } 1228 list ts-member-group { 1229 key "ts-member-id"; 1230 description 1231 "List of included TS Member groups for the SLO."; 1232 leaf ts-member-id { 1233 type leafref { 1234 path "/transport-slices/transport-slice/ts-member/ts-member-id"; 1235 } 1236 description 1237 "Identifies the included list of TS member."; 1238 } 1239 } 1240 container slo-group-monitoring { 1241 config false; 1242 description 1243 "SLO status Per slo group "; 1244 uses common-monitoring-parameters; 1245 } 1247 } 1248 } 1250 grouping slice-template { 1251 description 1252 "Grouping for slice-templates."; 1253 container slice-templates { 1254 description 1255 "Container for slice-templates."; 1256 list slice-template { 1257 key "id"; 1258 leaf id { 1259 type string; 1260 description 1261 "Identification of the SLO Template to be used. 1262 Local administration meaning."; 1263 } 1264 leaf template-description { 1265 type string; 1266 description 1267 "Description of the SLO template."; 1268 } 1269 description 1270 "List for SLO template identifiers."; 1271 } 1272 } 1273 } 1275 /* Configuration data nodes */ 1277 container transport-slices { 1278 description 1279 "transport-slice configurations"; 1280 uses slice-template; 1281 list transport-slice { 1282 key "ts-id"; 1283 description 1284 "a transport-slice is identified by a ts-id"; 1285 leaf ts-id { 1286 type uint32; 1287 description 1288 "a unique transport-slice identifier"; 1289 } 1290 leaf ts-name { 1291 type string; 1292 description 1293 "ts name"; 1294 } 1295 leaf-list ts-topology { 1296 type identityref { 1297 base ts-topology; 1298 } 1299 default "any-to-any"; 1300 description 1301 "TS service topology."; 1302 } 1303 uses transport-slice-slo-group; 1304 uses status-params; 1305 list ts-endpoint { 1306 key "ep-id"; 1307 uses endpoint; 1308 description 1309 "list of endpoints in this slice"; 1310 } 1311 list ts-member { 1312 key "ts-member-id"; 1313 description 1314 "List of ts-member in a slice"; 1315 uses ts-member; 1316 } 1317 } 1318 //ts-list 1319 } 1320 } 1322 1324 8. Security Considerations 1326 The YANG module defined in this document is designed to be accessed 1327 via network management protocols such as NETCONF [RFC6241] or 1328 RESTCONF [RFC8040]. The lowest NETCONF layer is the secure transport 1329 layer, and the mandatory-to-implement secure transport is Secure 1330 Shell (SSH) [RFC6242]. The lowest RESTCONF layer is HTTPS, and the 1331 mandatory-to-implement secure transport is TLS [RFC8446]. 1333 The NETCONF access control model [RFC8341] provides the means to 1334 restrict access for particular NETCONF or RESTCONF users to a 1335 preconfigured subset of all available NETCONF or RESTCONF protocol 1336 operations and content. 1338 There are a number of data nodes defined in this YANG module that are 1339 writable/creatable/deletable (i.e., config true, which is the 1340 default). These data nodes may be considered sensitive or vulnerable 1341 in some network environments. Write operations (e.g., edit-config) 1342 to these data nodes without proper protection can have a negative 1343 effect on network operations. 1345 o /ietf-transport-slice/transport-slices/transport-slice 1347 The entries in the list above include the whole transport network 1348 configurations corresponding with the slice which the higher 1349 management system requests, and indirectly create or modify the PE or 1350 P device configurations. Unexpected changes to these entries could 1351 lead to service disruption and/or network misbehavior. 1353 9. IANA Considerations 1355 This document registers a URI in the IETF XML registry [RFC3688]. 1356 Following the format in [RFC3688], the following registration is 1357 requested to be made: 1359 URI: urn:ietf:params:xml:ns:yang:ietf-transport-slice 1360 Registrant Contact: The IESG. 1361 XML: N/A, the requested URI is an XML namespace. 1363 This document requests to register a YANG module in the YANG Module 1364 Names registry [RFC7950]. 1366 Name: ietf-transport-slice 1367 Namespace: urn:ietf:params:xml:ns:yang:ietf-transport-slice 1368 Prefix: ts 1369 Reference: RFC XXXX 1371 10. Acknowledgments 1373 The authors wish to thank Qin Wu, and many others for their helpful 1374 comments and suggestions. 1376 11. References 1378 11.1. Normative References 1380 [I-D.ietf-teas-actn-vn-yang] 1381 Lee, Y., Dhody, D., Ceccarelli, D., Bryskin, I., and B. 1382 Yoon, "A Yang Data Model for VN Operation", draft-ietf- 1383 teas-actn-vn-yang-08 (work in progress), March 2020. 1385 [I-D.liu-teas-transport-network-slice-yang] 1386 Liu, X., Tantsura, J., Bryskin, I., Contreras, L., and Q. 1387 WU, "Transport Network Slice YANG Data Model", draft-liu- 1388 teas-transport-network-slice-yang-00 (work in progress), 1389 November 2019. 1391 [I-D.nsdt-teas-ns-framework] 1392 Gray, E. and J. Drake, "Framework for Transport Network 1393 Slices", draft-nsdt-teas-ns-framework-02 (work in 1394 progress), March 2020. 1396 [I-D.nsdt-teas-transport-slice-definition] 1397 Rokui, R., Homma, S., Makhijani, K., and L. Contreras, 1398 "IETF Definition of Transport Slice", draft-nsdt-teas- 1399 transport-slice-definition-01 (work in progress), March 1400 2020. 1402 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1403 Requirement Levels", BCP 14, RFC 2119, 1404 DOI 10.17487/RFC2119, March 1997, 1405 . 1407 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1408 and A. Bierman, Ed., "Network Configuration Protocol 1409 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1410 . 1412 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 1413 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 1414 . 1416 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 1417 RFC 6991, DOI 10.17487/RFC6991, July 2013, 1418 . 1420 [RFC7317] Bierman, A. and M. Bjorklund, "A YANG Data Model for 1421 System Management", RFC 7317, DOI 10.17487/RFC7317, August 1422 2014, . 1424 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1425 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1426 . 1428 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1429 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 1430 . 1432 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1433 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1434 May 2017, . 1436 [RFC8299] Wu, Q., Ed., Litkowski, S., Tomotaki, L., and K. Ogaki, 1437 "YANG Data Model for L3VPN Service Delivery", RFC 8299, 1438 DOI 10.17487/RFC8299, January 2018, 1439 . 1441 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 1442 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 1443 . 1445 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 1446 Access Control Model", STD 91, RFC 8341, 1447 DOI 10.17487/RFC8341, March 2018, 1448 . 1450 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 1451 and R. Wilton, "Network Management Datastore Architecture 1452 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 1453 . 1455 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1456 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1457 . 1459 [RFC8466] Wen, B., Fioccola, G., Ed., Xie, C., and L. Jalil, "A YANG 1460 Data Model for Layer 2 Virtual Private Network (L2VPN) 1461 Service Delivery", RFC 8466, DOI 10.17487/RFC8466, October 1462 2018, . 1464 [RFC8640] Voit, E., Clemm, A., Gonzalez Prieto, A., Nilsen-Nygaard, 1465 E., and A. Tripathy, "Dynamic Subscription to YANG Events 1466 and Datastores over NETCONF", RFC 8640, 1467 DOI 10.17487/RFC8640, September 2019, 1468 . 1470 [RFC8641] Clemm, A. and E. Voit, "Subscription to YANG Notifications 1471 for Datastore Updates", RFC 8641, DOI 10.17487/RFC8641, 1472 September 2019, . 1474 11.2. Informative References 1476 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1477 DOI 10.17487/RFC3688, January 2004, 1478 . 1480 Appendix A. Appendix A Comparison with Other Possible Transport Slice 1481 Models 1483 1.Transport Slice model based on IETF ACTN VN model 1485 The ACTN VN(Virtual Network) model introduced 1486 in[I-D.ietf-teas-actn-vn-yang] 1488 is the abstract customer view of the TE network. Its YANG structure 1489 includes four components: . 1491 o VN: The VN can be seen as a set of edge-to-edge abstract links (a 1492 Type 1 VN). 1494 o AP"links" list and "termination points" list describe how nodes in 1495 a network are connected to each other 1497 o VN-AP:vertical layering relationships between transport slice 1498 networks and underlay networks 1500 o VN member: Each abstract link is referred to as a VN member and is 1501 formed as an E2E tunnel across the underlying networks 1503 The main concern with this model is TE specific, which does not 1504 comply with the technology agnostic characteristic specified in 1505 [I-D.nsdt-teas-transport-slice-definition]. 1507 2.Transport Slice model based on IETF Network Topologies YANG data 1508 model extension 1510 IETF Network Topologies YANG data model extension introduced in 1511 Transport Network Slice YANG Data Model 1512 [I-D.liu-teas-transport-network-slice-yang]has the similar goal, but 1513 with different modelling design. Its YANG structure includes three 1514 parts: 1516 o Transport network: a transport network list and an list of nodes 1517 contained in the transport network 1519 o Link: "links" list and "termination points" list describe how 1520 nodes in a network are connected to each other 1522 o Support network: vertical layering relationships between transport 1523 slice networks and underlay networks 1525 Based on this structure, the transport slice-specific SLO attributes 1526 nodes are augmented on the Network Topologies model,, e.g. isolation 1527 etc. However, this modeling design requires the transport network to 1528 expose a lot of details of the network, such as the actual topology 1529 including nodes interconnection and different network layers 1530 interconnection. 1532 Appendix B. Appendix B Transporst Slice Traffic Criteria 1534 In some scenarios, some sites supports the customer service traffic 1535 of multiple slices. The transport network connected to the sites 1536 needs to identify the traffic of' different slices to provide 1537 different SLO guarantees. But the transport network does not have 1538 prior knowledge of these information. Therefore, the transport slice 1539 model needs to carry these slice traffic classification information. 1540 'ts-traffic-criteria' container is used to specify the TS traffic- 1541 related parameters, including IP addresses, VLAN information, and 1542 etc. 1544 +-------------------------------------------------------+ 1545 | Higher Layer System | 1546 +-------------------------------------------------------+ 1547 | | | 1548 | Transport Slice Model | 1549 +----------+ | +-----------+ 1550 | | | | | 1551 |RAN Slice | +----------------+ |Core Slice | 1552 |controlle | | TS controller | | controller| 1553 +----+-----+ +-------+--------+ +-----+-----+ 1554 | | | 1555 | | | 1556 +---+--+ +------------+----------------+ ++-----+ 1557 | | | | | | 1558 | | | | | | 1559 |+----+|TS1-EP1| | | | 1560 || || | | TS1 | |+----+| 1561 ||gNB1|+---+---+-----+-----------------------+---+---+|UPF1|| 1562 || |+***+****** / | | |+----+| 1563 |+----+|TS2-EP1| */ |TS1-EP3| | 1564 | | | /* | | | 1565 |+----+|TS1-EP2| / * | | | 1566 || |+---+---- * TS2 | |+----+| 1567 ||gNB2|+***+*************************************+****|UPF2|| 1568 || || | | | | |+----+| 1569 |+----+|TS2-EP2| |TS2-EP3| | 1570 | | | | | | 1571 | | | | | | 1572 +------+ +-----------------------------+ +------+ 1574 As shown in the figure, gNodeB 1 and gNodeB 2 use IP gNB1 and IP gNB2 1575 to communicate with the transport network, respectively. In 1576 addition, the traffic of TS1 and TS2 on gNodeB 1 and gNodeB 2 is 1577 transmitted through the same links to the transport network. 1578 Therefore, edge devices of the transport network cannot use IP 1579 addresses to distinguish a specific slice traffic. Other information 1580 is therefore needed to identity it. 1582 Authors' Addresses 1584 Bo Wu 1585 Huawei Technologies 1586 101 Software Avenue, Yuhua District 1587 Nanjing, Jiangsu 210012 1588 China 1590 Email: lana.wubo@huawei.com 1592 Dhruv Dhody 1593 Huawei Technologies 1594 Divyashree Techno Park 1595 Bangalore, Karnataka 560066 1596 India 1598 Email: dhruv.ietf@gmail.com 1600 Liuyan Han 1601 China Mobile 1603 Email: hanliuyan@chinamobile.com 1605 Reza Rokui 1606 Nokia Canada 1608 Email: reza.rokui@nokia.com