Skip to main content

Control-Plane and User-Plane Separation BNG Control Channel Protocol
draft-cuspdt-rtgwg-cu-separation-bng-protocol-03

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Authors Shujun Hu , Donald E. Eastlake 3rd , Zitao Wang , Fengwei Qin , Zhenqiang Li , Jun Song , Tee Mong Chua
Last updated 2018-11-30
Replaced by draft-chz-simple-cu-separation-bng-protocol
RFC stream (None)
Formats
Additional resources
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-cuspdt-rtgwg-cu-separation-bng-protocol-03
INTERNET-DRAFT                                                     S. Hu
Intended status: Proposed Standard                          China Mobile
                                                             D. Eastlake
                                                                 Z. Wang
                                                                  Huawei
                                                                  F. Qin
                                                                   Z. Li
                                                            China Mobile
                                                                 J. Song
                                                                  Huawei
                                                                 T. Chua
                                        Singapore Telecommunications Ltd
Expires: May 29, 2018                                  November 30, 2018

  Control-Plane and User-Plane Separation BNG Control Channel Protocol
          draft-cuspdt-rtgwg-cu-separation-bng-protocol-03.txt

Abstract

   This document specifies the CU Separation Broadband Network Gateway
   (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.

Status of This Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Distribution of this document is unlimited. Comments should be sent
   to the authors or the RGTWG working group mailing list:
   rtgwg@ietf.org.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   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."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/1id-abstracts.html. The list of Internet-Draft
   Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

Hu, et al                                                       [Page 1]
INTERNET-DRAFT                                    CU Separation Protocol

Table of Contents

      1. Introduction............................................3

      2. Concept and Terminology.................................4
      2.1 Terminology............................................4

      3. Protocol Overview.......................................5
      3.1 Initialization Phase...................................5
      3.2 Network Resource Report................................5
      3.3 IPoE Session Establishment.............................6
      3.4 PPPoE Session Establishment............................7
      3.5 Setting the User's QoS Information.....................9
      3.6 CUSP Session Statistics...............................10

      4. CUSP Common Header.....................................11

      5. Objective Message Formats..............................12
      5.1 Objective TLV Format..................................12

      6. Control Message Format.................................14
      6.1 Control TLV Format....................................14
      6.2 Hello Message.........................................15
      6.3 Statistics Message....................................15

      7. Event TLV Format.......................................17
      7.1 Event TLV Format......................................17
      7.2 USER_TRAFFIC_INFORMATION Message......................18
      7.3 USER_DETECT_RESULT_INFORMATION Message................18

      8. Resource Report TLV Format.............................20
      8.1 Resource Report TLV Format............................20

      9.  Error Message Format..................................21

      10. Security Considerations...............................22

      11. IANA Considerations...................................22
      11.1 Message Types........................................22
      11.2 TLV Types Values.....................................22
      11.3 ERRID Codes..........................................22

      Normative References......................................23
      Informative References....................................23

      Authors' Addresses........................................24

Hu, et al                                                       [Page 2]
INTERNET-DRAFT                                    CU Separation Protocol

1. Introduction

   A Broadband Network Gateway (BNG) is an Ethernet-centric IP edge
   router, and the aggregation point for user traffic.  To provide
   centralized session management, flexible address allocation, high
   scalability for subscriber management capacity, and cost-efficient
   redundancy, the Control/User (CU) separated BNG is descried in
   [TR-384].  The CU separated Service Control Plane, which is
   responsible for user access authentication and setting forwarding
   entries in User Planes, can be virtualized and centralized.  The
   routing control and forwarding plane, i.e. the BNG user plane
   (local), can be distributed across the infrastructure.

   This document specifies the CU Separation BNG control channel
   Protocol (CUSP) for communications between a BNG Control Plane (CP)
   and a set of User Planes (UPs).  CUSP is designed to be flexible and
   extensible so as to easily allow for additional messages and objects,
   should further requirements be expressed in the future.

Hu, et al                                                       [Page 3]
INTERNET-DRAFT                                    CU Separation Protocol

2. Concept and Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

2.1 Terminology

   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 the UP's resources such as the user
       entry and forwarding policy.

   CU: Control / User.

   CUSP: Control and User Separate Protocol.

   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.

Hu, et al                                                       [Page 4]
INTERNET-DRAFT                                    CU Separation Protocol

3. Protocol Overview

3.1 Initialization Phase

             UP                             CP
             |                               |
             |   TCP Session Establishment   |
             |<----------------------------->|
             |                               |
             |                               |
             |         HELLO (version)       |
             |------------------------------>|
             |                               |
             |                               |
             |        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 using port tbd1.

   2) Establishment of a CUSP session over the TCP connection.

   Once the TCP connection is established, the CP and the UP initialize
   the CUSP session during which the version negotiation is performed.
   The version information is carried within Hello messages (see Section
   6.2).  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.

