[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05

INTERNET-DRAFT                                                     S. Hu
Intended status: Proposed Standard                          China Mobile
                                                             D. Eastlake
                                                                 M. Chen
                                                     Huawei Technologies
                                                                  F. Qin
                                                                   Z. Li
                                                            China Mobile
                                                                 J. Song
                                                     Huawei Technologies
                                                                 T. Chua
                                            Singapore Telecommunications
Expires: September 10, 2019                               March 11, 2019


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


Abstract

   This document specifies the Simple Control Plane (CP) and User Plane
   (UP) Separation Broadband Network Gateway (BNG) control channel
   Protocol (S-CUSP) for communications between a CP and a UP. S-CUSP is
   designed to be flexible and extensible so as to easily allow for the
   addition of further messages and data items, should requirements be
   expressed in the future.


Status of This Memo

   This Internet-Draft is submitted 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                                           BNG Simple CUSP


Table of Contents

      1. Introduction............................................5

      2. Terminology.............................................6
      2.1 Acronyms...............................................6

      3. Protocol Overview.......................................8
      3.1 S-CUSP Configuration...................................8
      3.2 S-CUSP Session Establishment...........................9
      3.3 Overview of S-CUSP Procedures..........................9
      3.4 Network Resource Report...............................10
      3.5 BNG Access Procedures.................................11
      3.5.1 IPoE Access.........................................11
      3.5.2 PPPoE Access........................................12
      3.5.3 L2TP LAC Access.....................................13
      3.5.4 L2TP LNS Access.....................................13
      3.5.5 L2TP LTS Access.....................................15
      3.6 Setting the User's QoS Information....................15
      3.7 CP and UP Synchronization.............................16
      3.8 CGN Address Allocation................................17

      4. S-CUSP Message Formats.................................18
      4.1 Common Message Header.................................18
      4.1.1 Control Messages....................................19
      4.1.2 Flow Table Message..................................19
      4.1.3 Resource Reporting Message..........................19
      4.1.4 Event Reporting Message.............................19
      4.1.5 Vendor Message......................................20
      4.1.6 Resource Allocation Messages........................20
      4.2 Common Message TLV Format.............................20
      4.3 Basic Data Fields.....................................21
      4.4 Sub-TLV Format and Specific Sub-TLVs..................22
      4.4.1 VRF-Name............................................22
      4.4.2 Ingress-QoS-Profile.................................22
      4.4.3 Egress-QoS-Profile..................................23
      4.4.4 User-ACL-Policy.....................................23
      4.4.5 Multicast-Profile-v4................................23
      4.4.6 Multicast-Profile-v6................................23
      4.4.7 Ingress-CAR.........................................23
      4.4.8 Egress-CAR..........................................24
      4.4.9 NAT-Instance........................................24
      4.4.10 Pool-Name..........................................24
      4.4.11 If-Desc............................................25

      5. Basic TLVs.............................................26
      5.1 Interface Information TLV.............................26
      5.2 Basic User Information TLVs...........................28
      5.2.1 Basic User Information TLV..........................28
      5.2.2 User PPP Information TLV............................30
      5.3 User IPv4 Information TLV.............................31

Hu, et al                                                       [Page 2]


INTERNET-DRAFT                                           BNG Simple CUSP


Table of Contents (continued)

      5.4 User IPv6 Information.................................32
      5.5 User QoS Policy Information TLV.......................33
      5.6 Routing Table TLVs....................................34
      5.6.1 IPv4 Routing Information TLV........................34
      5.6.2 IPv6 Routing Information TLV........................35
      5.7 Static User Information TLVs..........................36
      5.7.1 Static IPv4 User Information TLV....................37
      5.7.2 Static IPv6 User Information TLV....................38
      5.8 L2TP User Information TLVs............................39
      5.8.1 L2TP-LAC User Information TLV.......................39
      5.8.2 L2TP-LNS User Information TLV.......................39
      5.8.3 L2TP-LAC Tunnel TLV.................................40
      5.8.4 L2TP-LNS Tunnel TLV.................................41
      5.9 NAT User Information TLV..............................41
      5.10 Vendor Defined TLV...................................42

      6. Control TLVs...........................................44
      6.1 Hello TLV.............................................44
      6.2 Error Information TLV.................................44

      7. Resource Reporting TLVs................................46
      7.1 Interface Resource Information TLV....................46
      7.2 UP Board Status Report Information TLV................46

      8. Event TLVs.............................................48
      8.1 User Traffic Statistics Report TLV....................48
      8.2 User Detection Result Report TLV......................49
      8.3 User Basic Table Operation Result TLV.................50

      9. Resource Allocation TLVs...............................51
      9.1 Request Address Allocation TLV........................51
      9.2 Address Assignment Response TLV.......................51
      9.3 Address Renewal Request TLV...........................52
      9.4 Address Renewal Response TLV..........................53
      9.5 Address Release Request TLV...........................53
      9.6 Address Release Response TLV..........................54

      10. Implementation Status.................................55
      10.1 Implementations......................................55
      10.1.1 Huawei Technologies................................55
      10.1.2 ZTE................................................56
      10.1.3 H3C................................................56
      10.2 Hackathon............................................56
      10.3 EANTC Testing........................................57

      11. Security Considerations...............................58

      12. IANA Considerations...................................59
      12.1 Service Name and Port Number.........................59

Hu, et al                                                       [Page 3]


INTERNET-DRAFT                                           BNG Simple CUSP


Table of Contents (continued)

      12.2 S-CUSP Parameters....................................59
      12.2.1 Message Types......................................59
      12.2.2 TLV Types..........................................60
      12.2.3 TLV Operation Codes................................61
      12.2.4 Sub-TLV Types......................................61
      12.2.5 ERRID Codes........................................62

      Contributors..............................................64

      Normative References......................................65
      Informative References....................................65

      Authors' Addresses........................................67





































Hu, et al                                                       [Page 4]


INTERNET-DRAFT                                           BNG Simple CUSP


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 framework is
   described in [TR-384].  The CU separated Service Control Plane (CP),
   which is responsible for user access authentication and setting
   forwarding entries in User Planes (UPs), can be virtualized and
   centralized.  The routing control and forwarding plane, i.e. the BNG
   user plane (local), can be distributed across the infrastructure.
   Other structures can also be supported such as both CP and UP being
   virtual or both being physical.

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
































Hu, et al                                                       [Page 5]


INTERNET-DRAFT                                           BNG Simple CUSP


2. 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 Acronyms

   ACK: Acknowledgement message.

   BNG: Broadband Network Gateway.  A broadband remote access server
       (BRAS (BRoadband Access Server), 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).

   BRAS: BRoadband Access Server (BNG).

   CAR: Committed Access Rate.

   CBS: Committed Burst Size.

   CGN: Carrier Grade NAT.

   Ci: Control Interface.

   CIR: Committed Information Rate.

   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-plane / User-plane.

   CUSP: Control and User Plane Separation Protocol.

   DEI: Drop Eligibility Indicator. A bit in a VLAN tag after the
       priority and before the  VLAN ID. (This bit was formerly the CFI
       (Canonical Format Indicator).)

   IPoE: IP over Ethernet.

   L2TP: Layer 2 Tunneling Protocol.

   LAC: L2TP Access Concentrator


Hu, et al                                                       [Page 6]


INTERNET-DRAFT                                           BNG Simple CUSP


   LNS: L2TP Network Server

   Mi: Management Interface.

   MSS: Maximum Segment Size.

   MRU: Maximum Receive Unit.

   NAT: Network Address Translation [RFC3022].

   ND: Neighbor Discovery.

   PBS: Peak Burst Size.

   PD: Prefix Delegation.

   PIR: Peak Information Rate.

   PPP: Point to Point Protocol [RFC1661].

   PPPoE: PPP over Ethernet.

   S-CUSP: Simple Control and User Plane Separation Protocol.

   Si: Service Interface.

   TLV: Type, Length, Value. See Section 4.2.

   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.

   URPF: Unicast Reverse Path Forwarding.

   user: Equivalent to "customer".

   VRF: Virtual Routing and Forwarding.














Hu, et al                                                       [Page 7]


INTERNET-DRAFT                                           BNG Simple CUSP


3. Protocol Overview

   This section shows example message exchanges.



3.1 S-CUSP Configuration

   To support Control Plane and User Plane separation, as defined in
   [SCUSP-architecture], three interfaces are defined. These are
   referred to as the Control Interface (Ci), Service Interface (Si) and
   Management Interface (Mi).

   NETCONF is the protocol used on the Manaegment Interface between a CP
   and UP. It is used to configure the parameters of the Control
   Interface, Service Interface and the Access interfaces. The
   parameters are defined in [SCUSP-YANG].

             UP                                CP
             |                                  |
             |   Configure Control Interface    |
             |<-----------via NETCONF-----------|
             |                                  |
             |   Configure Service Interface    |
             |<-----------via NETCONF-----------|
             |                                  |
             |   Configure Access Interfaces    |
             |<-----------via NETCONF-----------|
             |                                  |
             |   Configure QOS Template         |
             |<-----------via NETCONF-----------|
             |                                  |

   Once the parameters configured, a UP can start to establish S-CUSP
   session(s) with the specified CP(s) through the S-CUSP Session
   Establishment as defined Section 3.2 of this document.
















Hu, et al                                                       [Page 8]


INTERNET-DRAFT                                           BNG Simple CUSP


3.2 S-CUSP Session Establishment

             UP                               CP
             |                                 |
             |   TCP Session Establishment     |
             |<------------------------------->|
             |                                 |
             |                                 |
             |   HELLO (version, capability)   |
             |-------------------------------->|
             |                                 |
             |                                 |
             |   HELLO (version, capability)   |
             |<--------------------------------|
             |                                 |

   The S-CUSP session establishment 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 S-CUSP session over the TCP connection.

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



3.3 Overview of S-CUSP Procedures

             UP                                   CP

                1.
             |     UP reports the Statistic INFO   |
             |-----to CP via S-CUSP--------------->|
             |                                     |
             |     UP reports the Event INFO       |
             |-----to CP via S-CUSP--------------->|
             |                                     |
             |     UP reports Resource INFO        |
             |-----to CP via S-CUSP--------------->|
             |                                     |




Hu, et al                                                       [Page 9]


INTERNET-DRAFT                                           BNG Simple CUSP


                2.
             |     UP relays User Dial-up Request  |
             |-----to CP via Si------------------->|
             |                                     |
             |     CP sends User Dial-up Response  |
             |<----to UPs via Si-------------------|
             |                                     |

                3.
             |     CP sends User INFO              |
             |<----to UP via S-CUSP----------------|
             |                                     |
             |     CP sends User Policy INFO       |
             |<----to UP via S-CUSP----------------|
             |                                     |
             |     CP sends Route INFO             |
             |<----to UP via S-CUSP----------------|
             |                                     |
             |     CP sends Tunnel INFO            |
             |<----to UP via S-CUSP----------------|
             |                                     |

                4.
             |    CGN Address Allocation via S-CUSP|
             |<----------------------------------->|
             |                                     |

                5.
             |     Data Synchronization via S-CUSP |
             |<----------------------------------->|
             |                                     |



3.4 Network Resource Report

   Once an S-CUSP session is established between a CP and an UP. The UP
   will begin to report the status/attributes of its slots, interfaces,
   and sub-interfaces.













Hu, et al                                                      [Page 10]


INTERNET-DRAFT                                           BNG Simple CUSP


             UP                              CP
             |                                |
             |     Slot attributes report     |
             |          via S-CUSP            |
             |------------------------------->|
             |                                |
             |     Port attributes report     |
             |          via S-CUSP            |
             |------------------------------->|
             |                                |
             | Sub-interface attributes report|
             |          via S-CUSP            |
             |------------------------------->|
             |                                |

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



3.5 BNG Access Procedures



3.5.1 IPoE Access

             UP                                     CP
             |                                       |
             |     DHCP Negotiation Messages         |
             |<------------via Si------------------->|
             |                                       |
             |     CP sends USER_BASEC_INFO          |
             |<----to UPs via S-CUSP-----------------|
             |                                       |
             |     CP sends USER_POLICY_INFO         |
             |<----to UP via S-CUSP------------------|
             |                                       |
             |     CP sends USER_IPV4/6_INFO         |
             |<----to UPs via S-CUSP-----------------|
             |                                       |
             |     CP sends ROUTEV4/6 INFO           |
             |<----to UPs via S-CUSP-----------------|
             |                                       |
             |     UP reports USER_DETECT_RESULT_INFO|
             |-----to CP via S-CUSP----------------->|
             |                                       |
             |     UP reports USER_TRAFFIC_INFO      |
             |-----to CP via S-CUSP----------------->|
             |                                       |




Hu, et al                                                      [Page 11]


INTERNET-DRAFT                                           BNG Simple CUSP


3.5.2 PPPoE Access

             UP                                     CP
             |                                       |
             |     PPPoE Negotiation Messages        |
             |<-----------via Si-------------------->|
             |                                       |
             |     LCP Negotiation Messages          |
             |<-----------via Si-------------------->|
             |                                       |
             |     User Authentication Messages      |
             |<-----------via Si-------------------->|
             |                                       |
             |     IPCP Negotiation Messages         |
             |<-----------via Si-------------------->|
             |                                       |
             |     CP sends USER_BASEC_INFO          |
             |<----to UP via S-CUSP------------------|
             |                                       |
             |     CP sends USER_POLICY_INFO         |
             |<----to UP via S-CUSP------------------|
             |                                       |
             |     CP sends USER_IPV4/6_INFO         |
             |<----to UP via S-CUSP------------------|
             |                                       |
             |     CP sends ROUTEV4/6 INFO           |
             |<----to UP via S-CUSP------------------|
             |                                       |
             |     CP sends USER_PPP_INFO            |
             |<----to UP via S-CUSP------------------|
             |                                       |
             |     UP reports USER_DETECT_RESULT_INFO|
             |-----to CP via S-CUSP----------------->|
             |                                       |
             |     UP reports USER_TRAFFIC_INFO      |
             |-----to CP via S-CUSP----------------->|
             |                                       |















Hu, et al                                                      [Page 12]


INTERNET-DRAFT                                           BNG Simple CUSP


3.5.3 L2TP LAC Access

           UP                                   CP                LNS
           |                                     |                 |
           |     PPPoE Negotiation Messages      |                 |
           |<-----------via Si------------------>|                 |
           |                                     |                 |
           |     LCP Negotiation Messages        |                 |
           |<-----------via Si------------------>|                 |
           |                                     |                 |
           |     User Authentication Messages    |                 |
           |<-----------via Si------------------>|                 |
           |                                     |                 |
           |    LAC Tunnel Negotiation Messages  |                 |
           | -----------via Si------------------>|                 |
           | /\                                  |                 |
           | || forward                          |                 |
           | \/                                  |                 |
           |  ------------------ LAC Tunnel Negotiation ---------->|
           |                                     |                 |
           |   LAC Session Negotiation Messages  |                 |
           |<-----------via Si------------------>|                 |
           | /\                                  |                 |
           | || forward                          |                 |
           | \/                                  |                 |
           |  ------------------ LAC Session Negotiation --------->|
           |                                     |                 |
           |     CP sends USER_BASIC_INFO        |                 |
           |<----to UP via S-CUSP----------------|                 |
           |                                     |                 |
           |     CP sends LAC_TUNNEL_INFO        |                 |
           |<----to UP via S-CUSP----------------|                 |
           |                                     |                 |
           |     CP sends LAC_USER_INFO          |                 |
           |<----to UP via S-CUSP----------------|                 |
           |                                     |                 |
           |                                     |                 |
           |     UP reports USER_TRAFFIC_INFO    |                 |
           |-----to CP via S-CUSP--------------->|                 |
           |                                     |                 |




3.5.4 L2TP LNS Access







Hu, et al                                                      [Page 13]


INTERNET-DRAFT                                           BNG Simple CUSP


           |UP                                 CP|             LAC|
           |    LNS Tunnel Negotiation Messages  |                |
           |<-----------via Si------------------>|                |
           | /\                                  |                |
           | || forward                          |                |
           | \/                                  |                |
           |  ------------------ LNS Tunnel Negotiation --------->|
           |                                     |                |
           |   LNS Session Negotiation Messages  |                |
           |<-----------via Si------------------>|                |
           | /\                                  |                |
           | || forward                          |                |
           | \/                                  |                |
           |  ------------------ LNS Session Negotiation -------->|
           |                                     |                |
           |     LCP Negotiation Messages        |                |
           |<-----------via Si------------------>|                |
           |                                     |                |
           |     User Authentication Messages    |                |
           |<-----------via Si------------------>|                |
           |                                     |                |
           |     IPCP Negotiation Messages       |                |
           |<-----------via Si------------------>|                |
           |                                     |                |
           |     CP sends LNS_TUNNEL_INFO        |                |
           |<----to UP via S-CUSP----------------|                |
           |                                     |                |
           |     CP sends USER_BASEC_INFO        |                |
           |<----to UP via S-CUSP----------------|                |
           |                                     |                |
           |     CP sends USER_IPV4/6_INFO       |                |
           |<----to UP via S-CUSP----------------|                |
           |                                     |                |
           |     CP sends ROUTEV4/6 INFO         |                |
           |<----to UP via S-CUSP----------------|                |
           |                                     |                |
           |     CP sends USER_PPP_INFO          |                |
           |<----to UP via S-CUSP----------------|                |
           |                                     |                |
           |     CP sends LNS_USER_INFO          |                |
           |<----to UP via S-CUSP----------------|                |
           |                                     |                |
           |     CP sends USER_POLICY_INFO       |                |
           |<----to UP via S-CUSP----------------|                |
           |                                     |                |
           |  UP reports USER_DETECT_RESULT_INFO |                |
           |-----to CP via S-CUSP--------------->|                |
           |                                     |                |
           |     UP reports USER_TRAFFIC_INFO    |                |
           |-----to CP via S-CUSP--------------->|                |


Hu, et al                                                      [Page 14]


INTERNET-DRAFT                                           BNG Simple CUSP


3.5.5 L2TP LTS Access

           UP                                   CP            LAC/LNS
           |                                     |                |
           | LAC/LTS Tunnel Negotiation Messages |                |
           |<-----------via Si------------------>|                |
           | /\                                  |                |
           | || forward                          |                |
           | \/                                  |                |
           |  ------------------ LAC/LTS Tunnel Negotiation ----->|
           |                                     |                |
           | LAC/LTS Session Negotiation Messages|                |
           |<-----------via Si------------------>|                |
           | /\                                  |                |
           | || forward                          |                |
           | \/                                  |                |
           |  ------------------ LAC/LTS Session Negotiation ---->|
           |                                     |                |
           |     CP sends LAC_TUNNEL_INFO        |                |
           |<----to UP via S-CUSP----------------|                |
           |                                     |                |
           |     CP sends LNS_TUNNEL_INFO        |                |
           |<----to UP via S-CUSP----------------|                |
           |                                     |                |
           |     CP sends USER_BASEC_INFO        |                |
           |<----to UP via S-CUSP----------------|                |
           |                                     |                |
           |     CP sends LAC_USER_INFO          |                |
           |<----to UP via S-CUSP----------------|                |
           |                                     |                |
           |     CP sends LNS_USER_INFO          |                |
           |<----to UP via S-CUSP----------------|                |
           |                                     |                |



3.6 Setting the User's QoS Information















Hu, et al                                                      [Page 15]


INTERNET-DRAFT                                           BNG Simple CUSP


           UP                                   CP               AAA
           |                                     |                |
           |   Configure QOS template            |                |
           |<-----via NETCONF--------------------|                |
           |                                     |                |
           |    User dials up via Si             |                |
           |<----------------------------------->|                |
           |                                     |                |
           |    CP sends USER_QOS_INFO           |                |
           |<---to UPs via S-CUSP----------------|                |
           |                                     |<--COA request--|
           |    CP sends USER_QOS_INFO           |                |
           |<---to UPs via S-CUSP----------------|                |
           |                                     |                |
           |    UP sends ACK message             |                |
           |----to CP via S-CUSP---------------->|--COA response->|
           |                                     |                |

   Once an S-CUSP session has been established, if a user's Quality of
   Service (QoS) needs to be set dynamically, the CP initiate a NETCONF
   session to configure the requested User's QoS template.  Then the
   user dials up via Si, the CP sends the USER_BASIC_INFO message,
   USER_IPV4_INFO message, and USER_ROUTEV4_INFO messages to the UP, the
   UPs report 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.)



