Control-Plane and User-Plane separation BNG control channel Protocol

BNG is an Ethernet-centric IP edge router, and the aggregation point for the user traffic. To provide centralized session management, flexible address allocation, high scalability for subscriber management capacity, and cost-efficient redundancy, the CU separated BNG is introduced [TR-384]. The CU separated Service Control Plane could be virtualized and centralized, which is responsible for user access authentication and setting forwarding entries to user planes. The routing control and forwarding plane, i.e. BNG user plane (local), could be distributed across the infrastructure. This document specifies the CU Separation BNG control channel Protocol (CUSP) for communications between a Control Plane (CP) and a set of User Planes (UPs). CUSP is designed to be flexible and extensible so as to easily allow for the addition of further messages and objects, should further requirements be expressed in the future.

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 .

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.

| | | | | | | | HELLO (version) | |<----------------------------- | | | | | | | ]]> The initialization phase consists of two successive steps: 1) Establishment of a TCP connection (3-way handshake) between the CP and the UP. 2) Establishment of a CUSP session over the TCP connection. Once the TCP connection is established, the CP and the UP initiate CUSP session establishment during which the version negotiation are performed. The version's information are carried within Hello messages. If the CUSP session establishment phase fails because the CP or UP disagree on the version parameters or one of the CP or UP does not answer after the expiration of the establishment timer, the TCP connection is immediately closed. Details about the Hello message can be found in Sections 6.2 respectively.

The CP configures the BNG's access interface via NETCONF, and UPs report attributes of according interfaces and slots.

| | | | Configur BNG access | |<--------interface via netconf-| | | | CP sends ACCESS_IF_INFO | |<---to UPs via CUSP------------| | | | User dialup via VXLAN | |<----------------------------->| | | | CP sends USER_BASEC_INFO | |<---to UPs via CUSP------------| | | | CP sends USER_IPV4_INFO | |<---to UPs via CUSP------------| | | | CP sends ROUTEV4 INFO | |<---to UPs via CUSP------------| | | | UP report the USER_DETECT_RESULT_INFO |----to CP via CUSP------------>| | | | | | UP report the USER_TRAFFIC_INFO |----to CP via CUSP------------>| | | ]]> Once a CUSP session has been established, if an IPoE session be required that the UPs report attributes of corresponding interfaces and slots via CUSP, and the CP initiate a NETCONF session to configure requested access interface of BNG. Once above process has been accomplished, the CP sends the ACCESS_IF_INFO (Access Interface Information) message to UPs that contains a variety of objects that specify the set of constrains and attributes for the BNG access interface. For example, ifname = 0001, BNG service enable, IPv4 connection trigger enable, neighbor detection enable, etc. And then the user dialup via VXLAN, the CP sends the USER_BASIC_INFOR message USER_IPV4_INFOR, and USER_ROUTEV4_INFO to UPs that contains a variety of objects that specify the attributes for the user’s basic information, user’s ipv4 information, and routing information. Upon receiving above messages from a CP, the UPs reports the user detection results and user’s traffic status via USER_DETECT_RESULT_INFO message and USER_TRAFFIC_INFO, etc.

| | Configur BNG access | |<-------interface via netconf->| | | | CP sends ACCESS_IF_INFO | |<---to UPs via CUSP------------| | | | User dialup via VXLAN | |<----------------------------->| | | | CP sends USER_BASEC_INFO | |<---to UPs via CUSP------------| | | | CP sends USER_IPV4_INFO | |<---to UPs via CUSP------------| | | | CP sends ROUTEV4 INFO | |<---to UPs via CUSP------------| | | | CP sends USER_PPP_INFO | |<---to UPs via CUSP------------| | | | UP report the USER_DETECT_RESULT_INFO |----to CP via CUSP------------>| | | | UP report the USER_TRAFFIC_INFO |----to CP via CUSP------------>| | | ]]> Once a CUSP session has been established, if an PPPoE session be required that the UPs report attributes of corresponding interfaces and slots via CUSP, and the CP initiate a NETCONF session to configure requested access interface of BNG. Once above process has been accomplished, the CP sends the ACCESS_IF_INFO (Access Interface Information) message to UPs that contains a variety of objects that specify the set of constrains and attributes for the BNG access interface. For example, ifname = 0001, BNG service enable, IPv4 connection trigger enable, neighbor detection enable, etc. And then the user dialup via VXLAN, the CP sends the USER_BASIC_INFOR message, USER_PPP_INFO message, USER_IPV4_INFOR message, and USER_ROUTEV4_INFO message to UPs that contains a variety of objects that specify the attributes for the user’s basic information, user’s PPP information, user’s ipv4 information, and routing information. Upon receiving above messages from a CP, the UPs reports the user detection results and user’s traffic status via USER_DETECT_RESULT_INFO message and USER_TRAFFIC_INFO, etc.