3.2 Network Resource Report

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

Hu, et al                                                       [Page 5]
INTERNET-DRAFT                                    CU Separation Protocol

            UP                            CP
            |                              |
            |     slot attributes report   |
            |          via CUSP            |
            |----------------------------->|
            |                              |
            |     port attributes report   |
            |          via CUSP            |
            |----------------------------->|
            |                              |
            |      Configure BNG access    |
            |     interface via NETCONF    |
            |<---------------------------->|
            |                              |
            |                              |

   Details of the Resource Report Message can be found in Sections 8.

3.3 IPoE Session Establishment

        UP                              CP
        |                                |
        |    UP reports its resources    |
        |----via CUSP------------------->|
        |                                |
        |    Configure 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 reports the USER_DETECT_RESULT_INFO
        |----to CP via CUSP------------->|
        |                                |
        |    UP reports the USER_TRAFFIC_INFO
        |----to CP via CUSP------------->|

Hu, et al                                                       [Page 6]
INTERNET-DRAFT                                    CU Separation Protocol

        |                                |

   Once a CUSP session has been established, if an IPoE session is
   required, the UPs report attributes of the interfaces and slots to be
   used for the IPoE session via CUSP, and the CP initiate a NETCONF
   session to configure the requested access interface of BNG.

   Once the above process has been accomplished, the CP sends to the UP
   the ACCESS_IF_INFO (Access Interface Information) message that
   contains a variety of objects that specify the set of constrains and
   attributes for the BNG access interface.  For example, ifname = 0001
   [RFC2863], BNG service enable, IPv4 connection trigger enable,
   neighbor detection enable, etc.

   Then the user dials up via VXLAN, the CP sends to the UP the
   USER_BASIC_INFOR message USER_IPV4_INFOR, and USER_ROUTEV4_INFO 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 the above messages from a CP, the UPs reports the user
   detection results and user's traffic status via the
   USER_DETECT_RESULT_INFO message and USER_TRAFFIC_INFO, message.

3.4 PPPoE Session Establishment

Hu, et al                                                       [Page 7]
INTERNET-DRAFT                                    CU Separation Protocol

        UP                              CP
        |                                |
        |    UP reports the resources    |
        |----via CUSP------------------->|
        |                                |
        |        Configure 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 reports the USER_DETECT_RESULT_INFO
        |----to CP via CUSP------------->|
        |                                |
        |    UP reports the USER_TRAFFIC_INFO
        |----to CP via CUSP------------->|
        |                                |

   Once a CUSP session has been established, if an PPPoE session is
   required, the UPs report attributes of the corresponding interfaces
   and slots to be used for the PPPoE session via CUSP, and the CP
   initiate a NETCONF session to configure requested access interface of
   the BNG.

   Once the above process has been accomplished, the CP sends to the UP
   the ACCESS_IF_INFO (Access Interface Information) message that
   contains a variety of objects that specify the set of constrains and
   attributes for the BNG access interface.  For example, ifname = 0001
   [RFC2863], BNG service enable, IPv4 connection trigger enable,
   neighbor detection enable, etc.

   Then the user dials up via VXLAN, the CP sends to the UP the
   USER_BASIC_INFOR message, the USER_PPP_INFO message, USER_IPV4_INFOR
   message, and USER_ROUTEV4_INFO message that contains a variety of
   objects that specify the attributes of the user's basic information,

Hu, et al                                                       [Page 8]
INTERNET-DRAFT                                    CU Separation Protocol

   user's PPP information, user's ipv4 information, and routing
   information.

   Upon receiving the 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.