3.7 CP and UP Synchronization

             UP                                   CP
             |                                     |
             |    CP sends Synchronization Request |
             |<-----to UP via S-CUSP---------------|
             |                                     |
             |    UP sends Synchronization Begin   |
             |------to CP via S-CUSP-------------->|
             |                                     |
             |    UP reports Resource INFO         |
             |------to CP via S-CUSP-------------->|
             |                                     |
             |    UP sends Synchronization End     |
             |------to CP via S-CUSP-------------->|
             |                                     |



Hu, et al                                                      [Page 16]


INTERNET-DRAFT                                           BNG Simple CUSP


             |    UP sends NAT Address Renew Req.  |
             |------to CP via S-CUSP-------------->|
             |                                     |
             |    CP sends NAT Address Renew Res.  |
             |<-----to UP via S-CUSP---------------|
             |                                     |


             |    UP sends Snychronization Request |
             |------to CP via S-CUSP-------------->|
             |                                     |
             |    CP sends Synchronization Begin   |
             |<-----to UP via S-CUSP---------------|
             |                                     |
             |    CP sends User/Route/Tunnel. INFO |
             |<-----to UP via S-CUSP---------------|
             |                                     |
             |    CP sends Synchronization End     |
             |<-----to UP via S-CUSP---------------|
             |                                     |



