| rtgwg | S. Hu |
| Internet-Draft | China Mobile |
| Intended status: Informational | Donald. Eastlake |
| Expires: April 25, 2019 | M. Wang, Ed. |
| Huawei | |
| V. Lopez | |
| Telefonica | |
| F. Qin | |
| Z. Li | |
| China Mobile | |
| T. Chua | |
| Singapore Telecommunications Limited | |
| October 22, 2018 |
Information Model of Control-Plane and User-Plane Separation BNG
draft-cuspdt-rtgwg-cu-separation-infor-model-03
To improve network resource utilization and reduce operational expense, the Control-Plane and User-Plane separation concept is defined in Broadband Forum TR-384. This document describes the information model for the interface between the Control-Plane (CP) and the User-Plane (UP) in the CP/UP separation BNG. This information model may involve both the control channel interface and the configuration channel interface. The interface for the control channel allows the Control-Plane to send flow tables to the User-Plane, such as user's information table, user's interface table, and user's QoS table. And it also allows the User-Plane to report resource and statistics information to the Control-Plane. The interface for the configuration channel is in charge of the protocol version negotiation between the Control-Plane and User-Plane, the configuration for devices of the Control-Plane and User-Plane, and the reports of User-Plane's capabilities, etc. The information model defined in this document supports defining a standardized data model. Such a data model can be used to specify an interface to the CU separation BNG.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 25, 2019.
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
To improve network resource utilization and reduce operational expense, the Control-Plane and User-Plane separation concept is defined in Broadband Forum [TR-384]. The motivation for and architecture of the Control-Plane and User-Plane separation BNG is discussed in [I.D.cuspdt-rtgwg-cu-separation-bng-architecture].
This document describes an information model for the interface between the Control-Plane (CP) and the User-Plane (UP) separation in the CP / UP Separated BNG. This information model may involve both the control channel interface and the configuration channel interface. The interface for control channel allows the Control-Plane to send several flow tables to the User-Plane, such as user's information table, user's interface table, and user's QoS table, etc. And it also allows the User-Plane to report the resources and statistics information to the Control-Plane. The interface for configuration channel is in charge of the protocol version negotiation of protocols between the Control-Plane and User-Plane, the configuration for the devices of Control-Plane and User-Plane, and the report of User-Plane's capabilities, etc. The information model defined in this document enables supports defining a standardized data model. Such a data model can be used to define an interface to the CU separation BNG.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
BNG: Broadband Network Gateway. A broadband remote access server (BRAS, B-RAS or BBRAS) routes traffic to and from broadband remote access devices such as digital subscriber line access multiplexers (DSLAM) on an Internet service provider's (ISP) network. BRAS can also be referred to as a Broadband Network Gateway (BNG).
CP: Control Plane. CP is a user control management component which supports the management of UP’s resources such as the user entry and forwarding policy
UP: User Plane. UP is a network edge and user policy implementation component. The traditional router's Control Plane and Forwarding Plane are both preserved on BNG devices in the form of a user plane.
Briefly, a CU separation BNG is made up of a centralized CP and a set of UPs. The CP is a user control management component that manages UP's resources such as the user entry and forwarding policy, for example, the access bandwidth and priority management. The UP is a network edge and user policy implementation component. It can support the forwarding plane functions on traditional BNG devices, such as traffic forwarding, QoS, and traffic statistics collection, and it can also support the control plane functions on traditional BNG devices, such as routing, multicast, etc.
+-----+ +-----+ +-----+ +-----+
|EMS | |DHCP | |AAA | |policy
| | |server |server |server
+----|+ +---|-+ +--|--+ +--|--+
| | | |
| | | |
| | | |
| | | |
+----|---------|---------|---------|----+
| +--|----+ +--|--+ +---|--+ +----|--+ |
| |address| | sub | | AAA | |service| |
| |mgt | | Mgt | | | |control| |
| +-------+ +-----+ +------+ +-------+ |
| | Control Plane
| +--------------------------------+ |
| | User plane management | |
| | | |
| +-------------|------------------+ |
+-----------------|---------------------+
|
|
|
|----------------|-----------------|
| | |
| | |
+--------|-----+ +------|-------+ +------|------+
| +---------+ | | +---------+ | |+-----|----+ |
| | routing | | | | routing | | || routing | |
| | control | | | | control | | || control | |
| +---------+ | | +---------+ | |+----------+ |
| +----------+ | | +----------+ | |+----------+ | User Plane
| |forwarding| | | |forwarding| | ||forwarding| |
| |plane | | | |plane | | ||plane | |
| +----------+ | | +----------+ | |+----------+ |
+--------------+ +--------------+ +-------------+
Figure 1. CU Separated BNG
The CU separated BNG is shown in Figure 1. The BNG Control Plane could be virtualized and centralized, which provides significant benefits such as centralized session management, flexible address allocation, high scalability for subscriber management capacity, and cost-efficient redundancy, etc. The functional components inside the BNG Service Control Plane can be implemented as Virtual Network Functions (VNFs) and hosted in a Network Function Virtualization Infrastructure (NFVI).
The User Plane Management module in the BNG control plane centrally manages the distributed BNG User Planes (e.g. load balancing), as well as the setup, deletion, maintenance of channels between Control Planes and User Planes. Other modules in the BNG control plane, such as address management, AAA, and etc., are responsible for the connection with outside subsystems in order to provide the service. The routing control and forwarding Plane in the BNG User Plane (local) could be distributed across the infrastructure.
The idea of this information model is to propose a set of generic and abstract information models to be used in both Control Plane and User Planes. A typical scenario would be that this model can be used as a compendium to realize the communication between the Control Plane and User Planes of the CU separation BNG.
-----------------
//// \\\\
//// \\\\
// Cloud \\
| |
| |
| |
| |
| +-----------------+ |
| | Control Plane | |
\\ | | //
\\\\ +---------+-------+ ////
\\\\ | ////
------------------
|
+------------------+-----------+-----+
| | | |
User's information IP address QoS: .......
May Including: ...... CIR; |
User ID; | PIR; |
User MAC; | CBS; |
Access method(PPPoE, | PBS; |
IPoE, etc) ...... | ...... |
| | | |
+------------------V-----------+-----+
|
+----+
| -------
| /// \\\
+------+ +-------v---------+ +--------+ | |
| OTL | | User Plane | | Core | | Internet |
| +-------+ +-------+ Routing|-----| |
+------+ +-----------------+ +--------+ \\\ ///
-------
Figure 2. CU Separation BNG
As shown in Figure 2, when users access the BNG network, the control plane solicits these users' information (such as user's ID, user's MAC, user's access methods, for example via PPPoE/IPoE), associates them with available bandwidth which is reported by User planes, and based on the service's requirements generates a set of tables, which may include user's information, user's IP address, and QoS. Then the control plane can transmit these tables to the User planes. User planes receive these tables, parse them, matches these rules, and then performs corresponding actions.
This section specifies the information model in Routing Backus-Naur Form [RFC5511]. This grammar intends to help readers better understand the English text description in order to derive a data model. However it may not provide all the details provided by the English text. When there is a lack of clarity, the English text will take precedence.
This section describes the information model that represents the interface of the CU separation BNG that is language and protocol neutral.
The following Routing BNF grammar describes the Overview of Information Model for CU separation BNG.
<cu-separation-bng-infor-model>::=<control-plane-information-model>
<user-plane-information-model>
<control-plane-information-model>::=<user-related-infor-model>
<interface-related-infor-model>
<device-related-infor-model>
<user-related-infor-model>::= <user-basic-information>
[<ipv4-informatiom>]|[<ipv6-information>]
[<qos-information>]
<user-basic-information> :: = <USER_ID> <MAC_ADDRESS>
[<ACCESS_TYPE>][<SESSION_ID>]
[<INNER_VLAN-ID>][<OUTER_VLAN_ID>]
<USER_INTERFACE>
<ipv4-informatiom>::=<USER_ID><USER_IPV4>
<MASK_LENGTH><GATEWAY>
<VRF>
<ipv6-information>::=<USER_ID>(<USER_IPV6>
<PREFIX_LEN>)|(<PD_ADDRESS><PD_PREFIX_LEN>)
<VRF>
<qos-information>::=<USER_ID>
(<CIR><PIR><CBS><PBS>)
[<QOS_PROFILE>]
<interface-related-infor-model>::=<interface-information>
<interface-information>::=<IFINDEX><BAS_ENABLE>
<service-type>
<service-type>::=<PPP_Only><IPV4_TRIG>
<IPV6_TRIG><ND-TRIG>
<ARP_PROXY>
<device-related-infor-model>::=<address-field-distribute>
<address-field-distribute>::=<ADDRESS_SEGMENT><ADDRESS_SEGMENT_MASK>
<ADDRESS_SEGMENT_VRF><NEXT_HOP>
<IF_INDEX><MASK_LENGTH>
<user-plane-information-model>::=<port-resources-infor-model>
<traffic-statistics>
<port-resource-information>::=<IF_INDEX><IF_NAME>
<IF_TYPE><LINK_TYPE>
<MAC_ADDRESS><IF_PHY_STATE>
<MTU>
<traffic-statistics-information>::=<USER_ID><STATISTICS_TYPE>
<INGRESS_STATIISTICS_PACKETS>
<INGRESS STATISTICS_BYTES>
<EGRESS_STATISTICS_PACKETS>
<EGRESS_STATISTICS_BYTES>
This section describes information model for the Control-Plane (CP). As mentioned in Section 3, the Control Plane is a user control management component which manages the user’s information, User-Plane's resources and forwarding policy, etc. The control plane can generate several tables which contain a set of rules based on the resources and specific requirements of user's service. After that, the control plane sends the tables to User Planes, and User planes receive the tables, parse them, match the rules, and then perform corresponding actions.
The Routing Backus-Naur Form grammar below specifies the Information model for Control-Plane:
<control-plane-information-model>::=<user-related-infor-model>
<interface-related-infor-model>
<device-related-infor-model>
<user-related-infor-model>::= <user-basic-information>
[<ipv4-informatiom>]|[<ipv6-information>]
[<qos-information>]
<user-basic-information> :: = <USER_ID> <MAC_ADDRESS>
[<ACCESS_TYPE>][<SESSION_ID>]
[<INNER_VLAN-ID>][<OUTER_VLAN_ID>]
<USER_INTERFACE>
<ipv4-informatiom>::=<USER_ID><USER_IPV4>
<MASK_LENGTH><GATEWAY>
<VRF>
<ipv6-information>::=<USER_ID>(<USER_IPV6>
<PREFIX_LEN>)|(<PD_ADDRESS><PD_PREFIX_LEN>)
<VRF>
<qos-information>::=<USER_ID>
(<CIR><PIR><CBS><PBS>)
[<QOS_PROFILE>]
<interface-related-infor-model>::=<interface-information>
<interface-information>::=<IFINDEX><BAS_ENABLE>
<service-type>
<service-type>::=<PPP_Only><IPV4_TRIG>
<IPV6_TRIG><ND-TRIG>
<ARP_PROXY>
<device-related-infor-model>::=<address-field-distribute>
<address-field-distribute>::=<ADDRESS_SEGMENT><ADDRESS_SEGMENT_MASK>
<ADDRESS_SEGMENT_VRF><NEXT_HOP>
<IF_INDEX><MASK_LENGTH>
user-related-infor-model: presents the attributes that can describe the user’s profile, such as user’s basic information, qos, and IP address.
interface-related-infor-model: presents the attributes that relate to some physical/virtual interface. This model can be used to indicate which kinds of service can be supported by interfaces.
device-related-infor-model: presents the attributes which relate to a specific device. For example the control plane can manage and distribute the users, which belong to same subnet, to some specific devices. And the user plane’s devices provide corresponding service for these users.
The user related information is a collection of attributes bound to specific users. For example, the control plane can use a unified ID to distinguish different users and distribute the IP address and QoS rules to a specific user. In this section, the user related information models are presented. The user related information models include the user information model, IPv4/IPv6 information model, QoS information model, etc.
The Routing Backus-Naur Form grammar below specifies the user related information model:
<user-related-infor-model>::= <user-basic-information>
[<ipv4-informatiom>]|[<ipv6-information>]
[<qos-information>]
<user-basic-information> :: = <USER_ID> <MAC_ADDRESS>
[<ACCESS_TYPE>][<SESSION_ID>]
[<INNER_VLAN-ID>][<OUTER_VLAN_ID>]
<USER_INTERFACE>
<ipv4-informatiom>::=<USER_ID><USER_IPV4>
<MASK_LENGTH><GATEWAY>
<VRF>
<ipv6-information>::=<USER_ID>(<USER_IPV6>
<PREFIX_LEN>)|(<PD_ADDRESS><PD_PREFIX_LEN>)
<VRF>
<qos-information>::=<USER_ID>
(<CIR><PIR><CBS><PBS>)
[<QOS_PROFILE>]
The User Basic Information model contains a set of attributes to describe the basic information of a specific user, such as the user's MAC address, access type (via PPPoE, IPoE, etc), inner VLAN ID, outer VLAN ID, etc.
The Routing Backus-Naur Form grammar below specifies the user basic information model:
<user-basic-information> :: = <USER_ID> <MAC_ADDRESS>
[<ACCESS_TYPE>][<SESSION_ID>]
[<INNER_VLAN-ID>][<OUTER_VLAN_ID>]
<USER_INTERFACE>
USER_ID (4 bytes): is the identifier for a user. This parameter is unique and mandatory. It can be used to distinguish different users.
MAC_ADDRESS (6 bytes): is the MAC address of the user.
ACCESS_TYPE (2 bytes): This attribute is an optional parameter. It can be used to indicate the protocol being used for the user's access, such as PPPoE, IPoE, etc.
SESSION_ID (4 bytes): This attribute is an optional parameter. It can be used as the identifier of PPPoE session.
INNER_VLAN-ID (2 bytes): The 12-bit identifier of user's inner VLAN in network byte order. The unused high-order 4 bits MUST be sent as zero and ignored on receipt.
OUTER_VLAN_ID (2 bytes): The 12-bit identifier of user's outer VLAN in network byte order. The unused high-order 4 bits MUST be sent as zero and ignored on receipt.
USER_INTERFACE (4 bytes): This attribute specifies the binding interface of a specific user. The IfIndex of the interface MAY be included. This is the 32-bit IfIndex assigned to the interface by the device as specified by the Interfaces Group MIB [RFC2863]. The IfIndex can be utilized within a management domain to map to an actual interface, but it is also valuable in public applications [RFC5837]. The IfIndex can be used as an opaque token to discern which interface of the User-Plane is providing corresponding service for specific user.
The IPv4 information model presents the user’s IPv4 parameters. It is an optional constructs. The Routing Backus-Naur Form grammar below sepcifies the user’s IPv4 information model:
<ipv4-informatiom>::=<USER_ID><USER_IPV4>
<MASK_LENGTH><GATEWAY>
<VRF>
USER_ID (4 bytes): is the identifier of user. This parameter is unique and mandatory. This attribute is used to distinguish different users. In conjunction with other IPv4 parameters it links the user to the user's IPv4 information.
USER_IPV4 (4 bytes): This attribute specifies the user's IPv4 address, It is usually used in user plane discovery and ARP reply message.
MASK_LENGTH (4 bytes): This attribute specifies the user’s subnet mask length which can identify a range of IP addresses that are on the same network.
GATEWAY (4 bytes): This attribute specifies the user’s gateway, and is usually used in User Plane discovery and ARP reply message.
VRF (4 bytes): is the identifier of VRF instance.
The IPv6 information model presents the user’s IPv6 parameters. It is an optional constructs. The Routing Backus-Naur Form grammar below specifies the user’s IPv6 information model:
<ipv6-information>::=<USER_ID>(<USER_IPV6>
<PREFIX_LEN>)|(<PD_ADDRESS><PD_PREFIX_LEN>)
<VRF>
USER_ID (4 bytes): is the identifier of user. This parameter is unique and mandatory. This attribute is used to distinguish different users. in conjunction with other IPv6 parameters, I tlink the user to the user's IPv6 information.
USER_IPV6 (2 bytes): This attribute specifies the user's IPv6 address. It is usually used in neighbor discovery (ND discovery).
PREFIX_LEN (4 bytes): This attribute specifies the user’s subnet prefix lengths which can identify a range of IP addresses that are on the same network.
PD_ADDRESS (4 bytes): In IPv6 networking, DHCPv6 prefix delegation is used to assign a network address prefix and automate configuration and provisioning of the public routable addresses for the network. This attribute specifies the user’s DHCPv6 prefix delegation address, and is usually used in neighbor discovery (ND discovery).
PD_PREFIX_LEN (4 bytes): This attribute specifies the user’s DHCPv6 delegation prefix length, and it's usually used in neighbor discovery (ND discovery).
VRF (4 bytes): is the identifier of a VRF instance
In the CU separation BNG, the Control-Plane (CP) generates the QoS table base based on the UP's bandwidth resources and the specific QoS requirements ofof the user's services. This table contains a set of QoS matching rules such as user's committed information rate, peak information rate, committed burst size, etc. And itIs is an optional constructs. The Routing Backus-Naur Form grammar below illustratesspecifies the user's qos information model:
<qos-information>::=<USER_ID>
(<CIR><PIR><CBS><PBS>)
[<QOS_PROFILE>]
USER_ID (4 bytes): is the identifier of user. This parameter is unique and mandatory. This attribute is used to distinguish different users. within conjunction with other qos parameters it links the user to the user's qos information.
CIR (4 bytes): In a BNG network, the Committed Information Rate (CIR) is the bandwidth available for a user guaranteed by an internet service provider under normal conditions. This attribute is used to indicate the user's committed information rate, and it usually appears with other qos attributes (such as PIR, CBS, PBS, etc) to give the user's QoS profile.
PIR (4 bytes): Peak Information Rate (PIR) is a burstable rate set on routers and/or switches that allow throughput bursts. This attribute is used to indicate the user's peak information rate. In conjunction with with other QoS attributes (such as CIR, CBS, PBS, etc) it is used to give the user's QoS profile.
CBS (4 bytes): The Committed Burst Size (CBS) specifies the relative amount of reserved buffers for a specific ingress network's forwarding class queue or egress network's forwarding class queue. This attribute is used to indicate the user's committed burst size. In conjunction with other qos attributes (such as CIR, PIR, PBS, etc) it is used to give the user's QoS profile.
PBS (4 bytes): The Peak Burst Size (PBS) specifies the maximum size of the first token bucket. This attribute is used to indicate the user's peak burst size. In conjunction with other qos attributes (such as CIR, PIR, CBS, etc) it is used to give the user's QoS profile.
QOS_PROFILE (4 bytes): This attribute specifies the standard profile provided by the operator. It can be used as a QoS template that is defined as a list of classes of services and associated properties. The properties may include:
This model contains the necessary information for an interface. It is used to indicate which kind of service can be supported by this interface. The Routing Backus-Naur Form grammar below specifies the interface related information model:
<interface-related-infor-model>::=<interface-information>
<interface-information>::=<IFINDEX><BAS_ENABLE>
<service-type>
<service-type>::=<PPP_Only><IPV4_TRIG>
<IPV6_TRIG><ND-TRIG>
<ARP_PROXY>
The interface model mentioned here is a logical construct that identifies a specific process or a type of network service. In CU separation BNG network, the Control-Plane (CP) generates the Interface-Infor table based on the available resources, which are received from the User-Plane (UP), and the specific requirements of user's services.
The Routing Backus-Naur Form grammar below specifies the interface information model:
<interface-information>::=<IFINDEX><BAS_ENABLE>
<service-type>
<service-type>::=<PPP_Only><IPV4_TRIG>
<IPV6_TRIG><ND-TRIG>
<ARP_PROXY>
IFINDEX (4 bytes): The IfIndex is the 32-bit index assigned to the interface by the device as specified by the Interfaces Group MIB [RFC2863]. The IfIndex can be utilized within a management domain to map to an actual interface, but it is also valuable in public applications. The IfIndex can be used as an opaque token to discern which interface of the User-Plane is providing the corresponding service for specific user.
BAS_ENABLE (2 bytes): This is a flag, and if it is TRUE, the BRAS is enabled on this interface.
PPP_Only (2 bytes): This is a flag, and if it is TRUE, the interface only supports PPP user.
IPV4_TRIG (2 bytes): This is a flag, and if it is TRUE, the interface supports the user being triggered to connect to the internet by using an IPv4 message.
IPV6_TRIG (2 bytes): This is a flag, and if it is TRUE, the interface supports that the user being triggered to connect to the internet by using an IPv6 message.
ND-TRIG (2 bytes): This is a flag, and if it is TRUE, the interface supports the user being triggered to connect to the internet by using a neighbor discovery message.
ARP_PROXY (2 bytes): This is a flag, and if it is TRUE, ARP PROXY is enabled on this interface.
The device related information model presents the attributes which relate to a specific device. For example the control plane can manage and distribute the users, who belong to the same subnet, to some specific devices. And then the user plane's devices can provide the corresponding service for these users. The Routing Backus-Naur Form grammar below specifies the device related information model:
<device-related-infor-model>::=<address-field-distribute>
<address-field-distribute>::=<ADDRESS_SEGMENT><ADDRESS_SEGMENT_MASK>
<ADDRESS_SEGMENT_VRF><NEXT_HOP>
<IF_INDEX><MASK_LENGTH>
In the CU separation BNG information model, the Control-Plane (CP) generates and sends this Address field distribute table to UP. Based on this table, the user-plane’s devices can be divided into several blocks, and each block is in charge of working for users with the same subnet. The Routing Backus-Naur Form grammar below illustrates the address field sepcifies information model:
<address-field-distribute>::=<ADDRESS_SEGMENT><ADDRESS_SEGMENT_MASK>
<ADDRESS_SEGMENT_VRF><NEXT_HOP>
<IF_INDEX><MASK_LENGTH>
This section describes the information model for the interface of to the User Plane (UP). As mentioned in section Section 3, the UP is a network edge and user policy implementation component. It supports the following: Forwarding plane functions on traditional BNG devices, including traffic forwarding, QoS, and traffic statistics collection and Control plane functions on traditional BNG devices, including routing, multicast, and MPLS.
In CU separation BNG information model, the CP generates tables and provides the entries. The UP plays two roles:
The Routing Backus-Naur Form grammar below specifies the User Plane information model:
<user-plane-information-model>::=<port-resources-infor-model>
<traffic-statistics>
port-resource-information>::=<IF_INDEX><IF_NAME>
<IF_TYPE><LINK_TYPE>
<MAC_ADDRESS><IF_PHY_STATE>
<MTU>
<traffic-statistics-information>::=<USER_ID><STATISTICS_TYPE>
<INGRESS_STATIISTICS_PACKETS>
<INGRESS STATISTICS_BYTES>
<EGRESS_STATISTICS_PACKETS>
<EGRESS_STATISTICS_BYTES>
The User Plane can generate the network resource table, which contains a bunch of attributes to present the available network resources, for example the usable interfaces.
The Figure Routing BNF grammar below illustratesspecifies the Port Resources Information Table of User-Plane:
<port-resource-information>::<IF_INDEX><IF_NAME>
<IF_TYPE><LINK_TYPE>
<MAC_ADDRESS><IF_PHY_STATE>
<MTU>
IFINDEX (4 bytes): IfIndex is the 32-bit index assigned to the interface by the device as specified by the Interfaces Group MIB [RFC2863]. The IfIndex can be utilized within a management domain to map to an actual interface, but it is also valuable in public applications. The IfIndex can be used as an opaque token to discern which interface of the User-Plane is available.
IF_NAME (64 bytes): the textual name of the interface. The value of this object should be the name of the interface as assigned by the local device and should be suitable for use in commands entered at the device's "console". This might be a text name, such as "le0" or a simple port number, such as "1", depending on the interface naming syntax of the device. If several entries in the ifTable together represent a single interface as named by the device, then each will have the same value of ifName.
IF_TYPE (4 bytes): the type of interface, such as Ethernet, GE, Eth-Trunk, etc.
LINK_TYPE (4 bytes): This attribute specifies the type of link, such as point-to-point, broadcast, multipoint, point-to-multipoint, private and public (accessibility and ownership), etc.
MAC_ADDRESS (6 bytes): This attribute specifies the available interface’s MAC address.
IF_PHY_STATE (1 byte): The current operational state of the interface. This is an enumeration type node:
MTU: This attribute specifies the available interface’s MTU (Maximum Transmission Unit).
The user-plane also generates the traffic statistics table to report the current traffic statistics.
The Figure below specifies the Traffic Statistics Infor model of User-Plane:
<traffic-statistics-information>::=<USER_ID><STATISTICS_TYPE>
<INGRESS_STATIISTICS_PACKETS>
<INGRESS STATISTICS_BYTES>
<EGRESS_STATISTICS_PACKETS>
<EGRESS_STATISTICS_BYTES>
USER_ID (4 bytes): is the identifier of user. This parameter is unique and mandatory. This attribute is used to distinguish different users. In conjunction with other statistics parameters such as ingress packets, egress packets, etc, it is used to report the user’s status profile.
STATISTICS_TYPE (4 bytes): This attributes specifies the traffic type such as IPv4, IPv6, etc.
INGRESS_STATIISTICS_PACKETS (8 bytes): This attribute specifies the Ingress Statistics Packets of specific user.
INGRESS STATISTICS_BYTES (8 bytes): This attribute specifies the Ingress Statistics Bytes of specific user.
EGRESS_STATISTICS_PACKETS (8 bytes): This attribute specifies the Egress Statistics Packets of specific user.
EGRESS_STATISTICS_BYTES (8 bytes): This attribute specifies the Egress Statistics Bytes of specific user.
None.
None.
| [I-D.cuspdt-rtgwg-cu-separation-bng-architecture] | Hu, S., Qin, F., Li, Z., Chua, T., Wang, Z. and J. Song, "Architecture for Control Plane and User Plane Separated BNG", Internet-Draft draft-cuspdt-rtgwg-cu-separation-bng-architecture-01, July 2018. |
| [I-D.cuspdt-rtgwg-cu-separation-bng-deployment] | Gu, R., Hu, S. and Z. Wang, "Deployment Model of Control Plane and User Plane Separation BNG", Internet-Draft draft-cuspdt-rtgwg-cu-separation-bng-deployment-00, October 2017. |
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. |
| [RFC2863] | McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, DOI 10.17487/RFC2863, June 2000. |
| [RFC5511] | Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax Used to Form Encoding Rules in Various Routing Protocol Specifications", RFC 5511, DOI 10.17487/RFC5511, April 2009. |
| [RFC5837] | Atlas, A., Bonica, R., Pignataro, C., Shen, N. and JR. Rivers, "Extending ICMP for Interface and Next-Hop Identification", RFC 5837, DOI 10.17487/RFC5837, April 2010. |
| [RFC8174] | Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017. |
| [TR-384] | Broadband Forum, ""Cloud Central Office Reference Architectural Framework",", BBF TR-384, January. 2018. |