3.5 Setting the User's QoS Information

        UP                              CP
        |                                |
        |    UP reports the resources    |
        |----via CUSP------------------->|
        |                                |
        |   Configure BNG Access interface
        |<-----via NETCONF---------------|
        |                                |
        |   Configure QOS template       |
        |<-----via NETCONF---------------|
        |                                |
        |    User dials up via VXLAN     |
        |<---CP sends objective TLV/Event|
        |    report, etc.                |
        |                                |
        |    CP sends USER_QOS_INFO      |
        |<---to UPs via CUSP-------------|
        |                                |

   Once a CUSP session has been established, if a user's Quality of
   Service (QoS) needs to be set dynamically, then the UPs report
   attributes of the relevant interfaces and slots via CUSP, and the CP
   initiate a NETCONF session to configure the requested access
   interfaces of the BNG and User's configuration template.  Then the
   user dials up via VXLAN, the CP sends the USER_BASIC_INFOR message,
   USER_IPV4_INFOR message, and USER_ROUTEV4_INFO message to the 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 the UPs; this message contains a
   variety of objects that specify the set of constrains and attributes
   for the user's required QoS. (The format of these QoS attributes
   should be parallel to the QoS configuration templates.)

Hu, et al                                                       [Page 9]
INTERNET-DRAFT                                    CU Separation Protocol

3.6 CUSP Session Statistics

        UP                                  CP
        |                                    |
        |                                    |
        |<-----statistic_REQUEST ------------|
        |                                    |
        |------statistic_REQUEST (ACK)------>|
        |                                    |
        |------statistic_BEGIN-------------->|
        |                                    |
        |<-----statistic_BEGIN (ACK)---------|
        |                                    |
        |------statistic_DATA--------------->|
        |                                    |
        |------statistic_END---------------->|
        |                                    |
        |<-----statistic_END (ACK)-----------|
        |                                    |
        |                                    |

   If the CUSP session goes down, the CU separation BNG is required to
   save the users' information.  And if the CUSP session restarts, the
   CP may request that the UP send the previous session's statistics to
   synchronize user information.  The above figure shows this process,
   and the details of the session statistic message can be found in
   Sections 6.3.

Hu, et al                                                      [Page 10]
INTERNET-DRAFT                                    CU Separation Protocol

4. CUSP Common Header

   A CUSP message consists of a common header followed by a variable-
   length body made of a set of objects.  Receiving 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:
       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Message-Type |F|     Resv    |       Message-Length          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          Transaction id                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                          CUSP Message Common Header

   Message-Type (8 bits):  The following message types are defined in
            this document:

             Value      Meaning
             -----      ------------------
               1        Update objective
               2        Hello
               3        statistics Request
               4        statistics Begin
               5        statistics Data
               6        statistics End
               7        Source Report
               8        Event Report
               9        Error

   F (1 bit):  Setting the F bit to one enables the control message ACK
            mode and setting the F bit to zero disables that mode.

   Resv (7 bits):  Reserved bits.  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 as an unsigned
            integer.

   Transaction ID (32 bits): This field is used to identify requests. It
            is echoed back in the corresponding ACK / response / Error
            message.

Hu, et al                                                      [Page 11]
INTERNET-DRAFT                                    CU Separation Protocol

5. Objective Message Formats

   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.

5.1 Objective TLV Format

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

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |             Type              |       TLV-Length              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     Value                                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

         Type:       2 bytes
         TLV-Length: 2 bytes
         Value:      variable

   A CUSP objective TLV is comprised of 2 bytes for the type, 2 bytes
   specifying the TLV-Length, and a value field. The Type and TLV-Length
   fields are unsigned integers.

   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 object. Updating a non-existent object creates it.

   The remaining bits of the Type field indicate the TLV's type (4-15
   bits) which is the object to which it applies. The following objects
   / types are currently defined:

      Value   Meaning
      -----   --------------
        0     USER_BASIC_INFO
        1     USER_PPP_INFO
        2     ACCESS_IFSRV_INFO
        3     USER_IPV4_INFO
        4     USER_IPV6_INFO
        5     USER_QOS_AUTH_INFO
        6     ROUTEV4_INFO
        7     ROUTEV6_INFO
        8     STATIC_USER_INFO

Hu, et al                                                      [Page 12]
INTERNET-DRAFT                                    CU Separation Protocol

   The TLV-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 of the attributes of the Objective TLV are specified in
   Section 4.1 of [InforModel].

Hu, et al                                                      [Page 13]
INTERNET-DRAFT                                    CU Separation Protocol

6. Control Message Format

   CUSP Control messages have a common format.  They begin with the CUSP
   common header (see Section 4) followed by control TLVs fields for the
   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 [RFC5511]) 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.