3.8 CGN Address Allocation

             UP                                   CP
             |                                     |
             |    UP sends Address Allocation Req. |
             |------to CP via S-CUSP-------------->|
             |                                     |
             |    CP sends Address Allocation Res. |
             |<-----to UP via S-CUSP---------------|
             |                                     |



















Hu, et al                                                      [Page 17]


INTERNET-DRAFT                                           BNG Simple CUSP


4. S-CUSP Message Formats

   This section specifies the format of the common S-CUSP message
   header, the format of the TLVs that appear in S-CUSP messages, the
   format of the sub-TLVs that appear within the values of some TLVs,
   and the format of some basic data fields.

   An S-CUSP message consists of a common header followed by a variable-
   length body consisting of TLVs.  Receiving an S-CUSP message with a
   missing mandatory TLV MUST trigger an Error message (see Section
   5.6).  Conversely, if a TLV is optional, the TLV may or may not be
   present.

   Network byte order is used for all multi-byte fields.



4.1 Common Message Header

   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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Ver |  Resv   | Message-Type  |        Message-Length         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |            Reserved           |        Transaction-ID         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                         S-CUSP Message Common Header


      Ver (3 bits):  The version of the protocol. This document
                  specifies version 1.

      Resv (4 bits):  Reserved. MUST be sent as zero and ignored on
                  receipt.

      Message-Type (8 bits):  The set of message types specified in this
                  document is listed in Section 12.2.1.

      Message-Length (16 bits):  Total length of the CUSP message
                  including the common header, expressed in number of
                  bytes as an unsigned integer.

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





Hu, et al                                                      [Page 18]


INTERNET-DRAFT                                           BNG Simple CUSP


4.1.1 Control Messages

   Control messages are listed below.

   Type  Name              Notes and TLVs that can be carried
   ----  ----              ------------------------------------
      1  Hello             Capability negotiation.
      2  Keepalive         Keepalive.
      3  Synch_Request     Synchronization request.
      4  Sync_Begin        Synchronization starts.
      5  Sync_Data         Synchronization data: TLVs specified in
                            Section 5.
      6  Sync_End          End synchronization.



4.1.2 Flow Table Message

   Flow Table messages are listed below.

   Type  Name              Notes and TLVs that can be carried
   ----  ----              ------------------------------------
      7  Update_Request    TLVs specified in Section 5.
      8  Update_Response   TLVs specified in Section 5.



4.1.3 Resource Reporting Message

   The Resource Reporting message is as follows:

   Type  Name              Notes and TLVs that can be carried
   ----  ----              ------------------------------------
      9  Report            Interface-Info, Board-Info.



4.1.4 Event Reporting Message

   The Event Reporting message is as follows:

   Type  Name              Notes and TLVs that can be carried
   ----  ----              ------------------------------------
     10  Event             Traffic-Info, Detect-Info.








Hu, et al                                                      [Page 19]


INTERNET-DRAFT                                           BNG Simple CUSP


4.1.5 Vendor Message

   The Vendor message is as follows:

   Type  Name              Notes and TLVs that can be carried
   ----  ----              ------------------------------------
     11  Vendor            Vendor-Defined, any other TLV(s) as
                           implemented by the vendor.



4.1.6 Resource Allocation Messages

   The Resource Allocation messages are listed below.

   Type  Name                 Notes and TLVs that can be carried
   ----  ----                 ------------------------------------
    200  Addr_Allocation_Req  Addr-Alloc-Req
    201  Addr_Allocation_Ack  Addr-Alloc-Resp
    202  Addr_Renew_Req       Addr-Renew-Req
    203  Addr_Renew_Ack       Addr-Renew-Resp
    204  Addr_Release_Req     Addr-Release-Req
    205  Addr_Release_Ack     Addr-Release-Resp



4.2 Common Message TLV Format

   CUSP messages consist of the common header specified in Section 4.1
   followed by TLVs formatted as specified in this section.

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Oper  |      TLV-Type         |       TLV-Length              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        Value                                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...

      Oper (4 bits):  For Message-Types that indicate an operation on a
                  data set, the Oper field is interpreted as Update,
                  Delete, or Reserved as specified in Section 12.2.3.
                  For all other Message-Types, the Oper field MUST be
                  sent as zero and ignored on receipt.

      TLV-Type (12 bits): The Type of a TLV, that is the meaning and
                  format of the Value part, are determined by the TLV-
                  Type of the TLV. See Section 12.2.2.




Hu, et al                                                      [Page 20]


INTERNET-DRAFT                                           BNG Simple CUSP


      TLV-Length (2 bytes):  The length of the Value portion of the TLV
                  in bytes as an unsigned integer.

      Value (variable length):  This is the value portion of the TLV
                  whose size is given by TLV-Length.



4.3 Basic Data Fields

   This section specifies the binary format of several standard basic
   data fields that are used within other data structures in this
   specification.

      STRING
              0 to 255 octets. Will be encoded as a sub-TLV (see Section
              4.4) to provide the length.

      MAC-Addr
              6 octets. Ethernet MAC Address.

      IPv4 Address
              8 octets. 4 octets of the IPv4 address value followed by a
              4 octet address mask in the format XXX.XXX.XXX.XXX.

      IPv6 Address
              20 octets. 16 octets of IPv6 address followed by a 4 octet
              integer n in the range of 0 to 128 which gives the address
              mask as the one's complement of 2**(128-n) - 1.

      VLAN ID
              2 octets. As follows:

                  0                   1
                  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
                 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                 | PRI |D|      VLAN-ID          |
                 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                 PRI: Priority. Default value 7.

                 D: Drop Eligibility Indicator (DEI). Default value 0.

                 VLAN-ID: Unsigned integer in the range 1-4094.








Hu, et al                                                      [Page 21]


INTERNET-DRAFT                                           BNG Simple CUSP


4.4 Sub-TLV Format and Specific Sub-TLVs

   In some cases, the Value portion of a TLV, as specified above, can
   contain one or more Sub-TLVs formatted as follows:

       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             |          Length               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        Value                                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...

      Type (2 bytes): The Type of a Sub-TLV, that is the meaning and
                  format of the Value part, are determined by the Type
                  of the TLV. See Section 12.2.4.

      Length (2 bytes):  The length of the Value portion of the TLV in
                  bytes as an unsigned integer.

      Value (variable length):  This is the value portion of the TLV
                  whose size is given by TLV-Length.

   The sub-TLVs currently specified are specified in the following
   subsections.



4.4.1 VRF-Name

   The name of the VRF (Virtual Routing and Forwarding instance) that
   the BNG user accesses. Optional.

   Sub-TLV Type: 1, VRF Name
   Length: 1-255 octets.
   Value: STRING.



4.4.2 Ingress-QoS-Profile

   Indicates the upstream QoS Profile Name. Optional.

   Sub-TLV Type: 2, Ingress QoS Profile Name
   Length: 1-255 octets.
   Value: STRING.






Hu, et al                                                      [Page 22]


INTERNET-DRAFT                                           BNG Simple CUSP


4.4.3 Egress-QoS-Profile

   Indicates the downstream QoS Profile Name. Optional.

   Sub-TLV Type: 3, Egress QoS Profile Name
   Length: 1-255 octets.
   Value: STRING.



4.4.4 User-ACL-Policy

   Indicates the name of the ACL policy group to which the user belongs.
   Optional.

   Sub-TLV Type: 4, User ACL Policy Name
   Length: 1-255 octets.
   Value: STRING.



4.4.5 Multicast-Profile-v4

   Name of the IPv4 multicast program list a user can order. Optional.

   Sub-TLV Type: 5, Multicast Profile of IPv4.
   Length: 1-255 octets.
   Value: STRING.



4.4.6 Multicast-Profile-v6

   Name of the IPv6 multicast program list a user can order. Optional.

   Sub-TLV Type: 6, Multicast Profile of IPv6.
   Length: 1-255 octets.
   Value: STRING.



4.4.7 Ingress-CAR

   Indicates the authorized upstream Committed Access Rate (CAR)
   parameters. Optional.

   Sub-TLV Type: 7, Ingress CAR.
   Length: 16 Octets.
   Value: The following four fields in the order given:



Hu, et al                                                      [Page 23]


INTERNET-DRAFT                                           BNG Simple CUSP


       Name    Type     Description
      ------  -------  ---------------------------------
        CIR   4 bytes   Guaranteed rate in bits/second.
        PIR   4 bytes   Burst rate in bits/second.
        CBS   4 bytes   The token bucket in bytes.
        PBS   4 bytes   Burst token bucket in bytes.



4.4.8 Egress-CAR

   Indicates the authorized downstream Committed Access Rate (CAR)
   parameters. Optional.

   Sub-TLV Type: 8, Egress CAR.
   Length: 16 Octets.
   Value: The following four fields in the order given:

       Name    Type     Description
      ------  -------  ---------------------------------
        CIR   4 bytes   Guaranteed rate in bits/second.
        PIR   4 bytes   Burst rate in bits/second.
        CBS   4 bytes   The token bucket in bytes.
        PBS   4 bytes   Burst token bucket in bytes.



4.4.9 NAT-Instance

   Name of the Network Address Translation (NAT) Instance to which the
   user belongs. Optional.

   Sub-TLV Type: 9, NAT Instance Name.
   Length: 1-255 octets.
   Value: STRING.