| | | | Configure BNG Access interface |<-----via netconf--------------| | | | Configure QOS template | |<-----via netconf--------------| | | | User dialup via VXLAN/ | |<---CP sends objecitve tlv/event | report,etc. | | | | CP sends USER_QOS_INFO | |<---to UPs via CUSP------------| | | ]]> Once a CUSP session has been established, if a user’s QoS needs to be set dynamically that the UPs report attributes of according interfaces and slots via CUSP, and the CP initiate a NETCONF session to configure requested access interface of BNG and User’s configuration template. And then the user dialup via VXLAN, the CP sends the USER_BASIC_INFOR message, USER_IPV4_INFOR message, and USER_ROUTEV4_INFO message to UP, the UPs reports the user detection results and user’s traffic status. Once above process has been accomplished, the CP sends the USER_QOS_AUTH_INFO message to UPs that contains a variety of objects that specify the set of constrains and attributes for the user’s required QoS.(Note that the format of these QoS attributes should synchronize with QoS configuration templates.)

| | | |------statistic_BEGIN-------------->| | | |<-----statistic_BEGIN (ACK)---------| | | |------statistic_DATA--------------->| | | |------statistic_END---------------->| | | |<-----statistic_END (ACK)-----------| | | | | ]]> If the CUSP session down, the CU separation BNG required that the users’ information should be reserved. And if the CUSP session restart, the CP may request the UP to report the previous session’s statistics to synchronize user information. Above figure describe this process, and the details about the session statistic message can be found in Sections 6.3 respectively.

A CUSP message consists of a common header followed by a variable-length body made of a set of objects. A CUSP message with a missing mandatory object MUST trigger an Error message (see Section 5.6). Conversely, if an object is optional, the object may or may not be present. Common header:

Message-Type (8 bits): The following message types are currently defined:

Flags (1 bits): The control message ACK mode be enabled by setting it to one. Resv (7 bits): Unassigned bits are considered as reserved. They MUST be set to zero on transmission and MUST be ignored on receipt. Message-Length (16 bits): total length of the CUSP message including the common header, expressed in bytes.

CUSP objects have a common format. They begin with a CUSP common header (see Section 4). This is followed by object-specific fields defined for each different object. The object may also include one or more type-length-value (TLV) encoded data sets. Each TLV has the same structure as described in Section 5.1.

A CUSP object may include a set of one or more optional TLVs. All CUSP objective TLVs have the following format:

A CUSP object TLV is comprised of 2 bytes for the type, 2 bytes specifying the TLV length, and a value field. The first 4 bits of Type field indicate the operation of this TLV, currently, there are two types: 0 – update the objectives; 1 – delete the objectives. The other bits of Type field indicate the TLV’s type (4-15 bits), the following message types are currently defined:

The Length field defines the length of the value portion in bytes. The TLV is padded to 4-bytes alignment; padding is not included in the Length field (so a 3-byte value would have a length of 3, but the total size of the TLV would be 8 bytes). Unrecognized TLVs MUST be ignored. IANA management of the CUSP Object TLV type identifier codespace is described in Section 11. The details about the attributes of Objective TLV are specified in [Section 4.1 of draft-cuspdt-rtgwg-cu-separation-infor-model-00]

CUSP Control TLV have a common format. They begin with a CUSP common header (see Section 3). It is followed by control TLV fields defined for each different control operations. It may also include one or more type-length-value (TLV) encoded control data sets. Each TLV has the same structure as described in Section 6.1. For each CUSP message type, rules are defined that specify the set of objects that the message can carry. We use the Backus-Naur Form (BNF) (see [RBNF]) to specify such rules. Square brackets refer to optional sub-sequences. An implementation MUST form the CUSP messages using the object ordering specified in this document.

A CUSP control may include a set of one or more optional TLVs. All CUSP control TLVs have the following format:

A CUSP control TLV is comprised of 2 bytes for the type, 2 bytes specifying the TLV length, and a value field. Control Type (8 bits): The following message types are currently defined:

The Hello message is a CUSP message sent by a UP to a CP and by a CP to a UP in order to establish a CUSP session. The Type field of the CUSP common header for the Hello message is set to 2. Once the TCP connection has been successfully established, the first message sent by the UP to the CP or by the CP to the UP MUST be a Hello message. Any message received prior to a Hello message MUST trigger a protocol error condition causing an ERROR message to be sent with Error-Type Version_ Negotiation_Failed and the CUSP session establishment attempt MUST be terminated by closing the TCP connection. The Hello message is used to establish a CUSP session between the CUSP peers. During the establishment phase, the CUSP peers exchange version information. If both parties agree on such version negotiation, the CUSP session is successfully established. The format of a Hello message is as follows:

::= :: = ]]> Version (4 bytes) : specifies the CP/UP supported CUSP’s version, currently, the version is 1.

If the CUSP session down, the CU separation BNG required that the users’ information should be reserved. And if the CUSP session restart, the CP may request the UP to report the previous session’s statistics to synchronize user information. The Type field of the CUSP common header for the Smooth message is set to 3/4/5/6. The format of a Smooth message is as follows:

::= ::= ]]> ClassID (2 bytes): specified the statistics type of CUS session, the following statistics types are currently defined:

Event (2 bytes): specified the Smooth message’s subtypes, the following subtypes are currently defined:

Note that, the event value MUST be synchronized with the type of comment header.

CUSP Event TLV have a common format. They begin with a CUSP common header (see Section 3). It is followed by Event TLV fields defined for each different Events. It may also include one or more type-length-value (TLV) encoded Event data sets. Each TLV has the same structure as described in Section 7.1. For each CUSP message type, rules are defined that specify the set of objects that the message can carry. We use the Backus-Naur Form (BNF) (see [RBNF]) to specify such rules. Square brackets refer to optional sub-sequences. An implementation MUST form the CUSP messages using the object ordering specified in this document.

A CUSP Event may include a set of one or more optional TLVs. All CUSP Event TLVs have the following format:

A CUSP Event TLV is comprised of 2 bytes for the type, 2 bytes specifying the TLV length, and a value field. Event Type (8 bits): The following message types are currently defined:

The USER_TRAFFIC_INFORMATION Message be used to reported the user’s traffic statistics by UP. The format of a USER_TRAFFIC_INFORMATION message is as follows:

::= ::= < EgressBytes > ]]> USER_ID (4 bytes): is the identifier of user. This parameter is unique and mandatory. This attribute is used to distinguish different users. StatisticsType (4 bytes): be used to indicate the Statistics type, the following types are currently defined:

IngressPackets (8 bytes): be used to present the ingress packets. IngressBytes (8 bytes): be used to present the ingress bytes. EgressPackets (8 bytes): be used to present the egress packets. EgressBytes (8 bytes): be used to present the egress bytes.

The USER_TRAFFIC_INFORMATION Message be used to reported the user detect fail by UP. The format of a USER_DETECT_RESULT_ INFORMATION message is as follows:

::= < USER_DETECT_RESULT_ INFORMATION _TLV> < USER_DETECT_RESULT_ INFORMATION _TLV>::= ]]> USER_ID (4 bytes): is the identifier of user. This parameter is unique and mandatory. This attribute is used to distinguish different users. DetectFail (2 bytes): be used to indicate that the user detect fail.

CUSP Resource Report TLV have a common format. They begin with a CUSP common header (see Section 3). It is followed by Event TLV fields defined for each different Resources. It may also include one or more type-length-value (TLV) encoded Resource Report data sets. Each TLV has the same structure as described in Section 7.1.

A CUSP Resource Report may include a set of one or more optional TLVs. All CUSP Resource Report TLVs have the following format:

A CUSP Resource Report TLV is comprised of 2 bytes for the type, 2 bytes specifying the TLV length, and a value field. Resource Type (8 bits): The following message types are currently defined:

The Length field defines the length of the value portion in bytes. The TLV is padded to 4-bytes alignment; padding is not included in the Length field (so a 3-byte value would have a length of 3, but the total size of the TLV would be 8 bytes). Unrecognized TLVs MUST be ignored. IANA management of the CUSP Object TLV type identifier codespace is described in Section 11. The details about the attributes of Resource Report TLV are specified in [Section 4.2 of draft-cuspdt-rtgwg-cu-separation-infor-model-00]

Error messages are used by the CP or UPs to notify the other side of the connection of problems. They are mostly used by the UPs to indicate a failure of a request initiated by the CP. The format of an Error message is as follows:

::= ]]> ERRID (4 bytes): be used to indicate the error type, the following types are currently defined:

None.