idnits 2.17.1 draft-chin-nfvrg-cloud-5g-core-structure-yang-00.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 33 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 533 has weird spacing: '...on type e.g.,...' == The document doesn't use any RFC 2119 keywords, yet has text resembling RFC 2119 boilerplate text. -- The document date (December 28, 2017) is 2310 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC6241' is mentioned on line 91, but not defined == Missing Reference: 'RFC7895' is mentioned on line 302, but not defined ** Obsolete undefined reference: RFC 7895 (Obsoleted by RFC 8525) == Missing Reference: 'RFC7223' is mentioned on line 304, but not defined ** Obsolete undefined reference: RFC 7223 (Obsoleted by RFC 8343) == Unused Reference: 'I-D.ietf-rtgwg-device-model' is defined on line 602, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-rtgwg-lne-model' is defined on line 607, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-rtgwg-ni-model' is defined on line 611, but no explicit reference was found in the text == Unused Reference: 'RFC6021' is defined on line 620, but no explicit reference was found in the text == Unused Reference: 'RFC7317' is defined on line 624, but no explicit reference was found in the text ** Downref: Normative reference to an Informational draft: draft-ietf-rtgwg-device-model (ref. 'I-D.ietf-rtgwg-device-model') == Outdated reference: A later version (-10) exists of draft-ietf-rtgwg-lne-model-01 == Outdated reference: A later version (-12) exists of draft-ietf-rtgwg-ni-model-01 ** Obsolete normative reference: RFC 6021 (Obsoleted by RFC 6991) Summary: 5 errors (**), 0 flaws (~~), 13 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force C. Chen 2 Internet Draft Ericsson 3 Intended status: Standards Track A. Pan 4 Expires: June 2018 Ericsson 5 December 28, 2017 7 Yang Data Model for Cloud Native 5G Core structure 8 draft-chin-nfvrg-cloud-5g-core-structure-yang-00.txt 10 Abstract 12 In 5G core network, all network functions are componentized, 13 virtualized and grouped into VNF. Network management system will manage 14 the functions based on VNF. This document presents YANG model proposal 15 on overall structure of cloud native 5G core network. The structure is 16 itself represented as an example YANG model, with all of the related 17 component models logically organized in a way that is operationally 18 intuitive, but this model is not expected to be implemented. The 19 identified component modules are expected to be defined and 20 implemented. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that 29 other groups may also distribute working documents as Internet- 30 Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/ietf/1id-abstracts.txt 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html 42 This Internet-Draft will expire on February 28, 2009. 44 Copyright Notice 46 Copyright (c) 2016 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction ................................................ 2 62 1.1. Terminology ............................................ 2 63 1.2. Tree Diagrams .......................................... 3 64 1.3. Definition of terms ..................................... 4 65 2. Overview .................................................... 4 66 2.1. Background ............................................. 4 67 2.2. Management Structure .................................... 5 68 2.3. Model Proposal ......................................... 7 69 3. YANG Module ................................................. 8 70 4. Security Considerations ..................................... 13 71 5. IANA Considerations ........................................ 14 72 6. Normative References........................................ 14 74 1. Introduction 76 In Cloud native 5G core network, the control and user plane 77 functionalities are separated into NFs. Some NFs can be grouped in 78 one VNF. From the NBI's view, network management system will manage 79 the network based on VNF. This document will define the YANG of 5G 80 core network management top-level structure. 82 1.1. Terminology 84 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 85 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 86 "OPTIONAL" in this document are to be interpreted as described in BCP 87 14 [RFC2119]. 89 The following terms are used within this document: 91 The following terms are defined in [RFC6241] and are not redefined 92 here: 94 o client 96 o configuration data 98 o server 100 o state data 102 The following terms are defined in [RFC6020] and are not redefined 103 here: 105 o augment 107 o data model 109 o data node 111 o presence container 113 1.2. Tree Diagrams 115 A simplified graphical representation of the data model is used in 116 this document. The meaning of the symbols in these diagrams is as 117 follows: 119 o Brackets "[" and "]" enclose list keys. 121 o Abbreviations before data node names: "rw" means configuration 122 (read-write), and "ro" means state data (read-only). 124 o Symbols after data node names: "?" means an optional node, "!" 125 means a presence container, and "*" denotes a list and leaf-list. 127 o Parentheses enclose choice and case nodes, and case nodes are also 128 marked with a colon (":"). 130 o Ellipsis ("...") stands for contents of subtrees that are not 131 shown. 133 1.3. Definition of terms 135 CP: Control Plane 137 UP: User Plane 139 NSSF: Network Slice Selection Function 141 AUSF: Authentication Server Function 143 AMF: Core Access and Mobility Management Function 145 DN: Data network 147 SDSF: Structured Data Storage network function 149 UDSF: Unstructured Data Storage network function 151 NEF: Network Exposure Function 153 NRF: NF Repository Function 155 PCF: Policy Control function 157 SMF: Session Management Function 159 UDM: Unified Data Management 161 UPF: User plane Function 163 AF: Application Function 165 UE: User Equipment 167 (R)AN: (Radio) Access Network 169 2. Overview 171 2.1. Background 173 Currently, 3GPP defined the three key technologies on infrastructure 174 of 5G. 176 1) CUPS: CP/UP Separation 177 2) SBA: Service Based Architecture 179 3) Slicing 181 5G Core CP/UP functions are componentized into NFs, including 182 NSSF, NEF, NRF, PCF, UDM, AUSF, AMF, SMF and UPF. The above 183 components are required to be stateless and able to communicate 184 with network based API. Furthermore, the NFs should be virtualized 185 to be decouple to any hardware. Consequently, CP/UP function 186 components can be flexibly deployed in native cloud environment. 187 Figure 1 presents the overall 5G network view. 189 +------------------------------------------------------+ 190 | | 191 | +--------------------------------------------------+ | 192 | | | | 193 | | +------+ +------+ +------+ +------+ +------+ | | +------+ 194 | | | NSSF | | NEF | | NRF | | PCF | | UDM | | | | AF | 195 | | +---+--+ +---+--+ +---+--+ +---+--+ +---+--+ | | +---+--+ 196 | | | | | | | | | | 197 | |-----+-----+---+---------+---+-----+-----+---+----+-+-----+ 198 | | | | | | | 199 | | +----+----+ +----+----+ +---+------+ | | 200 | | | AUSF | + + AMF | | SMF | | | 201 | | +---------+ / +-----+---+ +-----+----+ | | 202 | |5G Core CP NF / | | | | 203 | +-------------------/----------+------------+------+ | 204 | / | | | 205 | / | +-----+----+ | 206 | / | | UPF +---+-+ 207 | / | +-----+----+ | | 208 | 5G Core NF / | | | | 209 +---------------/----------------+------------+--------+ | 210 / | | | 211 +---+---+ +-----+--+ | +--------+-------+ 212 | UE +--------+ (R)AN +---------+ | Data Network | 213 +-------+ +--------+ +----------------+ 215 Figure 1: 5G Network View 217 2.2. Management Structure 219 ETSI defines the NFV architectural framework as Figure 2. Network 220 management system(EMS as below) manages the network based on VNF. 221 Each VNF has an NBI to communicate with EMS. 222 +-----------------------------------------------------------+ 223 | OSS/BSS | 224 +-----------------------------+-----------------------------+ 225 | 226 +-----------------------------+-----------------------------+ 227 | VNF | 228 | +-------------+ +-------------+ +---------------+ | 229 | | EMS 1 | | EMS 2 | | EMS 3 | | 230 | +------+------+ +------+------+ +-------+-------+ | 231 | | | | | 232 | +------+------+ +------+------+ +-------+-------+ | 233 | | VNF 1 | | VNF 2 | | VNF 3 | | 234 | +------+------+ +------+------+ +-------+-------+ | 235 +----------+-----------------+------------------+-----------+ 236 | | | 237 +----------+-----------------+------------------+-----------+ 238 | VNFI | 239 | +-----------------------------------------------------+ | 240 | | +-------------+ +-------------+ +-------------+ | | 241 | | | Virtual | | Virtual | | Virtual | | | 242 | | | Compute | | Storage | | Network | | | 243 | | +-------------+ +-------------+ +-------------+ | | 244 | | Virtualization Layer | | 245 | +-------------------------+---------------------------+ | 246 | | | 247 | +-------------------------+---------------------------+ | 248 | | Hardware Resources | | 249 | | +-------------+ +-------------+ +-------------+ | | 250 | | | Compute | | Storage | | Network | | | 251 | | | Hardware | | Hardware | | Hardware | | | 252 | | +-------------+ +-------------+ +-------------+ | | 253 | +-----------------------------------------------------+ | 254 +-----------------------------------------------------------+ 255 Figure 2: NFV Architectural Framework 257 In 5G core network, NFs will be grouped into VNF as Figure 3 and 258 Figure 4. Moreover, the packaging and definition of VNF is flexible 259 1) AMF could be a VNF 260 2) AMF and SMF + SAPC could be a VNF 261 3) SMF + 3PP extended IP allocator could be a VNF 262 4) SMF + UPF could be a VNF 263 5) Any NFs could be grouped in one VNF 264 6) ... 266 NBI NBI 267 | | | | 268 ,''''''''''|'|'''''''''''''''''''''|'|'''''''''`. 270 | | | | | | 271 | ..................... ..................... | 272 | : Virtual Network : : Virtual Network : | 273 | : Function : : Function : | 274 | :+-----+-----+-----+: :+-----+-----+-----+: | 275 | :| Net | Net | Net |: :| Net | Net | Net |: | 276 | :|Func.|Func.|Func.|: :|Func.|Func.|Func.|: | 277 | :+-----+-----+-----+: :+-----+-----+-----+: | 278 | : : : : | 279 | :...................: :...................: | 280 | | 281 | 5G Core Network | 282 `''''''''''''''''''''''''''''''''''''''''''''''' 283 Figure 3: NF and VNF Relationships 285 +--------------------------------------------------------------+ 286 |+----------+ +---+ +----------+ +------++------++-----------+ | 287 || UPD | |AMF| | SMF | | NSSF || NEF || NRF | | 288 |+----------+ +---+ +----------+ +------++------++-----------+ | 289 | | 290 | ... | 291 | | 292 | VNF | 293 +--------------------------------------------------------------+ 295 Figure 4: 5G core NF and VNF Relationships 297 2.3. Model Proposal 299 The overall structure is: 301 module: example-5g-core-network 302 +--rw modules-state [RFC7895] 303 | 304 +--rw interfaces [RFC7223] 305 +--rw hardware 306 +--rw system-management [RFC7317 or derived] 307 | 308 ... [Here, define the generic protocols for NFs] 309 | 310 +--rw nssf 311 +--rw nef 312 +--rw nrf 313 +--rw pcf 314 +--rw udm 315 +--rw ausf 316 +--rw amf 317 +--rw smf 318 +--rw upf 319 | 320 +--rw virtual-network-functions 321 +--rw virtual-network-function [name] 322 | 323 +--rw name 324 +--rw enable 325 +--rw description 326 +--rw network-functions 327 +--rw network-function [name] 328 | 329 +--rw name 330 +--rw enable 331 +--rw description 332 +--rw type 333 | +--:(upf) 334 | 335 +--rw (nf-root) 336 +--:(upf-root) 337 +--mp upf-root 339 3. YANG Module 341 file "example-5g-core-network.yang" 342 module example-5g-core-network { 344 yang-version "1.1"; 346 /*** NAMESPACE / PREFIX DEFINITION ***/ 347 namespace "urn:example:5g-core-network"; 348 prefix "core-net"; 350 /*** LINKAGE (IMPORTS / INCLUDES) ***/ 351 import ietf-yang-schema-mount { 352 prefix yangmnt; 353 reference "draft-ietf-netmod-schema-mount: YANG Schema Mount"; 354 } 356 /*** META INFORMATION ***/ 357 organization 358 "Ericsson (China) Communications Company Ltd. 359 Ericsson Tower, No. 5 Lize East Street, 360 Chaoyang District Beijing 100102, P.R. China"; 362 contact 363 "Editor: Chin Chen 364 "; 366 description 367 "This YANG module provide the example on 5G core network 368 structure."; 370 revision 2017-12-28 { 371 description 372 "Initial revision."; 373 reference 374 "RFC XXXX: A YANG Data Model for 5G Core Network 375 Structure."; 376 } 378 /*** TYPE DEFINITIONS ***/ 380 identity network-function-type { 381 description 382 "Base identity for derivation of network functions"; 383 } 385 identity nssf { 386 base network-function-type; 387 description 388 "Network Slice Selection Function"; 389 reference 390 ""; 391 } 393 identity nef { 394 base network-function-type; 395 description 396 "Network Exposure Function"; 397 reference 398 ""; 399 } 401 identity nrf { 402 base network-function-type; 403 description 404 "NF Repository Function"; 405 reference 406 ""; 408 } 410 identity pcf { 411 base network-function-type; 412 description 413 "Policy Control function"; 414 reference 415 ""; 416 } 418 identity udm { 419 base network-function-type; 420 description 421 "Unified Data Management"; 422 reference 423 ""; 424 } 426 identity ausf { 427 base network-function-type; 428 description 429 "Authentication Server Function"; 430 reference 431 ""; 432 } 434 identity amf { 435 base network-function-type; 436 description 437 "Core Access and Mobility Management Function"; 438 reference 439 ""; 440 } 442 identity smf { 443 base network-function-type; 444 description 445 "Session Management Function"; 446 reference 447 ""; 448 } 450 identity upf { 451 base network-function-type; 452 description 453 "User Plane Function"; 454 reference 455 ""; 456 } 458 /*** SCHEMA DEFINITIONS ***/ 459 container ietf-yang-library { 460 description 461 "YANG Module Library as defined in 462 draft-ietf-netconf-yang-library"; 463 } 465 container interfaces { 466 description 467 "Interface list as defined by RFC7223/RFC7224"; 468 } 470 container hardware { 471 description 472 "Hardware / vendor-specific data relevant to the platform. 473 This container is an anchor point for platform-specific 474 configuration and operational state data. It may be further 475 organized into chassis, line cards, ports, etc. It is 476 expected that vendor or platform-specific augmentations 477 would be used to populate this part of the device model"; 478 } 480 container system-management { 481 description 482 "System management for physical or virtual device."; 483 } 485 container virtual-network-functions { 486 description 487 "Container for list of configured virtual network 488 functions."; 489 list virtual-network-function { 490 key "name"; 491 description 492 "Lisf for instance of virtual network function"; 494 leaf name { 495 type string; 496 description 497 "The virtual network function name."; 498 } 500 leaf enable { 501 type boolean; 502 description 503 "Enable the virtual network fucntion."; 504 } 506 leaf description { 507 type string; 508 description 509 "Describe the virtual network fucntion."; 510 } 512 container network-functions { 513 description 514 "Container for list of configured network 515 functions."; 516 list network-function { 517 key "name"; 518 description 519 "Lisf for instance of network function"; 521 leaf name { 522 type string; 523 description 524 "The network function name."; 525 } 527 leaf type { 528 type identityref { 529 base network-function-type; 530 } 531 mandatory true; 532 description 533 "The network function type e.g., UPF, SMF, 534 AMF etc."; 535 } 537 leaf enable { 538 type boolean; 539 description 540 "Enable the network fucntion."; 541 } 543 leaf description { 544 type string; 545 description 546 "Describe the network fucntion."; 547 } 548 choice root { 549 description 550 "Well known mount points."; 551 case upf-root { 552 description 553 "Container for mount point."; 554 yangmnt:mount-point "upf-root" { 555 description 556 "Root models that support network function 557 UPF."; 558 } 559 } 560 case amf-root { 561 description 562 "Container for mount point."; 563 yangmnt:mount-point "amf-root" { 564 description 565 "Root models that support network function 566 AMF."; 567 } 568 } 569 case smf-root { 570 description 571 "Container for mount point."; 572 yangmnt:mount-point "smf-root" { 573 description 574 "Root models that support network function 575 SMF."; 576 } 577 } 578 } 579 } 580 } 581 } 582 } 583 } 584 586 4. Security Considerations 588 The data model defined does not create any security implications. 590 5. IANA Considerations 592 This draft does not request any IANA action. 594 6. Normative References 596 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 597 Requirement Levels", BCP 14, RFC 2119, March 1997. 599 [Network Functions Virtualisation White Paper] ETSI. link: 600 http://portal.etsi.org/NFV/NFV_White_Paper2.pdf 602 [I-D.ietf-rtgwg-device-model] A. Lindem, Ed., L. Berger, Ed., D. 603 Bogdanovic, C. Hopps, "Network Device YANG Logical 604 Organization", draft-ietf-rtgwg-device-model-02 (work in 605 progress), March 2017. 607 [I-D.ietf-rtgwg-lne-model] Berger, L., Hopps, C., Lindem, A., and D. 608 Bogdanovic, "YANG Logical Network Elements", draft-ietf- 609 rtgwg-lne-model-01 (work in progress), October 2016. 611 [I-D.ietf-rtgwg-ni-model] Berger, L., Hopps, C., Lindem, A., and D. 612 Bogdanovic, "YANG Network Instances", draft-ietf-rtgwg-ni- 613 model-01 (work in progress), October 2016. 615 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 616 the Network Configuration Protocol (NETCONF)", RFC 6020, 617 DOI 10.17487/RFC6020, October 2010, . 620 [RFC6021] Schoenwaelder, J., Ed., "Common YANG Data Types", RFC 6021, 621 DOI 10.17487/RFC6021, October 2010, . 624 [RFC7317] Bierman, A. and M. Bjorklund, "A YANG Data Model for 625 System Management", RFC 7317, DOI 10.17487/RFC7317, August 626 2014, . 628 Authors' Addresses 629 Chin Chen 630 Ericsson (China) Communications Company Ltd. 631 Ericsson Tower, No. 5 Lize East Street, 632 Chaoyang District Beijing 100102, P.R. China 634 Email: chin.chen@ericsson.com 636 Adrian Pan 637 Ericsson (China) Communications Company Ltd. 638 Ericsson Tower, No. 5 Lize East Street, 639 Chaoyang District Beijing 100102, P.R. China 641 Email: adrian.pan@ericsson.com