4.4.10 Pool-Name

   Indicates the name of the address pool to which the public network
   segment belongs. Optional.

   Sub-TLV Type: 10, IP Address Pool Name.
   Length: 1-255 octets.
   Value: STRING.






Hu, et al                                                      [Page 24]


INTERNET-DRAFT                                           BNG Simple CUSP


4.4.11 If-Desc

   Description of an interface. Mandatory.

   Sub-TLV Type: 11, Interface Description
   Length: 12
   Value: Several fields structured as follows:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          If-Type                     4 bytes  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Chassis    |                                      1 byte
   +-+-+-+-+-+-+-+-+
   |     Slot      |                                      1 byte
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Port Information         |                      2 bytes
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Sub-Port Number                 4 bytes  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      If-Type: Interface Type:
            0 = Reserved, 1 = FE, 2 = GE, 3 = 10GE, 4 = 100GE, 5: Eth-
            Trunk, 6: Tunnel, 7: VE
      Chassis: Subrack Number
      Slot: Slot
      Port Information:
         If-Type = Physical, the Port Information consists of a 1 byte
            Physical Slot number followed by a 1 byte Physical port
            number.
         If-Type - virtual port, the Port Information consists of a 2
            byte logical number of the virtual interface.
      Sub-Port: Sub-port Number


















Hu, et al                                                      [Page 25]


INTERNET-DRAFT                                           BNG Simple CUSP


5. Basic TLVs

   This section describes basic TLVs.



5.1 Interface Information TLV

   The Interface Information TLV can be used by a CP to control the
   access mode, authentication methods, and other related functions of
   an interface.

   The format of the Interface Information TLV value part is as below:

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          If-Index                             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Access-Mode  |  Auth-Method4 |  Auth-Method6 |    Reserved   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                             Flags                             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ~                         sub-TLVs (optional)                   ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                    Figure 5.1: Interface Information TLV

   Function:   Service information about the user access interface
               on the BNG.
   TLV Type:   1
   TLV Length: variable

   TLV fields:
   If-Index:    4 bytes in length, a unique identifier of an interface
                of a BNG.
   Access-Mode: 1 byte in length, indicates the access mode of the
                interface; this document defines following values:
                0: Layer 2 subscriber;
                1: Layer 3 subscriber;
                2: Layer 2 leased line;
                3: Layer 3 leased line;
                4-255: Reserved.

   Auth-Method4: 1 byte in length, for IPv4 scenario, indicates the
                authentication on this interface; this field is defined
                as a bitmap, this document defines following values
                (other bits are reserved and MUST be sent as zero and
                ignored on receipt):
                0x1: PPPoE authentication;


Hu, et al                                                      [Page 26]


INTERNET-DRAFT                                           BNG Simple CUSP


                0x2: DOT1X authentication;
                0x4: Web authentication;
                0x8: Web fast authentication;
                0x10: Binding authentication.

   Auth-Method6: 1 byte in length, for IPv6 scenario, indicates the
                authentication on this interface; this field is defined
                as a bitmap, this document defines following values
                (other bits are reserved and MUST be sent as zero and
                ignored on receipt):
                0x1: PPPoE authentication;
                0x2: DOT1X authentication;
                0x4: Web authentication;
                0x8: Web fast authentication;
                0x10: Binding authentication;

   The flags field is defined as below:

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                MBZ                            |Y|X|P|I|N|A|S|F|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                         Figure 5.2: Interface Flags

   Where:

   F (IPv4 Trigger) bit: Indicates whether IPv4 packets can trigger a
                  subscriber go to online.
                  1: enabled, 0: disabled.

   S (IPv6 Trigger) bit: Indicates whether IPv6 packets can trigger a
                  subscriber go to online.
                  1: enabled, 0: disabled.

   A (ARP Trigger) bit: Indicates whether ARP packets can trigger a
                  subscriber go to online.
                  1: enabled, 0: disabled.

   N (ND Trigger) bit: Indicates whether ND packets can trigger a
                  subscriber go to online.
                  1: enabled, 0: disabled.

   I (IPoE-Flow-Check): Used for UP detection. IPoE 1: Enable traffic
                  detection. 0: Disable traffic detection.

   P (PPP-Flow-Check) bit: Used for UP detection. PPP 1: Enable traffic
                  detection. 0: Disable traffic detection.



Hu, et al                                                      [Page 27]


INTERNET-DRAFT                                           BNG Simple CUSP


   X (ARP-Proxy) bit: 1: The interface is enabled with ARP proxy and can
                  process ARP requests across different Port+VLANs.
               0: The ARP proxy is not enabled on the interface, and
                  only the ARP requests of the same Port+VLAN are
                  processed.

   Y (ND-Proxy) bit: 1: The interface is enabled with ND proxy and can
                  process ND requests across different Port+VLANs.
               0: The ND proxy is not enabled on the interface, and only
                  the ND requests of the same Port+VLAN are processed.

   MBZ: Reserved bits that MUST be sent as zero and ignored on receipt.



5.2 Basic User Information TLVs

   The Basic User Information TLVs are defined for a CP to carry the
   basic information about a user to an UP.



5.2.1 Basic User Information TLV

   The format of the Basic User Information TLV value part is as below:

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          User ID                              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          Session ID                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          User MAC                             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |             User MAC          |   Oper ID     |    Reserved   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Access Type   |Sub-access Type|  Account Type | Address Family|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               C-VID           |          P-VID                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               Detect Times    |          Detect Interval      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                            If-Index                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ~                            sub-TLVs (optional)                ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                    Figure 5.3: Basic User Information TLV



Hu, et al                                                      [Page 28]


INTERNET-DRAFT                                           BNG Simple CUSP


   Function:   Basic information about a BNG user.
   TLV Type:   2
   TLV Length: variable in length;

   TLV Fields:
    Name           Length   Description
   --------------  ------   ----------------------
   User-ID         4 bytes  User ID.
   User-Mac        MAC-Addr User MAC Address.
   Oper-ID         1 byte   Indicates the ID of an operation performed
                            by a user. This field is carried in the
                            response from the UP.
   Session-ID      4 bytes  Session ID of a PPPoE user. Zero for non-
                            PPPoE user.
   Access-Type     1 byte   See Section 5.2.1.1.
   Sub-Access-Type 1 byte   Indicates whether PPP termination or PPP
                            relay is used. 0: N/A 1: PPP2 on the LAC
                            side: Termination, PPP on the LNS side
   Account-Type    1 byte   IPv4/IPv6 charging: 0 separate charging:
                            Collects statistics on IPv4 and IPv6 traffic
                            of terminals independently. 1: Statistics
                            and charging Collects statistics on IPv4 and
                            IPv6 traffic of terminals.
   User-IP-Type    1 byte   1:IPv4 stack and 2:IPv6 stack 3: dual stack
   C-VID           VLAN-ID  Indicates the inner VLAN ID. The value 0
                            indicates that the VLAN ID is invalid. The
                            default value of PRI is 7, the value of DEI
                            is 0, and the value of VID is 1~4094. The
                            PRI value can also be obtained by parsing
                            terminal packets.
   P-VID           VLAN-ID  Outer VLAN ID. The value 0 indicates that
                            the VLAN ID is invalid. The format is the
                            same as that the C-VID.
   Detect-Times    2 bytes  Number of detection timeout times. The value
                            0 indicates that no detection is performed.
   Detect-Interval 2 bytes  Detection interval in seconds.
   If-Index        4 bytes  Interface index.

   The Reserved field MUST be sent as zero and ignored on receipt.













Hu, et al                                                      [Page 29]


INTERNET-DRAFT                                           BNG Simple CUSP


5.2.1.1 Access Types Table

      Value  Meaning
      -----  ---------
         1   PPP access (PPP)
         2   PPP over Ethernet over ATM access (PPPoEoA)
         3   PPP over ATM access (PPPoA)
         4   PPP over Ethernet access (PPPoE)
         5   PPPoE over VLAN access (PPPoEoVLAN)
         6   PPP over LNS access (PPPoLNS)
         7   IP over Ethernet DHCP access (IPoE_DHCP)
         8   IP over Ethernet EAP authentication access (IPoE_EAP)
         9   IP over Ethernet Layer 3 access (IPoE_L3)
        10   IP over Ethernet Layer 2 Static access (IPoE_L2_STATIC)
        11   Layer 2 Leased Line access (L2_Leased_Line)
        12   Layer 2 VPN Leased Line access (L2VPN_Leased_Line)
        13   Layer 3 Leased Line access (L3_Leased_Line)
        14   Layer 2 Leased line Sub-User access
                                           (L2_Leased_Line_SUB_USER)
        15   L2TP LAC tunnel access (L2TP_LAC)
        16   L2TP LNS tunnel access (L2TP_LNS)



5.2.2 User PPP Information TLV

   The User PPP Information TLV is defined to carry PPP information of a
   User, from a CP to an UP.

   The format of the TLV value part is as below:

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          User ID                              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |        MSS                    |        Reserved             |M|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |        MRU                    |        Reserved               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          Magic Number                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          Peer Magic Number                    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                     Figure 5.4: User PPP Information TLV

   Function:   PPP [RFC1661] information for a BNG user.
   TLV Type:   3
   TLV Length: 20 bytes in length


Hu, et al                                                      [Page 30]


INTERNET-DRAFT                                           BNG Simple CUSP


   TLV Fields:
    Name            Type     Description
   --------------  ------   ----------------------
   User-ID         4 bytes  User ID.
   MSS-Value       2 bytes  Indicates the MSS value.
   MSS-Enable      1 bit    Indicates whether the MSS is enabled. 0: The
                            function is disabled. 1: Enable
   MRU             2 bytes  PPoE local MRU.
   Magic-Number    4 bytes  Local magic number in PPP negotiation
                            packets.
   Peer-Magic-Number 4 bytes Remote peer magic number.

   The Reserved fields MUST be sent as zero and ignored on receipt.



5.3 User IPv4 Information TLV

   The User IPv4 Information TLV is defined to carry IPv4 related
   information for a BNG user.

   The format of the TLV value part is as below:

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          User ID                              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          User IPv4 Address                    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          Gateway IPv4 Address                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          MTU                  |   Reserved            |U|E|W|P|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ~                            sub-TLVs                           ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                    Figure 5.5: User IPv4 Information TLV

   Function:   IPv4 information for a BNG user.
   TLV Type:   4
   TLV Length: variable

   TLV fields:
    Name            Type     Description
   --------------  ------   ----------------------
   User-ID         4 bytes  User ID.
   User-IPv4       IPv4     User IPv4 address.
   Gateway-IPv4    IPv4     User gateway.
   Portal Force    1 bit    (P) Push advertisement switch, 0: off, 1:


