idnits 2.17.1 draft-cuspdt-rtgwg-cu-separation-infor-model-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 22, 2018) is 2013 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.cuspdt-rtgwg-cu-separation-bng-architecture' is defined on line 848, but no explicit reference was found in the text == Unused Reference: 'I-D.cuspdt-rtgwg-cu-separation-bng-deployment' is defined on line 854, but no explicit reference was found in the text == Unused Reference: 'RFC8174' is defined on line 879, but no explicit reference was found in the text == Outdated reference: A later version (-04) exists of draft-cuspdt-rtgwg-cu-separation-bng-architecture-01 == Outdated reference: A later version (-02) exists of draft-cuspdt-rtgwg-cu-separation-bng-deployment-00 Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 rtgwg S. Hu 3 Internet-Draft China Mobile 4 Intended status: Informational Donald. Eastlake 5 Expires: April 25, 2019 M. Wang, Ed. 6 Huawei 7 V. Lopez 8 Telefonica 9 F. Qin 10 Z. Li 11 China Mobile 12 T. Chua 13 Singapore Telecommunications Limited 14 October 22, 2018 16 Information Model of Control-Plane and User-Plane Separation BNG 17 draft-cuspdt-rtgwg-cu-separation-infor-model-03 19 Abstract 21 To improve network resource utilization and reduce operational 22 expense, the Control-Plane and User-Plane separation concept is 23 defined in Broadband Forum TR-384. This document describes the 24 information model for the interface between the Control-Plane (CP) 25 and the User-Plane (UP) in the CP/UP separation BNG. This 26 information model may involve both the control channel interface and 27 the configuration channel interface. The interface for the control 28 channel allows the Control-Plane to send flow tables to the User- 29 Plane, such as user's information table, user's interface table, and 30 user's QoS table. And it also allows the User-Plane to report 31 resource and statistics information to the Control-Plane. The 32 interface for the configuration channel is in charge of the protocol 33 version negotiation between the Control-Plane and User-Plane, the 34 configuration for devices of the Control-Plane and User-Plane, and 35 the reports of User-Plane's capabilities, etc. The information model 36 defined in this document supports defining a standardized data model. 37 Such a data model can be used to specify an interface to the CU 38 separation BNG. 40 Status of This Memo 42 This Internet-Draft is submitted in full conformance with the 43 provisions of BCP 78 and BCP 79. 45 Internet-Drafts are working documents of the Internet Engineering 46 Task Force (IETF). Note that other groups may also distribute 47 working documents as Internet-Drafts. The list of current Internet- 48 Drafts is at https://datatracker.ietf.org/drafts/current/. 50 Internet-Drafts are draft documents valid for a maximum of six months 51 and may be updated, replaced, or obsoleted by other documents at any 52 time. It is inappropriate to use Internet-Drafts as reference 53 material or to cite them other than as "work in progress." 55 This Internet-Draft will expire on April 25, 2019. 57 Copyright Notice 59 Copyright (c) 2018 IETF Trust and the persons identified as the 60 document authors. All rights reserved. 62 This document is subject to BCP 78 and the IETF Trust's Legal 63 Provisions Relating to IETF Documents 64 (https://trustee.ietf.org/license-info) in effect on the date of 65 publication of this document. Please review these documents 66 carefully, as they describe your rights and restrictions with respect 67 to this document. Code Components extracted from this document must 68 include Simplified BSD License text as described in Section 4.e of 69 the Trust Legal Provisions and are provided without warranty as 70 described in the Simplified BSD License. 72 Table of Contents 74 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 75 2. Concept and Terminology . . . . . . . . . . . . . . . . . . . 3 76 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 77 3. Control Plane and User Plane Separation BNG Information Model 78 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 79 3.1. Service Data Model Usage . . . . . . . . . . . . . . . . 6 80 4. Information Model . . . . . . . . . . . . . . . . . . . . . . 8 81 4.1. Information Model for Control-Plane . . . . . . . . . . . 9 82 4.1.1. User-Related Information . . . . . . . . . . . . . . 11 83 4.1.1.1. User Basic Information Model . . . . . . . . . . 11 84 4.1.1.2. IPv4 Information Model . . . . . . . . . . . . . 12 85 4.1.1.3. IPv6 Information Model . . . . . . . . . . . . . 13 86 4.1.1.4. QoS Information Model . . . . . . . . . . . . . . 14 87 4.1.2. Interface Related Information . . . . . . . . . . . . 15 88 4.1.2.1. Interface Information Model . . . . . . . . . . . 15 89 4.1.3. Device Related Information . . . . . . . . . . . . . 16 90 4.1.3.1. Address field distribute Table . . . . . . . . . 17 91 4.2. Information Model for User Plane . . . . . . . . . . . . 17 92 4.2.1. Port Resources of UP . . . . . . . . . . . . . . . . 18 93 4.2.2. Traffic Statistics Infor . . . . . . . . . . . . . . 19 94 5. Security Considerations . . . . . . . . . . . . . . . . . . . 20 95 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 96 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 97 7.1. Normative References . . . . . . . . . . . . . . . . . . 20 98 7.2. Informative References . . . . . . . . . . . . . . . . . 21 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 101 1. Introduction 103 To improve network resource utilization and reduce operational 104 expense, the Control-Plane and User-Plane separation concept is 105 defined in Broadband Forum [TR-384]. The motivation for and 106 architecture of the Control-Plane and User-Plane separation BNG is 107 discussed in [I.D.cuspdt-rtgwg-cu-separation-bng-architecture]. 109 This document describes an information model for the interface 110 between the Control-Plane (CP) and the User-Plane (UP) separation in 111 the CP / UP Separated BNG. This information model may involve both 112 the control channel interface and the configuration channel 113 interface. The interface for control channel allows the Control- 114 Plane to send several flow tables to the User-Plane, such as user's 115 information table, user's interface table, and user's QoS table, etc. 116 And it also allows the User-Plane to report the resources and 117 statistics information to the Control-Plane. The interface for 118 configuration channel is in charge of the protocol version 119 negotiation of protocols between the Control-Plane and User-Plane, 120 the configuration for the devices of Control-Plane and User-Plane, 121 and the report of User-Plane's capabilities, etc. The information 122 model defined in this document enables supports defining a 123 standardized data model. Such a data model can be used to define an 124 interface to the CU separation BNG. 126 2. Concept and Terminology 128 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 129 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 130 document are to be interpreted as described in [RFC2119]. 132 2.1. Terminology 134 BNG: Broadband Network Gateway. A broadband remote access server 135 (BRAS, B-RAS or BBRAS) routes traffic to and from broadband remote 136 access devices such as digital subscriber line access multiplexers 137 (DSLAM) on an Internet service provider's (ISP) network. BRAS can 138 also be referred to as a Broadband Network Gateway (BNG). 140 CP: Control Plane. CP is a user control management component which 141 supports the management of UP's resources such as the user entry and 142 forwarding policy 143 UP: User Plane. UP is a network edge and user policy implementation 144 component. The traditional router's Control Plane and Forwarding 145 Plane are both preserved on BNG devices in the form of a user plane. 147 3. Control Plane and User Plane Separation BNG Information Model 148 Overview 150 Briefly, a CU separation BNG is made up of a centralized CP and a set 151 of UPs. The CP is a user control management component that manages 152 UP's resources such as the user entry and forwarding policy, for 153 example, the access bandwidth and priority management. The UP is a 154 network edge and user policy implementation component. It can 155 support the forwarding plane functions on traditional BNG devices, 156 such as traffic forwarding, QoS, and traffic statistics collection, 157 and it can also support the control plane functions on traditional 158 BNG devices, such as routing, multicast, etc. 160 +-----+ +-----+ +-----+ +-----+ 161 |EMS | |DHCP | |AAA | |policy 162 | | |server |server |server 163 +----|+ +---|-+ +--|--+ +--|--+ 164 | | | | 165 | | | | 166 | | | | 167 | | | | 168 +----|---------|---------|---------|----+ 169 | +--|----+ +--|--+ +---|--+ +----|--+ | 170 | |address| | sub | | AAA | |service| | 171 | |mgt | | Mgt | | | |control| | 172 | +-------+ +-----+ +------+ +-------+ | 173 | | Control Plane 174 | +--------------------------------+ | 175 | | User plane management | | 176 | | | | 177 | +-------------|------------------+ | 178 +-----------------|---------------------+ 179 | 180 | 181 | 182 |----------------|-----------------| 183 | | | 184 | | | 185 +--------|-----+ +------|-------+ +------|------+ 186 | +---------+ | | +---------+ | |+-----|----+ | 187 | | routing | | | | routing | | || routing | | 188 | | control | | | | control | | || control | | 189 | +---------+ | | +---------+ | |+----------+ | 190 | +----------+ | | +----------+ | |+----------+ | User Plane 191 | |forwarding| | | |forwarding| | ||forwarding| | 192 | |plane | | | |plane | | ||plane | | 193 | +----------+ | | +----------+ | |+----------+ | 194 +--------------+ +--------------+ +-------------+ 195 Figure 1. CU Separated BNG 197 The CU separated BNG is shown in Figure 1. The BNG Control Plane 198 could be virtualized and centralized, which provides significant 199 benefits such as centralized session management, flexible address 200 allocation, high scalability for subscriber management capacity, and 201 cost-efficient redundancy, etc. The functional components inside the 202 BNG Service Control Plane can be implemented as Virtual Network 203 Functions (VNFs) and hosted in a Network Function Virtualization 204 Infrastructure (NFVI). 206 The User Plane Management module in the BNG control plane centrally 207 manages the distributed BNG User Planes (e.g. load balancing), as 208 well as the setup, deletion, maintenance of channels between Control 209 Planes and User Planes. Other modules in the BNG control plane, such 210 as address management, AAA, and etc., are responsible for the 211 connection with outside subsystems in order to provide the service. 212 The routing control and forwarding Plane in the BNG User Plane 213 (local) could be distributed across the infrastructure. 215 3.1. Service Data Model Usage 217 The idea of this information model is to propose a set of generic and 218 abstract information models to be used in both Control Plane and User 219 Planes. A typical scenario would be that this model can be used as a 220 compendium to realize the communication between the Control Plane and 221 User Planes of the CU separation BNG. 223 ----------------- 224 //// \\\\ 225 //// \\\\ 226 // Cloud \\ 227 | | 228 | | 229 | | 230 | | 231 | +-----------------+ | 232 | | Control Plane | | 233 \\ | | // 234 \\\\ +---------+-------+ //// 235 \\\\ | //// 236 ------------------ 237 | 238 +------------------+-----------+-----+ 239 | | | | 240 User's information IP address QoS: ....... 241 May Including: ...... CIR; | 242 User ID; | PIR; | 243 User MAC; | CBS; | 244 Access method(PPPoE, | PBS; | 245 IPoE, etc) ...... | ...... | 246 | | | | 247 +------------------V-----------+-----+ 248 | 249 +----+ 250 | ------- 251 | /// \\\ 252 +------+ +-------v---------+ +--------+ | | 253 | OTL | | User Plane | | Core | | Internet | 254 | +-------+ +-------+ Routing|-----| | 255 +------+ +-----------------+ +--------+ \\\ /// 256 ------- 257 Figure 2. CU Separation BNG 259 As shown in Figure 2, when users access the BNG network, the control 260 plane solicits these users' information (such as user's ID, user's 261 MAC, user's access methods, for example via PPPoE/IPoE), associates 262 them with available bandwidth which is reported by User planes, and 263 based on the service's requirements generates a set of tables, which 264 may include user's information, user's IP address, and QoS. Then the 265 control plane can transmit these tables to the User planes. User 266 planes receive these tables, parse them, matches these rules, and 267 then performs corresponding actions. 269 4. Information Model 271 This section specifies the information model in Routing Backus-Naur 272 Form [RFC5511]. This grammar intends to help readers better 273 understand the English text description in order to derive a data 274 model. However it may not provide all the details provided by the 275 English text. When there is a lack of clarity, the English text will 276 take precedence. 278 This section describes the information model that represents the 279 interface of the CU separation BNG that is language and protocol 280 neutral. 282 The following Routing BNF grammar describes the Overview of 283 Information Model for CU separation BNG. 285 ::= 286 288 ::= 289 290 292 ::= 293 []|[] 294 [] 296 :: = 297 [][] 298 [][] 299 301 ::= 302 303 305 ::=( 306 )|() 307 309 ::= 310 () 311 [] 313 ::= 315 ::= 316 318 ::= 319 320 322 ::= 324 ::= 325 326 328 ::= 329 331 ::= 332 333 334 335 ::= 336 337 338 339 341 4.1. Information Model for Control-Plane 343 This section describes information model for the Control-Plane (CP). 344 As mentioned in Section 3, the Control Plane is a user control 345 management component which manages the user's information, User- 346 Plane's resources and forwarding policy, etc. The control plane can 347 generate several tables which contain a set of rules based on the 348 resources and specific requirements of user's service. After that, 349 the control plane sends the tables to User Planes, and User planes 350 receive the tables, parse them, match the rules, and then perform 351 corresponding actions. 353 The Routing Backus-Naur Form grammar below specifies the Information 354 model for Control-Plane: 356 ::= 357 358 360 ::= 361 []|[] 362 [] 364 :: = 365 [][] 366 [][] 367 369 ::= 370 371 373 ::=( 374 )|() 375 377 ::= 378 () 379 [] 381 ::= 383 ::= 384 386 ::= 387 388 390 ::= 392 ::= 393 394 396 user-related-infor-model: presents the attributes that can describe 397 the user's profile, such as user's basic information, qos, and IP 398 address. 400 interface-related-infor-model: presents the attributes that relate to 401 some physical/virtual interface. This model can be used to indicate 402 which kinds of service can be supported by interfaces. 404 device-related-infor-model: presents the attributes which relate to a 405 specific device. For example the control plane can manage and 406 distribute the users, which belong to same subnet, to some specific 407 devices. And the user plane's devices provide corresponding service 408 for these users. 410 4.1.1. User-Related Information 412 The user related information is a collection of attributes bound to 413 specific users. For example, the control plane can use a unified ID 414 to distinguish different users and distribute the IP address and QoS 415 rules to a specific user. In this section, the user related 416 information models are presented. The user related information 417 models include the user information model, IPv4/IPv6 information 418 model, QoS information model, etc. 420 The Routing Backus-Naur Form grammar below specifies the user related 421 information model: 423 ::= 424 []|[] 425 [] 427 :: = 428 [][] 429 [][] 430 432 ::= 433 434 436 ::=( 437 )|() 438 440 ::= 441 () 442 [] 444 4.1.1.1. User Basic Information Model 446 The User Basic Information model contains a set of attributes to 447 describe the basic information of a specific user, such as the user's 448 MAC address, access type (via PPPoE, IPoE, etc), inner VLAN ID, outer 449 VLAN ID, etc. 451 The Routing Backus-Naur Form grammar below specifies the user basic 452 information model: 454 :: = 455 [][] 456 [][] 457 459 USER_ID (4 bytes): is the identifier for a user. This parameter is 460 unique and mandatory. It can be used to distinguish different users. 462 MAC_ADDRESS (6 bytes): is the MAC address of the user. 464 ACCESS_TYPE (2 bytes): This attribute is an optional parameter. It 465 can be used to indicate the protocol being used for the user's 466 access, such as PPPoE, IPoE, etc. 468 SESSION_ID (4 bytes): This attribute is an optional parameter. It 469 can be used as the identifier of PPPoE session. 471 INNER_VLAN-ID (2 bytes): The 12-bit identifier of user's inner VLAN 472 in network byte order. The unused high-order 4 bits MUST be sent as 473 zero and ignored on receipt. 475 OUTER_VLAN_ID (2 bytes): The 12-bit identifier of user's outer VLAN 476 in network byte order. The unused high-order 4 bits MUST be sent as 477 zero and ignored on receipt. 479 USER_INTERFACE (4 bytes): This attribute specifies the binding 480 interface of a specific user. The IfIndex of the interface MAY be 481 included. This is the 32-bit IfIndex assigned to the interface by 482 the device as specified by the Interfaces Group MIB [RFC2863]. The 483 IfIndex can be utilized within a management domain to map to an 484 actual interface, but it is also valuable in public applications 485 [RFC5837]. The IfIndex can be used as an opaque token to discern 486 which interface of the User-Plane is providing corresponding service 487 for specific user. 489 4.1.1.2. IPv4 Information Model 491 The IPv4 information model presents the user's IPv4 parameters. It 492 is an optional constructs. The Routing Backus-Naur Form grammar 493 below sepcifies the user's IPv4 information model: 495 ::= 496 497 499 USER_ID (4 bytes): is the identifier of user. This parameter is 500 unique and mandatory. This attribute is used to distinguish 501 different users. In conjunction with other IPv4 parameters it links 502 the user to the user's IPv4 information. 504 USER_IPV4 (4 bytes): This attribute specifies the user's IPv4 505 address, It is usually used in user plane discovery and ARP reply 506 message. 508 MASK_LENGTH (4 bytes): This attribute specifies the user's subnet 509 mask length which can identify a range of IP addresses that are on 510 the same network. 512 GATEWAY (4 bytes): This attribute specifies the user's gateway, and 513 is usually used in User Plane discovery and ARP reply message. 515 VRF (4 bytes): is the identifier of VRF instance. 517 4.1.1.3. IPv6 Information Model 519 The IPv6 information model presents the user's IPv6 parameters. It 520 is an optional constructs. The Routing Backus-Naur Form grammar 521 below specifies the user's IPv6 information model: 523 ::=( 524 )|() 525 527 USER_ID (4 bytes): is the identifier of user. This parameter is 528 unique and mandatory. This attribute is used to distinguish 529 different users. in conjunction with other IPv6 parameters, I tlink 530 the user to the user's IPv6 information. 532 USER_IPV6 (2 bytes): This attribute specifies the user's IPv6 533 address. It is usually used in neighbor discovery (ND discovery). 535 PREFIX_LEN (4 bytes): This attribute specifies the user's subnet 536 prefix lengths which can identify a range of IP addresses that are on 537 the same network. 539 PD_ADDRESS (4 bytes): In IPv6 networking, DHCPv6 prefix delegation is 540 used to assign a network address prefix and automate configuration 541 and provisioning of the public routable addresses for the network. 542 This attribute specifies the user's DHCPv6 prefix delegation address, 543 and is usually used in neighbor discovery (ND discovery). 545 PD_PREFIX_LEN (4 bytes): This attribute specifies the user's DHCPv6 546 delegation prefix length, and it's usually used in neighbor discovery 547 (ND discovery). 549 VRF (4 bytes): is the identifier of a VRF instance 551 4.1.1.4. QoS Information Model 553 In the CU separation BNG, the Control-Plane (CP) generates the QoS 554 table base based on the UP's bandwidth resources and the specific QoS 555 requirements ofof the user's services. This table contains a set of 556 QoS matching rules such as user's committed information rate, peak 557 information rate, committed burst size, etc. And itIs is an optional 558 constructs. The Routing Backus-Naur Form grammar below 559 illustratesspecifies the user's qos information model: 561 ::= 562 () 563 [] 565 USER_ID (4 bytes): is the identifier of user. This parameter is 566 unique and mandatory. This attribute is used to distinguish 567 different users. within conjunction with other qos parameters it 568 links the user to the user's qos information. 570 CIR (4 bytes): In a BNG network, the Committed Information Rate (CIR) 571 is the bandwidth available for a user guaranteed by an internet 572 service provider under normal conditions. This attribute is used to 573 indicate the user's committed information rate, and it usually 574 appears with other qos attributes (such as PIR, CBS, PBS, etc) to 575 give the user's QoS profile. 577 PIR (4 bytes): Peak Information Rate (PIR) is a burstable rate set on 578 routers and/or switches that allow throughput bursts. This attribute 579 is used to indicate the user's peak information rate. In conjunction 580 with with other QoS attributes (such as CIR, CBS, PBS, etc) it is 581 used to give the user's QoS profile. 583 CBS (4 bytes): The Committed Burst Size (CBS) specifies the relative 584 amount of reserved buffers for a specific ingress network's 585 forwarding class queue or egress network's forwarding class queue. 586 This attribute is used to indicate the user's committed burst size. 587 In conjunction with other qos attributes (such as CIR, PIR, PBS, etc) 588 it is used to give the user's QoS profile. 590 PBS (4 bytes): The Peak Burst Size (PBS) specifies the maximum size 591 of the first token bucket. This attribute is used to indicate the 592 user's peak burst size. In conjunction with other qos attributes 593 (such as CIR, PIR, CBS, etc) it is used to give the user's QoS 594 profile. 596 QOS_PROFILE (4 bytes): This attribute specifies the standard profile 597 provided by the operator. It can be used as a QoS template that is 598 defined as a list of classes of services and associated properties. 599 The properties may include: 601 o Rate-limit: used to rate-limit the class of service. The value 602 is expressed as a percentage of the global service bandwidth. 604 o latency: used to define the latency constraint of the class. 605 The latency constraint can be expressed as the lowest possible 606 latency or a latency boundary expressed in milliseconds. 608 o jitter: used to define the jitter constraint of the class. The 609 jitter constraint can be expressed as the lowest possible jitter 610 or a jitter boundary expressed in microseconds. 612 o bandwidth: used to define a guaranteed amount of bandwidth for 613 the class of service. It is expressed as a percentage. 615 4.1.2. Interface Related Information 617 This model contains the necessary information for an interface. It 618 is used to indicate which kind of service can be supported by this 619 interface. The Routing Backus-Naur Form grammar below specifies the 620 interface related information model: 622 ::= 624 ::= 625 627 ::= 628 629 631 4.1.2.1. Interface Information Model 633 The interface model mentioned here is a logical construct that 634 identifies a specific process or a type of network service. In CU 635 separation BNG network, the Control-Plane (CP) generates the 636 Interface-Infor table based on the available resources, which are 637 received from the User-Plane (UP), and the specific requirements of 638 user's services. 640 The Routing Backus-Naur Form grammar below specifies the interface 641 information model: 643 ::= 644 646 ::= 647 648 650 IFINDEX (4 bytes): The IfIndex is the 32-bit index assigned to the 651 interface by the device as specified by the Interfaces Group MIB 652 [RFC2863]. The IfIndex can be utilized within a management domain to 653 map to an actual interface, but it is also valuable in public 654 applications. The IfIndex can be used as an opaque token to discern 655 which interface of the User-Plane is providing the corresponding 656 service for specific user. 658 BAS_ENABLE (2 bytes): This is a flag, and if it is TRUE, the BRAS is 659 enabled on this interface. 661 PPP_Only (2 bytes): This is a flag, and if it is TRUE, the interface 662 only supports PPP user. 664 IPV4_TRIG (2 bytes): This is a flag, and if it is TRUE, the interface 665 supports the user being triggered to connect to the internet by using 666 an IPv4 message. 668 IPV6_TRIG (2 bytes): This is a flag, and if it is TRUE, the interface 669 supports that the user being triggered to connect to the internet by 670 using an IPv6 message. 672 ND-TRIG (2 bytes): This is a flag, and if it is TRUE, the interface 673 supports the user being triggered to connect to the internet by using 674 a neighbor discovery message. 676 ARP_PROXY (2 bytes): This is a flag, and if it is TRUE, ARP PROXY is 677 enabled on this interface. 679 4.1.3. Device Related Information 681 The device related information model presents the attributes which 682 relate to a specific device. For example the control plane can 683 manage and distribute the users, who belong to the same subnet, to 684 some specific devices. And then the user plane's devices can provide 685 the corresponding service for these users. The Routing Backus-Naur 686 Form grammar below specifies the device related information model: 688 ::= 690 ::= 691 692 694 4.1.3.1. Address field distribute Table 696 In the CU separation BNG information model, the Control-Plane (CP) 697 generates and sends this Address field distribute table to UP. Based 698 on this table, the user-plane's devices can be divided into several 699 blocks, and each block is in charge of working for users with the 700 same subnet. The Routing Backus-Naur Form grammar below illustrates 701 the address field sepcifies information model: 703 ::= 704 705 707 4.2. Information Model for User Plane 709 This section describes the information model for the interface of to 710 the User Plane (UP). As mentioned in section Section 3, the UP is a 711 network edge and user policy implementation component. It supports 712 the following: Forwarding plane functions on traditional BNG devices, 713 including traffic forwarding, QoS, and traffic statistics collection 714 and Control plane functions on traditional BNG devices, including 715 routing, multicast, and MPLS. 717 In CU separation BNG information model, the CP generates tables and 718 provides the entries. The UP plays two roles: 720 1. It receives these tables, parses them, then performs 721 corresponding actions. 723 2. It also generates several tables to report the available 724 resources (such as usable interfaces, etc.) and statistical 725 information to CP. 727 The Routing Backus-Naur Form grammar below specifies the User Plane 728 information model: 730 ::= 731 733 port-resource-information>::= 734 735 736 737 ::= 738 739 740 741 743 4.2.1. Port Resources of UP 745 The User Plane can generate the network resource table, which 746 contains a bunch of attributes to present the available network 747 resources, for example the usable interfaces. 749 The Figure Routing BNF grammar below illustratesspecifies the Port 750 Resources Information Table of User-Plane: 752 :: 753 754 755 757 IFINDEX (4 bytes): IfIndex is the 32-bit index assigned to the 758 interface by the device as specified by the Interfaces Group MIB 759 [RFC2863]. The IfIndex can be utilized within a management domain to 760 map to an actual interface, but it is also valuable in public 761 applications. The IfIndex can be used as an opaque token to discern 762 which interface of the User-Plane is available. 764 IF_NAME (64 bytes): the textual name of the interface. The value of 765 this object should be the name of the interface as assigned by the 766 local device and should be suitable for use in commands entered at 767 the device's "console". This might be a text name, such as "le0" or 768 a simple port number, such as "1", depending on the interface naming 769 syntax of the device. If several entries in the ifTable together 770 represent a single interface as named by the device, then each will 771 have the same value of ifName. 773 IF_TYPE (4 bytes): the type of interface, such as Ethernet, GE, Eth- 774 Trunk, etc. 776 LINK_TYPE (4 bytes): This attribute specifies the type of link, such 777 as point-to-point, broadcast, multipoint, point-to-multipoint, 778 private and public (accessibility and ownership), etc. 780 MAC_ADDRESS (6 bytes): This attribute specifies the available 781 interface's MAC address. 783 IF_PHY_STATE (1 byte): The current operational state of the 784 interface. This is an enumeration type node: 786 1- Up: ready to pass packets; 788 2- Down 790 3- Testing: in some test mode; 792 4- Unknow: status cannot be determined for some reason; 794 5- Dormant; 796 6- Not present: some component is missing. 798 MTU: This attribute specifies the available interface's MTU (Maximum 799 Transmission Unit). 801 4.2.2. Traffic Statistics Infor 803 The user-plane also generates the traffic statistics table to report 804 the current traffic statistics. 806 The Figure below specifies the Traffic Statistics Infor model of 807 User-Plane: 809 ::= 810 811 812 813 815 USER_ID (4 bytes): is the identifier of user. This parameter is 816 unique and mandatory. This attribute is used to distinguish 817 different users. In conjunction with other statistics parameters 818 such as ingress packets, egress packets, etc, it is used to report 819 the user's status profile. 821 STATISTICS_TYPE (4 bytes): This attributes specifies the traffic type 822 such as IPv4, IPv6, etc. 824 INGRESS_STATIISTICS_PACKETS (8 bytes): This attribute specifies the 825 Ingress Statistics Packets of specific user. 827 INGRESS STATISTICS_BYTES (8 bytes): This attribute specifies the 828 Ingress Statistics Bytes of specific user. 830 EGRESS_STATISTICS_PACKETS (8 bytes): This attribute specifies the 831 Egress Statistics Packets of specific user. 833 EGRESS_STATISTICS_BYTES (8 bytes): This attribute specifies the 834 Egress Statistics Bytes of specific user. 836 5. Security Considerations 838 None. 840 6. IANA Considerations 842 None. 844 7. References 846 7.1. Normative References 848 [I-D.cuspdt-rtgwg-cu-separation-bng-architecture] 849 Hu, S., Qin, F., Li, Z., Chua, T., Wang, Z., and J. Song, 850 "Architecture for Control Plane and User Plane Separated 851 BNG", draft-cuspdt-rtgwg-cu-separation-bng-architecture-01 852 (work in progress), July 2018. 854 [I-D.cuspdt-rtgwg-cu-separation-bng-deployment] 855 Gu, R., Hu, S., and Z. Wang, "Deployment Model of Control 856 Plane and User Plane Separation BNG", draft-cuspdt-rtgwg- 857 cu-separation-bng-deployment-00 (work in progress), 858 October 2017. 860 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 861 Requirement Levels", BCP 14, RFC 2119, 862 DOI 10.17487/RFC2119, March 1997, 863 . 865 [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group 866 MIB", RFC 2863, DOI 10.17487/RFC2863, June 2000, 867 . 869 [RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax 870 Used to Form Encoding Rules in Various Routing Protocol 871 Specifications", RFC 5511, DOI 10.17487/RFC5511, April 872 2009, . 874 [RFC5837] Atlas, A., Ed., Bonica, R., Ed., Pignataro, C., Ed., Shen, 875 N., and JR. Rivers, "Extending ICMP for Interface and 876 Next-Hop Identification", RFC 5837, DOI 10.17487/RFC5837, 877 April 2010, . 879 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 880 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 881 May 2017, . 883 7.2. Informative References 885 [TR-384] Broadband Forum, ""Cloud Central Office Reference 886 Architectural Framework",", BBF TR-384, January. 2018. 888 Authors' Addresses 890 Shujun Hu 891 China Mobile 892 32 Xuanwumen West Ave, Xicheng District 893 Beijing, Beijing 100053 894 China 896 Email: hushujun@chinamobile.com 898 Donald Eastlake, 3rd 899 Huawei 900 1424 Pro Shop Court 901 Davenport, FL 33896 902 USA 904 Email: d3e3e3@gmail.com 906 Michael Wang (editor) 907 Huawei 908 101 Software Avenue, Yuhua District 909 Nanjing, Jiangsu 210012 910 China 912 Email: wangzitao@huawei.com 913 Victor Lopez 914 Telefonica 915 Sur 3 building, 3rd floor, Ronda de la Comunicacion s/n 916 Madrid 28050 917 Spain 919 Email: victor.lopezalvarez@telefonica.com 921 Fengwei Qin 922 China Mobile 923 32 Xuanwumen West Ave, Xicheng District 924 Beijing, Beijing 100053 925 China 927 Email: qinfengwei@chinamobile.com 929 Zhenqiang Li 930 China Mobile 931 32 Xuanwumen West Ave, Xicheng District 932 Beijing, Beijing 100053 933 China 935 Email: lizhenqiang@chinamobile.com 937 Tee Mong Chua 938 Singapore Telecommunications Limited 939 31 Exeter Road, #05-04 Comcentre Podium Block 940 Singapore City 239732 941 Singapore 943 Email: teemong@singtel.com