6.1 Control TLV Format

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

      Type:       2 bytes
      TLV-Length: 2 bytes
      Value:      variable

   A CUSP control TLV consists 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:

      Value    Meaning
      -----    ----------
        0      Hello
        1      Statistics

   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.

Hu, et al                                                      [Page 14]
INTERNET-DRAFT                                    CU Separation Protocol

6.2 Hello Message

   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:

      <Hello Message>::= <Common Header>
               <HELLO_TLV>
      <HELLO_TLV>:: = <version>

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

6.3 Statistics Message

   If the CUSP session goes down, the CU separation BNG is required to
   preserve the users' information.  If the CUSP session restarts, 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 Statistics messages
   is set to 3, 4, 5, or 6.

   The format of a Statistics message is as follows:

      <Statistics Message>::= <Common Header>
               <Statistics_TLV>
      <Statistics_TLV>::= <ClassID><Event><Resv>

   ClassID (2 bytes): This field specifies the statistics type of CUS
   session, the following statistics types are currently defined:

Hu, et al                                                      [Page 15]
INTERNET-DRAFT                                    CU Separation Protocol

      Value    Meaning
      -----    -------------------------------
        0      objective message statistic
        1      Source report message statistic
        2      Event report message statistic

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

      Value    Meaning
      -----    -------
        0      request Statistics message
        1      begin Statistics message
        2      Statistics data message
        3      End Statistics message

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

Hu, et al                                                      [Page 16]
INTERNET-DRAFT                                    CU Separation Protocol

7. Event TLV Format

   CUSP Event TLVs have a common format.  They begin with a CUSP common
   header (see Section 4).  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 [RFC5511]) 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.

7.1 Event TLV Format

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

      Type:   2 bytes
      Length: 2 bytes
      Value:  variable

   A CUSP Event TLV consists 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:

      Type    Meaning
      -----    ------------------------------
        0      USER_TRAFFIC_INFORMATION
        1      USER_DETECT_RESULT_INFORMATION

   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.

Hu, et al                                                      [Page 17]
INTERNET-DRAFT                                    CU Separation Protocol

7.2 USER_TRAFFIC_INFORMATION Message

   The USER_TRAFFIC_INFORMATION Message be used by the UP to reported
   the user's traffic statistics.

   The format of a USER_TRAFFIC_INFORMATION message is as follows:

      <USER_TRAFFIC_INFORMATION Message>::= <Common Header>
                               <USER_TRAFFIC_INFORMATION_TLV>
      <USER_TRAFFIC_INFORMATION_TLV>::= <UserId><StatisticsType>
                               <IngressPackets><IngressBytes>
                               <EngressPackets><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:

      Value    Meaning
      -----    -----------------------
        0      IPv4 traffic statistics
        1      IPv6 traffic statistics

   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.

7.3 USER_DETECT_RESULT_INFORMATION Message

   The USER_TRAFFIC_INFORMATION Message is used to reported the failure
   of user detection by the UP.

   The format of a USER_DETECT_RESULT_INFORMATION message is as follows:

      <USER_DETECT_RESULT_INFORMATION Message>::= <Common Header>
                                   <USER_DETECT_RESULT_ INFORMATION_TLV>
      <USER_DETECT_RESULT_INFORMATION_TLV>::= <UserId><DetectFail>

   USER_ID (4 bytes): is the identifier of user.  This parameter is
   unique and mandatory. This attribute is used to distinguish different
   users.

Hu, et al                                                      [Page 18]
INTERNET-DRAFT                                    CU Separation Protocol

   DetectFail (2 bytes): be used to indicate that the user detect fail.

Hu, et al                                                      [Page 19]
INTERNET-DRAFT                                    CU Separation Protocol

8. Resource Report TLV Format

   CUSP Resource Report TLVs have a common format.  They begin with a
   CUSP common header (see Section 4).  It is followed by Event TLV
   fields defined for each different Resource.  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.

8.1 Resource Report TLV Format

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

      Type:   2 bytes
      Length: 2 bytes
      Value:  variable

   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:

      Value    Meaning
      -----    -------
        0      RESOURCE_IF_INFO
        1      RESOURCE_SLOT_INFO

   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 [InforModel]

Hu, et al                                                      [Page 20]
INTERNET-DRAFT                                    CU Separation Protocol