Hu, et al                                                      [Page 31]


INTERNET-DRAFT                                           BNG Simple CUSP


                            on.
   Web-Force       1 bit    (W) IP4 Web push flag. 0: off, 1: on.
   Echo-Enable     1 bit    (E) Compatible with PPP/ARP and the UP
                            returns ARP Req or PPP Echo. 0: off, 1: on.
   IPv4-URPF       1 bit    (U) Unicast Reverse Path Forwarding (URPF)
                            flag of a user. 0: off, 1: on.
   MTU             2 bytes  MTU value. The default value is 1500.
   VRF-Name        Sub-TLV  VRF name.

   The Reserved field MUST be sent as zero and ignored on receipt.



5.4 User IPv6 Information

   The User IPv6 Information TLV is defined to carry IPv6 related
   information of a BNG user.

   The format of the TLV value part is as below:

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          User ID                              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ~                          User PD-Address                      ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ~                          Gateway ND-Address                   ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          User IANA Address                    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          IPv6 Interface ID                    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          IPv6 Interface ID (cont.)            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          MTU                  |   Reserved            |U|E|W|P|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ~                          sub-TLVs (VRF Name sub-TLV)          ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                    Figure 5.6: User IPv6 Information TLV

   Function:   IPv6 information for a BNG user.
   TLV Type:   5
   TLV Length: variable







Hu, et al                                                      [Page 32]


INTERNET-DRAFT                                           BNG Simple CUSP


   TLV fields:
    Name            Type     Description
   --------------  ------   ----------------------
   User-ID         4 bytes  User ID.
   PD-Address      IPv6     Prefix Delegation (PD) address.
   ND-Address      IPv6     Neighbor Discovery (ND) address.
   IANA-Address    IPv6     IANA address.
   Interface-ID    8 bytes  IPv6 interface ID.
   Portal Force    1 bit    (P) Push advertisement switch, 0: off, 1:
                            on.
   Web-Force       1 bit    (W) IP6 Web push flag. 0: off, 1: on.
   Echo-Enable     1 bit    (E) Compatible with PPP/ARP and the UP
                            returns ARP Req or PPP Echo. 0: off, 1: on.
   IPv6-URPF       1 bit    (U) User Reverse Path Forwarding (URPF) flag
                            of a user. 0: off, 1: on.
   MTU             2 bytes  MTU value. The default value is 1500.
   VRF-Name        Sub-TLV  VRF name.

   The Reserved field MUST be sent as zero and ignored on receipt.



5.5 User QoS Policy Information TLV

   The format of the TLV value part is as follows:

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          User ID                              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   I-Priority  |   E-Priority  |   Reserved                    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ~                          sub-TLVs                             ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                 Figure 5.7: User QoS Policy Information TLV

   Function:   BNG user authorization information.
   TLV Type:   6
   TLV length: variable in length

   TLV Fields:
    Name            Type     Description
   --------------  ------   ----------------------
   User-ID         4 bytes  User ID.
   Ingress-Priority 1 byte  Indicates the upstream priority. The value
                            is 0~7.
   Egress-Priority 1 byte   Indicates the downstream priority. The value
                            is 0~7.


Hu, et al                                                      [Page 33]


INTERNET-DRAFT                                           BNG Simple CUSP


   Ingress-CAR     Sub-TLV  Upstream CAR.
   Egress-CAR      Sub-TLV  Downstream CAR.
   Ingress-QoS-Profile Sub-TLV Indicates the name of the QoS-Profile
                            profile in the upstream direction.
   Egress-QoS-Profile Sub-TLV Indicates the name of the QoS-Profile
                            profile in the downstream direction.
   User-ACL-Policy Sub-TLV  All ACL user policies, including v4ACLIN,
                            v4ACLOUT, v6ACLIN, v6ACLOUT, v4WEBACL,
                            v6WEBACL, v4SpecialACL, and v6SpecialACL.
   Multicast-Profile4 Sub-TLV IPv4 multicast policy name.
   Multicast-Profile6 Sub-TLV IPv6 multicast policy name.
   NAT-Instance    Sub-TLV  Indicates the instance ID of a NAT user.

   The Reserved field MUST be sent as zero and ignored on receipt.



5.6 Routing Table TLVs



5.6.1 IPv4 Routing Information TLV

   The format of the TLV value part is as below:

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          User ID                              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          Dest-Address                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          Next-Hop                             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          Out-If-Index                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          Cost                                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          Tag                                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |        Route Type             |          Reserved           |A|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ~                          sub-TLVs                             ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                   Figure 5.8: IPv4 Routing Information TLV

   Function:   IPv4 routing information.
   TLV Type:   7
   TLV Length: Variable length


Hu, et al                                                      [Page 34]


INTERNET-DRAFT                                           BNG Simple CUSP


   TLV Fields:
    Name            Type     Description
   --------------  ------   ----------------------
   User-ID         4 bytes  User ID. This field is filled with all Fs
                            when a non-user route is delivered to the
                            UP.
   Dest-Address    IPv4     Destination address.
   Next-Hop        IPv4     Next hop address.
   Out-If-Index    4 bytes  Indicates the interface index.
   Cost            4 bytes  Cost value of the route.
   Tag             4 bytes  Route tag value.
   Route-Type      2 bytes  Route type. The options are as follows:
                            HOST_RT = 0 user host route
                            FRAME_RT = 1 Radius authorization FrameRoute
                            NET_RT = 2, network segment route
                            GATEWAY_RT = 3, gateway route
                            RADIUS_IP_RT = 4, Radius authorized IP route
                            LNS_USER_RT = 5 L2TP LNS side user route
   Advertise-Flag  1 bit    Indicates the route advertisement flag. 0:
                            Not advertised, 1: advertised.
   VRF-Name        Sub-TLV  VRF name.

   The Reserved field MUST be sent as zero and ignored on receipt.



5.6.2 IPv6 Routing Information TLV

   The format of the TLV value part is as follows:

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          User ID                              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ~                          IPv6 Dest-Address                    ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ~                          IPv6 Next-Hop                        ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          Out-If-Index                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          Cost                                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          Tag                                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |        Route Type             |          Reserved           |A|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ~                      VRF-Name sub-TLVs                        ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



Hu, et al                                                      [Page 35]


INTERNET-DRAFT                                           BNG Simple CUSP


                   Figure 5.9: IPv6 Routing Information TLV

   Function:   IPv4 routing information.
   TLV Type:   8
   TLV Length: Variable

   TLV Fields:
    Name            Type     Description
   --------------  ------   ----------------------
   User-ID         4 bytes  User ID. This field is filled with all Fs
                            when a non-user route is delivered to the
                            UP.
   Dest-Address    IPv6     Destination address.
   Next-Hop        IPv6     Next hop address.
   Out-If-Index    4 bytes  Indicates the interface index.
   Cost            4 bytes  Cost value of the route.
   Tag             4 bytes  Route tag value.
   Route-Type      2 bytes  Route type. The options are as follows:
                            HOST_RT = 0 user host route
                            FRAME_RT = 1 Radius authorization FrameRoute
                            NET_RT = 2, network segment route
                            GATEWAY_RT = 3, gateway route
                            RADIUS_IP_RT = 4, Radius authorized IP route
                            LNS_USER_RT = 5 L2TP LNS side user route
   Advertise-Flag  1 bit    Indicates the route advertisement flag. 0:
                            Not advertised, 1: advertised.
   VRF-Name        Sub-TLV  VRF name.

   The Reserved field MUST be sent as zero and ignored on receipt.



5.7 Static User Information TLVs



















Hu, et al                                                      [Page 36]


INTERNET-DRAFT                                           BNG Simple CUSP


5.7.1 Static IPv4 User Information TLV

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          If-Index                             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           C-VID               |           P-VID               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          User Address                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          Gateway Address                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          User MAC                             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |        User MAC (cont.)       |           Reserved            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ~                       VRF-Name sub-TLVs                       ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                Figure 5.10: Static IPv4 User Information TLV

   Function:   User information which is used proactively to detect
               and go on line.
   TLV Type:   9
   TLV Length: variable

   TLV Fields:
    Name            Type     Description
   --------------  ------   ----------------------
   If-Index        4 bytes  Indicates the interface index.
   C-VID           VLAN-ID  Indicates the inner VLAN ID. The value 0
                            indicates that the VLAN ID is invalid. The
                            valid value is 1~4094.
   P-VID           VLAN-ID  Outer VLAN ID. The value 0 indicates that
                            the VLAN ID is invalid. The format is the
                            same as that the C-VID. The valid value is
                            1~4094. For a single-layer VLAN, set this
                            parameter to PeVid.
   User Address    IPv4-Addr Terminal IP address.
   Gateway Address IPv4-Addr Gateway IP Address.
   User-MAC        MAC-Addr MAC address of the terminal.
   VRF-Name        Sub-TLV  VRF Name.

   The Reserved field MUST be sent as zero and ignored on receipt.







Hu, et al                                                      [Page 37]


INTERNET-DRAFT                                           BNG Simple CUSP


5.7.2 Static IPv6 User Information TLV

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          If-Index                             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           C-VID               |           P-VID               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ~                          User Address                         ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ~                          Gateway Address                      ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          User MAC                             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |        User MAC (cont.)       |           Reserved            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ~                          sub-TLVs                             ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                Figure 5.11: Static IPv6 User Information TLV

   Function:   User information which is used proactively to detect
               and go on line.
   TLV Type:   10
   TLV Length: variable

   TLV Fields:
    Name            Type     Description
   --------------  ------   ----------------------
   If-Index        4 bytes  Indicates the interface index.
   C-VID           VLAN-ID  Indicates the inner VLAN ID. The value 0
                            indicates that the VLAN ID is invalid. The
                            valid value is 1~4094.
   P-VID           VLAN-ID  Outer VLAN ID. The value 0 indicates that
                            the VLAN ID is invalid. The format is the
                            same as that the C-VID. The valid value is
                            1~4094. For a single-layer VLAN, set this
                            parameter to PeVid.
   User Address    IPv6-Addr User IP address.
   Gateway Address IPv6-Addr Gateway IP Address.
   User-MAC        MAC-Addr MAC address of the terminal.
   VRF-Name        Sub-TLV  VRF Name.

   The Reserved field MUST be sent as zero and ignored on receipt.







