idnits 2.17.1 draft-wd-teas-transport-slice-yang-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 3 instances of too long lines in the document, the longest one being 4 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 287 has weird spacing: '...mber-id lea...' == Line 307 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 (July 12, 2020) is 1381 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: 'RFC6991' is defined on line 1322, but no explicit reference was found in the text == Outdated reference: A later version (-05) exists of draft-nsdt-teas-ns-framework-03 ** 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-02 ** Downref: Normative reference to an Informational draft: draft-nsdt-teas-transport-slice-definition (ref. 'I-D.nsdt-teas-transport-slice-definition') == Outdated reference: A later version (-05) exists of draft-geng-teas-network-slice-mapping-01 == 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-01 Summary: 3 errors (**), 0 flaws (~~), 10 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: January 13, 2021 L. Han 6 China Mobile 7 R. Rokui 8 Nokia Canada 9 July 12, 2020 11 A Yang Data Model for Transport Slice NBI 12 draft-wd-teas-transport-slice-yang-02 14 Abstract 16 This document provides a YANG data model for the Transport Slice NBI. 17 The model can be used by a higher level system which is the Transport 18 slice consumer of a Transport Slice Controller (TSC) to request, 19 configure, and manage the components of a transport slices. 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 January 13, 2021. 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 NBI Model Usage . . . . . . . . . . . . . . . 4 62 4. Transport Slice NBI Model Overview . . . . . . . . . . . . . 5 63 5. Transport Slice NBI Model Description . . . . . . . . . . . . 8 64 5.1. Transport Slice Connection Pattern . . . . . . . . . . . 8 65 5.2. Transport Slice EndPoint (TSE) . . . . . . . . . . . . . 8 66 5.3. Transport Slice SLO . . . . . . . . . . . . . . . . . . . 9 67 6. Transport Slice Monitoring . . . . . . . . . . . . . . . . . 10 68 7. Transport Slice NBI Model Usage Example . . . . . . . . . . . 11 69 8. Transport Slice NBI Module . . . . . . . . . . . . . . . . . 11 70 9. Security Considerations . . . . . . . . . . . . . . . . . . . 26 71 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 72 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27 73 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 74 12.1. Normative References . . . . . . . . . . . . . . . . . . 27 75 12.2. Informative References . . . . . . . . . . . . . . . . . 29 76 Appendix A. Comparison with Other Possible Design choices for 77 Transport Slice NBI (Northbound Interface) . . . . . 30 78 A.1. ACTN VN Model Augmentation . . . . . . . . . . . . . . . 30 79 A.2. RFC8345 Augmentation Model . . . . . . . . . . . . . . . 31 80 Appendix B. Appendix B Transport Slice Filter Criteria . . . . . 31 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 83 1. Introduction 85 This document provides a YANG [RFC7950] data model for the transport 86 Slice NBI. 88 The YANG model discussed in this document is defined based on the 89 description of the transport slice in 90 [I-D.nsdt-teas-transport-slice-definition] and 91 [I-D.nsdt-teas-ns-framework], which is used to operate customer- 92 driven Transport Slice during the Transport Slice instantiation, and 93 the operations includes modification, deletion, and monitoring. 95 The YANG model discussed in this document describes the requirements 96 of a Transport Slice that interconnects a set of Transport Slice 97 Endpoints from the point of view of the consumer, which is classified 98 as Customer Service Model in [RFC8309]. 100 It will be up to the management system or TSC (Transport Slice 101 controller) to take this model as an input and use other management 102 system or specific configuration models to configure the different 103 network elements to deliver a Transport Slice. The YANG models can 104 be used with network management protocols such as NETCONF [RFC6241] 105 or RESTCONF [RFC8040]. How the configuration of network elements is 106 done is out of scope for this document. 108 The Transport Slice operational state is included in the same tree as 109 the configuration consistent with Network Management Datastore 110 Architecture [RFC8342]. 112 2. Conventions used in this document 114 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 115 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 116 "OPTIONAL" in this document are to be interpreted as described in 117 BCP14, [RFC2119], [RFC8174] when, and only when, they appear in all 118 capitals, as shown here. 120 The following terms are defined in [RFC6241] and are used in this 121 specification: 123 o client 125 o configuration data 127 o state data 129 This document also makes use of the following terminology introduced 130 in the YANG 1.1 Data Modeling Language [RFC7950]: 132 o augment 134 o data model 136 o data node 138 This document also makes use of the following terminology introduced 139 in the Transport Slice definition draft 140 [I-D.nsdt-teas-transport-slice-definition]: 142 o Transport Slice: A transport slice is a logical network topology 143 connecting a number of endpoints and a set of shared or dedicated 144 network resources, which are used to satisfy specific Service 145 Level Objectives (SLO). The definition is from Section 3 of 146 [I-D.nsdt-teas-transport-slice-definition]. 148 o Transport Slice Endpoint (TSE): A Transport Slice Endpoint is a 149 logical identifier at an external interface of Transport Network 150 to identify the logical access to which, a particular subset of 151 traffic traversing the external interface, is mapped to a specific 152 TS and it follows the definition of TSE (Transport Slice Endpoint) 153 in Section 4.2 of [I-D.nsdt-teas-transport-slice-definition]. 155 o SLO: An SLO is a service level objective 157 o DAN: Device,Application,Network Function 159 o TSC: Transport Slice Controller 161 o NBI: NorthBound Interface 163 In addition, this document defines the following terminology: 165 o Transport Slice Member (TS-Member): A TS member is an abstract 166 entity which represents the transport resources mapped to a 167 particular connection between a pair of TSEs belonging to a 168 Transport slice. Note that different SLO requirement per-TS- 169 Member could be applied. 171 o TS-SLO-Group: Indicates a group of TS-members with same SLOs in 172 one transport slice. 174 2.1. Tree Diagrams 176 Tree diagrams used in this document follow the notation defined in 177 [RFC8340]. 179 3. Transport Slice NBI Model Usage 181 The intention of the transport slice NBI model is to allow the 182 consumer, e.g. A higher level management system, to request and 183 monitor transport slices. In particular, the model allows consumers 184 to operate in an abstract, technology-agnostic manner, with 185 implementation details hidden. 187 In the use case of 5G transport application, the E2E network slice 188 orchestrator acts as the higher layer system to request the transport 189 slices. The interface is used to support dynamic transport slice 190 creation and its lifecycle management to facilitate end-to-end 191 network slice services. 193 +----------------------------------------+ 194 | Transport Slice Consumer | 195 | | 196 +----------------+-----------------------+ 197 | 198 | Transport Slice NBI YANG 199 | 200 | 201 +---------------------+--------------------------+ 202 | Transport Slice Controller | 203 +------------------------------------------------+ 205 Figure 1 Transport Slice NBI Model Context 207 4. Transport Slice NBI Model Overview 209 From a consumer perspective, an example of a transport slice is shown 210 in figure 2. 212 Transport Network 213 DAN1 +---------------------------------+ DAN3 214 +--------+ | | +--------+ 215 | /--\ | | /--\ | 216 | |TSE1+-+ +-+TSE3| | 217 +--------\--/ | | \--/ | 218 | | | | 219 +--------+ | | | 220 | /--\ | | /--\ | 221 | |TSE2+-+ +-+TSE4| | 222 | \--/ | | \--/ | 223 +--------+ | | +--------+ 224 DAN2 +---------------------------------+ 225 | | 226 | | 227 |<------------Transport Slice 1------------->| 229 Legend:DAN (Device,Application,Network Function) 231 TS-SLO-Group Red TS-SLO-Group Blue 232 TS-Member 2 TSE1-TSE3 TS-Member 1 TSE1-TSE2 233 TS-Member 3 TSE1-TSE4 234 TS-Member 4 TSE2-TSE3 235 TS-Member 5 TSE2-TSE4 237 Figure 2: An example of TSEs and TS-Members of a transport slice 239 As shown in figure 2, a Transport Slice (TS) links together TSEs at 240 external Interfaces to the DANs, which are customer endpoints that 241 request a transport slice. At each customer DAN, one or multiple 242 TSEs could be connected to the Transport Slice. 244 A TS is a connectivity service with specific SLO characteristics, 245 including bandwidth, QoS metric, etc. The connectivity service is a 246 combination of logical connections, represented by TS-members. When 247 some parts of a slice have different SLO requirements, a group of TS- 248 Members with the same SLO is described by TS-SLO-Group. 250 Based on this design, the Transport Slice YANG module consists of the 251 main containers: "transport-slice", "ts-endpoint", "ts-member",and 252 "ts-slo-group". 254 The figure below describes the overall structure of the YANG module: 256 module: ietf-transport-slice 257 +--rw transport-slices 258 +--rw slice-templates 259 | +--rw slice-template* [id] 260 | +--rw id string 261 | +--rw template-description? string 262 +--rw transport-slice* [ts-id] 263 +--rw ts-id uint32 264 +--rw ts-name? string 265 +--rw ts-topology* identityref 266 +--rw ts-slo-group* [slo-group-name] 267 | +--rw slo-group-name string 268 | +--rw default-slo-group? boolean 269 | +--rw slo-tag? string 270 | +--rw (slo-template)? 271 | | +--:(standard) 272 | | | +--rw template? leafref 273 | | +--:(custom) 274 | | +--rw ts-slo-policy 275 | | +--rw latency 276 | | | +--rw one-way-latency? uint32 277 | | | +--rw two-way-latency? uint32 278 | | +--rw jitter 279 | | | +--rw one-way-jitter? uint32 280 | | | +--rw two-way-jitter? uint32 281 | | +--rw loss 282 | | | +--rw one-way-loss? decimal64 283 | | | +--rw two-way-loss? decimal64 284 | | +--rw availability-type? identityref 285 | | +--rw isolation-type? identityref 286 | +--rw ts-member-group* [ts-member-id] 287 | | +--rw ts-member-id leafref 288 | +--ro slo-group-monitoring 289 | +--ro latency? uint32 290 | +--ro jitter? uint32 291 | +--ro loss? decimal64 292 +--rw status 293 | +--rw admin-enabled? boolean 294 | +--ro oper-status? operational-type 295 +--rw ts-endpoint* [ep-id] 296 | +--rw ep-id uint32 297 | +--rw ep-name? string 298 | +--rw ep-role* identityref 299 | +--rw geolocation 300 | | +--rw altitude? int64 301 | | +--rw latitude? decimal64 302 | | +--rw longitude? decimal64 303 | +--rw node-id? string 304 | +--rw port-id? string 305 | +--rw ts-filter-criteria 306 | | +--rw ts-filter-criteria* [match-type] 307 | | +--rw match-type identityref 308 | | +--rw value? string 309 | +--rw bandwidth 310 | | +--rw incoming-bandwidth 311 | | | +--rw guaranteed-bandwidth? te-types:te-bandwidth 312 | | +--rw outgoing-bandwidth 313 | | +--rw guaranteed-bandwidth? te-types:te-bandwidth 314 | +--rw mtu uint16 315 | +--rw protocol 316 | | +--rw bgp 317 | | | +--rw bgp-peer-ipv4* inet:ipv4-prefix 318 | | | +--rw bgp-peer-ipv6* inet:ipv6-prefix 319 | | +--rw static 320 | | +--rw static-route-ipv4* inet:ipv4-prefix 321 | | +--rw static-route-ipv6* inet:ipv6-prefix 322 | +--rw status 323 | | +--rw admin-enabled? boolean 324 | | +--ro oper-status? operational-type 325 | +--ro ep-monitoring 326 | +--ro incoming-utilized-bandwidth? 327 | | te-types:te-bandwidth 328 | +--ro incoming-bw-utilization decimal64 329 | +--ro outgoing-utilized-bandwidth? 330 | | te-types:te-bandwidth 331 | +--ro outgoing-bw-utilization decimal64 332 +--rw ts-member* [ts-member-id] 333 +--rw ts-member-id uint32 334 +--rw src 335 | +--rw src-ts-ep-id? leafref 336 +--rw dest 337 | +--rw dest-ts-ep-id? leafref 338 +--rw monitoring-type? ts-monitoring-type 339 +--ro ts-member-monitoring 340 +--ro latency? uint32 341 +--ro jitter? uint32 342 +--ro loss? decimal64 344 5. Transport Slice NBI Model Description 346 A Transport Slice consists of a group of interconnected TSEs, and the 347 connections between TSEs may have different SLO requirements, 348 including symmetrical or asymmetrical traffic throughput, different 349 traffic delay, etc. 351 5.1. Transport Slice Connection Pattern 353 A Transport Slice can be point-to-point (P2P), point-to-multipoint 354 (P2MP), multipoint-to-point (MP2P), or multipoint-to-multipoint 355 (MP2MP) based on the consumer's traffic pattern requirements. 357 Therefore, the "ts-topology" under the node "transport-slice" is 358 required for configuration. The model supports any-to-any, Hub and 359 Spoke (where Hubs can exchange traffic), and the different 360 combinations. New topologies could be added via augmentation. By 361 default, the any-to-any topology is used. 363 In addition, "ep-role" under the node "ts-endpoint" also needs to be 364 defined, which specifies the role of the TSE in a particular TS 365 topology. In the any-to-any topology, all TSEs MUST have the same 366 role, which will be "any-to-any-role". In the Hub-and-Spoke 367 topology, TSEs MUST have a Hub role or a Spoke role. 369 5.2. Transport Slice EndPoint (TSE) 371 A TSE belong to a single Transport Slice. A TS involves two or more 372 TSEs. 374 A TSE is used to define the limit on the user traffic that can be 375 injected to a TS. For example, in some scenarios, the access traffic 376 of a DAN is allowed only when it matches the logical Layer 2 377 connection identifier. In some scenarios, the access traffic of a 378 DAN is allowed only when the traffic matches a source IP address. 379 Sometimes, the traffic from a distinct physical connection of a DAN 380 is allowed. 382 Therefore, to ensure that the TSE is uniquely identified, the model 383 use the following parameters including "node-id", "port-id" and "ts- 384 filter-criteria". The "node-id" identifies a DAN node, the "tp-id" 385 identifies a port, and the "ts-filter-criteria" identifies a possible 386 logical L2 ID or IP address or other possible traffic identifier in 387 the user traffic. 389 Additionally, a number of slice interconnection parameters need to be 390 agreed with a customer DAN and the transport network, such as IP 391 address (v4 or v6) etc. 393 5.3. Transport Slice SLO 395 As defined in [I-D.nsdt-teas-transport-slice-definition] 397 This model defines the minimum Transport Slice SLO attributes, and 398 other SLO nodes can be augmented as needed. TS SLO assurance is 399 implemented through the following mechanisms: 401 o TS SLO list: Which defines the performance objectives of the TS. 402 Performance objectives can be specified for various performance 403 metrics,and different objectives are as follows: 405 Latency: Indicates the maximum latency between two TSE. The 406 unit is micro seconds. The latency could be round trip times 407 or one-way metrics. 409 Jitter: Indicates the jitter constraint of the slice maximum 410 permissible delay variation, and is measured by the difference 411 in the one- way delay between sequential packets in a flow. 413 Loss: Indicates maximum permissible packet loss rate, which is 414 defined by the ratio of packets dropped to packets transmitted 415 between two endpoints. 417 Availability: Is defined as the ratio of up-time to 418 total_time(up-time+down-time), where up-time is the time the 419 transport slice is available in accordance with the SLOs 420 associated with it. 422 Isolation: Whether the isolation needs to be explicitly 423 requested is still in discussion. 425 o Bandwidth: Indicates the guaranteed minimum bandwidth between any 426 two TSE. The unit is data rate per second. And the bandwidth is 427 unidirectional. The bandwidth is specified at each TSE and can be 428 applied to incoming TS traffic or outgoing TS traffic. When 429 applied in the incoming direction, the Bandwidth is applicable to 430 the traffic from the TSE to the Transport Network that passes 431 through the external interface. When Bandwidth is applied to the 432 outgoing direction, it is applied to the traffic from the TN to 433 the TSE of that particular TS. 435 Note: About the definition of SLO parameters, the author is 436 discussing to reuse the TE-Types grouping definition as much as 437 possible, to avoid duplication of definitions. 439 Consumers' Tranport Slices can be very different, e.g. some slices 440 has the same SLO requirements of connections, some slices has the 441 different SLO requirements for different parts of the slice. In some 442 slices, the bandwidth of one endpoint is different from that of other 443 endpoints, for example, one is central endpoint, the other endpoints 444 are access endpoints. 446 The list "ts-slo-group" defines a group of different SLOs, which are 447 used to describe that different parts of the slice have different 448 SLOs. The specific SLO of the slice SLO group may use a standard SLO 449 template, or may use different customized parameters. A group of 450 "ts-member" is used to describe which connections of the slice use 451 the SLO. 453 For some simplest Transport Slices, only one category SLO of "ts-slo- 454 group" needs to be defined. For some complicated slices, in addition 455 to the configurations above, multiple "ts-slo-group" needs to be 456 defined, and "ts-member-group" under the "ts-slo-group" or "slo- 457 group" under the "ts-member" describe details of the per-connection 458 SLO. 460 In addition to SLO performance objectives, there are also some other 461 TS objectives, such as MTU and security which can be augmented when 462 needed. MTU specifies the maximum packet length that the slice 463 guarantee to be able to carry across. 465 Note: In some use cases, the number of connections represented by 466 "ts-member-group" may be huge, which may lead to configuration 467 issues, for example, the scalability or error-prone. 469 6. Transport Slice Monitoring 471 This model also describes performance status of a transport slice. 472 The statistics are described in the following granularity: 474 o Per TS SLO group: specified in 'ts-member-group-monitoring' under 475 the "ts-slo-groupr" 477 o Per TS connection: specified in 'ts-member-monitoring' under the 478 "ts-member" 480 o Per TS Endpoint: specified in 'ep-monitoring' under the "ts- 481 endpoint" 483 This model does not define monitoring enabling methods. The 484 mechanism defined in [RFC8640] and [RFC8641] can be used for either 485 periodic or on-demand subscription. 487 By specifying subtree filters or xpath filters to 'ts-member' or 488 'endpoint' ,so that only interested contents will be sent. These 489 mechanisms can be used for monitoring the transport slice performance 490 status so that the client management system could initiate 491 modification based on the transport slice running status. 493 7. Transport Slice NBI Model Usage Example 495 TBD 497 8. Transport Slice NBI Module 499 file "ietf-transport-slice@2020-07-12.yang" 501 module ietf-transport-slice { 502 yang-version 1.1; 503 namespace "urn:ietf:params:xml:ns:yang:ietf-transport-slice"; 504 prefix ts; 506 import ietf-inet-types { 507 prefix inet; 508 } 509 import ietf-te-types { 510 prefix te-types; 511 } 513 organization 514 "IETF Traffic Engineering Architecture and Signaling (TEAS) 515 Working Group"; 516 contact 517 "WG Web: 518 WG List: 519 Editor: Bo Wu 520 : Dhruv Dhody "; 521 description 522 "This module contains a YANG module for the Transport Slice NBI. 524 Copyright (c) 2020 IETF Trust and the persons identified as 525 authors of the code. All rights reserved. 527 Redistribution and use in source and binary forms, with or 528 without modification, is permitted pursuant to, and subject to 529 the license terms contained in, the Simplified BSD License set 530 forth in Section 4.c of the IETF Trust's Legal Provisions 531 Relating to IETF Documents 532 (http://trustee.ietf.org/license-info). 534 This version of this YANG module is part of RFC XXXX; see the 535 RFC itself for full legal notices."; 537 revision 2020-07-12 { 538 description 539 "initial version."; 540 reference 541 "RFC XXXX: A Yang Data Model for Transport Slice NBI Operation"; 542 } 544 /* Features */ 545 /* Identities */ 547 identity ts-topology { 548 description 549 "Base identity for Transport Slice topology."; 550 } 552 identity any-to-any { 553 base ts-topology; 554 description 555 "Identity for any-to-any Transport Slice topology."; 556 } 558 identity hub-spoke { 559 base ts-topology; 560 description 561 "Identity for Hub-and-Spoke Transport Slice topology."; 562 } 564 identity ep-role { 565 description 566 "TSE Role in a Transport Slice topology "; 567 } 569 identity any-to-any-role { 570 base ep-role; 571 description 572 "TSE as the any-to-any role in an any-to-any Transport Slice."; 573 } 575 identity hub { 576 base ep-role; 577 description 578 "TSE as the hub role in a Hub-and-Spoke Transport Slice."; 579 } 581 identity spoke { 582 base ep-role; 583 description 584 "TSE as the spoke role in a Hub-and-Spoke transport slice."; 585 } 587 identity isolation-type { 588 description 589 "Base identity from which specific isolation types are derived."; 590 } 592 identity physical-isolation { 593 base isolation-type; 594 description 595 "physical isolation."; 596 } 598 identity logical-isolation { 599 base isolation-type; 600 description 601 "logical-isolation."; 602 } 604 identity ts-slo-metric-type { 605 description 606 "Base identity for TS SLO metric type"; 607 } 609 identity ts-match-type { 610 description 611 "Base identity for TS metric type"; 612 } 614 identity ts-vlan-match { 615 base ts-match-type; 616 description 617 "logical-isolation."; 618 } 620 /* 621 * Identity for availability-type 622 */ 624 identity availability-type { 625 description 626 "Base identity from which specific map types are derived."; 627 } 629 identity level-1 { 630 base availability-type; 631 description 632 "level 1: 99.9999%"; 633 } 635 identity level-2 { 636 base availability-type; 637 description 638 "level 2: 99.999%"; 639 } 641 identity level-3 { 642 base availability-type; 643 description 644 "level 3: 99.99%"; 645 } 647 identity level-4 { 648 base availability-type; 649 description 650 "level 4: 99.9%"; 651 } 653 identity level-5 { 654 base availability-type; 655 description 656 "level 5: 99%"; 657 } 659 /* typedef */ 661 typedef operational-type { 662 type enumeration { 663 enum up { 664 value 0; 665 description 666 "Operational status UP."; 667 } 668 enum down { 669 value 1; 670 description 671 "Operational status DOWN"; 673 } 674 enum unknown { 675 value 2; 676 description 677 "Operational status UNKNOWN"; 678 } 679 } 680 description 681 "This is a read-only attribute used to determine the 682 status of a particular element"; 683 } 685 typedef ts-monitoring-type { 686 type enumeration { 687 enum one-way { 688 description 689 "represents one-way monitoring type"; 690 } 691 enum two-way { 692 description 693 "represents two-way monitoring type"; 694 } 695 } 696 description 697 "enumerated type of monitoring on a ts-member "; 698 } 700 /* Groupings */ 702 grouping status-params { 703 description 704 "Grouping used to join operational and administrative status"; 705 container status { 706 description 707 "Container for status of administration and operational"; 708 leaf admin-enabled { 709 type boolean; 710 description 711 "Administrative Status UP/DOWN"; 712 } 713 leaf oper-status { 714 type operational-type; 715 config false; 716 description 717 "Operations status"; 718 } 719 } 720 } 721 grouping ts-filter-criteria { 722 description 723 "Grouping for TS filter definition."; 724 container ts-filter-criteria { 725 description 726 "Describes TS filter criteria."; 727 list ts-filter-criteria { 728 key "match-type"; 729 description 730 "List of TS traffic criteria"; 731 leaf match-type { 732 type identityref { 733 base ts-match-type; 734 } 735 description 736 "Identifies an entry in the list of match-type for the TS."; 737 } 738 leaf value { 739 type string; 740 description 741 "Describes TS filter criteria,e.g. IP address, VLAN, etc."; 742 } 743 } 744 } 745 } 747 grouping routing-protocols { 748 description 749 "Grouping for endpoint protocols definition."; 750 container protocol { 751 description 752 "Describes protocol between TSE and transport network edge device."; 753 container bgp { 754 description 755 "BGP-specific configuration."; 756 leaf-list bgp-peer-ipv4 { 757 type inet:ipv4-prefix; 758 description 759 "BGP peer ipv4 address."; 760 } 761 leaf-list bgp-peer-ipv6 { 762 type inet:ipv6-prefix; 763 description 764 "BGP peer ipv6 address."; 765 } 766 } 767 container static { 768 description 769 "Only applies when protocol is static."; 770 leaf-list static-route-ipv4 { 771 type inet:ipv4-prefix; 772 description 773 "ipv4 static route"; 774 } 775 leaf-list static-route-ipv6 { 776 type inet:ipv6-prefix; 777 description 778 "ipv6 static route"; 779 } 780 } 781 } 782 } 784 grouping ep-monitoring-parameters { 785 description 786 "Grouping for ep-monitoring-parameters."; 787 container ep-monitoring { 788 config false; 789 description 790 "Container for ep-monitoring-parameters."; 791 leaf incoming-utilized-bandwidth { 792 type te-types:te-bandwidth; 793 description 794 "Bandwidth utilization that represents the actual 795 utilization of the incoming endpoint."; 796 } 797 leaf incoming-bw-utilization { 798 type decimal64 { 799 fraction-digits 5; 800 range "0..100"; 801 } 802 units "percent"; 803 mandatory true; 804 description 805 "To be used to define the bandwidth utilization 806 as a percentage of the available bandwidth."; 807 } 808 leaf outgoing-utilized-bandwidth { 809 type te-types:te-bandwidth; 810 description 811 "Bandwidth utilization that represents the actual 812 utilization of the incoming endpoint."; 813 } 814 leaf outgoing-bw-utilization { 815 type decimal64 { 816 fraction-digits 5; 817 range "0..100"; 818 } 819 units "percent"; 820 mandatory true; 821 description 822 "To be used to define the bandwidth utilization 823 as a percentage of the available bandwidth."; 824 } 825 } 826 } 828 grouping common-monitoring-parameters { 829 description 830 "Grouping for link-monitoring-parameters."; 831 leaf latency { 832 type uint32; 833 units "usec"; 834 description 835 "The latency statistics per TS member."; 836 } 837 leaf jitter { 838 type uint32 { 839 range "0..16777215"; 840 } 841 description 842 "The jitter statistics per TS member."; 843 } 844 leaf loss { 845 type decimal64 { 846 fraction-digits 6; 847 range "0 .. 50.331642"; 848 } 849 description 850 "Packet loss as a percentage of the total traffic 851 sent over a configurable interval. The finest precision is 852 0.000003%. where the maximum 50.331642%."; 853 reference 854 "RFC 7810, section-4.4"; 855 } 856 } 858 grouping geolocation-container { 859 description 860 "A grouping containing a GPS location."; 861 container geolocation { 862 description 863 "A container containing a GPS location."; 864 leaf altitude { 865 type int64; 866 units "millimeter"; 867 description 868 "Distance above the sea level."; 869 } 870 leaf latitude { 871 type decimal64 { 872 fraction-digits 8; 873 range "-90..90"; 874 } 875 description 876 "Relative position north or south on the Earth's surface."; 877 } 878 leaf longitude { 879 type decimal64 { 880 fraction-digits 8; 881 range "-180..180"; 882 } 883 description 884 "Angular distance east or west on the Earth's surface."; 885 } 886 } 887 // gps-location 888 } 890 // geolocation-container 892 grouping endpoint { 893 description 894 "Transport Slice endpoint related information"; 895 leaf ep-id { 896 type uint32; 897 description 898 "unique identifier for the referred Transport Slice endpoint"; 899 } 900 leaf ep-name { 901 type string; 902 description 903 "ep name"; 904 } 905 leaf-list ep-role { 906 type identityref { 907 base ep-role; 908 } 909 default "any-to-any-role"; 910 description 911 "Role of the endpoint in the Transport Slice."; 912 } 913 uses geolocation-container; 914 leaf node-id { 915 type string; 916 description 917 "Uniquely identifies an edge customer node."; 918 } 919 leaf port-id { 920 type string; 921 description 922 "Reference to the Port-id of the customer node."; 923 } 924 uses ts-filter-criteria; 925 container bandwidth { 926 container incoming-bandwidth { 927 leaf guaranteed-bandwidth { 928 type te-types:te-bandwidth; 929 description 930 "If guaranteed-bandwidth is 0, it means best effort, no 931 minimum throughput is guaranteed."; 932 } 933 description 934 "Container for the incoming bandwidth policy"; 935 } 936 container outgoing-bandwidth { 937 leaf guaranteed-bandwidth { 938 type te-types:te-bandwidth; 939 description 940 "If guaranteed-bandwidth is 0, it means best effort, no 941 minimum throughput is guaranteed."; 942 } 943 description 944 "Container for the bandwidth policy"; 945 } 946 description 947 "Container for the bandwidth policy"; 948 } 949 leaf mtu { 950 type uint16; 951 units "bytes"; 952 mandatory true; 953 description 954 "MTU of TS traffic. If the traffic type is IP, 955 it refers to the IP MTU. If the traffic type is Ethertype, 956 will refer to the Ethernet MTU. "; 957 } 958 uses routing-protocols; 959 uses status-params; 960 uses ep-monitoring-parameters; 962 } 964 //ts-ep 966 grouping ts-member { 967 description 968 "ts-member is described by this container"; 969 leaf ts-member-id { 970 type uint32; 971 description 972 "ts-member identifier"; 973 } 974 container src { 975 description 976 "the source of TS link"; 977 leaf src-ts-ep-id { 978 type leafref { 979 path "/transport-slices/transport-slice/ts-endpoint/ep-id"; 980 } 981 description 982 "reference to source TS endpoint"; 983 } 984 } 985 container dest { 986 description 987 "the destination of TS link "; 988 leaf dest-ts-ep-id { 989 type leafref { 990 path "/transport-slices/transport-slice/ts-endpoint/ep-id"; 991 } 992 description 993 "reference to dest TS endpoint"; 994 } 995 } 996 leaf monitoring-type { 997 type ts-monitoring-type; 998 description 999 "One way or two way monitoring type."; 1000 } 1001 container ts-member-monitoring { 1002 config false; 1003 description 1004 "SLO status Per ts endpoint to endpoint "; 1005 uses common-monitoring-parameters; 1006 } 1007 } 1009 //ts-member 1010 grouping transport-slice-slo-group { 1011 description 1012 "Grouping for SLO definition of TS"; 1013 list ts-slo-group { 1014 key "slo-group-name"; 1015 description 1016 "List of TS SLO groups, the SLO group is used to 1017 support different SLO objectives between different ts-members 1018 in the same slice."; 1019 leaf slo-group-name { 1020 type string; 1021 description 1022 "Identifies an entry in the list of SLO group for the TS."; 1023 } 1024 leaf default-slo-group { 1025 type boolean; 1026 default "false"; 1027 description 1028 "Is the SLO group is selected as the default-slo-group"; 1029 } 1030 leaf slo-tag { 1031 type string; 1032 description 1033 "slo tag for operational management"; 1034 } 1035 choice slo-template { 1036 description 1037 "Choice for SLO template. 1038 Can be standard template or customized template."; 1039 case standard { 1040 description 1041 "Standard SLO template."; 1042 leaf template { 1043 type leafref { 1044 path "/transport-slices/slice-templates/slice-template/id"; 1045 } 1046 description 1047 "QoS template to be used."; 1048 } 1049 } 1050 case custom { 1051 description 1052 "Customized SLO template."; 1053 container ts-slo-policy { 1054 container latency { 1055 leaf one-way-latency { 1056 type uint32 { 1057 range "0..16777215"; 1059 } 1060 units "usec"; 1061 description 1062 "Lowest latency in micro seconds."; 1063 } 1064 leaf two-way-latency { 1065 type uint32 { 1066 range "0..16777215"; 1067 } 1068 description 1069 "Lowest-way delay or latency in micro seconds."; 1070 } 1071 description 1072 "Latency constraint on the traffic class."; 1073 } 1074 container jitter { 1075 leaf one-way-jitter { 1076 type uint32 { 1077 range "0..16777215"; 1078 } 1079 description 1080 "lowest latency in micro seconds."; 1081 } 1082 leaf two-way-jitter { 1083 type uint32 { 1084 range "0..16777215"; 1085 } 1086 description 1087 "lowest-way delay or latency in micro seconds."; 1088 } 1089 description 1090 "Jitter constraint on the traffic class."; 1091 } 1092 container loss { 1093 leaf one-way-loss { 1094 type decimal64 { 1095 fraction-digits 6; 1096 range "0 .. 50.331642"; 1097 } 1098 description 1099 "Packet loss as a percentage of the total traffic sent 1100 over a configurable interval. The finest precision is 1101 0.000003%. where the maximum 50.331642%."; 1102 reference 1103 "RFC 7810, section-4.4"; 1104 } 1105 leaf two-way-loss { 1106 type decimal64 { 1107 fraction-digits 6; 1108 range "0 .. 50.331642"; 1109 } 1110 description 1111 "Packet loss as a percentage of the total traffic sent 1112 over a configurable interval. The finest precision is 1113 0.000003%. where the maximum 50.331642%."; 1114 reference 1115 "RFC 7810, section-4.4"; 1116 } 1117 description 1118 "Loss constraint on the traffic class."; 1119 } 1120 leaf availability-type { 1121 type identityref { 1122 base availability-type; 1123 } 1124 description 1125 "Availability Requirement for the TS"; 1126 } 1127 leaf isolation-type { 1128 type identityref { 1129 base isolation-type; 1130 } 1131 default "logical-isolation"; 1132 description 1133 "TS isolation-level."; 1134 } 1135 description 1136 "container for customized policy constraint on the slice 1137 traffic."; 1138 } 1139 } 1140 } 1141 list ts-member-group { 1142 key "ts-member-id"; 1143 description 1144 "List of included TS Member groups for the SLO."; 1145 leaf ts-member-id { 1146 type leafref { 1147 path "/transport-slices/transport-slice/ts-member/ts-member-id"; 1148 } 1149 description 1150 "Identifies the included list of TS member."; 1151 } 1152 } 1153 container slo-group-monitoring { 1154 config false; 1155 description 1156 "SLO status Per slo group "; 1157 uses common-monitoring-parameters; 1158 } 1159 } 1160 } 1162 grouping slice-template { 1163 description 1164 "Grouping for slice-templates."; 1165 container slice-templates { 1166 description 1167 "Container for slice-templates."; 1168 list slice-template { 1169 key "id"; 1170 leaf id { 1171 type string; 1172 description 1173 "Identification of the SLO Template to be used. 1174 Local administration meaning."; 1175 } 1176 leaf template-description { 1177 type string; 1178 description 1179 "Description of the SLO template."; 1180 } 1181 description 1182 "List for SLO template identifiers."; 1183 } 1184 } 1185 } 1187 /* Configuration data nodes */ 1189 container transport-slices { 1190 description 1191 "transport-slice configurations"; 1192 uses slice-template; 1193 list transport-slice { 1194 key "ts-id"; 1195 description 1196 "a transport-slice is identified by a ts-id"; 1197 leaf ts-id { 1198 type uint32; 1199 description 1200 "a unique transport-slice identifier"; 1201 } 1202 leaf ts-name { 1203 type string; 1204 description 1205 "ts name"; 1206 } 1207 leaf-list ts-topology { 1208 type identityref { 1209 base ts-topology; 1210 } 1211 default "any-to-any"; 1212 description 1213 "TS topology."; 1214 } 1215 uses transport-slice-slo-group; 1216 uses status-params; 1217 list ts-endpoint { 1218 key "ep-id"; 1219 uses endpoint; 1220 description 1221 "list of endpoints in this slice"; 1222 } 1223 list ts-member { 1224 key "ts-member-id"; 1225 description 1226 "List of ts-member in a slice"; 1227 uses ts-member; 1228 } 1229 } 1230 //ts-list 1231 } 1232 } 1234 1236 9. Security Considerations 1238 The YANG module defined in this document is designed to be accessed 1239 via network management protocols such as NETCONF [RFC6241] or 1240 RESTCONF [RFC8040]. The lowest NETCONF layer is the secure transport 1241 layer, and the mandatory-to-implement secure transport is Secure 1242 Shell (SSH) [RFC6242]. The lowest RESTCONF layer is HTTPS, and the 1243 mandatory-to-implement secure transport is TLS [RFC8446]. 1245 The NETCONF access control model [RFC8341] provides the means to 1246 restrict access for particular NETCONF or RESTCONF users to a 1247 preconfigured subset of all available NETCONF or RESTCONF protocol 1248 operations and content. 1250 There are a number of data nodes defined in this YANG module that are 1251 writable/creatable/deletable (i.e., config true, which is the 1252 default). These data nodes may be considered sensitive or vulnerable 1253 in some network environments. Write operations (e.g., edit-config) 1254 to these data nodes without proper protection can have a negative 1255 effect on network operations. 1257 o /ietf-transport-slice/transport-slices/transport-slice 1259 The entries in the list above include the whole transport network 1260 configurations corresponding with the slice which the higher 1261 management system requests, and indirectly create or modify the PE or 1262 P device configurations. Unexpected changes to these entries could 1263 lead to service disruption and/or network misbehavior. 1265 10. IANA Considerations 1267 This document registers a URI in the IETF XML registry [RFC3688]. 1268 Following the format in [RFC3688], the following registration is 1269 requested to be made: 1271 URI: urn:ietf:params:xml:ns:yang:ietf-transport-slice 1272 Registrant Contact: The IESG. 1273 XML: N/A, the requested URI is an XML namespace. 1275 This document requests to register a YANG module in the YANG Module 1276 Names registry [RFC7950]. 1278 Name: ietf-transport-slice 1279 Namespace: urn:ietf:params:xml:ns:yang:ietf-transport-slice 1280 Prefix: ts 1281 Reference: RFC XXXX 1283 11. Acknowledgments 1285 The authors wish to thank Sergio Belotti, Qin Wu, Susan Hares, Eric 1286 Grey, and many other NS DT members for their helpful comments and 1287 suggestions. 1289 12. References 1291 12.1. Normative References 1293 [I-D.nsdt-teas-ns-framework] 1294 Gray, E. and J. Drake, "Framework for Transport Network 1295 Slices", draft-nsdt-teas-ns-framework-03 (work in 1296 progress), April 2020. 1298 [I-D.nsdt-teas-transport-slice-definition] 1299 Rokui, R., Homma, S., Makhijani, K., and L. Contreras, 1300 "IETF Definition of Transport Slice", draft-nsdt-teas- 1301 transport-slice-definition-02 (work in progress), April 1302 2020. 1304 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1305 Requirement Levels", BCP 14, RFC 2119, 1306 DOI 10.17487/RFC2119, March 1997, 1307 . 1309 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1310 DOI 10.17487/RFC3688, January 2004, 1311 . 1313 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1314 and A. Bierman, Ed., "Network Configuration Protocol 1315 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1316 . 1318 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 1319 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 1320 . 1322 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 1323 RFC 6991, DOI 10.17487/RFC6991, July 2013, 1324 . 1326 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1327 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1328 . 1330 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1331 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 1332 . 1334 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1335 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1336 May 2017, . 1338 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 1339 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 1340 . 1342 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 1343 Access Control Model", STD 91, RFC 8341, 1344 DOI 10.17487/RFC8341, March 2018, 1345 . 1347 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 1348 and R. Wilton, "Network Management Datastore Architecture 1349 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 1350 . 1352 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1353 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1354 . 1356 [RFC8640] Voit, E., Clemm, A., Gonzalez Prieto, A., Nilsen-Nygaard, 1357 E., and A. Tripathy, "Dynamic Subscription to YANG Events 1358 and Datastores over NETCONF", RFC 8640, 1359 DOI 10.17487/RFC8640, September 2019, 1360 . 1362 [RFC8641] Clemm, A. and E. Voit, "Subscription to YANG Notifications 1363 for Datastore Updates", RFC 8641, DOI 10.17487/RFC8641, 1364 September 2019, . 1366 12.2. Informative References 1368 [I-D.geng-teas-network-slice-mapping] 1369 Geng, X., Dong, J., Pang, R., Han, L., Niwa, T., Jin, J., 1370 Liu, C., and N. Nageshar, "5G End-to-end Network Slice 1371 Mapping from the view of Transport Network", draft-geng- 1372 teas-network-slice-mapping-01 (work in progress), April 1373 2020. 1375 [I-D.ietf-teas-actn-vn-yang] 1376 Lee, Y., Dhody, D., Ceccarelli, D., Bryskin, I., and B. 1377 Yoon, "A Yang Data Model for VN Operation", draft-ietf- 1378 teas-actn-vn-yang-08 (work in progress), March 2020. 1380 [I-D.liu-teas-transport-network-slice-yang] 1381 Liu, X., Tantsura, J., Bryskin, I., Contreras, L., WU, Q., 1382 Belotti, S., and R. Rokui, "Transport Network Slice YANG 1383 Data Model", draft-liu-teas-transport-network-slice- 1384 yang-01 (work in progress), July 2020. 1386 [RFC8309] Wu, Q., Liu, W., and A. Farrel, "Service Models 1387 Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018, 1388 . 1390 Appendix A. Comparison with Other Possible Design choices for Transport 1391 Slice NBI (Northbound Interface) 1393 According to the TS framework draft 3.3.1. Northbound Inteface 1394 (NBI), the TS NBI is a technology-agnostic interface, which is used 1395 for a consumer to express requirements for a particular TS. 1396 Consumers operate on abstract transport slices, with details related 1397 to their realization hidden. As classified by [RFC8309], the TS NBI 1398 is classified as Customer Service Model. 1400 This draft analyzes the following existing IETF models to identify 1401 the gap between TS NBI requirements. 1403 A.1. ACTN VN Model Augmentation 1405 The difference between the ACTN VN model and the TS NBI requirements 1406 is that the TS NBI is an technology-agnostic interface, whereas the 1407 VN model is bound to the IETF TE Topologies YANG model. The 1408 realization of the Transport Slice does not necessarily require the 1409 Transport network to support the TE technology. 1411 The ACTN VN (Virtual Network) model introduced in 1412 [I-D.ietf-teas-actn-vn-yang] is the abstract consumer view of the TE 1413 network. Its YANG structure includes four components: 1415 o VN: The VN can be seen as a set of edge-to-edge abstract links (a 1416 Type 1 VN). 1418 o AP"links" list and "termination points" list describe how nodes in 1419 a network are connected to each other 1421 o VN-AP:vertical layering relationships between transport slice 1422 networks and underlay networks 1424 o VN-member: Each abstract link is referred to as a VN member and is 1425 formed as an E2E tunnel across the underlying networks 1427 The "VN","VN-AP", and "VN-member" can describe basic consumer 1428 connection requirements. However, the TS SLO and TS-Endpoint are not 1429 clearly defined and there's no direct equivalent. For example, the 1430 SLO requirement of the VN is defined through the IETF TE Topologies 1431 YANG model, but the TE Topologies model is related to a specific 1432 implementation technology. Also, VN-AP does not define "ts-filter- 1433 criteria" to specify a specific TSE belonging to a TS. 1435 A.2. RFC8345 Augmentation Model 1437 The difference between the TS NBI requirements and the IETF basic 1438 network model is that the TS NBI requests abstract consumer transport 1439 slices, with details related to the Transport Network hidden. But 1440 the IETF network model is used to describe the interconnection 1441 details of a Transport Network. The customer service model does not 1442 need to provide details on the Transport Network. 1444 For example, IETF Network Topologies YANG data model extension 1445 introduced in Transport Network Slice YANG Data Model 1446 [I-D.liu-teas-transport-network-slice-yang] includes three major 1447 parts: 1449 o Transport network: a transport network list and an list of nodes 1450 contained in the transport network 1452 o Link: "links" list and "termination points" list describe how 1453 nodes in a network are connected to each other 1455 o Support network: vertical layering relationships between transport 1456 slice networks and underlay networks 1458 Based on this structure, the transport slice-specific SLO attributes 1459 nodes are augmented on the Network Topologies model,, e.g. isolation 1460 etc. However, this modeling design requires the transport network to 1461 expose a lot of details of the network, such as the actual topology 1462 including nodes interconnection and different network layers 1463 interconnection. 1465 Appendix B. Appendix B Transport Slice Filter Criteria 1467 5G is a use case of the Transport Slice and 5G End-to-end Network 1468 Slice Mapping from the view of Transport Network 1469 [I-D.geng-teas-network-slice-mapping] 1471 defines two types of TS slice interconnection and differentiation 1472 methods: by physical interface or by TNSII (Transport Network Slice 1473 Interworking Identifier). TNSII is a field in the packet header when 1474 different 5G wireless network slices are transported through a single 1475 physical interfaces of the Transport Network. In the 5G scenario, 1476 "ts-filter-criteria" refers to TNSII. 1478 +-------------------------------------------------------+ 1479 | Higher Layer System | 1480 +-------------------------------------------------------+ 1481 | | | 1482 | Transport Slice Model | 1483 +----------+ | +-----------+ 1484 | | | | | 1485 |RAN Slice | +----------------+ |Core Slice | 1486 |controller | | TS controller | | controller| 1487 +----+-----+ +-------+--------+ +-----+-----+ 1488 | | | 1489 | | | 1490 +---+--+ +------------+----------------+ ++-----+ 1491 | | | | | | 1492 | | | | | | 1493 |+----+| | | | | 1494 || ||TS1-EP1| TS1 | |+----+| 1495 ||gNB1|+-------+-----+-----------------------+-------+|UPF1|| 1496 || |+********** / | |+----+| 1497 |+----+|TS2-EP1| */ |TS1-EP3| | 1498 | | /* | | | 1499 |+----+|TS1-EP2| / * | | | 1500 || |+-------- * TS2 | |+----+| 1501 ||gNB2|+*********************************************+|UPF2|| 1502 || ||TS2-EP2| | |+----+| 1503 |+----+| | |TS2-EP3| | 1504 | | | | | | 1505 | | | | | | 1506 +------+ +-----------------------------+ +------+ 1508 As shown in the figure, gNodeB 1 and gNodeB 2 use IP gNB1 and IP gNB2 1509 to communicate with the transport network, respectively. In 1510 addition, the traffic of TS1 and TS2 on gNodeB 1 and gNodeB 2 is 1511 transmitted through the same access links to the transport network. 1512 The transport network need to to distinguish different Transport 1513 Slice traffic of same gNB. Therefore, in addition to using "node-id" 1514 and "port-id" to identify a TS-EP, other information is needed along 1515 with these parameters to uniquely distinguish a TS-EPs. For example, 1516 VLAN IDs in the user traffic can be used to distinguish the TS-EP1 or 1517 TS2-EP1 or other TS-EPs of gNBs and UPFs. 1519 Authors' Addresses 1520 Bo Wu 1521 Huawei Technologies 1522 101 Software Avenue, Yuhua District 1523 Nanjing, Jiangsu 210012 1524 China 1526 Email: lana.wubo@huawei.com 1528 Dhruv Dhody 1529 Huawei Technologies 1530 Divyashree Techno Park 1531 Bangalore, Karnataka 560066 1532 India 1534 Email: dhruv.ietf@gmail.com 1536 Liuyan Han 1537 China Mobile 1539 Email: hanliuyan@chinamobile.com 1541 Reza Rokui 1542 Nokia Canada 1544 Email: reza.rokui@nokia.com