9.  Error Message Format

   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:

      <Err Message> ::= <Common Header>
                          <ERRID>

   ERRID (4 bytes): Used to indicate the error type. The following types
                   are currently defined:

      Value    Meaning
      -------  --------------------------------
      00~1000  Reserved
      1001     version negotiation failed
      1002     TLV type cannot be recognized
      1003     TLV length Anomaly
      1004     TLV objective Anomaly
      1005     Statistics failed
      1006     Statistics request not supported

Hu, et al                                                      [Page 21]
INTERNET-DRAFT                                    CU Separation Protocol

10. Security Considerations

   TBD.

11. IANA Considerations

   IANA is registered to assign a port for CUSP as follows:

      Service  Port    Transport
      Name     Number  Protocol   Description   Reference
      -------  ------  ---------  ------------  ---------------
      cusp     tbd1    tcp        Control User  [this document]
                                  Separation
                                  Protocol

   IANA is requested to create a "CUSP Parameters" web page and include
   there of the registries set up below in this Section.

11.1 Message Types

   TBD.

11.2 TLV Types Values

   TBD.

11.3 ERRID Codes

   TBD.

Hu, et al                                                      [Page 22]
INTERNET-DRAFT                                    CU Separation Protocol

Normative References

   [cuspdt-rtgwg-cu-separation-bng-deployment] Gu, R., Hu, S., and Z.
             Wang, "Deployment Model of Control Plane and User Plane
             Separation BNG", draft-cuspdt-rtgwg-cu-separation-bng-
             deployment (work in progress), October 2017.

   [InforModel] Wang, Z., Gu, R., Lopezalvarez, V., and S. Hu,
             "Information Model of Control-Plane and User-Plane
             separation BNG", draft-cuspdt-rtgwg-cu-separation-infor-
             model (work in progress), October 2018.

   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
             Requirement Levels", BCP 14, RFC 2119, DOI
             10.17487/RFC2119, March 1997, <https://www.rfc-
             editor.org/info/rfc2119>.

   [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group
             MIB", RFC 2863, DOI 10.17487/RFC2863, June 2000,
             <https://www.rfc-editor.org/info/rfc2863>.

   [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, <https://www.rfc-editor.org/info/rfc5511>.

   [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119
             Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May
             2017, <https://www.rfc-editor.org/info/rfc8174>.

Informative References

   [cuspdt-rtgwg-cusp-requirements] Hu, S., Gu, R., Lopezalvarez, V.,
             Song, J., and Z. Wang, "Requirements for Control Plane and
             User Plane Separated BNG Protocol", draft-cuspdt-rtgwg-
             cusp-requirements (work in progress), October 2018.

   [TR-384] Broadband Forum, "Cloud Central Office Reference
             Architectural Framework", BBF TR-384, 2018.

Hu, et al                                                      [Page 23]
INTERNET-DRAFT                                    CU Separation Protocol

Authors' Addresses

      Shujun Hu
      China Mobile
      32 Xuanwumen West Ave, Xicheng District
      Beijing, Beijing  100053
      China

      Email: hushujun@chinamobile.com

      Donald Eastlake, 3rd
      Huawei
      1424 Pro Shop Court
      Davenport, FL  33896
      USA

      Phone: +1-508-333-2270
      Email: d3e3e3@gmail.com

      Zitao Wang
      Huawei
      101 Software Avenue, Yuhua District
      Nanjing, Jiangsu  210012
      China

      Email: wangzitao@huawei.com

      Fengwei Qin
      China Mobile
      32 Xuanwumen West Ave, Xicheng District
      Beijing, Beijing  100053
      China

      Email: qinfengwei@chinamobile.com

      Zhenqiang Li
      China Mobile
      32 Xuanwumen West Ave, Xicheng District
      Beijing, Beijing  100053
      China

      Email: lizhenqiang@chinamobile.com

      Jun Song
      Huawei

Hu, et al                                                      [Page 24]
INTERNET-DRAFT                                    CU Separation Protocol

      101 Software Avenue, Yuhua District
      Nanjing, Jiangsu  210012
      China

      Email: song.jun@huawei.com

      Tee Mong Chua
      Singapore Telecommunications Limited
      31 Exeter Road, #05-04 Comcentre Podium Block
      Singapore City  239732
      Singapore

      Email: teemong@singtel.com

Hu, et al                                                      [Page 25]
INTERNET-DRAFT                                    CU Separation Protocol

Copyright, Disclaimer, and Additional IPR Provisions

   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
   (http://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.

Hu, et al                                                      [Page 26]