Hu, et al                                                      [Page 38]


INTERNET-DRAFT                                           BNG Simple CUSP


5.8 L2TP User Information TLVs



5.8.1 L2TP-LAC User Information TLV

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          User ID                              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      Local Tunnel ID          |     Local Session ID          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      Remote Tunnel ID         |     Remote Session ID         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 5.12: L2TP-LAC User Information TLV

   Function:   Information about the L2TP-LAC for a BNG user.
   TLV Type:   11
   TLV Length: 12

   TLV Fields:
   Name              Type     Description
   --------------    ------   ----------------------
   User-ID           4 bytes  The User identifier.
   Local-Tunnel-ID   2 bytes  The local ID of the L2TP tunnel.
   Local-Session-ID  2 bytes  The local session ID with the L2TP tunnel.
   Remote-Tunnel-ID  2 bytes  The remote ID of the L2TP tunnel.
   Remote-Session-ID 2 bytes  The remote session ID with the L2TP
                              tunnel.



5.8.2 L2TP-LNS User Information TLV

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          User ID                              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      Local Tunnel ID          |     Local Session ID          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      Remote Tunnel ID         |     Remote Session ID         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 5.13: L2TP-LNS User Information TLV





Hu, et al                                                      [Page 39]


INTERNET-DRAFT                                           BNG Simple CUSP


   Function:   Information about the L2TP tunnel for a BNG user.
   TLV Type:   12
   TLV Length: 12

   TLV Fields:
    Name             Type     Description
   --------------    ------   ----------------------
   User-ID           4 bytes  The User identifier.
   Local-Tunnel-ID   2 bytes  The local ID of the L2TP tunnel.
   Local-Session-ID  2 bytes  The local session ID with the L2TP tunnel.
   Remote-Tunnel-ID  2 bytes  The remote ID of the L2TP tunnel.
   Remote-Session-ID 2 bytes  The remote session ID with the L2TP
                              tunnel.



5.8.3 L2TP-LAC Tunnel TLV

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |       Local Tunnel ID         |       Remote Tunnel ID        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           Source Port         |        Destination Port       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ~                          Tunnel Source Address                ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ~                          Tunnel Destination Address           ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ~                       sub-TLVs (VRF Name sub-TLV)             ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                       Figure 5.14: L2TP-LAC Tunnel TLV

   Function:   Information about the L2TP tunnel for a BNG user.
   TLV Type:   13
   TLV Length: variable

   TLV Fields:
    Name           Type     Description
   --------------  ------   ----------------------
   Local-Tunnel-ID 2 bytes  The local ID of the L2TP tunnel.
   Remote-Tunnel-ID 2 bytes The remote ID of the L2TP tunnel.
   Source-Port     2 bytes  Indicates the source UDP port number of an
                            L2TP user.
   Dest-Port       2 bytes  Indicates the destination UDP port number of
                            an L2TP user.
   Source-IP       IPv4/v6  The source IP address of the tunnel.
   Dest-IP         IPv4/v6  The destination IP address of the tunnel.
   Tunnel-VRF-Name Sub-TLV  L2TP user tunnel VRG name.


Hu, et al                                                      [Page 40]


INTERNET-DRAFT                                           BNG Simple CUSP


5.8.4 L2TP-LNS Tunnel TLV

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |       Local Tunnel ID         |       Remote Tunnel ID        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           Source Port         |        Destination Port       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ~                          Tunnel Source Address                ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ~                          Tunnel Destination Address           ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ~                       sub-TLVs (VRF Name sub-TLV)             ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                       Figure 5.15: L2TP-LNS Tunnel TLV

   Function:   Information about the L2TP tunnel for a BNG user.
   TLV Type:   14
   TLV Length: variable

   TLV Fields:
    Name           Type     Description
   --------------  ------   ----------------------
   Local-Tunnel-ID 2 bytes  The local ID of the L2TP tunnel.
   Remote-Tunnel-ID 2 bytes The remote ID of the L2TP tunnel.
   Source-Port     2 bytes  Indicates the source UDP port number of an
                            L2TP user.
   Dest-Port       2 bytes  Indicates the destination UDP port number of
                            an L2TP user.
   Source-IP       IPv4/v6  The source IP address of the tunnel.
   Dest-IP         IPv4/v6  The destination IP address of the tunnel.
   Tunnel-VRF-Name Sub-TLV  L2TP user tunnel VRG name.



5.9 NAT User Information TLV

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                            User ID                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           NAT Port Start      |          NAT Port End         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                            NAT Address                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                    Figure 5.16: NAT User Information TLV


Hu, et al                                                      [Page 41]


INTERNET-DRAFT                                           BNG Simple CUSP


   Function:   NAT [RFC3022] public network information for a BNG user.
   TLV Type:   15
   TLV Length: 12

   TLV Fields:
    Name            Type     Description
   --------------  ------   ----------------------
   User-ID         4 bytes  User ID.
   NAT-Port-Start  2 bytes  NAT start port number.
   NAT-Port-End    2 bytes  NAT end port number.
   NAT-Sub-IP      4 bytes  NAT public network address.



5.10 Vendor Defined TLV

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           Vendor ID                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           Sub-Type            |       Sub-Type-Version        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ~                      sub-TLVs (optional)                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                       Figure 5.17: Vendor Defined TLV

   Function:   Used to indicate vendor, sub-type, and version for a
               Vendor Defined message.
   TLV Type:   1024
   TLV Length: variable

   TLV Fields:
   Name             Type     Description
   --------------  ------   ----------------------
   Vendor-ID       4 bytes  Vendor ID, which is defined in the RADIUS
                            [RFC2865].
   Sub-Type        2 bytes  Used by the Vendor to distinguish multiple
                            different vendor messages.
   Sub-Type-Version 2 bytes Used by the Vendor to dintinguish different
                            versions of a Vendor Defined message sub-
                            type.

   Since Vendor code will be handling the TLV after the Vendor ID field
   is recognized, the remainder of the TLV value can be organized
   however the vendor wants. But it desireable for a vendor to be able
   to define multiple different vendor messages and to keep track of
   different versions of its vendor defined messages. Thus, it is
   RECOMMENDED that the vendor assigne a Sub-Type value for each vendor


Hu, et al                                                      [Page 42]


INTERNET-DRAFT                                           BNG Simple CUSP


   message that it defines different from other Sub-Type values that
   vendor has used. Also, when modifying a vendor defined messages in a
   way potentially incompatible with a previous definition, the vendor
   SHOULD increase the value it is using in the Sub-Type-Version field.
















































Hu, et al                                                      [Page 43]


INTERNET-DRAFT                                           BNG Simple CUSP


6. Control TLVs



6.1 Hello TLV

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           Version                             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           Vendor ID                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                            Figure 6.1: Hello TLV

   Function:   Hello Message.
   TLV Type:   100
   TLV Length: 8

   TLV Fields:
    Name            Type     Description
   --------------  ------   ----------------------
   Version         4 bytes  Version number. Each bit corresponds to a
                            version. 0 is reserved and starts from 1.
   Vendor-ID       4 bytes  Vendor ID, which is defined in RADIUS
                            [RFC2865].



6.2 Error Information TLV

       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                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           Status Code                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                            Figure 6.2: Error TLV

   Function:   Error response.
   TLV Type:   101
   TLV Length: 8







Hu, et al                                                      [Page 44]


INTERNET-DRAFT                                           BNG Simple CUSP


   TLV Fields:
    Name            Type     Description
   --------------  ------   ----------------------
   Message-Type    4 bytes  Message category. Set this parameter to the
                            corresponding processing message code.
   Status-Code     4 bytes  Error Code (see Section 12.2.5).














































Hu, et al                                                      [Page 45]


INTERNET-DRAFT                                           BNG Simple CUSP


7. Resource Reporting TLVs



7.1 Interface Resource Information TLV

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          If-Index                             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          MAC Address (upper part)             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   MAC Address (lower part)    |   Phy-State   |   Reserved    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          MTU                                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ~                          sub-TLVs (optional)                  ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                      Figure 7.1: Interface Resource TLV

   Function:   BNG interface resource information.
   TLV Type:   200
   TLV Length: variable

   TLV Fields:
    Name            Type     Description
   --------------  ------   ----------------------
   If-Index        4 bytes  Indicates the interface index.
   MAC-Address     MAC-Addr Interface MAC address.
   Phy-State       1 byte   Physical status of the interface. 0: down,
                            1: Up
   MTU             4 bytes  Interface MTU value.

   The Reserved field MUST be sent as zero and ignored on receipt.



7.2 UP Board Status Report Information TLV

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Chassis     |   Slot        |   Sub-Slot    | Board-Type    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   State       |                  Reserved                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                      Figure 7.2: Interface Resource TLV


Hu, et al                                                      [Page 46]


INTERNET-DRAFT                                           BNG Simple CUSP


   Function:   Board information reported by the UP, including the
               board type and in-position status
   TLV Type:   201
   TLV Length: 8

   TLV Fields:
    Name            Type     Description
   --------------  ------   ----------------------
   Chassis         1 byte   Subrack number.
   Slot            1 byte   Slot number.
   Sub-Slot        1 byte   Sub-slot number.
   Board-Type      1 byte   1: CGN service card, 2: Interface board.
   State           1 byte   Board status  0: Normal, 1: Abnormal.

   The reserved field must be sent as zero and ignored on receipt.





































Hu, et al                                                      [Page 47]


INTERNET-DRAFT                                           BNG Simple CUSP


8. Event TLVs



8.1 User Traffic Statistics Report TLV

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                User-ID                                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                Statistics Type                                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                Ingress Packets (upper part)                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                Ingress Packets (lower part)                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                Ingress Bytes (upper part)                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                Ingress Bytes (lower part)                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                Ingress Loss Packets (upper part)              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                Ingress Loss Packets (lower part)              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                Ingress Loss Bytes (upper part)                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                Ingress Loss Bytes (lower part)                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                Egress Packets (upper part)                    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                Egress Packets (lower part)                    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                Egress Bytes (upper part)                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                Egress Bytes (lower part)                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                Egress Loss Packets (upper part)               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                Egress Loss Packets (lower part)               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                Egress Loss Bytes (upper part)                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                Egress Loss Bytes (lower part)                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                Figure 8.1: User Traffic Statistics Report TLV





Hu, et al                                                      [Page 48]


INTERNET-DRAFT                                           BNG Simple CUSP


   Function:   User traffic statistics report.
   TLV Type:   300
   TLV Length: 72

   TLV Fields:
    Name            Type     Description
   --------------  ------   ----------------------
   User-ID         4 bytes  User ID.
   Statistics-Type 4 bytes  Traffic type. The options are as follows: 0:
                            IPv4 traffic, 1: IPv6 traffic, 2: Dual stack
                            traffic.
   Ingress-Packets 8 bytes  Upstream traffic: number of packets
                            (UNIT64).
   Ingress-Bytes   8 bytes  Upstream traffic: byte count (UINT64).
   Ingress-Loss-Packets 8 bytes Upstream packet loss: number of data
                            packets (UNIT64).
   Ingress-Loss-Bytes 8 bytes Upstream packet loss: byte count (UINT64).
   Egress-Packets  8 bytes  Downstream traffic: number of packets
                            (UNIT64).
   Egress-Bytes    8 bytes  Downstream traffic: byte count (UINT64).
   Egress-Loss-Packets 8 bytes Downstream packet loss: number of data
                            packets (UNIT64).
   Egress-Loss-Bytes 8 bytes Downstream packet loss: byte count
                            (UINT64).



8.2 User Detection Result Report TLV

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          User-ID                              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Detect Type   | Detect Result |          Reserved             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                 Figure 8.2: User Detection Result Report TLV

   Function:   Report BNG user detection.
   TLV Type:   301
   TLV Length: 8

   TLV Fields:
    Name            Type     Description
   --------------  ------   ----------------------
   User-ID         4 bytes  User ID.
   Detect-Type     1 byte   0: IPv4 detection,
                            1: IPv6 detection,
                            2: PPP detection.


Hu, et al                                                      [Page 49]


INTERNET-DRAFT                                           BNG Simple CUSP


   Detect-Result   1 bytes  0: indicates that the detection is
                            successful, 1: Detection failure. The UP
                            needs report only when the detection fails.

   The Reserved field MUST be sent as zero and ignored on receipt.



8.3 User Basic Table Operation Result TLV

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          User-ID                              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Oper ID     |   Oper Code   |  Oper Result  |  Reserved     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Error Code                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                 Figure 8.3: User Detection Result Report TLV

   Function:   Report the operation result of a table update.
   TLV Type:   302
   TLV Length: 12

   TLV Fields:
    Name            Type     Description
   --------------  ------   ----------------------
   User-ID         4 bytes  User ID.
   Oper-ID         1 byte   When a user connection number, dual stack,
                            or Modify operation is performed, the
                            response message carries the ConnectID
                            carried in the following table. The CP
                            verifies the corresponding operation.
   Oper-Code       1 byte   Operation code. 1: update, 2: delete.
   Oper-Result     1 byte   Operation Result. 0: Success, Others:
                            Failure
   Error-Code      4 bytes  Operation failure cause code.  For details,
                            see Section 12.2.5.

   The Reserved field MUST be sent as zero and ignored on receipt.










Hu, et al                                                      [Page 50]


INTERNET-DRAFT                                           BNG Simple CUSP


9. Resource Allocation TLVs



9.1 Request Address Allocation TLV

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ~                          sub-TLV                              ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 9.1: Request Address Allocation TLV

   Function:   Request address allocation.
   TLV Type:   400
   TLV Length: variable

   TLV Fields:
    Name            Type     Description
   --------------  ------   ----------------------
   Pool-Name       Sub-TLV  Address pool name.



9.2 Address Assignment Response TLV

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Lease Time                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        IPv4 Addr and Mask                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        IPv4 Addr and Mask continued           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Result Code   |    Reserved   |                               ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+          sub-TLVs             |
      ~                                                               ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                 Figure 9.2: Address Assignment Response TLV

   Function:   The CGN sends a response to the address assignment
               request.
   TLV Type:   401
   TLV Length: variable





Hu, et al                                                      [Page 51]


INTERNET-DRAFT                                           BNG Simple CUSP


   TLV Fields:
    Name            Type     Description
   --------------  ------   ----------------------
   Lease-Time      4 bytes  Duration of address lease in seconds.
   Client-IP       IPv4-Addr Start address and mask of the address
                            segment.
   Result-Code     1 byte   Processing Result, 0: Success, 1: Failure
   Pool-Name       Sub-TLV  Address segment address pool name.



9.3 Address Renewal Request TLV

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     IPv4 Address and Mask                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     IPv4 Address and Mask continued           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ~                          sub-TLVs                             ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                   Figure 9.3: Request Address Renewal TLV

   Function:   Request address renewal.
   TLV Type:   402
   TLV Length: variable

   TLV fields:
    Name            Type     Description
   --------------  ------   ----------------------
   Client-IP       IPv4-Addr Start address and mask of the address
                            segment.
   Pool-Name       Sub-TLV  Address segment address pool name.

















Hu, et al                                                      [Page 52]


INTERNET-DRAFT                                           BNG Simple CUSP


9.4 Address Renewal Response TLV

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     IPv4 Address and Mask                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     IPv4 Address and Mask continued           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Result-Code  |  Reserved     |                               ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+         sub-TLVs              |
      ~                                                               ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                   Figure 9.4: Address Renewal Response TLV

   Function:   Request address renewal.
   TLV Type:   403
   TLV Length: variable

   TLV fields:
    Name            Type     Description
   --------------  ------   ----------------------
   Client-IP       IPv4-Addr Start address and mask of the address
                            segment.
   Result-Code     1 bytes  Processing Result, 0: Success, 1: Failure
   Pool-Name       Sub-TLV  Address segment address pool name.



9.5 Address Release Request TLV

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     IPv4 Address and Mask                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     IPv4 Address and Mask continued           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ~                          sub-TLVs                             ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                   Figure 9.5: Request Address Renewal TLV

   Function:   The CGN request the release of IP addresses.
   TLV Type:   404
   TLV Length: variable





Hu, et al                                                      [Page 53]


INTERNET-DRAFT                                           BNG Simple CUSP


   TLV fields:
    Name            Type     Description
   --------------  ------   ----------------------
   Client-IP       IPv4-Addr Start address and mask of the address
                            segment.
   Pool-Name       Sub-TLV  Address segment address pool name.



9.6 Address Release Response TLV

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     IPv4 Address and Mask                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     IPv4 Address and Mask continued           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Result-Code  |  Reserved     |                               ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+         sub-TLVs              |
      ~                                                               ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                   Figure 9.6: Address Renewal Response TLV

   Function:   Request address renewal.
   TLV Type:   405
   TLV Length: variable

   TLV fields:
    Name            Type     Description
   --------------  ------   ----------------------
   Client-IP       IPv4-Addr Start address and mask of the address
                            segment.
   Result-Code     4 bytes  Processing Result, 0: Success, 1: Failure
   Pool-Name       Sub-TLV  Address segment address pool name.
















Hu, et al                                                      [Page 54]


INTERNET-DRAFT                                           BNG Simple CUSP


10. Implementation Status

   This Section is NOT intended to appear in any resulting RFC.

   This section discusses the status of implementations that have
   provided information and the testing of this protocol at the time of
   posting of this Internet-Draft, and is based on the proposal in
   [RFC7942] ("Improving Awareness of Running Code: The Implementation
   Status Section").  The description of implementations in this section
   is intended to assist the IETF in its decision processes in
   progressing drafts to RFCs.  Please note that the listing of any
   individual implementation or test results here does not imply
   endorsement by the IETF.  Furthermore, no effort has been spent to
   verify the information presented here that was supplied by IETF
   contributors.  This is not intended as, and must not be construed to
   be, a catalog of available implementations or their testing or
   features.  Readers are advised to note that other implementations may
   exist.

   According to [RFC7942], "this will allow reviewers and working groups
   to assign due consideration to documents that have the benefit of
   running code, which may serve as evidence of valuable experimentation
   and feedback that have made the implemented protocols more mature.
   It is up to the individual working groups to use this information as
   they see fit".



10.1 Implementations

   Information on three S-CUSP implementations appears below.



10.1.1 Huawei Technologies

      Name: Cloud-based BNG.

      Maturity: Production.

      Coverage: According to S-CUSP protocol.

      Contact information:
            Zhouyi Yu: yuzhouyi@huawei.com

      Date: 2018-11-01






Hu, et al                                                      [Page 55]


INTERNET-DRAFT                                           BNG Simple CUSP


10.1.2 ZTE

      Name: ZXR10 V6000 vBRAS

      Maturity: Production

      Coverage: According to S-CUSP protocol.

      Contact information:
            Yong Chen: 10056167@zte.com.cn
            Huaibin Wang: 10008729@zte.com.cn

      Date: 2018-12-01



10.1.3 H3C

      Name: CUSP protocol for BRAS Control Plane and User Plan
      Separation

      Maturity: Research

      Coverage: According to S-CUSP protocol

      Contact information: mengdan@h3c.com; liuhanlei@h3c.com

      Date: 2019-1-30



10.2 Hackathon

   Successful use of the protocol at the IETF-102 Hackathon, Montreal,
   Quebec, in 2018.

      Hackathon Project: Control Plane and User Plane Separattion BNG
      control channel Protocol (CUSP)

      Champions: Zhenqiang Li, Michael Wang

      Report: See
      github.com/IETF-Hackathon/ietf102-project-presentations/blob/
         master/IETF102-hackathon-presentation-CUSP.pptx








Hu, et al                                                      [Page 56]


INTERNET-DRAFT                                           BNG Simple CUSP


10.3 EANTC Testing

   EANTC (European Advanced Networking Test Center (www.eantc.de))
   tested the Huawei implementation. Their summary was as follows:
   "EANTC tested advanced aspects of the Cloud-based Broadband Network
   Gateway (vBNG) with a focus on performance, scalability and high
   availability with up to 20 Million emulated subscribers. The solution
   performed very well across all test scenarios."

   See report at
   www.eantc.de/fileadmin/eantc/downloads/News/2018/EANTC-vBRAS-
   phase2.pdf








































Hu, et al                                                      [Page 57]


INTERNET-DRAFT                                           BNG Simple CUSP


11. Security Considerations

   The S-CUSP messages do not provide security. Thus, if these messages
   are exchanged in an environment where security is a concern, that
   security must be provided by another protocol such as TLS 1.3
   [RFC8446].














































Hu, et al                                                      [Page 58]


INTERNET-DRAFT                                           BNG Simple CUSP


12. IANA Considerations

   IANA is requested to perform the actions below in this section.



12.1 Service Name and Port Number

   IANA is requested to assign a service name and port for BNG S-CUSP as
   follows:

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



12.2 S-CUSP Parameters

   IANA is requested to create an "S-CUSP Parameters" web page and
   include thereon the registries set up in the Sub-Sections below.



12.2.1 Message Types

   IANA is requested to create an S-CUSP Message Types registry on the
   CUSP Parameters Web Page as follows:

   Registry Name: S-CUSP Message Types
   Registration Procedure: Expert Review
   Reference: [this document]

       Type      Name                 Reference
      ------    -----------          ---------------
          0      - Reserved
          1     Hello                [this document]
          2     Keepalive            [this document]
          3     Sync_Request         [this document]
          4     Sync_Begin           [this document]
          5     Sync_Data            [this document]
          6     Sync_End             [this document]
          7     Update_Request       [this document]
          8     Update_Response      [this document]
          9     Report               [this document]
         10     Event                [this document]
         11     Vendor               [this document]


Hu, et al                                                      [Page 59]


INTERNET-DRAFT                                           BNG Simple CUSP


      12-199     - Unassigned
        200     Addr_Allocation_Req  [this document]
        201     Addr_Allocation_Ack  [this document]
        202     Addr_Renew_Req       [this document]
        203     Addr_Renew_Ack       [this document]
        204     Addr_Release_Req     [this document]
        205     Addr_Release_Ack     [this document]
      206-254    - Unassigned
        255      - Reserved



12.2.2 TLV Types

   IANA is requested to create an S-CUSP TLV Types registry on the S-
   CUSP Parameters Web Page as follows:

   Registry Name: S-CUSP TLV Types
   Registration Procedure: Expert Review
   Reference: [this document]

      Type     Name           Usage Description
     ------   ------------   --------------------------
         1   Access-IfSrv     Service information about the user access
                              interface on the BNG.
         2   User-Basic       Basic information about a BNG user.
         3   User-PPP         PPP information about a BNG user.
         4   User-IPv4        IPv4 address of a BNG user.
         5   User-IPv6        IPv6 address of a BNG user.
         6   User-Auth        QoS authorization information of a BNG
                              user.
         7   RouteV4-Info     BNG IPv4 routing information.
         8   RouteV6-Info     BNG IPv6 routing information.
         9   Static-IPv4-User Static user information on a BNG. Used to
                              proactively detect and go online.
        10   Static-IPv6-User Static user information on a BNG. Used to
                              proactively detect and go online.
        11   User-L2TP-LAC    L2TP LAC user information.
        12   User-L2TP-LNS    L2TP LNS user information.
        13   User-L2TP-LAC-Tnl L2TP LAC tunnel information.
        14   User-L2TP-LNS-Tnl L2TP LNS tunnel information.
        15   User-NAT         Public network segment information for a
                              NAT user.
     16-99   unassigned
       100   Hello-Info       The CP and UP advertise versions to each
                              other
       101   Error-Info       The Ack of the control message carries the
                              processing result, success, or error.
     102-199 unassigned       -
       200   Interface-Info   Interfaces reported by the UP including


Hu, et al                                                      [Page 60]


INTERNET-DRAFT                                           BNG Simple CUSP


                              physical interfaces, sub-interfaces, trunk
                              interfaces, and tunnel interfaces.
       201   Board-Info       Board information reported by the UP
                              including the board type and in-position
                              status.
     202-299 unassigned       -
       300   Traffic-Info     User traffic statistics.
       301   Detect-Info      User detection information.
       302   User-TBL-Result  Processing result of user forwarding table
                              delivery.
     303-299 unassigned       -
       400   Addr-Alloc-Req   Request address allocation.
       401   Addr-Alloc-Ack   Address allocation response.
       402   Addr-Renew-Req   Request for address lease renewal.
       403   Addr-Renew-Ack   Response to a request for extending an IP
                              address lease.
       404   Addr-Release-Req Request to release the address.
       405   Addr-Release-Ack Ack of a message releasing an IP address.
     406-1023 unassigned      -
      1024   Vendor-Defined   As implemented by vendor.
     1025-65535 unassigned    -



12.2.3 TLV Operation Codes

   IANA is requested to create an S-CUSP TLV Operation Codes registry on
   the S-CUSP Parameters Web Page as follows:

   Registry Name: S-CUSP TLV Operation Codes
   Registration Procedure: Expert Review
   Reference: [this document]

      Code  Operation     Reference
      ----  ----------    ---------
         0  - reserved
         1  Update        [this document]
         2  Delete        [this document]
      3-15  - unassigned



12.2.4 Sub-TLV Types

   IANA is requested to create a S-CUSP Sub-TLV Types registry on the S-
   CUSP Parameters Web Page as follows:

   Registry Name: S-CUSP Sub-TLV Types
   Registration Procedure: Expert Review
   Reference: [this document]


Hu, et al                                                      [Page 61]


INTERNET-DRAFT                                           BNG Simple CUSP


      Code    Operation            Reference
      -----  ------------------   ---------------
         0   - reserved
         1   VRF Name             [this document]
         2   Ingress-QoS-Profile  [this document]
         3   Egress-QoS-Profile   [this document]
         4   User-ACL-Policy      [this document]
         5   Multicast-ProfileV4  [this document]
         6   Multicast-ProfileV6  [this document]
         7   Ingress-CAR          [this document]
         8   Egress-CAR           [this document]
         9   NAT-Instance         [this document]
        10   Pool-Name            [this document]
        11   If-Desc              [this document]
      12-64534  - unassigned
      65535  -reserved



12.2.5 ERRID Codes

   IANA is requested to create an S-CUSP ERRID Codes registry on the S-
   CUSP Parameters Web Page as follows:

   Registry Name: S-CUSP ERRID Codes
   Registration Procedure: Expert Review
   Reference: [this document]

   Value     Name             Remarks
   ------   -------          --------
       0    Success          Success
       1    Fail             Failure. The reason is not classified.
       2    TLV-Unknown      The TVL type cannot be identified.
       3    TLV-Length       The TLV length is abnormal.
       4    TLV-Value        The TLV value is abnormal
   5-999     - unassigned    Unassigned basic error codes.
    1000     - reserved
    1001    Version-Mismatch The version negotiation fails. Terminate.
                             The subsequent service processes
                             corresponding to the UP are suspended.
   1002-1999 - unassigned    Unassigned version negotiation error codes.
    2000     - reserved
    2001    Synch-NoReady    The data to be smoothed is not ready.
    2002    Synch-Unsupport  The request for smooth data is not
                             supported.
   2003-2999  - unassigned   Unassigned data synchronization error
                             codes.
    3000     - reserved
    3001    Pool-Mismatch    The corresponding address pool cannot be
                             found.


Hu, et al                                                      [Page 62]


INTERNET-DRAFT                                           BNG Simple CUSP


    3002    Pool-Full        The address pool is fully allocated and no
                             address segment is available.
    3003    Subnet-Mismatch  The address pool subnet cannot be found.
    3004    Subnet-Conflict  Subnets in the address pool have been
                             classified into other clients.
   3005-3999  - unassigned   Unassigned address allocation error codes,
                             used in NAT address allocation.
    4000     - reserved
    4001    Update-Fail-No-Res  The forwarding table fails to be
                             delivered because the forwarding resources
                             are insufficient.
    4002    QoS-Update-Success  The QoS policy takes effect.
    4003    QoS-Update-Sq-Fail  Failed to process the queue in the QoS
                             policy.
    4004    QoS-Update-CAR-Fail  Processing of the CAR in the QoS policy
                             fails.
    4005    Statistic-Fail-No-Res  Statistics processing failed due to
                             insufficient statistics resources.
   4006-4999  - unassigned forwarding table delivery error codes.
   5000-4294967295  - reserved
































Hu, et al                                                      [Page 63]


INTERNET-DRAFT                                           BNG Simple CUSP


Contributors

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

      Email: wangzitao@huawei.com











































Hu, et al                                                      [Page 64]


INTERNET-DRAFT                                           BNG Simple CUSP


Normative References

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

   [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
             "Remote Authentication Dial In User Service (RADIUS)", RFC
             2865, DOI 10.17487/RFC2865, June 2000, <https://www.rfc-
             editor.org/info/rfc2865>.

   [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

   [SCUSP-architecture] Hu, S., Qin, G. Li, Z., Chua, T., Lopez, V.,
             Eastlake, D., Wang, Z., and J. Song, "Architecture for
             Control Plane and User Plane Separated BNG",
             draft-cuspdt-rtgwg-cu-separation-bng-architecture-03 (work
             in progress), December 2018.

   [SCUSP-YANG] Huang, G., Hu, F., Hu, S., and F. Fangwei, "YANG Data
             Model for Configuration Interface of Control-Plane and
             User-Plane separation BNG",
             draft-cuspdt-rtgwg-cu-separation-yang-model (work in
             progress), January 2019.

   [RFC1661] Simpson, W., Ed., "The Point-to-Point Protocol (PPP)", STD
             51, RFC 1661, DOI 10.17487/RFC1661, July 1994,
             <https://www.rfc-editor.org/info/rfc1661>.

   [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network
             Address Translator (Traditional NAT)", RFC 3022, DOI
             10.17487/RFC3022, January 2001, <https://www.rfc-
             editor.org/info/rfc3022>

   [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group
             MIB", RFC 2863, DOI 10.17487/RFC2863, June 2000,

   [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
             Code: The Implementation Status Section", BCP 205, RFC
             7942, DOI 10.17487/RFC7942, July 2016, <https://www.rfc-
             editor.org/info/rfc7942>.



Hu, et al                                                      [Page 65]


INTERNET-DRAFT                                           BNG Simple CUSP


   [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
             Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
             <https://www.rfc-editor.org/info/rfc8446>.

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














































Hu, et al                                                      [Page 66]


INTERNET-DRAFT                                           BNG Simple CUSP


Authors' Addresses

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

      Email: hushujun@chinamobile.com


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

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


      Mach Chen
      Huawei Technologies
      Huawei Bldg., No. 156 Beiqing Road
      Beijing 100095 China

      Email: mach.chen@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







Hu, et al                                                      [Page 67]


INTERNET-DRAFT                                           BNG Simple CUSP


      Jun Song
      Huawei Technologies
      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 68]


INTERNET-DRAFT                                           BNG Simple CUSP


Copyright, Disclaimer, and Additional IPR Provisions

   Copyright (c) 2019 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 69]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/