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

Versions: (draft-cuspdt-rtgwg-cu-separation-bng-protocol) 00 01 02 03 04

Network Working Group                                              S. Hu
Internet-Draft                                              China Mobile
Intended status: Informational                               D. Eastlake
Expires: December 5, 2019                                        M. Chen
                                                     Huawei Technologies
                                                                  F. Qin
                                                                   Z. Li
                                                            China Mobile
                                                                 T. Chua
                                    Singapore Telecommunications Limited
                                                                D. Huang
                                                                     ZTE
                                                           June 03, 2019


  The China Mobile, Huawei, and ZTE BNG Simple Control and User Plane
                      Separation Protocol (S-CUSP)
             draft-chz-simple-cu-separation-bng-protocol-00

Abstract

   To support Control Plane (CP) and User Plane (UP) Separation (CUPS)
   for fixed network Broadband Network Gateway (BNG) service providers,
   China Mobile, Huawei Technologies, and ZTE have developed a simple
   CUPS control channel Protocol (S-CUSP).  This document is intended to
   make the S-CUSP specification conveniently available to the Internet
   community.

Status of This Memo

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

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on November 24, 2019.







Hu, et al.              Expires November 24, 2019               [Page 1]


Internet-Draft               S-CUSP for BNG                     May 2019


Copyright Notice

   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
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   5
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   5
   3.  BNG CUPS Overview . . . . . . . . . . . . . . . . . . . . . .   8
     3.1.  BNG CUPS Motivation . . . . . . . . . . . . . . . . . . .   8
     3.2.  BNG CUPS Architecture Overview  . . . . . . . . . . . . .   8
     3.3.  BNG CUPS Interfaces . . . . . . . . . . . . . . . . . . .  10
       3.3.1.  Service Interface . . . . . . . . . . . . . . . . . .  11
       3.3.2.  Management Interface  . . . . . . . . . . . . . . . .  11
       3.3.3.  Control Interface . . . . . . . . . . . . . . . . . .  11
     3.4.  BNG CUPS Procedure Overview . . . . . . . . . . . . . . .  12
   4.  S-CUSP Protocol Overview  . . . . . . . . . . . . . . . . . .  14
     4.1.  Control Channel Related Procedures  . . . . . . . . . . .  14
       4.1.1.  S-CUSP Session Establishment  . . . . . . . . . . . .  14
       4.1.2.  Keep Alive  . . . . . . . . . . . . . . . . . . . . .  16
     4.2.  Node Related Procedures . . . . . . . . . . . . . . . . .  16
       4.2.1.  UP Board and Interface Status Report  . . . . . . . .  16
       4.2.2.  Enable BAS Function on Access Interface . . . . . . .  17
       4.2.3.  Advertise Subscriber Network Routing  . . . . . . . .  17
       4.2.4.  CGN Public IP Address Allocation  . . . . . . . . . .  18
       4.2.5.  Data Synchronization Between CP and UP  . . . . . . .  19
     4.3.  Subscriber Session Related Procedures . . . . . . . . . .  20
       4.3.1.  Create Subscriber Session . . . . . . . . . . . . . .  21
       4.3.2.  Update Subscriber Session . . . . . . . . . . . . . .  22
       4.3.3.  Delete Subscriber Session . . . . . . . . . . . . . .  23
       4.3.4.  Subscriber Session Events Report  . . . . . . . . . .  23
   5.  S-CUSP Call Flows . . . . . . . . . . . . . . . . . . . . . .  24
     5.1.  IPoE  . . . . . . . . . . . . . . . . . . . . . . . . . .  24
       5.1.1.  DHCPv4 Access . . . . . . . . . . . . . . . . . . . .  24
       5.1.2.  DHCPv6 Access . . . . . . . . . . . . . . . . . . . .  26
       5.1.3.  IPv6 SLAAC Access . . . . . . . . . . . . . . . . . .  28
       5.1.4.  DHCPv6 + SLAAC Access . . . . . . . . . . . . . . . .  30



Hu, et al.              Expires November 24, 2019               [Page 2]


Internet-Draft               S-CUSP for BNG                     May 2019


       5.1.5.  DHCP Dual Stack Access  . . . . . . . . . . . . . . .  32
       5.1.6.  L2 Static Subscriber Access . . . . . . . . . . . . .  35
     5.2.  PPPoE . . . . . . . . . . . . . . . . . . . . . . . . . .  37
       5.2.1.  IPv4 PPPoE Access . . . . . . . . . . . . . . . . . .  37
       5.2.2.  IPv6 PPPoE Access . . . . . . . . . . . . . . . . . .  39
       5.2.3.  PPPoE Dual Stack Access . . . . . . . . . . . . . . .  41
     5.3.  WLAN Access . . . . . . . . . . . . . . . . . . . . . . .  43
     5.4.  L2TP  . . . . . . . . . . . . . . . . . . . . . . . . . .  46
       5.4.1.  L2TP LAC Access . . . . . . . . . . . . . . . . . . .  46
       5.4.2.  L2TP LNS IPv4 Access  . . . . . . . . . . . . . . . .  47
       5.4.3.  L2TP LNS IPv6 Access  . . . . . . . . . . . . . . . .  49
     5.5.  CGN (Carrier Grade NAT) . . . . . . . . . . . . . . . . .  52
     5.6.  L3 Leased Line Access . . . . . . . . . . . . . . . . . .  54
       5.6.1.  Web Authentication  . . . . . . . . . . . . . . . . .  54
       5.6.2.  User Traffic Trigger  . . . . . . . . . . . . . . . .  57
     5.7.  Multicast Access  . . . . . . . . . . . . . . . . . . . .  58
   6.  S-CUSP Message Formats  . . . . . . . . . . . . . . . . . . .  60
     6.1.  Common Message Header . . . . . . . . . . . . . . . . . .  60
     6.2.  Control Messages  . . . . . . . . . . . . . . . . . . . .  61
       6.2.1.  Hello Message . . . . . . . . . . . . . . . . . . . .  61
       6.2.2.  Keepalive Message . . . . . . . . . . . . . . . . . .  62
       6.2.3.  Synch_Request Message . . . . . . . . . . . . . . . .  62
       6.2.4.  Sync_Begin Message  . . . . . . . . . . . . . . . . .  62
       6.2.5.  Sync_Data Message . . . . . . . . . . . . . . . . . .  63
       6.2.6.  Sync_End Message  . . . . . . . . . . . . . . . . . .  64
       6.2.7.  Update_Request Message  . . . . . . . . . . . . . . .  64
       6.2.8.  Update_Response Message . . . . . . . . . . . . . . .  64
     6.3.  Event Message . . . . . . . . . . . . . . . . . . . . . .  65
     6.4.  Report Message  . . . . . . . . . . . . . . . . . . . . .  66
     6.5.  CGN Messages  . . . . . . . . . . . . . . . . . . . . . .  66
       6.5.1.  Addr_Allocation_Req Message . . . . . . . . . . . . .  66
       6.5.2.  Addr_Allocation_Ack Message . . . . . . . . . . . . .  66
       6.5.3.  Addr_Renew_Req Message  . . . . . . . . . . . . . . .  66
       6.5.4.  Addr_Renew_Ack Message  . . . . . . . . . . . . . . .  67
       6.5.5.  Addr_Release_Req Message  . . . . . . . . . . . . . .  67
       6.5.6.  Addr_Release_Ack Message  . . . . . . . . . . . . . .  67
     6.6.  Vendor Message  . . . . . . . . . . . . . . . . . . . . .  67
   7.  S-CUSP TLVs and Sub-TLVs  . . . . . . . . . . . . . . . . . .  67
     7.1.  Common TLV Header . . . . . . . . . . . . . . . . . . . .  68
     7.2.  Basic Data Fields . . . . . . . . . . . . . . . . . . . .  68
     7.3.  Sub-TLV Format and Sub-TLVs . . . . . . . . . . . . . . .  69
       7.3.1.  Name sub-TLVs . . . . . . . . . . . . . . . . . . . .  70
       7.3.2.  Ingress-CAR sub-TLV . . . . . . . . . . . . . . . . .  70
       7.3.3.  Egress-CAR sub-TLV  . . . . . . . . . . . . . . . . .  71
       7.3.4.  If-Desc sub-TLV . . . . . . . . . . . . . . . . . . .  71
       7.3.5.  IPv6 Address List sub-TLV . . . . . . . . . . . . . .  73
     7.4.  The Hello TLV . . . . . . . . . . . . . . . . . . . . . .  73
     7.5.  The Keep Alive TLV  . . . . . . . . . . . . . . . . . . .  75



Hu, et al.              Expires November 24, 2019               [Page 3]


Internet-Draft               S-CUSP for BNG                     May 2019


     7.6.  The Error Information TLV . . . . . . . . . . . . . . . .  75
     7.7.  BAS Function Enabler TLV  . . . . . . . . . . . . . . . .  76
     7.8.  Routing TLVs  . . . . . . . . . . . . . . . . . . . . . .  79
       7.8.1.  IPv4 Routing TLV  . . . . . . . . . . . . . . . . . .  79
       7.8.2.  IPv6 Routing TLV  . . . . . . . . . . . . . . . . . .  80
     7.9.  Subscriber TLVs . . . . . . . . . . . . . . . . . . . . .  82
       7.9.1.  Basic Subscriber TLV  . . . . . . . . . . . . . . . .  82
       7.9.2.  PPP Subscriber TLV  . . . . . . . . . . . . . . . . .  85
       7.9.3.  IPv4 Subscriber TLV . . . . . . . . . . . . . . . . .  86
       7.9.4.  IPv6 Subscriber TLV . . . . . . . . . . . . . . . . .  87
       7.9.5.  IPv4 Static Subscriber TLV  . . . . . . . . . . . . .  89
       7.9.6.  IPv6 Static Subscriber TLV  . . . . . . . . . . . . .  90
       7.9.7.  L2TP-LAC Subscriber TLV . . . . . . . . . . . . . . .  91
       7.9.8.  L2TP-LNS Subscriber TLV . . . . . . . . . . . . . . .  92
       7.9.9.  L2TP-LAC Tunnel TLV . . . . . . . . . . . . . . . . .  93
       7.9.10. L2TP-LNS Tunnel TLV . . . . . . . . . . . . . . . . .  94
       7.9.11. Session Update Response TLV . . . . . . . . . . . . .  95
       7.9.12. Subscriber Policy TLV . . . . . . . . . . . . . . . .  95
       7.9.13. Subscriber CGN Port Range TLV . . . . . . . . . . . .  97
     7.10. Device Status TLVs  . . . . . . . . . . . . . . . . . . .  97
       7.10.1.  Interface Status TLV . . . . . . . . . . . . . . . .  97
       7.10.2.  Board Status TLV . . . . . . . . . . . . . . . . . .  98
     7.11. CGN TLVs  . . . . . . . . . . . . . . . . . . . . . . . .  99
       7.11.1.  Address Allocation Request TLV . . . . . . . . . . .  99
       7.11.2.  Address Allocation Response TLV  . . . . . . . . . . 100
       7.11.3.  Address Renewal Request TLV  . . . . . . . . . . . . 101
       7.11.4.  Address Renewal Response TLV . . . . . . . . . . . . 102
       7.11.5.  Address Release Request TLV  . . . . . . . . . . . . 103
       7.11.6.  Address Release Response TLV . . . . . . . . . . . . 103
     7.12. Event TLVs  . . . . . . . . . . . . . . . . . . . . . . . 104
       7.12.1.  Subscriber Traffic Statistics TLV  . . . . . . . . . 104
       7.12.2.  Subscriber Detection Result TLV  . . . . . . . . . . 106
     7.13. Vendor TLV  . . . . . . . . . . . . . . . . . . . . . . . 107
   8.  Implementation Status . . . . . . . . . . . . . . . . . . . . 108
     8.1.  Implementations . . . . . . . . . . . . . . . . . . . . . 108
       8.1.1.  Huawei Technologies . . . . . . . . . . . . . . . . . 109
       8.1.2.  ZTE . . . . . . . . . . . . . . . . . . . . . . . . . 109
       8.1.3.  H3C . . . . . . . . . . . . . . . . . . . . . . . . . 109
     8.2.  Hackathon . . . . . . . . . . . . . . . . . . . . . . . . 109
     8.3.  EANTC Testing . . . . . . . . . . . . . . . . . . . . . . 110
   9.  Summary of Major S-CUSP Codepoints  . . . . . . . . . . . . . 110
     9.1.  Message Types . . . . . . . . . . . . . . . . . . . . . . 110
     9.2.  TLV Types . . . . . . . . . . . . . . . . . . . . . . . . 111
     9.3.  TLV Operation Codes . . . . . . . . . . . . . . . . . . . 112
     9.4.  Sub-TLV Types . . . . . . . . . . . . . . . . . . . . . . 112
     9.5.  Error Codes . . . . . . . . . . . . . . . . . . . . . . . 113
   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 115
   11. Security Considerations . . . . . . . . . . . . . . . . . . . 115



Hu, et al.              Expires November 24, 2019               [Page 4]


Internet-Draft               S-CUSP for BNG                     May 2019


   12. Contributors  . . . . . . . . . . . . . . . . . . . . . . . . 115
   13. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . 116
   14. Informative References  . . . . . . . . . . . . . . . . . . . 116
   Appendix A.  An Appendix  . . . . . . . . . . . . . . . . . . . . 117
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . 117

1.  Introduction

   A fixed network 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.

   S-CUSP was designed by China Mobile, Huawei Technologies, and ZTE,
   has been implemented by Huawei Technologies, ZTE, and H3C, and has
   been deployed by China Mobile.

2.  Terminology

   This section specifies acronyms used in this document.

   AAA: Authentication Authorization Accounting.

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




Hu, et al.              Expires November 24, 2019               [Page 5]


Internet-Draft               S-CUSP for BNG                     May 2019


   BAS:Broadband ACCESS Service.

   CAR: Committed Access Rate.

   CBS: Committed Burst Size.

   CGN: Carrier Grade NAT.

   Ci: Control Interface.

   CIR: Committed Information Rate.

   CoA: Change of Authorization.

   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.

   CPE: Customer Premises Equipment.

   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).) [802.1Q]

   DHCP: Dynamic Host Configuration Protocol [RFC2131].

   dial-up: This refers to the initial connection messages when a new
   user appears.  The name is left over from when users literally dialed
   up on a modem equipped phone line but herein is applied to other
   initial connection techniques.  Initial connection is frequently
   indicated by the receipt of packets over PPPoE or IPoE.

   EMS: Element Management System.

   IPoE: IP over Ethernet.

   L2TP: Layer 2 Tunneling Protocol [RFC2661].

   LAC: L2TP Access Concentrator.

   LNS: L2TP Network Server.




Hu, et al.              Expires November 24, 2019               [Page 6]


Internet-Draft               S-CUSP for BNG                     May 2019


   MAC: 48-bit Media Access Control address [RFC7042].

   MANO: Management and Orchestration.

   Mi: Management Interface.

   MSS: Maximum Segment Size.

   MRU: Maximum Receive Unit.

   NAT: Network Address Translation [RFC3022].

   ND: Neighbor Discovery.

   NFV: Network Function Virtualization.

   NFVI: NFV Infrastructure

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

   VRF: Virtual Routing and Forwarding.








Hu, et al.              Expires November 24, 2019               [Page 7]


Internet-Draft               S-CUSP for BNG                     May 2019


3.  BNG CUPS Overview

3.1.  BNG CUPS Motivation

   The rapid development of new services, such as 4K TV, IoT, etc., and
   increasing numbers of home broadband service users present some new
   challenges for BNGs such as:

      Low resource utilization: The traditional BNG acts as both a
      gateway for user access authentication and accounting and an IP
      network's Layer 3 edge.  The mutually affecting nature of the
      tightly coupled control plane and forwarding plane makes it
      difficult to achieve the maximum performance of either plane.

      Complex management and maintenance: Due to the large numbers of
      traditional BNGs, configuring each device in a network is very
      tedious when deploying global service policies.  As the network
      expands and new services are introduced, this deployment mode will
      cease to be feasible as it is unable to manage services
      effectively and rectify faults rapidly.

      Slow service provisioning: The coupling of control plane and
      forwarding plane, in addition to a distributed network control
      mechanism, means that any new technology has to rely heavily on
      the existing network devices.

   To address these challenges for fixed networks, the framework for a
   cloud-based BNG with Control-Plane and User-Plane (CU) separation is
   described in [TR-384].  The main idea of CU separation is to extract
   and centralize the user management functions of multiple BNG devices,
   forming a unified and centralized Control Plane (CP).  And the
   traditional router's Control Plane and Forwarding Plane are both
   preserved on BNG devices in the form of a User Plane (UP).  Note that
   the CU separation concept has also been introduced in the 3GPP 5G
   architecture [3GPP.23.501].

3.2.  BNG CUPS Architecture Overview

   The functions in a traditional BNG can be divided into two parts: one
   is the user access management function, the other is the router
   function.  In a cloud-based BNG, we find that splitting these two
   functions apart can make a difference.  The user management function
   can be centralized and deployed as a concentrated module or device,
   called the BNG-CP (Control Plane).  The other functions, such as the
   router function and forwarding engine, can be deployed in the form of
   the BNG User Plane.  Thus, the Cloud-based BNG architecture is made
   up of Control Plane and User Plane.




Hu, et al.              Expires November 24, 2019               [Page 8]


Internet-Draft               S-CUSP for BNG                     May 2019


   The following figure shows the architecture of CU separated BNG:

    +------------------------------------------------------------------+
    |        Neighboring policy and resource management systems        |
    |                                                                  |
    |   +-------------+   +-----------+   +---------+   +----------+   |
    |   |AAA    Server|   |DHCP Server|   |   EMS   |   |   MANO   |   |
    |   +-------------+   +-----------+   +---------+   +----------+   |
    +------------------------------------------------------------------+

    +------------------------------------------------------------------+
    |                       CU-separated BNG system                    |
    | +--------------------------------------------------------------+ |
    | |   +----------+  +----------+ +------++------++-----------+   | |
    | |   | Address  |  |Subscriber| | AAA  ||PPPoE/||    UP     |   | |
    | |   |management|  |management| |      ||IPoE  ||management |   | |
    | |   +----------+  +----------+ +------++------++-----------+   | |
    | |                              CP                              | |
    | +--------------------------------------------------------------+ |
    |                                                                  |
    |                                                                  |
    |                                                                  |
    | +---------------------------+      +--------------------------+  |
    | |  +------------------+     |      |  +------------------+    |  |
    | |  | Routing control  |     |      |  | Routing control  |    |  |
    | |  +------------------+     | ...  |  +------------------+    |  |
    | |  +------------------+     |      |  +------------------+    |  |
    | |  |Forwarding engine |     |      |  |Forwarding engine |    |  |
    | |  +------------------+  UP |      |  +------------------+  UP|  |
    | +---------------------------+      +--------------------------+  |
    +------------------------------------------------------------------+
               Figure 3.1:  Architecture of CU Separated BNG

   As shown in Figure 3.1, the BNG Control Plane could be virtualized
   and centralized, which provides benefits such as centralized session
   management, flexible address allocation, high scalability for
   subscriber management capacity, and cost-efficient redundancy, etc.
   The functional components inside the BNG Service Control Plane can be
   implemented as Virtual Network Functions (VNFs) and hosted in a
   Network Function Virtualization Infrastructure (NFVI).

   The User Plane Management module in the BNG Control Plane centrally
   manages the distributed BNG User Planes (e.g. load balancing), as
   well as the setup, deletion, and maintenance of channels between
   Control Planes and User Planes.  Other modules in the BNG control
   plane, such as address management, AAA, etc., are responsible for the
   connection with outside subsystems in order to fulfill those
   services.  Note that the User Plane shouldsupport both physical and



Hu, et al.              Expires November 24, 2019               [Page 9]


Internet-Draft               S-CUSP for BNG                     May 2019


   virtual network functions.  For example, BNG user plane L3 forwarding
   related network functions can be disaggregated and distributed across
   the physical infrastructure.  And the other control plane and
   management plane functions in the CU Separation BNG can be moved into
   the NFVI for virtualization [TR-384].

   The details of CU separated BNG's function components are as
   following:

   The Control Plane should support:

   1.  Address management: unified address pool management and CGN
       subscriber address traceability management.

   2.  AAA: This component performs Authentication, Authorization and
       Accounting, together with RADIUS/DIAMETER.  The BNG communicates
       with the AAA server to check whether the subscriber who sent an
       Access-Request has network access authority.  Once the subscriber
       goes online, this component together with the Service Control
       component implement accounting, data capacity limitation, and QoS
       enforcement policies.

   3.  Subscriber management: user entry management and forwarding
       policy management.

   4.  PPPoE/IPoE: process user dial-up packets via PPPoE/IPoE.

   5.  UP management: management of UP interface status, and the setup,
       deletion, and maintenance of channels between CP and UP.

   The User Plane should support:

   1.  Control plane functions including routing, multicast, and MPLS.

   2.  Forwarding plane functions including traffic forwarding, QoS and
       traffic statistics collection.

   3.  Subscriber detection, to detect whether an subscriber is still
       online.

3.3.  BNG CUPS Interfaces

   To support the communication between the Control Plane and User
   Plane, three interfaces are defined.  These are referred to as the
   Control Interface (Ci), Service Interface (Si) and Management
   Interface (Mi) as shown in Figure 3.2.





Hu, et al.              Expires November 24, 2019              [Page 10]


Internet-Draft               S-CUSP for BNG                     May 2019


                +-----------------------------------+
                |                                   |
                |               BNG-CP              |
                |                                   |
                +--+--------------+--------------+--+
                   |              |              |
        1. Service |   2. Control | 3. Management|
         Interface |    Interface |    Interface |
              (Si) |         (Ci) |         (Mi) |
                   |              |              |
                +--+--------------+--------------+--+
                |                                   |
                |               BNG-UP              |
                |                                   |
                +-----------------------------------+

     Figure 3.2: Interfaces Between the CP and UP of the BNG

3.3.1.  Service Interface

   For a traditional BNG (without CU separation), the user dial-up
   signals are terminated and processed by the control plane of a BNG.
   When the CP and UP of a BNG are separated, there needs to be a way to
   relay these signals between the CP and the UP.

   The Service Interface (Si) is used to establish tunnels between the
   CP and UP.  The tunnels are responsible for relaying the PPPoE, IPoE,
   and L2TP related control packets that are received from an RG over
   those tunnels.

   The detail definition of Si is out of the scope of this document.

3.3.2.  Management Interface

   NETCONF [RFC6241] is the protocol used on the Management Interface
   between a CP and UP.  It is used to configure the parameters of the
   Control Interface, Service Interface, the Access interfaces and QoS/
   ACL Templates.  The definitions of the parameters are out of the
   scope of this document.

3.3.3.  Control Interface

   The CP uses the Control Interface to deliver service entries, and the
   UP uses this interface to report service events to the CP.  A
   carrying protocol for this interface is specified in this document.






Hu, et al.              Expires November 24, 2019              [Page 11]


Internet-Draft               S-CUSP for BNG                     May 2019


3.4.  BNG CUPS Procedure Overview

   The following numbered sequences gives a high level view of the main
   BNG CUPS procedures.

        RG              UP                       CP             AAA
        |               |                        |               |
        |               |Establish S-CUSP Channel|               |
        |              1|<---------------------->|               |
        |               |                        |               |
        |               | Report Board/interface |               |
        |               |       status           |               |
        |              2|------to CP via Ci----->|               |
        |               |                        |               |
        |               | Enable BAS function    |               |
        |              3|<-----on UP via Ci------|               |
        |               |                        |               |
        |               | Notify UP to advertise |               |
        |               |   subscriber network   |               |
        |               |        routing         |               |
        |              4|<------- via Ci---------|               |
        |               |                        |               |
        |  Dial-up Req  |                        |               |
     5.1|-------------->|                        |               |
        |               | Relay the Dial-up Req  |               |
        |            5.2|-----to CP via Si------>| Authentication|
        |               |                        |    Req/Rep    |
        |               |                     5.3|<------------->|
        |               | Send the Dial-up Rep   |               |
        |            5.4|<----to UP via Si-------|               |
        |  Dial-up Rep  |                        |               |
     5.5|<--------------|                        |               |
        |               | Create subscriber      |               |
        |               |    session on UP       |               |
        |            5.6|<--------via Ci-------->|               |
        |               |                        |  CoA Request  |
        |               |                     6.1|<--------------|
        |               | Update session on UP   |               |
        |            6.2|<--------via Ci-------->|               |
        |               |                        |  CoA Response |
        |               |                     6.3|-------------->|
        |               |                        |               |
        |  Offline Req  |                        |               |
     7.1|-------------->|                        |               |
        |               | Relay the Offline Req  |               |
        |            7.2|------to CP via Si----->|               |
        |               |                        |               |
        |               | Send the Offline Rep   |               |



Hu, et al.              Expires November 24, 2019              [Page 12]


Internet-Draft               S-CUSP for BNG                     May 2019


        |            7.3|<-----to UP via Si------|               |
        |  Offline Rep  |                        |               |
     7.4|<--------------|                        |               |
        |               | Delete session on UP   |               |
        |            7.5|<--------via Ci-------->|               |
        |               |                        |               |
        |               | Event report           |               |
        |              8|---------via Ci-------->|               |
        |               |                        |               |
        |               | Data Synchronization   |               |
        |              9|<--------via Ci-------->|               |
        |               |                        |               |
        |               | CGN Address Allocation |               |
        |             10|<--------via Ci-------->|               |
        |               |                        |               |

                     Figure 3.3: BNG CUPS Overview Procedures

   1.   S-CUSP session establishment: This is the first step of BNG CUPS
        procedures.  Once the Control Interface parameters are
        configured on a UP.  It will start to setup S-CUSP session(s)
        with the specified CP(s).  The detailed definition of S-CUSP
        session establishment can be found in Section 4.1.1.

   2.   Board and interface report: Once the S-CUSP session is
        established between a UP and a CP, the UP will report the status
        information on the board(s) and access side interface(s) of this
        UP to the CP.  The CP can use this information to enable the
        Broadband Access Service (BAS) function (e.g., IPoE, PPPoE,
        etc.) on the specified interface(s).  See Sections 4.2.1 and
        7.10 for more details on Resource reporting.

   3.   BAS (Broadband Access Service) function enable: To enable the
        BAS function on the specified interfaces(s) of a UP.

   4.   Subscriber network route advertisement: The CP will allocate one
        or more address blocks to a UP.  Each address block contains a
        series of IP addresses.  Those IP addresses will be allocated to
        subscribers who are dialing up from the UP.  To enable other
        nodes in the network to learn how to reach the subscribers, the
        CP needs to notify the UP to advertise the routes that can reach
        those IP addresses to the network.

   5.   5.1-5.6 is a general call flow of a subscriber dial-up process.
        When a UP receives a dial-up request, it will relay the request
        packet to a CP through the Service Interface.  The CP will parse
        the request.  If everything is OK, it will send an
        authentication request to the AAA server to authenticate the



Hu, et al.              Expires November 24, 2019              [Page 13]


Internet-Draft               S-CUSP for BNG                     May 2019


        subscriber.  Once the subscriber passes the authentication, the
        AAA server will return a positive response to the CP.  Then the
        CP will send the dial-up response packet to the UP and the UP
        will forward the response packet to the subscriber (RG).  At the
        same time, the CP will create a subscriber session on the UP,
        which enables the subscriber to access the network.  For
        different access types, the process may be a bit different.  But
        the high-level process is similar.  For each access type, the
        detail process can be found in Section 5.

   6.   6.1-6.2 is the sequence when updating an existing session.  The
        AAA server initiates a Change of Authorization (CoA) and sends
        the CoA to the CP.  The CP will then update the session
        according to the CoA.  See Section 4.3.2 for more detail on CP
        messages updating UP tables.

   7.   7.1-7.5 is the sequence for deleting an existing session.  When
        a UP receives a offline request, it will relay the request to a
        CP through the Service Interface.  The CP will send back a
        response to the UP through the Service Interface.  The UP will
        forward the offline response to the subscriber.  Then the CP
        will delete the session on the UP through the Control Interface.

   8.   Event reports include the following two parts (more detail can
        be found in Section 4.3.4).  Both are reported using the Event
        message.

        1.  Subscriber Traffic Statistics Report

        2.  Subscriber Detection Result Report

   9.   Data synchronization: See Sections 4.2.5 for more detail on CP
        and UP Synchronization.

   10.  CGN address allocation: See Sections 4.2.4 for more detail on
        CGN Address Allocation.

4.  S-CUSP Protocol Overview

4.1.  Control Channel Related Procedures

4.1.1.  S-CUSP Session Establishment

   A UP is associated with a CP and is controlled by that CP.  In the
   case of a hot-standby or warm-standby, a UP is associated with two
   CPs, one called the Master CP and the other called the Standby CP.
   The association between a UP and its CP(s) is implemented by
   configuration.



Hu, et al.              Expires November 24, 2019              [Page 14]


Internet-Draft               S-CUSP for BNG                     May 2019


   Once a UP knows its CP(s), the UP starts to establish S-CUSP
   session(s) with those CP(s) as shown below.

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

              Figure 4.1.1: S-CUSP Session Establishment

   The S-CUSP session establishment consists of two successive steps:

   1.  Establishment of a TCP [RFC793] 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 and Keepalive
   timers negotiation are performed.

   The version information (Hello TLV, see section 7.4) is carried
   within Hello messages (see Section 6.2.1).  A CP can support multiple
   versions, but a UP can only support one version.  So, the version
   negotiation is based on whether a version can be support by both the
   CP and the UP.  For a CP or UP, if received a Hello message that does
   not have a supported version, the next Hello message with an Error
   Information TLV will be sent to its peer to notify the "Version-
   Mismatch" error . Then session establishment phase fails.

   Keepalive negotiation is performed by carrying a Keepalive TLV in the
   Hello message.  The Keepalive TLV carries a Keepalive timer and Dead
   Timer.  Both the CP and UP have to agree on the Keepalive Timer and
   Dead Timer.  Otherwise, a Hello message with an Error Information TLV
   will be sent to its peer.  Then session establishment phase fails.

   The S-CUSP session establishment phase fails if the CP or UP disagree
   on the version and Keepalive 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.



Hu, et al.              Expires November 24, 2019              [Page 15]


Internet-Draft               S-CUSP for BNG                     May 2019


4.1.2.  Keep Alive

   Once an S-CUSP session has been established, a UP or CP may want to
   know that its S-CUSP peer is still available for use.

   Each end of a S-CUSP session runs a Keepalive timer.  It restarts the
   timer every time it sends a message on the session.  When the timer
   expires, it sends a Keepalive message.

   The ends of the S-CUSP session also run DeadTimers that they restart
   whenever a message is received on the session.  If one end of the
   session receives no message after the DeadTimer expires, it declares
   the session dead.  The session is closed.

   The minimum value of the Keepalive timer is 1 second, and it is
   specified in units of 1 second.  The recommended default value is 30
   seconds.  The timer may be disabled by setting it to zero.

   The recommended default for the DeadTimer is 4 times the value of the
   Keepalive timer used by the remote peer.  This implies there is
   essentially no risk of TCP congestion due to excessive Keepalive
   messages.

   The Keepalive timer and DeadTimer are initially negotiated through
   the Keepalive TLV carried in the Hello Message.

4.2.  Node Related Procedures

4.2.1.  UP Board and Interface Status Report

   Once an S-CUSP session has been established between a CP and a UP.
   The UP reports the information about the Board(s) and access side
   interface(s) on this UP to the CP.

   The CP can use that information to activate/enable the Broadband
   Access Service (BAS) functions (e.g., IPoE, PPPoE, etc.) on the
   specified interface(s).

   In addition, the UP resource report may trigger a UP warm-standby
   procedure.  In the case of warm-standby, a failure on a UP may
   trigger the CP to start the warm-standby procedure, by moving the on-
   line subscriber sessions to a standby UP and then directing the
   affected subscribers to access the Internet through the standby UP.








Hu, et al.              Expires November 24, 2019              [Page 16]


Internet-Draft               S-CUSP for BNG                     May 2019


                        UP                      CP
                        |                        |
                        |   Report Board Status  |
                        |------to CP via Ci----->|
                        |                        |
                        | Report Interface Status|
                        |------to CP via Ci----->|
                        |                        |

              Figure 4.2.1: UP Board and Interface Report

   Board status information is carried in the Board Status
   TLV(Section 7.10.2), interface status information is carried in the
   Interface Status TLV (Section 7.10.1).  Both Board and Interface
   Status TLVs are carried in the Report message (Section 6.4).

4.2.2.  Enable BAS Function on Access Interface

   Once the CP collects the interface status of a UP, it will activate/
   enable the BAS functions on specified interfaces through the
   Update_Request and Update_Response message (Section 6.2) exchanges
   carrying the BAS Function Enabler TLV (Section 7.7).

                        UP                       CP
                        |                         |
                        |   Enable BAS function   |
                        |         Request         |
                        |<-----on UP via Ci-------|
                        |                         |
                        |   Enable BAS function   |
                        |         Response        |
                        |------on UP via Ci------>|
                        |                         |
                    Figure 4.2.2: Enable BAS Functions

4.2.3.  Advertise Subscriber Network Routing

   The CP will allocate one or more address blocks to a UP.  Each
   address block contains a series of IP addresses.  Those IP addresses
   will be allocated to subscribers who are dialing up to the UP.  To
   enable other nodes in the network to learn how to reach the
   subscribers, the CP needs to install the routes on the UP and notify
   the UP to advertise the routes to the network.








Hu, et al.              Expires November 24, 2019              [Page 17]


Internet-Draft               S-CUSP for BNG                     May 2019


                        UP                       CP
                        |                         |
                        | Subscriber network route|
                        |   advertisement request |
                        |<------- via Ci----------|
                        |                         |
                        | Subscriber network route|
                        |  advertisement response |
                        |-------- via Ci--------->|
                        |                         |

             Figure 4.2.3: Advertise Subscriber Network Routing

   The subscriber network route advertisement request and response are
   achieved through the Update_Request and Update_Response Messages
   exchanges by carrying the IPv4/IPv6 Routing TLVs (Section 7.8).

4.2.4.  CGN Public IP Address Allocation

   The following sequences describe the CGN address management related
   procedures.  Three independent procedures are defined.  The relevant
   messages are defined in Section 6.5.

                        UP                       CP
                        |                         |
                        | CGN Address Allocation  |
                        |         Request         |
                     1.1|-------- via Ci--------->|
                        | CGN Address Allocation  |
                        |         Response        |
                     1.2|<------- via Ci----------|
                        |                         |
                        | CGN Address Renew       |
                        |         Request         |
                     2.1|-------- via Ci--------->|
                        | CGN Address Renew       |
                        |         Response        |
                     2.2|<------- via Ci----------|
                        |                         |
                        | CGN Address Release     |
                        |         Request         |
                     3.1|-------- via Ci--------->|
                        | CGN Address Release     |
                        |         Response        |
                     3.3|<------- via Ci----------|
                        |                         |

              Figure 4.2.4: CGN Public IP Address Allocation



Hu, et al.              Expires November 24, 2019              [Page 18]


Internet-Draft               S-CUSP for BNG                     May 2019


4.2.5.  Data Synchronization Between CP and UP

   Under some circumstances it is necessary to synchronize state between
   the CP and UP, for example if a CP fails and the UP is switched to a
   different CP.

   Synchronization includes two directions.  One direction is from UP to
   CP, the synchronization information is mainly about the board/
   interface status of the UP.  The other direction is from CP to UP,
   the subscriber sessions, subscriber network routes, L2TP tunnels,
   etc. will be synchronized to the UP.

   The synchronization is triggered by a Synch_Request message, the
   receiver will reply with a Sync_Begin message to notify the requester
   that synchronization will begin, then start the synchronization
   through one or more Sync_Data messages.  When synchronization
   finishes, a Sync_End message is sent.

   The following figure shows the process of data synchronization
   between a UP and a CP.































Hu, et al.              Expires November 24, 2019              [Page 19]


Internet-Draft               S-CUSP for BNG                     May 2019


                        UP                       CP
                        |                         |
                        | Synchronization Request |
                        |<------- via Ci----------|
                        |                         |
                        | Synchronization Begin   |
                        |-------- via Ci--------->|
                        |                         |
                        | Board/Interface Report  |
                        |-------- via Ci--------->|
                        |                         |
                        | Synchronization End     |
                        |-------- via Ci--------->|
                        |                         |
                       1) Synchronization from UP to CP


                        UP                       CP
                        |                         |
                        | Synchronization Request |
                        |-------- via Ci--------->|
                        |                         |
                        | Synchronization Begin   |
                        |<-------- via Ci---------|
                        |                         |
                        | Synchronizes Sessions   |
                        |  /Routes/Tunnels...     |
                        |<------- via Ci----------|
                        |                         |
                        | Synchronization End     |
                        |<-------- via Ci---------|
                        |                         |
                       2) Synchronization from CP to UP

                      Figure 4.2.5: Data Synchronization

4.3.  Subscriber Session Related Procedures

   A subscriber session consists of a set of forwarding states,
   policies, and security rules that are required to apply to the
   subscriber.  It is used for forwarding subscriber traffic on a UP.
   To initialize a session on a UP, a set of hardware resource have to
   be allocated (e.g.  NP, TCAM etc.) to a session.

   Subscriber session related procedures include subscriber session
   create, update, delete and statistics report.  The following sub-
   sections give a high view about the procedures.




Hu, et al.              Expires November 24, 2019              [Page 20]


Internet-Draft               S-CUSP for BNG                     May 2019


4.3.1.  Create Subscriber Session

   The below sequence describes the DHCP IPv4 dial-up process, it gives
   an example that shows how a subscriber session is created.

        RG              UP                       CP             AAA
        |               |                        |               |
        | DHCP Discovery|                        |               |
       1|-------------->|                        |               |
        |               |Relay the DHCP Discovery|               |
        |              2|-----to CP via Si------>| Authentication|
        |               |                        |    Req/Rep    |
        |               |                       3|<------------->|
        |               |                        |               |
        |               |  Send the DHCP Offer   |               |
        |              4|<----to UP vis Si-------|               |
        |  DHCP Offer   |                        |               |
       5|<--------------|                        |               |
        |               |                        |               |
        |  DHCP Request |                        |               |
       6|-------------->|                        |               |
        |               |  Relay the DHCP Request|               |
        |              7|-----to CP via Si------>|               |
        |               |                        |               |
        |               |  Create subscriber     |               |
        |               |   session Request      |               |
        |              8|<--------via Ci-------->|               |
        |               |                        |               |
        |               |  Create subscriber     |               |
        |               |   session Response     |               |
        |              9|---------via Ci-------->|               |
        |               |                        |               |
        |               |                        |   Accounting  |
        |               |                      10|<------------->|
        |               |                        |               |
        |               |  Send DHCP ACK         |               |
        |             11|<----to UP via Si-------|               |
        |               |                        |               |
        |  DHCP ACK     |                        |               |
      12|<--------------|                        |               |
        |               |                        |               |

                    Figure 4.3.1: Subscriber Session Create

   The request starts from a DHCP Discovery message from the RG.  When
   the UP receives the DHCP Discovery from the RG, it will tunnel the
   DHCP Discovery to the CP through the Service Interface.  The Service
   Interface is implemented by a tunnel technology.



Hu, et al.              Expires November 24, 2019              [Page 21]


Internet-Draft               S-CUSP for BNG                     May 2019


   When the CP receives the DHCP Discovery from the UP, it will send an
   authentication request to the AAA server to authenticate and
   authorize the subscriber.  When a positive return from the AAA sever
   received, the CP will send a DHCP Offer message to the UP through the
   Service Interface.  The UP will then forward the DHCP Offer to the
   RG.

   After received the DHCP Offer, the RG will send a DHCP Request to the
   UP.  As when dealing with the DHCP Discovery message, the UP will
   tunnel the DHCP Request to the CP.  The CP starts to create a
   subscriber session for the request.  Relevant resource (e.g., IP
   address, bandwidth, etc.) will be allocated to the subscriber and
   policies and security rules will be generated for the subscriber.
   Then the CP sends a session create request to the UP through the
   Control Interface (Ci), and a response is expected from the UP to
   confirm the creation.

   Finally, the CP will notify the AAA server to start accounting.  At
   the same time, a DHCP ACK message will be sent to the UP through the
   Si.  And the UP will forward the DHCP ACK to the RG.

   This completes the whole dial-up process.

4.3.2.  Update Subscriber Session

   The following numbered sequence describes the process of subscriber
   session update.

                        UP                       CP             AAA
                        |                        |  COA Request  |
                        |                       1|<--------------|
                        | Session update Request |               |
                       2|<--------via Ci---------|               |
                        |                        |               |
                        | Session update Response|               |
                       3|---------via Ci-------->|               |
                        |                        |  COA Response |
                        |                       4|-------------->|
                        |                        |               |

                        Figure 4.3.2: Subscriber Session Update

   When a subscriber session has been created on a UP, there may be
   requirements to update the session with new parameters (e.g.,
   Bandwidth, QoS, policies, etc.).

   This procedure is triggered by a Change of Authorization (COA)
   request message sent by the AAA server.  The CP will update the



Hu, et al.              Expires November 24, 2019              [Page 22]


Internet-Draft               S-CUSP for BNG                     May 2019


   session on the UP according to the new parameters through the Control
   Interface.

4.3.3.  Delete Subscriber Session

   The below call flow shows a general process for how BNG CUPS deals
   with the subscriber offline request.

        RG               UP                       CP
        |                |                        |
        |Offline Request |                        |
       1|--------------->|                        |
        |                |    Relay the Offline   |
        |                |        Request         |
        |               2|------to CP via Si----->|
        |                |                        |
        |                |    Send the Offline    |
        |                |        Response        |
        |               3|<-----to UP via Si------|
        |Offline Response|                        |
       4|<---------------|                        |
        |                |     Session delete     |
        |                |<--------via Ci-------->|
        |                |                        |

          Figure 4.3.3: Subscriber Session Delete

   Similar to the session creation process, when a UP receives an
   offline request from an RG, it will tunnel the request to a CP
   through the Si.

   When the CP receives the offline request, it will withdraw/release
   the resource (e.g., IP address, bandwidth) that has been allocated to
   the subscriber.  And then, it may send a response to the UP through
   the Service Interface, the UP will forward the response to the RG.
   At the same time, it will delete all the status of the session on the
   UP through the Ci.

4.3.4.  Subscriber Session Events Report

                        UP                       CP
                        |                        |
                        | Statistic/Detect report|
                        |---------via Ci-------->|
                        |                        |






Hu, et al.              Expires November 24, 2019              [Page 23]


Internet-Draft               S-CUSP for BNG                     May 2019


   When a subscriber session is created on a UP, the UP will
   periodically report statistics and detection results of the session
   to the CP.

5.  S-CUSP Call Flows

   The subsections below give an overview of various "dial-up"
   interactions over the Service Interface followed by the setting of
   various information on the UP by the CP using S-CUSP over the Control
   Interface.

5.1.  IPoE

5.1.1.  DHCPv4 Access

   The following sequence gives detailed procedures for DHCPv4 access.



































Hu, et al.              Expires November 24, 2019              [Page 24]


Internet-Draft               S-CUSP for BNG                     May 2019


        RG              UP                       CP             AAA
        |               |                        |               |
        | DHCP Discovery|                        |               |
       1|-------------->|                        |               |
        |               |Relay the DHCP Discovery|               |
        |              2|-----to CP via Si------>|      AAA      |
        |               |                        |    Req/Rep    |
        |               |                       3|<------------->|
        |               |                        |               |
        |               |  Send the DHCP Offer   |               |
        |              4|<----to UP vis Si-------|               |
        |  DHCP Offer   |                        |               |
       5|<--------------|                        |               |
        |  DHCP Request |                        |               |
       6|-------------->|                        |               |
        |               |  Relay the DHCP Request|               |
        |              7|-----to CP via Si------>|               |
        |               |                        |               |
        |               |  Create subscriber     |               |
        |               |   session Request      |               |
        |              8|<---------via Ci--------|               |
        |               |  Create subscriber     |               |
        |               |   session Response     |               |
        |              9|---------via Ci-------->|               |
        |               |                        |   Accounting  |
        |               |                      10|<------------->|
        |               |                        |               |
        |               |  Send DHCP ACK         |               |
        |             11|<----to UP via Si-------|               |
        |               |                        |               |
        |  DHCP ACK     |                        |               |
      12|<--------------|                        |               |
        |               |                        |               |

                    Figure 5.1.1: DHCPv4 Access

   Step 8 and 9 are implemented by the S-CUSP protocol.

   When a subscriber is authenticated and authorized by the AAA server,
   the CP will create a subscriber session on the UP.  This is achieved
   by sending a UPdate_Request message to the UP.

   The format of the Update_Request message is as follows:








Hu, et al.              Expires November 24, 2019              [Page 25]


Internet-Draft               S-CUSP for BNG                     May 2019


   <Update_Request Message> ::= <Common Header>
                     <Basic Subscriber TLV>
                     <IPv4 Subscriber TLV>
                     <IPv4 Routing TLV>
                     [<Subscriber Policy TLV>]

   The UP will reply with an Update_Response message, the format of the
   Update_Response is as follows:

   <Update_Response Message> ::= <Common Header>
                    <Subscriber Session Update Response TLV>
                    [<Subscriber CGN Port Range TLV>]

5.1.2.  DHCPv6 Access

   The following sequence gives detailed procedures for DHCPv6 access.



































Hu, et al.              Expires November 24, 2019              [Page 26]


Internet-Draft               S-CUSP for BNG                     May 2019


        RG              UP                       CP             AAA
        |               |                        |               |
        |  Solicit      |                        |               |
       1|-------------->|                        |               |
        |               |  Relay the Solicit     |               |
        |              2|-----to CP via Si------>|      AAA      |
        |               |                        |    Req/Rep    |
        |               |                       3|<------------->|
        |               |                        |               |
        |               |  Send the Advertise    |               |
        |              4|<----to UP vis Si-------|               |
        |  Advertise    |                        |               |
       5|<--------------|                        |               |
        |               |                        |               |
        |  Request      |                        |               |
       6|-------------->|                        |               |
        |               |  Relay the Request     |               |
        |              7|-----to CP via Si------>|               |
        |               |                        |               |
        |               |                        |               |
        |               |  Create subscriber     |               |
        |               |   session Request      |               |
        |              8|<--------via Ci-------->|               |
        |               |                        |               |
        |               |  Create subscriber     |               |
        |               |   session Response     |               |
        |              9|---------via Ci-------->|               |
        |               |                        |               |
        |               |                        |   Accounting  |
        |               |                      10|<------------->|
        |               |                        |               |
        |               |  Send Reply            |               |
        |             11|<----to UP via Si-------|               |
        |               |                        |               |
        |  Reply        |                        |               |
      12|<--------------|                        |               |
        |               |                        |               |

                   Figure 5.1.2: DHCPv6 Access

   Steps 1-7 are a standard DHCP IPv6 access process.  The subscriber
   creation is triggered by a DHCP IPv6 request message.  This message
   means that the subscriber has passed the AAA authentication and
   authorization.  Then the CP will create a subscriber session on the
   UP.  This is achieved by sending a UPdate_Request message to the UP
   (Step 8).

   The format of the Update_Request message is as follows:



Hu, et al.              Expires November 24, 2019              [Page 27]


Internet-Draft               S-CUSP for BNG                     May 2019


   <Update_Request Message> ::= <Common Header>
                     <Basic Subscriber TLV>
                     <IPv6 Subscriber TLV>
                     <IPv6 Routing TLV>
                     [<Subscriber Policy TLV>]

   The UP will reply with an Update_Response message (Step 9), the
   format of the Update_Response is as follows:

   <Update_Response Message> ::= <Common Header>
                    <Subscriber Session Update Response TLV>

5.1.3.  IPv6 SLAAC Access

   The following flow describes the IPv6 SLAAC access process.




































Hu, et al.              Expires November 24, 2019              [Page 28]


Internet-Draft               S-CUSP for BNG                     May 2019


        RG              UP                       CP             AAA
        |               |                        |               |
        |      RS       |                        |               |
       1|-------------->|                        |               |
        |               |  Relay the Router      |               |
        |               |    Solicit (RS)        |               |
        |              2|-----to CP via Si------>|      AAA      |
        |               |                        |    Req/Rep    |
        |               |                       3|<------------->|
        |               |                        |               |
        |               |  Create subscriber     |               |
        |               |   session Request      |               |
        |              4|<--------via Ci---------|               |
        |               |                        |               |
        |               |  Create subscriber     |               |
        |               |   session Response     |               |
        |              5|---------via Ci-------->|               |
        |               |                        |               |
        |               |  Send Router Advertise |               |
        |               |         (RA)           |               |
        |              6|<----to UP vis Si-------|               |
        |      RA       |                        |               |
       7|<--------------|                        |               |
        |               |                        |               |
        |      NS       |                        |               |
       8|-------------->|                        |               |
        |               |  Relay the Neighbor    |               |
        |               |     Solicit (NS)       |               |
        |              9|-----to CP via Si------>|               |
        |               |                        |               |
        |               |                        |   Accounting  |
        |               |                      10|<------------->|
        |               |                        |               |
        |               |  Send a Neighbor       |               |
        |               |     Advertise (NA)     |               |
        |             11|<----to UP via Si-------|               |
        |               |                        |               |
        |      NA       |                        |               |
      12|<--------------|                        |               |
        |               |                        |               |

                      Figure 5.1.3: IPv6 SLAAC Access

   It starts with a Router Solicit (RS) request from an RG, it will be
   tunneled to the CP when the UP receives the message.  After the AAA
   authentication and authorization, the CP will create a subscriber
   session on the UP.  This is achieved by sending a UPdate_Request
   message to the UP (step 4).



Hu, et al.              Expires November 24, 2019              [Page 29]


Internet-Draft               S-CUSP for BNG                     May 2019


   The format of the Update_Request message is as follows:

   <Update_Request Message> ::= <Common Header>
                     <Basic Subscriber TLV>
                     <IPv6 Subscriber TLV>
                     <IPv6 Routing TLV>
                     [<Subscriber Policy TLV>]


   The UP will reply with an Update_Response message (step 5).  The
   format of the Update_Response is as follows:

   <Update_Response Message> ::= <Common Header>
                    <Subscriber Session Update Response TLV>


5.1.4.  DHCPv6 + SLAAC Access

   The following call flow describes the DHCP IPv6 and SLAAC access
   process.































Hu, et al.              Expires November 24, 2019              [Page 30]


Internet-Draft               S-CUSP for BNG                     May 2019


        RG              UP                       CP             AAA
        |               |                        |               |
        |      RS       |                        |               |
       1|-------------->|                        |               |
        |               |  Relay the Router      |               |
        |               |    Solicit (RA)        |               |
        |              2|-----to CP via Si------>|      AAA      |
        |               |                        |    Req/Rep    |
        |               |                       3|<------------->|
        |               |                        |               |
        |               |  Create subscriber     |               |
        |               |   session Request      |               |
        |              4|<--------via Ci---------|               |
        |               |                        |               |
        |               |  Create subscriber     |               |
        |               |   session Response     |               |
        |              5|---------via Ci-------->|               |
        |               |                        |               |
        |               |  Send Router Advertise |               |
        |               |         (RA)           |               |
        |              6|<----to UP vis Si-------|               |
        |      RA       |                        |               |
       7|<--------------|                        |               |
        |               |                        |               |
        |DHCPv6 Solicit |                        |               |
       8|-------------->|                        |               |
        |               |  Relay DHCPv6 Solicit  |               |
        |              9|-----to CP via Si------>|               |
        |               |                        |               |
        |               |  Update subscriber     |               |
        |               |   session Request      |               |
        |             10|<--------via Ci---------|               |
        |               |                        |               |
        |               |  Update subscriber     |               |
        |               |   session Response     |               |
        |             11|---------via Ci-------->|               |
        |               |                        |               |
        |               |                        |   Accounting  |
        |               |                      12|<------------->|
        |               |                        |               |
        |               |  Send DHCPv6 Reply     |               |
        |             13|<----to UP via Si-------|               |
        |               |                        |               |
        | DHCPv6 Reply  |                        |               |
      14|<--------------|                        |               |
        |               |                        |               |

                 Figure 5.1.4: DHCPv6 + SLAAC Access



Hu, et al.              Expires November 24, 2019              [Page 31]


Internet-Draft               S-CUSP for BNG                     May 2019


   When a subscriber passed AAA authentication, the CP will create a
   subscriber session on the UP.  This is achieved by sending a
   UPdate_Request message to the UP (step 4).

   <Update_Request Message> ::= <Common Header>
                     <Basic Subscriber TLV>
                     <IPv6 Subscriber TLV>
                     <IPv6 Routing TLV>
                     [<Subscriber Policy TLV>]

   The UP will reply with an Update_Response message (step 5).  The
   format of the Update_Response is as follows:

   <Update_Response Message> ::= <Common Header>
                    <Subscriber Session Update Response TLV>

   After receiving a DHCPv6 Solicit, the CP will update the subscriber
   session by sending a UPdate_Request message with new parameters to
   the UP (Step 10).

   The format of the Update_Request message is as follows:

   <Update_Request Message> ::= <Common Header>
                     <Basic Subscriber TLV>
                     <IPv6 Subscriber TLV>
                     <IPv6 Routing TLV>
                     [<Subscriber Policy TLV>]

   The UP will reply with an Update_Response message (step 11).  The
   format of the Update_Response is as follows:

   <Update_Response Message> ::= <Common Header>
                    <Subscriber Session Update Response TLV>

5.1.5.  DHCP Dual Stack Access

   The following sequence is a combination of DHCP IPv4 and DHCP IPv6
   access process.

        RG              UP                       CP             AAA
        |               |                        |               |
        | DHCP Discovery|                        |               |
       1|-------------->|                        |               |
        |               |Relay the DHCP Discovery|               |
        |              2|-----to CP via Si------>|      AAA      |
        |               |                        |    Req/Rep    |
        |               |                       3|<------------->|
        |               |                        |               |



Hu, et al.              Expires November 24, 2019              [Page 32]


Internet-Draft               S-CUSP for BNG                     May 2019


        |               |  Send the DHCP Offer   |               |
        |              4|<----to UP vis Si-------|               |
        |  DHCP Offer   |                        |               |
       5|<--------------|                        |               |
        |  DHCP Request |                        |               |
       6|-------------->|                        |               |
        |               |  Relay the DHCP Request|               |
        |              7|-----to CP via Si------>|               |
        |               |                        |               |
        |               |  Create subscriber     |               |
        |               |   session Request      |               |
        |              8|<--------via Ci-------->|               |
        |               |  Create subscriber     |               |
        |               |   session Response     |               |
        |              9|---------via Ci-------->|               |
        |               |                        |   Accounting  |
        |               |                      10|<------------->|
        |               |  Send DHCP ACK         |               |
        |             11|<----to UP via Si-------|               |
        |               |                        |               |
        |  DHCP ACK     |                        |               |
      12|<--------------|                        |               |
        |      RS       |                        |               |
      13|-------------->|                        |               |
        |               |  Relay the Router      |               |
        |               |    Solicit (RA)        |               |
        |             14|-----to CP via Si------>|               |
        |               |                        |   Accounting  |
        |               |                      15|<------------->|
        |               |                        |               |
        |               |  Update subscriber     |               |
        |               |   session Request      |               |
        |             16|<--------via Ci---------|               |
        |               |  Update subscriber     |               |
        |               |   session Response     |               |
        |             17|---------via Ci-------->|               |
        |               |                        |               |
        |               |  Send Router Advertise |               |
        |               |         (RA)           |               |
        |             18|<----to UP vis Si-------|               |
        |      RA       |                        |               |
      19|<--------------|                        |               |
        |               |                        |               |
        |DHCPv6 Solicit |                        |               |
      20|-------------->|                        |               |
        |               |  Relay DHCPv6 Solicit  |               |
        |             21|-----to CP via Si------>|               |
        |               |                        |               |



Hu, et al.              Expires November 24, 2019              [Page 33]


Internet-Draft               S-CUSP for BNG                     May 2019


        |               |  Update subscriber     |               |
        |               |   session Request      |               |
        |             22|<--------via Ci---------|               |
        |               |  Update subscriber     |               |
        |               |   session Response     |               |
        |             23|---------via Ci-------->|               |
        |               |                        |   Accounting  |
        |               |                      24|<------------->|
        |               |  Send DHCPv6 Reply     |               |
        |             25|<----to UP via Si-------|               |
        | DHCPv6 Reply  |                        |               |
      26|<--------------|                        |               |
        |               |                        |               |

                  Figure 5.1.5: DHCP Dual Stack Access

   The DHCP dual stack access includes three Update_Request/
   Update_Response message exchanges to create/update DHCPv4/v6
   subscriber session.

   1.  Create DHCPv4 session (step 8 and 9)

   <Update_Request Message> ::= <Common Header>
                     <Basic Subscriber TLV>
                     <IPv4 Subscriber TLV>
                     <IPv4 Routing TLV>
                     [<Subscriber Policy TLV>]

   <Update_Response Message> ::= <Common Header>
                    <Subscriber Session Update Response TLV>
                    [<Subscriber CGN Port Range TLV>]

   2.  Create or Update?  DHCPv6 session (step 16 and 17)

   <Update_Request Message> ::= <Common Header>
                     <Basic Subscriber TLV>
                     <IPv6 Subscriber TLV>
                     <IPv6 Routing TLV>
                     [<Subscriber Policy TLV>]

   <Update_Response Message> ::= <Common Header>
                    <Subscriber Session Update Response TLV>

   3.  Update DHCPv6 session (step 22 and 23)







Hu, et al.              Expires November 24, 2019              [Page 34]


Internet-Draft               S-CUSP for BNG                     May 2019


   <Update_Request Message> ::= <Common Header>
                     <Basic Subscriber TLV>
                     <IPv6 Subscriber TLV>
                     <IPv6 Routing TLV>
                     [<Subscriber Policy TLV>]

   <Update_Response Message> ::= <Common Header>
                    <Subscriber Session Update Response TLV>

5.1.6.  L2 Static Subscriber Access

   L2 static subscriber access processes are as follows:

        RG              UP                      CP              AAA
        |               |                        |               |
        |               |Static Subscriber Access|               |
        |               |     Control List Req.  |               |
        |              1|<-----to UP via Ci------|               |
        |               |Static Subscriber Access|               |
        |               |     Control List Rep.  |               |
        |              2|------to CP via Ci----->|               |
        |  ARP/ND(REQ)  |                        |               |
     3.1|<--------------|                        |               |
        |  ARP/ND(ACK)  |                        |               |
     3.2|-------------->|                        |               |
        |               |  Relay the ARP/ND      |               |
        |            3.3|-----to CP via Si------>|       AAA     |
        |               |                        |    Req/Rep    |
        |               |                     3.4|<------------->|
        |               |  Create subscriber     |               |
        |               |   session Request      |               |
        |            3.5|<--------via Ci---------|               |
        |               |  Create subscriber     |               |
        |               |   session Response     |               |
        |            3.6|---------via Ci-------->|               |
        |               |                        |               |
        |  ARP/ND(REQ)  |                        |               |
     4.1|-------------->|                        |               |
        |               |  Relay the ARP/ND      |               |
        |            4.2|-----to CP via Si------>|      AAA      |
        |               |                        |    Req/Rep    |
        |               |                     4.3|<------------->|
        |               |  Create subscriber     |               |
        |               |   session Request      |               |
        |            4.4|<--------via Ci-------->|               |
        |               |  Create subscriber     |               |
        |               |   session Response     |               |
        |            4.5|---------via Ci-------->|               |



Hu, et al.              Expires November 24, 2019              [Page 35]


Internet-Draft               S-CUSP for BNG                     May 2019


        |  ARP/ND(ACK)  |                        |               |
     4.6|<--------------|                        |               |
        |               |                        |               |
        |   IP Traffic  |                        |               |
     5.1|-------------->|                        |               |
        |               |  Relay the IP Traffic  |               |
        |            5.2|-----to CP via Si------>|      AAA      |
        |               |                        |    Req/Rep    |
        |               |                     5.3|<------------->|
        |               |  Create subscriber     |               |
        |               |   session Request      |               |
        |            5.4|<--------via Ci---------|               |
        |               |  Create subscriber     |               |
        |               |   session Response     |               |
        |            5.5|---------via Ci-------->|               |
        |               |                        |               |
        |  ARP/ND(REQ)  |                        |               |
     5.6|<--------------|                        |               |
        |  ARP/ND(ACK)  |                        |               |
     5.7|-------------->|                        |               |
        |               |                        |               |
                    Figure 5.1.6: L2 Static Subscriber Access

   For L2 static subscriber access, it always starts with a CP
   installing a subscriber access control list on a UP.  The subscriber
   access control list is used by the UP to determine whether an RG is
   allowed to access the network.  This is implemented by exchanging
   Update_Request and Update_Response messages between CP and UP.  The
   format of the messages are as follows:

   <Update_Request Message> ::= <Common Header>
                     <IPv4 Static User Information TLV>
                     <IPv6 Static User Information TLV>

   <Update_Response Message> ::= <Common Header>
                    <Subscriber Session Update Response TLV>

   For L2 Static Subscriber Access, there are three ways to trigger the
   access process:

   1.  Triggered by UP (3.1-3.6): This assumes that the UP knows the IP
       address, the access interface, and VLAN of the RG.  The UP will
       actively trigger the access flow by sending an ARP/ND packet to
       the RG.  If the RG is online, it will reply with an ARP/ND
       response to the UP.  The UP will tunnel the ARP/ND to the CP
       through the Si.  It will then trigger the authentication process.
       If the authentication result is positive.  The CP will create a
       corresponding subscriber session on the UP.



Hu, et al.              Expires November 24, 2019              [Page 36]


Internet-Draft               S-CUSP for BNG                     May 2019


   2.  Triggered by RG ARP/ND (4.1-4.6): Most of the process is same as
       option 1 (triggered by UP).  The difference is that the RG will
       actively send the ARP/ND to trigger the process.

   3.  Triggered by RG IP traffic (5.1-5.7): This is for the case where
       the RG has the ARP/ND entity, but the subscriber session on the
       UP is lost (e.g., due to failure on the UP, or the UP restarted).
       That means the RG may keep sending IP packets to the UP.  The
       packets will trigger the UP to start a new access process.

   From a subscriber session point of view, the procedures and the
   message formats for the above three cases are the same, as follows:

   IPv4 Case:
   <Update_Request Message> ::= <Common Header>
                     <Basic Subscriber TLV>
                     <IPv4 Subscriber TLV>
                     <IPv4 Routing TLV>
                     [<Subscriber Policy TLV>]

   <Update_Response Message> ::= <Common Header>
                    <Subscriber Session Update Response TLV>
                    [<Subscriber CGN Port Range TLV>]

   IPv6 Case:
   <Update_Request Message> ::= <Common Header>
                     <Basic Subscriber TLV>
                     <IPv6 Subscriber TLV>
                     <IPv6 Routing TLV>
                     [<Subscriber Policy TLV>]

   <Update_Response Message> ::= <Common Header>
                    <Subscriber Session Update Response TLV>

5.2.  PPPoE

5.2.1.  IPv4 PPPoE Access

   The following figure describes the IPv4 PPPoE access call flow.












Hu, et al.              Expires November 24, 2019              [Page 37]


Internet-Draft               S-CUSP for BNG                     May 2019


        RG              UP                      CP              AAA
        |               |                        |               |
        |  PPPoE Disc   |        PPPoE Disc      |               |
       1|<------------->|<---------via Si------->|               |
        |               |                        |               |
        |  PPP LCP      |        PPP LCP         |               |
       2|<------------->|<---------via Si------->|               |
        |               |                        |      AAA      |
        |  PPP PAP/CHAP |        PPP PAP/CHAP    |    Req/Rep    |
       3|<------------->|<---------via Si------->|<------------->|
        |               |                        |               |
        |  PPP IPCP     |        PPP IPCP        |               |
       4|<------------->|<---------via Si------->|               |
        |               |                        |               |
        |               |  Create subscriber     |               |
        |               |   session Request      |               |
        |              5|<--------via Ci---------|               |
        |               |                        |               |
        |               |  Create subscriber     |               |
        |               |   session Response     |               |
        |              6|---------via Ci-------->|               |
        |               |                        |               |
        |               |                        |   Accounting  |
        |               |                       7|<------------->|
        |               |                        |               |

                        Figure 5.2.1: IPv4 PPPoE Access

   From the above sequence, steps 1-4 are the standard PPPoE call flow.
   The UP is responsible for redirecting the PPPoE control packets to
   the CP or RG.  The PPPoE control packets are transmitted between the
   CP and UP through the Si.

   After the PPPoE call flow, if the subscriber passed the AAA
   authentication and authorization, the CP will create a corresponding
   session on the UP through the Ci.  The formats of the messages are as
   follows:

   <Update_Request Message> ::= <Common Header>
                     <Basic Subscriber TLV>
                     <PPP Subscriber TLV>
                     <IPv4 Subscriber TLV>
                     <IPv4 Routing TLV>
                     [<Subscriber Policy TLV>]

   <Update_Response Message> ::= <Common Header>
                    <Subscriber Session Update Response TLV>
                    [<Subscriber CGN Port Range TLV>]



Hu, et al.              Expires November 24, 2019              [Page 38]


Internet-Draft               S-CUSP for BNG                     May 2019


5.2.2.  IPv6 PPPoE Access

   The following figure describes the IPv6 PPPoE access call flow.

        RG              UP                      CP              AAA
        |               |                        |               |
        |  PPPoE Disc   |        PPPoE Disc      |               |
       1|<------------->|<--------via Si-------->|               |
        |               |                        |               |
        |  PPP LCP      |        PPP LCP         |               |
       2|<------------->|<---------via Si------->|               |
        |               |                        |      AAA      |
        |  PPP PAP/CHAP |        PPP PAP/CHAP    |    Req/Rep    |
       3|<------------->|<---------via Si------->|<------------->|
        |               |                        |               |
        |  PPP IP6CP    |        PPP IP6CP       |               |
       4|<------------->|<---------via Si------->|               |
        |               |                        |               |
        |               |  Create subscriber     |               |
        |               |   session Request      |               |
        |              5|<---------via Ci--------|               |
        |               |                        |               |
        |               |  Create subscriber     |               |
        |               |   session Response     |               |
        |              6|---------via Ci-------->|               |
        |               |                        |               |
        | ND Negotiation|        ND Negotiation  |               |
       7|<------------->|<---------via Si------->|               |
        |               |                        |               |
        |               |  Update subscriber     |               |
        |               |   session Request      |               |
        |              8|<---------via Ci--------|               |
        |               |                        |               |
        |               |  Update subscriber     |               |
        |               |   session Response     |               |
        |              9|---------via Ci-------->|               |
        |               |                        |               |
        |               |                        |   Accounting  |
        |               |                      10|<------------->|
        |               |                        |               |
        |    DHCPv6     |        DHCPv6          |               |
        |  Negotiation  |      Negotiation       |               |
      7'|<------------->|<---------via Si------->|               |
        |               |                        |               |
        |               |  Update subscriber     |               |
        |               |   session Request      |               |
        |             8'|<--------via Ci---------|               |
        |               |                        |               |



Hu, et al.              Expires November 24, 2019              [Page 39]


Internet-Draft               S-CUSP for BNG                     May 2019


        |               |  Update subscriber     |               |
        |               |   session Response     |               |
        |             9'|---------via Ci-------->|               |
        |               |                        |               |
        |               |                        |   Accounting  |
        |               |                     10'|<------------->|
        |               |                        |               |

                       Figure 5.2.2: IPv6 PPPoE Access

   From the above sequence, steps 1-4 are the standard PPPoE call flow.
   The UP is responsible for redirecting the PPPoE control packets to
   the CP or RG.  The PPPoE control packets are transmitted between the
   CP and UP through the Si.

   After the PPPoE call flow, if the subscriber passed AAA
   authentication and authorization, the CP will create a corresponding
   session on the UP through the Ci.  The formats of the messages are as
   follows:

   <Update_Request Message> ::= <Common Header>
                     <Basic Subscriber TLV>
                     <PPP Subscriber TLV>
                     <IPv6 Subscriber TLV>
                     <IPv6 Routing TLV>
                     [<Subscriber Policy TLV>]

   <Update_Response Message> ::= <Common Header>
                    <Subscriber Session Update Response TLV>

   Then, the RG will initialize a ND/DHCPv6 negotiation process with the
   CP (see step 7 and 7'), after then, it will trigger an update (8-9,
   8'-9') to the subscriber session, the formats of the update messages
   are as follows:

   <Update_Request Message> ::= <Common Header>
                     <Basic Subscriber TLV>
                     <PPP Subscriber TLV>
                     <IPv6 Subscriber TLV>
                     <IPv6 Routing TLV>
                     [<Subscriber Policy TLV>]

   <Update_Response Message> ::= <Common Header>
                    <Subscriber Session Update Response TLV>







Hu, et al.              Expires November 24, 2019              [Page 40]


Internet-Draft               S-CUSP for BNG                     May 2019


5.2.3.  PPPoE Dual Stack Access

   The following figure describes a combination of IPv4 and IPv6 PPPoE
   access call flow.

        RG              UP                      CP              AAA
        |               |                        |               |
        |PPPoE Discovery|      PPPoE Discovery   |               |
       1|<------------->|<---------via Si------->|               |
        |               |                        |               |
        |  PPP LCP      |        PPP LCP         |               |
       2|<------------->|<---------via Si------->|               |
        |               |                        |      AAA      |
        |  PPP PAP/CHAP |        PPP PAP/CHAP    |    Req/Rep    |
       3|<------------->|<---------via Si------->|<------------->|
        |               |                        |               |
        |  PPP IPCP     |        PPP IPCP        |               |
       4|<------------->|<---------via Si------->|               |
        |               |                        |               |
        |               |  Create v4 subscriber  |               |
        |               |   session Request      |               |
        |              5|<--------via Ci---------|               |
        |               |  Create v4 subscriber  |               |
        |               |   session Response     |               |
        |              6|---------via Ci-------->|               |
        |               |                        |   Accounting  |
        |               |                       7|<------------->|
        |  PPP IP6CP    |        PPP IP6CP       |               |
      4'|<------------->|<---------via Si------->|               |
        |               |                        |               |
        |               |  Create V6 subscriber  |               |
        |               |   session Request      |               |
        |             5'|<--------via Ci---------|               |
        |               |  Create v6 subscriber  |               |
        |               |   session Response     |               |
        |             6'|---------via Ci-------->|               |
        |               |                        |               |
        | ND Negotiation|     ND Negotiation     |               |
       8|<------------->|<---------via Si------->|               |
        |               |                        |               |
        |               |  Update v6 subscriber  |               |
        |               |   session Request      |               |
        |              9|<---------via Ci--------|               |
        |               |  Update v6 subscriber  |               |
        |               |   session Response     |               |
        |             10|---------via Ci-------->|               |
        |               |                        |   Accounting  |
        |               |                      7'|<------------->|



Hu, et al.              Expires November 24, 2019              [Page 41]


Internet-Draft               S-CUSP for BNG                     May 2019


        |    DHCPv6     |        DHCPv6          |               |
        |  Negotiation  |      Negotiation       |               |
      8'|<------------->|<---------via Si------->|               |
        |               |                        |               |
        |               |  Update v6 subscriber  |               |
        |               |   session Request      |               |
        |             9'|<---------via Ci--------|               |
        |               |                        |               |
        |               |  Update v6 subscriber  |               |
        |               |   session Response     |               |
        |            10'|---------via Ci-------->|               |
        |               |                        |   Accounting  |
        |               |                      7"|<------------->|
        |               |                        |               |

                      Figure 5.2.3: PPPoE Dual Stack Access

   PPPoE dual stack is a combination of IPv4 PPPoE and IPv6 PPPoE
   access.  The process is as above.  The formats of the messages are as
   follows:

   1.  Create an IPv4 PPPoE subscriber session (5-6)

   <Update_Request Message> ::= <Common Header>
                     <Basic Subscriber TLV>
                     <PPP Subscriber TLV>
                     <IPv4 Subscriber TLV>
                     <IPv4 Routing TLV>
                     [<Subscriber Policy TLV>]

   <Update_Response Message> ::= <Common Header>
                    <Subscriber Session Update Response TLV>
                    [<Subscriber CGN Port Range TLV>]

   2.  Create an IPv6 PPPoE subscriber session (5'-6')

   <Update_Request Message> ::= <Common Header>
                     <Basic Subscriber TLV>
                     <PPP Subscriber TLV>
                     <IPv6 Subscriber TLV>
                     <IPv6 Routing TLV>
                     [<Subscriber Policy TLV>]

   <Update_Response Message> ::= <Common Header>
                    <Subscriber Session Update Response TLV>

   3.  Update the IPv6 PPPoE subscriber session (9-10, 9'-10')




Hu, et al.              Expires November 24, 2019              [Page 42]


Internet-Draft               S-CUSP for BNG                     May 2019


   <Update_Request Message> ::= <Common Header>
                     <Basic Subscriber TLV>
                     <PPP Subscriber TLV>
                     <IPv6 Subscriber TLV>
                     <IPv6 Routing TLV>
                     [<Subscriber Policy TLV>]

   <Update_Response Message> ::= <Common Header>
                    <Subscriber Session Update Response TLV>

5.3.  WLAN Access

   The following figure describes the WLAN access call flow.

        RG            UP              CP         AAA      WEB Server
        |             |                |          |           |
        |    DHCP     |                |          |           |
        |  Discovery  |                |          |           |
       1|------------>|                |          |           |
        |             |      DHCP      |          |           |
        |             |    Discovery   |          |           |
        |            2|-----via Si---->|   AAA    |           |
        |             |   DHCP Offer   |<-------->|           |
        |            3|<----via Si-----|          |           |
        |  DHCP Offer |                |          |           |
       4|<------------|                |          |           |
        |     DHCP    |                |          |           |
        |    Request  |                |          |           |
       5|------------>|                |          |           |
        |             |  DHCP Request  |          |           |
        |            6|-----via Si---->|          |           |
        |             |                |          |           |
        |             | Create session |          |           |
        |             |    Request     |          |           |
        |            7|<----via Ci-----|          |           |
        |             | Create session |          |           |
        |             |    Response    |          |           |
        |            8|----via Ci----->|          |           |
        |             |                |          |           |
        |             |  DHCP ACK      |          |           |
        |            9|<----via Si-----|          |           |
        |             |                |          |           |
        |  DHCP ACK   |                |          |           |
      10|<------------|                |          |           |
        |             |                |          |           |
        | Subscriber  |                |          |           |
        | HTTP Traffic|                |          |           |
      11|------------>|-->             |          |           |



Hu, et al.              Expires November 24, 2019              [Page 43]


Internet-Draft               S-CUSP for BNG                     May 2019


        |             |  | WEB URL     |          |           |
        |  Traffic    |  | Redirect    |          |           |
        | Redirection |  |             |          |           |
      12|<------------|<-+             |          |           |
        |                              |          |           |
        |                                                     |
      13|-----------------Redirect to Web server------------->|
        |                                                     |
      14|<----------------Push HTTP log-in page---------------|
        |                                                     |
      15|-----------------User Authentication---------------->|
        |                                                     |
        |             |                |  Portal Interchange  |
        |             |              16|<-------------------->|
        |             |                |                      |
        |             |                |   AAA    |           |
        |             |                |  Req/Rep |           |
        |             |              17|<-------->|           |
        |             |                |          |           |
        |             | Update session |          |           |
        |             |    Request     |          |           |
        |           18|<----via Ci-----|          |           |
        |             |                |          |           |
        |             | Update session |          |           |
        |             |    Response    |          |           |
        |           19|-----via Ci---->|          |           |
        |             |                |          |           |

                          Figure 5.3: WLAN Access

   WLAN access starts with the DHCP dial-up process (steps 1-6), after
   that the CP will create a subscriber session on the UP (step 7-8).
   The formats of the session creation messages are as follows:


















Hu, et al.              Expires November 24, 2019              [Page 44]


Internet-Draft               S-CUSP for BNG                     May 2019


   IPv4 Case:
   <Update_Request Message> ::= <Common Header>
                     <Basic Subscriber TLV>
                     <IPv4 Subscriber TLV>
                     <IPv4 Routing TLV>
                     [<Subscriber Policy TLV>]

   <Update_Response Message> ::= <Common Header>
                    <Subscriber Session Update Response TLV>
                    [<Subscriber CGN Port Range TLV>]

   IPv6 Case:
   <Update_Request Message> ::= <Common Header>
                     <Basic Subscriber TLV>
                     <IPv6 Subscriber TLV>
                     <IPv6 Routing TLV>
                     [<Subscriber Policy TLV>]

   <Update_Response Message> ::= <Common Header>
                    <Subscriber Session Update Response TLV>

   After step 10, the RG will be allocated an IP address and its first
   HTTP packet will be redirected to a WEB server for subscriber
   authentication (step 11-17).  After the WEB authentication, if the
   result is positive, the CP will update the subscriber session by
   using the following message exchanges:

   IPv4 Case:
   <Update_Request Message> ::= <Common Header>
                     <Basic Subscriber TLV>
                     <IPv4 Subscriber TLV>
                     <IPv4 Routing TLV>
                     [<Subscriber Policy TLV>]

   <Update_Response Message> ::= <Common Header>
                    <Subscriber Session Update Response TLV>
                    [<Subscriber CGN Port Range TLV>]

   IPv6 Case:
   <Update_Request Message> ::= <Common Header>
                     <Basic Subscriber TLV>
                     <IPv6 Subscriber TLV>
                     <IPv6 Routing TLV>
                     [<Subscriber Policy TLV>]

   <Update_Response Message> ::= <Common Header>
                    <Subscriber Session Update Response TLV>




Hu, et al.              Expires November 24, 2019              [Page 45]


Internet-Draft               S-CUSP for BNG                     May 2019


5.4.  L2TP

5.4.1.  L2TP LAC Access

        RG         UP(LAC)      CP(LAC)     AAA        LNS
        |            |              |        |          |
        |    PPPoE   |    PPPoE     |        |          |
        |  Discovery |   Discovery  |        |          |
       1|<---------->|<---via Si--->|        |          |
        |            |              |        |          |
        |  PPP LCP   |   PPP LCP    |        |          |
       2|<---------->|<---via Si--->|        |          |
        |            |              |   AAA  |          |
        |PPP PAP/CHAP| PPP PAP/CHAP | Req/Rep|          |
       3|<---------->|<---via Si--->|<------>|          |
        |            |              |        |          |
        |  PPP IPCP  |  PPP IPCP    |        |          |
       4|<---------->|<---via Si--->|        |          |
        |            |              |        |          |
        |            | L2TP tunnel  |        |          |
        |            | negotiation  |        |          |
        |            |   SCCRQ/     |        |          |
        |            |   SCCRP/     |        |          |
        |            |   SCCCN      |        |          |
        |           5|<---via Si--->|        |          |
        |            | /\                               |
        |            | || forward                       |
        |            | \/                               |
        |            |<-----------via routing---------->|
        |            |                                  |
        |            | L2TP session |        |          |
        |            | negotiation  |        |          |
        |            |    ICRQ/     |        |          |
        |            |    ICRP/     |        |          |
        |            |    ICCN      |        |          |
        |           6|<---via Si--->|        |          |
        |            | /\                               |
        |            | || forward                       |
        |            | \/                               |
        |            |<-----------via routing---------->|
        |            |                                  |
        |            |    Create    |         |         |
        |            |   subscriber |         |         |
        |            |    session   |         |         |
        |            |    Request   |         |         |
        |           7|<---via Ci----|         |         |
        |            |              |         |         |
        |            |    Create    |         |         |



Hu, et al.              Expires November 24, 2019              [Page 46]


Internet-Draft               S-CUSP for BNG                     May 2019


        |            |   subscriber |         |         |
        |            |    session   |         |         |
        |            |    Response  |         |         |
        |           8|----via Ci--->|         |         |
        |            |              |         |         |
        |                                               |
        |         PAP/CHAP (Triggered by LNS)           |
       9|<-----------------via routing?---------------->|
        |                                               |

                  Figure 5.4.1: L2TP-LAC Access

   Steps 1-4 are a standard PPPoE access process.  After that the LAC-CP
   starts to negotiate a L2TP session and tunnel with the LNS.  After
   the negotiation, the CP will create a L2TP LAC subscriber session on
   the UP through the following messages:

   <Update_Request Message> ::= <Common Header>
                     <Basic Subscriber TLV>
                     <L2TP-LAC Subscriber TLV>
                     <L2TP-LAC Tunnel TLV>

   <Update_Response Message> ::= <Common Header>
                    <Subscriber Session Update Response TLV>


5.4.2.  L2TP LNS IPv4 Access

        RG          LAC            UP(LNS)  AAA      CP(LNS)
        |            |              |        |          |
        |    PPPoE   |              |        |          |
        |  Discovery |              |        |          |
       1|<---------->|              |        |          |
        |            |              |        |          |
        |  PPP LCP   |              |        |          |
       2|<---------->|                       |          |
        |            |          AAA          |          |
        |PPP PAP/CHAP|        Req/Rep        |          |
       3|<---------->|<--------------------->|          |
        |            |                                  |
        |            |                                  |
        |            | L2TP tunnel  |     L2TP tunnel   |
        |            | negotiation  |     negotiation   |
        |            |   SCCRQ/     |       SCCRQ/      |
        |            |   SCCRP/     |       SCCRP/      |
        |            |   SCCCN      |       SCCCN       |
        |           4|<------------>|<------via Si----->|
        |            |              |                   |



Hu, et al.              Expires November 24, 2019              [Page 47]


Internet-Draft               S-CUSP for BNG                     May 2019


        |            | L2TP session |    L2TP session   |
        |            | negotiation  |    negotiation    |
        |            |    ICRQ/     |        ICRQ/      |
        |            |    ICRP/     |        ICRP/      |
        |            |    ICCN      |        ICCN       |
        |           5|<------------>|<------via Si----->|
        |            |              |                   |
        |            |              |    Create         |
        |            |              |   subscriber      |
        |            |              |    session        |
        |            |              |    Request        |
        |            |             6|<-----via Ci-------|
        |            |              |    Create         |
        |            |              |   subscriber      |
        |            |              |    session        |
        |            |              |    Response       |
        |            |             7|------via Ci------>|
        |                                               |
        |          PAP/CHAP (Triggered by LNS)          |
       8|<--------------------------------------------->|
        |                                               |
        |            |              |        |    AAA   |
        |            |              |        |  Req/Rep |
        |            |              |       9|<-------->|
        |            |              |                   |
        |                                               |
        |                   PPP IPCP                    |
      10|<--------------------------------------------->|
        |                                               |
        |            |              |    Update         |
        |            |              |   subscriber      |
        |            |              |    session        |
        |            |              |    Request        |
        |            |            11|<-----via Ci-------|
        |            |              |    Update         |
        |            |              |   subscriber      |
        |            |              |    session        |
        |            |              |    Response       |
        |            |            12|------via Ci------>|
        |            |              |                   |

                 Figure 5.4.2: IPv4 L2TP-LNS Access

   In this case, the BNG is running as an LNS and separated into LNS-CP
   and LNS-UP.  Step 1-5 finish the normal L2TP dial-up process.  When
   the L2TP session and tunnel negotiations are finished, the LNS-CP
   will create a L2TP LNS subscriber session on the LNS-UP.  The format
   of messages are as follows:



Hu, et al.              Expires November 24, 2019              [Page 48]


Internet-Draft               S-CUSP for BNG                     May 2019


   <Update_Request Message> ::= <Common Header>
                     <L2TP-LNS Subscriber TLV>
                     <Basic Subscriber TLV>
                     <PPP Subscriber TLV>
                     <IPv4 Subscriber TLV>
                     <IPv4 Routing TLV>
                     <L2TP-LNS Tunnel TLV>
                     [<Subscriber Policy TLV>]

   <Update_Response Message> ::= <Common Header>
                    <Subscriber Session Update Response TLV>
                    [<Subscriber CGN Port Range TLV>]

   After then, the LNS-CP will trigger a AAA authentication, if the
   authentication result is positive.  A PPP IPCP process will follow,
   then the CP will update the session with the following message
   exchanges:

   <Update_Request Message> ::= <Common Header>
                     <L2TP-LNS Subscriber TLV>
                     <Basic Subscriber TLV>
                     <PPP Subscriber TLV>
                     <IPv4 Subscriber TLV>
                     <IPv4 Routing TLV>
                     <L2TP-LNS Tunnel TLV>
                     [<Subscriber Policy TLV>]

   <Update_Response Message> ::= <Common Header>
                    <Subscriber Session Update Response TLV>
                    [<Subscriber CGN Port Range TLV>]

5.4.3.  L2TP LNS IPv6 Access

        RG          LAC          UP(LNS)    AAA      CP(LNS)
        |            |              |        |          |
        |    PPPoE   |              |        |          |
        |  Discovery |              |        |          |
       1|<---------->|              |        |          |
        |            |              |        |          |
        |  PPP LCP   |              |        |          |
       2|<---------->|                       |          |
        |            |          AAA          |          |
        |PPP PAP/CHAP|        Req/Rep        |          |
       3|<---------->|<--------------------->|          |
        |            |                                  |
        |            |                                  |
        |            | L2TP tunnel  |     L2TP tunnel   |
        |            | negotiation  |     negotiation   |



Hu, et al.              Expires November 24, 2019              [Page 49]


Internet-Draft               S-CUSP for BNG                     May 2019


        |            |   SCCRQ/     |       SCCRQ/      |
        |            |   SCCRP/     |       SCCRP/      |
        |            |   SCCCN      |       SCCCN       |
        |           4|<------------>|<------via Si----->|
        |            |              |                   |
        |            | L2TP session |    L2TP session   |
        |            | negotiation  |    negotiation    |
        |            |    ICRQ/     |        ICRQ/      |
        |            |    ICRP/     |        ICRP/      |
        |            |    ICCN      |        ICCN       |
        |           5|<------------>|<------via Si----->|
        |            |              |                   |
        |            |              |    Create         |
        |            |              |   subscriber      |
        |            |              |    session        |
        |            |              |    Request        |
        |            |             6|<-----via Ci-------|
        |            |              |    Create         |
        |            |              |   subscriber      |
        |            |              |    session        |
        |            |              |    Response       |
        |            |             7|------via Ci------>|
        |                                               |
        |          PAP/CHAP (Triggered by LNS)          |
       8|<--------------------------------------------->|
        |                                               |
        |            |              |        |    AAA   |
        |            |              |        |  Req/Rep |
        |            |              |       9|<-------->|
        |            |              |        |          |
        |                                               |
        |                   PPP IP6CP                   |
      10|<--------------------------------------------->|
        |                                               |
        |            |              |    Update         |
        |            |              |   subscriber      |
        |            |              |    session        |
        |            |              |    Request        |
        |            |            11|<-----via Ci-------|
        |            |              |    Update         |
        |            |              |   subscriber      |
        |            |              |    session        |
        |            |              |    Response       |
        |            |            12|------via Ci------>|
        |            |              |                   |
        |                           |                   |
        |       ND negotiation      |   ND negotiation  |
      13|<------------------------->|<-----via Si------>|



Hu, et al.              Expires November 24, 2019              [Page 50]


Internet-Draft               S-CUSP for BNG                     May 2019


        |                           |                   |
        |            |              |    Update         |
        |            |              |   subscriber      |
        |            |              |    session        |
        |            |              |    Request        |
        |            |            14|<-----via Ci-------|
        |            |              |    Update         |
        |            |              |   subscriber      |
        |            |              |    session        |
        |            |              |    Response       |
        |            |            15|------via Ci------>|
        |            |              |                   |

                 Figure 5.4.3 L2TP-LNS IPv6 Access

   Step 1-12 are the same as L2TP LNS IPv4 Access.  Step 1-5 finish the
   normal L2TP dial-up process.  When the L2TP session and tunnel
   negotiations are finished, the LNS-CP will create a L2TP LNS
   subscriber session on the LNS-UP.  The formats of the messages are as
   follows:

   <Update_Request Message> ::= <Common Header>
                     <L2TP-LNS Subscriber TLV>
                     <Basic Subscriber TLV>
                     <PPP Subscriber TLV>
                     <IPv6 Subscriber TLV>
                     <IPv6 Routing TLV>
                     <L2TP-LNS Tunnel TLV>
                     [<Subscriber Policy TLV>]

   <Update_Response Message> ::= <Common Header>
                    <Subscriber Session Update Response TLV>

   After that, the LNS-CP will trigger a AAA authentication.  If the
   authentication result is positive, a PPP IP6CP process will follow,
   then the CP will update the session with the following message
   exchanges:














Hu, et al.              Expires November 24, 2019              [Page 51]


Internet-Draft               S-CUSP for BNG                     May 2019


   <Update_Request Message> ::= <Common Header>
                     <L2TP-LNS Subscriber TLV>
                     <Basic Subscriber TLV>
                     <PPP Subscriber TLV>
                     <IPv6 Subscriber TLV>
                     <IPv6 Routing TLV>
                     <L2TP-LNS Tunnel TLV>
                     [<Subscriber Policy TLV>]

   <Update_Response Message> ::= <Common Header>
                    <Subscriber Session Update Response TLV>

   Then, a ND negotiation will be triggered by the RG.  After the ND
   negotiation, the CP will update the session with the following
   message exchanges:

   <Update_Request Message> ::= <Common Header>
                     <L2TP-LAC Subscriber TLV>
                     <Basic Subscriber TLV>
                     <PPP Subscriber TLV>
                     <IPv6 Subscriber TLV>
                     <IPv6 Routing TLV>
                     <L2TP-LNS Tunnel TLV>
                     [<Subscriber Policy TLV>]

   <Update_Response Message> ::= <Common Header>
                    <Subscriber Session Update Response TLV>

5.5.  CGN (Carrier Grade NAT)






















Hu, et al.              Expires November 24, 2019              [Page 52]


Internet-Draft               S-CUSP for BNG                     May 2019


          RG              UP                       CP             AAA
          |               |                        |               |
          |               |  Public Address Block  |               |
          |               |   Allocation Request   |               |
          |              1|---------via Ci-------->|               |
          |               |  Public Address Block  |               |
          |               |   Allocation Response  |               |
          |              2|<---------via Ci--------|               |
          |               |                        |               |
          |   Subscriber  |                        |               |
          | access request|        Subscriber      |               |
         3|-------------->|      access request    |               |
          |              4|----------via Si------->|               |
          |               |                        |      AAA      |
          |               |       Subscriber       |    Req/Rep    |
          |               |      access response  5|<------------->|
          |              6|<---------via Si--------|               |
          |   Subscriber  |                        |               |
          |access response|                        |               |
         7|<--------------|                        |               |
          |               |                        |               |
          |               |  Create subscriber     |               |
          |               |   session Request      |               |
          |              8|<--------via Ci---------|               |
          |               |                        |               |
          |               |  Create subscriber     |               |
          |               |   session Response     |               |
          |               | (with NAT information) |               |
          |              9|---------via Ci-------->|               |
          |               |                        |               |
          |               |                        |   Accounting  |
          |               |                        |  with source  |
          |               |                        |   information |
          |               |                      10|<------------->|
          |               |                        |  Public IP +  |
          |               |                        |  Port range   |
          |               |                        |  to Private IP|
          |               |                        |  mapping      |
          |               |                        |               |

                        Figure 5.5: CGN Access

   The first step is to allocate one or more CGN address blocks to the
   UP (1-2).  This is achieved by the following message exchanges
   between CP and UP.






Hu, et al.              Expires November 24, 2019              [Page 53]


Internet-Draft               S-CUSP for BNG                     May 2019


   <Addr_Allocation_Req Message> ::= <Common Header>
                     <Request Address Allocation TLV>

   <Addr_Allocation_Ack Message> ::= <Common Header>
                    <Address Assignment Response TLV>

   Step 3-9 describe the general dial-up process in the case of CGN
   mode.  The specific processes (e.g., IPoE, PPPoE, L2TP, etc.) are
   defined in above sections.

   If a subscriber is a CGN subscriber, once the subscriber session
   created/updated, the UP will report the NAT information to the CP.
   This is achieved by carrying the "Subscriber CGN Port Range TLV" in
   the Update_Response message.

5.6.  L3 Leased Line Access

5.6.1.  Web Authentication

































Hu, et al.              Expires November 24, 2019              [Page 54]


Internet-Draft               S-CUSP for BNG                     May 2019


        RG            UP              CP         AAA      WEB Server
        |             |                |          |           |
        |    User     |                |          |           |
        |   traffic   |                |          |           |
       1|------------>|                |          |           |
        |             |      User      |          |           |
        |             |    traffic     |          |           |
        |            2|-----via Si---->|    AAA   |           |
        |             |                |  Req/Rep |           |
        |             |               3|<-------->|           |
        |             | Create session |          |           |
        |             |    Request     |          |           |
        |            4|<----via Ci-----|          |           |
        |             |                |          |           |
        |             | Create session |          |           |
        |             |    Response    |          |           |
        |            5|----via Ci----->|          |           |
        |    HTTP     |                |          |           |
        |   traffic   |                |          |           |
       6|------------>|                |          |           |
        |             |                |          |           |
        | Redirect to |                |          |           |
        |   Web URL   |                |          |           |
       7|<------------|                |          |           |
        |             |                |          |           |
        |                                                     |
       8|-----------------Redirected to Web server----------->|
        |                                                     |
       9|<----------------Push HTTP Log-in page---------------|
        |                                                     |
      10|-----------------User Authentication---------------->|
        |                                                     |
        |             |                |  Portal Interchange  |
        |             |              11|<-------------------->|
        |             |                |                      |
        |             |                |   AAA    |           |
        |             |                |  Req/Rep |           |
        |             |              12|<-------->|           |
        |             |                |          |           |
        |             | Update session |          |           |
        |             |    Request     |          |           |
        |           13|<----via Ci-----|          |           |
        |             | Update session |          |           |
        |             |    Response    |          |           |
        |           14|----via Ci----->|          |           |
        |             |                |          |           |

      Figure 5.6.1: Web Authentication based L3 Leased Line Access



Hu, et al.              Expires November 24, 2019              [Page 55]


Internet-Draft               S-CUSP for BNG                     May 2019


   In this case, IP traffic from the RG will trigger the CP to
   authenticate the RG by checking the source IP and the exchanges with
   the AAA server.  Once the RG passed the authentication, the CP will
   create a corresponding subscriber session on the UP through the
   following message exchanges:

   IPv4 Case:
   <Update_Request Message> ::= <Common Header>
                     <Basic Subscriber TLV>
                     <IPv4 Subscriber TLV>
                     <IPv4 Routing TLV>
                     [<Subscriber Policy TLV>]

   <Update_Response Message> ::= <Common Header>
                    <Subscriber Session Update Response TLV>
                    [<Subscriber CGN Port Range TLV>]

   IPv6 Case:
   <Update_Request Message> ::= <Common Header>
                     <Basic Subscriber TLV>
                     <IPv6 Subscriber TLV>
                     <IPv6 Routing TLV>
                     [<Subscriber Policy TLV>]

   <Update_Response Message> ::= <Common Header>
                    <Subscriber Session Update Response TLV>

   Then, the HTTP traffic from the RG will be redirected to a WEB server
   to finish the WEB authentication.  Once the authentication passed,
   the CP will trigger another AAA authentication.  After the AAA
   authentication, the CP will update the session with the following
   message exchanges:



















Hu, et al.              Expires November 24, 2019              [Page 56]


Internet-Draft               S-CUSP for BNG                     May 2019


   IPv4 Case:
   <Update_Request Message> ::= <Common Header>
                     <Basic Subscriber TLV>
                     <IPv4 Subscriber TLV>
                     <IPv4 Routing TLV>
                     [<Subscriber Policy TLV>]

   <Update_Response Message> ::= <Common Header>
                    <Subscriber Session Update Response TLV>
                    [<Subscriber CGN Port Range TLV>]

   IPv6 Case:
   <Update_Request Message> ::= <Common Header>
                     <Basic Subscriber TLV>
                     <IPv6 Subscriber TLV>
                     <IPv6 Routing TLV>
                     [<Subscriber Policy TLV>]

   <Update_Response Message> ::= <Common Header>
                    <Subscriber Session Update Response TLV>

5.6.2.  User Traffic Trigger

        RG            UP              CP         AAA
        |             |                |          |
        |             |   L3 access    |          |
        |             |  control list  |          |
        |            1|<----via Ci-----|          |
        |    User     |                |          |
        |   traffic   |                |          |
       2|------------>|                |          |
        |             |      User      |          |
        |             |    traffic     |          |
        |            3|-----via Si---->|          |
        |             |                |   AAA    |
        |             |                |  Req/Rep |
        |             |               4|<-------->|
        |             |                |          |
        |             | Create session |          |
        |             |    Request     |          |
        |            5|<----via Ci-----|          |
        |             | Create session |          |
        |             |    Response    |          |
        |            6|----via Ci----->|          |
        |             |                |          |

   Figure 5.6.2: User Traffic Triggered L3 Leased Line Access




Hu, et al.              Expires November 24, 2019              [Page 57]


Internet-Draft               S-CUSP for BNG                     May 2019


   In this user traffic triggered case, the CP must install an access
   control list on the UP, which is used by the UP to determine whether
   an RG is legal or not.  If the traffic is from a legal RG, it will be
   redirected to the CP though the Si.  The CP will trigger an AAA
   interchange with the AAA server.  After that, the CP will create a
   corresponding subscriber session on the UP with the following message
   exchanges:

   IPv4 Case:
   <Update_Request Message> ::= <Common Header>
                     <Basic Subscriber TLV>
                     <IPv4 Subscriber TLV>
                     <IPv4 Routing TLV>
                     [<Subscriber Policy TLV>]

   <Update_Response Message> ::= <Common Header>
                    <Subscriber Session Update Response TLV>
                    [<Subscriber CGN Port Range TLV>]

   IPv6 Case:
   <Update_Request Message> ::= <Common Header>
                     <Basic Subscriber TLV>
                     <IPv6 Subscriber TLV>
                     <IPv6 Routing TLV>
                     [<Subscriber Policy TLV>]

   <Update_Response Message> ::= <Common Header>
                    <Subscriber Session Update Response TLV>

5.7.  Multicast Access





















Hu, et al.              Expires November 24, 2019              [Page 58]


Internet-Draft               S-CUSP for BNG                     May 2019


          RG            UP              CP         AAA
          |             |                |          |
          | User access |  User access   |   AAA    |
          |   request   |    request     |  Req/Rep |
         1|<----------->|<----via Si---->|<-------->|
          |             |      User      |          |
          |             |                |          |
          |             |                |          |
          |             | Create session |          |
          |             |    Request     |          |
          |            2|<----via Ci---->|          |
          |             |                |          |
          |             | Create session |          |
          |             |    Response    |          |
          |            3|----via Ci----->|          |
          |             |                |          |
          |  Multicast  |                |          |
          | negotiation |                |          |
         4|<----------->|                |          |
          |             |                |          |

                  Figure 5.6: Multicast Access

   Multicast access starts with a user access request from the RG.  The
   request will be redirected to the CP by the Si.  A follow-up AAA
   interchange between the CP and the AAA server will be triggered.
   After the authentication, the CP will create a multicast subscriber
   session on the UP through the following messages:























Hu, et al.              Expires November 24, 2019              [Page 59]


Internet-Draft               S-CUSP for BNG                     May 2019


   IPv4 Case:
   <Update_Request Message> ::= <Common Header>
                     <Multicast Group Information TLV>
                     <Basic Subscriber TLV>
                     <IPv4 Subscriber TLV>
                     <IPv4 Routing TLV>
                     [<Subscriber Policy TLV>]

   <Update_Response Message> ::= <Common Header>
                    <Subscriber Session Update Response TLV>
                    [<Subscriber CGN Port Range TLV>]

   IPv6 Case:
   <Update_Request Message> ::= <Common Header>
                     <Multicast Group Information TLV>
                     <Basic Subscriber TLV>
                     <IPv6 Subscriber TLV>
                     <IPv6 Routing TLV>
                     [<Subscriber Policy TLV>]

   <Update_Response Message> ::= <Common Header>
                    <Subscriber Session Update Response TLV>

6.  S-CUSP Message Formats

   An S-CUSP message consists of a common header followed by a variable-
   length body consisting entirely of TLVs.  Receiving an S-CUSP message
   with a missing mandatory TLV must trigger an Error message (see
   Section 7.2 and 8.6).  Conversely, if a TLV is optional, the TLV may
   or may not be present.  Optional TLVs are indicated in the message
   formats shown in this document by being enclosed in square brackets.

   This section specifies the format of the common S-CUSP message header
   and lists the defined message.

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

6.1.  Common Message 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         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                    Figure 7.1. S-CUSP Message Common Header



Hu, et al.              Expires November 24, 2019              [Page 60]


Internet-Draft               S-CUSP for BNG                     May 2019


   o  Ver (4 bits): The major version of the protocol.  This document
      specifies version 1.  Different major versions of the protocol may
      have significantly different message structure and format except
      that the Ver field will always be in the same place at the
      beginning of each message.  A successful S-CUSP session depends on
      the CP and UP both using the same major version of the protocol.

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

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

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

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

6.2.  Control Messages

   This document defines the following control messages:

      Type  Name              Notes and TLVs that can be carried
      ----  ----              ------------------------------------
         1  Hello             Hello TLV, Keep-Alive TLV.
         2  Keepalive         A common header with the Keepalive message
                              type.
         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.
         7  Update_Request    TLVs specified in Sections 8.7 and 8.8.
         8  Update_Response   TLVs specified in Sections 8.7 and 8.8.

6.2.1.  Hello Message

   Hello message is used for S-CUSP session establishment and version
   negotiation.  The detail of S-CUSP session establishment and version
   negotiation can be found in Section 4.1.1.

   The format of Hello message is as follows:






Hu, et al.              Expires November 24, 2019              [Page 61]


Internet-Draft               S-CUSP for BNG                     May 2019


   <Hello Message> ::= <Common Header>
                        <Hello TLV>
                        <Keepalive TLV>
                        [<Error Information TLV>]

   The return code and negotiation result will be carried in the Error
   Information TLV.  They are listed as follows:

      0: Success, version negotiation success.

      1: Failure, malformed message received.

      2: One or more of the TLVs was not understood.

      1001: Version-Mismatch.  The version negotiation fails.
      Terminate.  The subsequent service processes corresponding to the
      UP are suspended.

6.2.2.  Keepalive Message

   The Keepalive message is periodically sent by each end of an S-CUSP
   session.  It is used to detect whether the peer end is still alive.
   The Keepalive procedures are defined Section 4.1.1.

   The format of Keepalive message is as follows:

   <Keepalive Message> ::= <Common Header>

6.2.3.  Synch_Request Message

   The Synch_Request message is used to request synchronization from an
   S-CUSP peer.  Both the CP and UP can request their to peer to
   synchronize data.

   The format of Synch_Request message is as follows:

   <Keepalive Message> ::= <Common Header>

   A Synch_Request message may result in a Synch_Begin message from its
   peer.  The Synch_Begin message is defined in Section 6.2.4.

6.2.4.  Sync_Begin Message

   The Sync_Begin message is a reply to a Sync_Request message.  It is
   used to notify the synchronization requester as to whether the
   synchronization can be started.

   The format of Sync_Begin message is as follows:



Hu, et al.              Expires November 24, 2019              [Page 62]


Internet-Draft               S-CUSP for BNG                     May 2019


   <Keepalive Message> ::= <Common Header>
                           <Error Information TLV>

   The return codes are carried in the Error Information TLV.  The codes
   are listed below:

      0: Success, be ready to synchronize.

      1: Failure, malformed message received.

      2: One or more of the TLVs was not understood.

      2001: Synch-NoReady.  The data to be synchronized is not ready.

      2002: Synch-Unsupport.  The data synchronization is not supported.

6.2.5.  Sync_Data Message

   The Sync_Data message is used to synchronize data between CP and UP.
   Sync_Data message has the same function and format as Update_Request
   message.  The difference is that there is no ACK for Sync_Data
   message.  An error caused by the Sync_Data message will result in a
   Sync_End message.

   There are two scenarios:

      Synchronization from UP to CP: Synchronize the resource data to
      CP.



   <Sync_Data Message> ::= <Common Header>
                           [<Resource Reporting TLVs>]

      Synchronization from CP to UP: Synchronize all subscriber sessions
      to UP.  As for which TLVs should be carried, it depends on the
      specific session data to be synchronized.  This is equivalent to
      create the specific session.  Refer to Section 4.2.5 to see more
      details.

   <Sync_Data Message> ::= <Common Header>
                           [<User Routing TLVs>]
                           [<User Information TLVs>]
                           [<L2TP Subscriber TLVs>]
                           [<Subscriber CGN Port Range TLV>]
                           [<Subscriber Policy TLV>]





Hu, et al.              Expires November 24, 2019              [Page 63]


Internet-Draft               S-CUSP for BNG                     May 2019


6.2.6.  Sync_End Message

   The Sync_End message is used to indicate the end of synchronization
   process.  The format of Sync_End message is as follows:

   <Keepalive Message> ::= <Common Header>
                           <Error Information TLV>

   The return/error codes are listed as follows:

      0: Success, synchronization finished.

      1: Failure, malformed message received.

      2: One or more of the TLVs was not understood.

6.2.7.  Update_Request Message

   The Update_Request message is a multi-task message, it can be used to
   create, update and delete subscriber session on a UP.

   For session operations, the specific operation is controlled by the
   "Oper" field of the carried TLVs.  As defined in Section 7.1, the
   "Oper" can be set to either "update" or "delete" when a TLV is
   carried in an Update_Request message.

   When the "Oper" set to update, it means to create or update a
   subscriber session, if the "Oper" set to delete, it indicates to
   delete a corresponding session on a UP.

   The format of Update_Request message is as follows:

   <Update_Request Message> ::= <Common Header>
                           [<User Routing TLVs>]
                           [<User Information TLVs>]
                           [<L2TP Subscriber TLVs>]
                           [<Subscriber CGN Port Range TLV>]
                           [<Subscriber Policy TLV>]

   Each Update_Request message will result in a UPdate_Response message
   that is defined in Section 6.2.8.

6.2.8.  Update_Response Message

   The Update_Response message is a response to a UPdate_Request
   message.  It is used to confirm the update request.  The format of
   Update_Response message is as follows:




Hu, et al.              Expires November 24, 2019              [Page 64]


Internet-Draft               S-CUSP for BNG                     May 2019


   <Update_Response Message> ::= <Common Header>
                           [<Subscriber CGN Port Range TLV>]
                           [<Error Information TLV>]

   The return/error codes are carried in the Error Information TLV.
   They are listed as follows:

      0: Success.

      1: Failure, malformed message received.

      2: One or more of the TLVs was not understood.

      3001(Pool-Mismatch): The corresponding address pool cannot be
      found.

      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.

      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.

6.3.  Event Message

   The Event message is used to report subscriber session traffic
   statistics and detection information.  The format of Event message is
   as follows:

   <Report Message> ::= <Common Header>
                           [<User Traffic Statistics Report TLV>]
                           [<User Detection Result Report TLV>]




Hu, et al.              Expires November 24, 2019              [Page 65]


Internet-Draft               S-CUSP for BNG                     May 2019


6.4.  Report Message

   The Report message is used to report board and interface status on a
   UP.  The format of Report message is as follows:

   <Report Message> ::= <Common Header>
                           [<Board Status TLVs>]
                           [<Interface Status TLVs>]

6.5.  CGN Messages

   This document defines the following resource allocation messages:

      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

6.5.1.  Addr_Allocation_Req Message

   The Addr_Allocation_Req message is used to request CGN address
   allocation.  The format of Addr_Allocation_Req message is as follows:

   <Addr_Allocation_Req Message> ::= <Common Header>
                           <Address Allocation Request TLV>

6.5.2.  Addr_Allocation_Ack Message

   The Addr_Allocation_Ack message is a response to an
   Addr_Allocation_Req message.  The format of Addr_Allocation_Ack
   message is as follows:

   <Addr_Allocation_Ack Message> ::= <Common Header>
                           <Address Allocation Response TLV>

6.5.3.  Addr_Renew_Req Message

   The Addr_Renew_Req message is used to request address renewal.  The
   format of Addr_Renew_Req message is as follows:

   <Addr_Renew_Req Message> ::= <Common Header>
                           <Address Renewal Request TLV>





Hu, et al.              Expires November 24, 2019              [Page 66]


Internet-Draft               S-CUSP for BNG                     May 2019


6.5.4.  Addr_Renew_Ack Message

   The Addr_Renew_Ack message is a response to an Addr_Renew_Req
   message.  The format of Addr_Renew_Req message is as follows:

   <Addr_Renew_Ack Message> ::= <Common Header>
                           <Address Renewal Response TLV>

6.5.5.  Addr_Release_Req Message

   The Addr_Release_Req message is used to request address release.  The
   format of Addr_Release_Req message is as follows:

   <Addr_Release_Req Message> ::= <Common Header>
                           <Address Release Request TLV>

6.5.6.  Addr_Release_Ack Message

   The Addr_Release_Ack message is a response to an Addr_Release_Req
   message.  The format of Addr_Release_Ack message is as follows:

   <Addr_Renew_Ack Message> ::= <Common Header>
                           <Address Renewal Release TLV>

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

7.  S-CUSP TLVs and Sub-TLVs

   This section specifies the following

   o  the format of the TLVs that appear in S-CUSP messages,

   o  the format of the sub-TLVs that appear within the values of some
      TLVs, and

   o  the format of some basic data fields that appear within TLVs or
      sub-TLVs.

   In addition, it lists all defined TLVs and sub-TLVs.





Hu, et al.              Expires November 24, 2019              [Page 67]


Internet-Draft               S-CUSP for BNG                     May 2019


7.1.  Common TLV Header

   S-CUSP messages consist of the common header specified in Section 7.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                                  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...

                         Figure 7.1. Common TLV Header

   o  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 9.3.  For all other Message-
      Types, the Oper field must be sent as zero and ignored on receipt.

   o  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 9.2.

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

   o  Value (variable length): This is the value portion of the TLV
      whose size is given by TLV-Length.  The value portion consists of
      fields, frequently using one of the basic data field types (see
      Section 7.2) and sub-TLVs (see Section 7.3).

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

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

   o  MAC-Addr: 6 octets.  Ethernet MAC Address.

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






Hu, et al.              Expires November 24, 2019              [Page 68]


Internet-Draft               S-CUSP for BNG                     May 2019


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

   o  VLAN ID: 2 octets.  As follows [802.1Q]:

                    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. (0 and
                   4095 are not valid VLAN IDs[802.1Q].)

7.3.  Sub-TLV Format and 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                                  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...

                           Figure 7.3. Sub-TLV Header

   o  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 sub-
      TLV.  Sub-TLV Types numbers have the same meaning regardless of
      the TLV Type of the TLV within which the sub-TLV occurs.  See
      Section 9.4.

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

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

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






Hu, et al.              Expires November 24, 2019              [Page 69]


Internet-Draft               S-CUSP for BNG                     May 2019


7.3.1.  Name sub-TLVs

   This document defines the following name sub-TLVs, it is used to
   carry the name of the corresponding object.  The length of each sub-
   TLV are variable from 1 to 255 octets.  The value is STRING type.

   Type    Sub-TLV Name            Meaning
  -----    --------------------    -------------------
     1     VRF-Name                The name of a VRF
     2     Ingress-QoS-Profile     The name of an ingress QoS profile
     3     Egress-QoS-Profile      The name of an egress QoS profile
     4     User-ACL-Policy         The name of an ACL policy
     5     Multicast-ProfileV4     The name of an IPv4 multicast profile
     6     Multicast-ProfileV6     The name of an IPv6 multicast profile
     7     NAT-Instance            The name of a NAT instance
     8     Pool-Name               The name of an address pool

7.3.2.  Ingress-CAR sub-TLV

   Ingress-CAR sub-TLV indicates the authorized upstream Committed
   Access Rate (CAR) parameters.  The sub-TLV type of Ingress-CAR sub-
   TLV is 9, the sub-TLV length is 16 octets.  The format is as defined
   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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                              CIR                              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                              PIR                              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                              CBS                              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                              PBD                              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                   Figure 7.3.2 Ingress-CAR sub-TLV

   Where:

      CIR: 4 bytes in length, indicates the guaranteed rate in bits/
      second.

      PIR: 4 bytes in length, indicates the burst rate in bits/second.

      CBS: 4 bytes in length, indicates the token bucket in bytes.

      PBS: 4 bytes in length, indicates the burst token bucket in bytes.



Hu, et al.              Expires November 24, 2019              [Page 70]


Internet-Draft               S-CUSP for BNG                     May 2019


   These fields are unsigned integers.

7.3.3.  Egress-CAR sub-TLV

   Ingress-CAR sub-TLV indicates the authorized downstream Committed
   Access Rate (CAR) parameters.  The sub-TLV type of Egress-CAR sub-TLV
   is 10, the sub-TLV length is 16 octets.  The format is as defined
   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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                              CIR                              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                              PIR                              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                              CBS                              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                              PBD                              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                    Figure 7.3.3 Egress-CAR sub-TLV

   Where:

      CIR: 4 bytes in length, indicates the guaranteed rate in bits/
      second.

      PIR: 4 bytes in length, indicates the burst rate in bits/second.

      CBS: 4 bytes in length, indicates the token bucket in bytes.

      PBS: 4 bytes in length, indicates the burst token bucket in bytes.

   These fields are unsigned integers.

7.3.4.  If-Desc sub-TLV

   If-Desc sub-TLV is defined to describe an interface.  The sub-TLV
   type is 11, the sub-TLV length is 12 octets.  The sub-TLV format is
   as follows:










Hu, et al.              Expires November 24, 2019              [Page 71]


Internet-Draft               S-CUSP for BNG                     May 2019


       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    |                Reserved                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Chassis    |      Slot     |        Port Information       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Sub-Port Number                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                            Figure 7.3.4. If-Desc sub-TLV

   Where:

      If-Type: 8 bits in length, indicates the type of an interface.
      Following types are defined in this document:

         0: Reserved,

         1: Fast Ethernet (FE)

         2: GE

         3: 10GE

         4: 100GE

         5: Eth-Trunk

         6: Tunnel

         7: VE

         8-255: Reserved.

      Chassis: Identify the chassis that the interface belongs to.

      Slot: Identify the slot that the interface belongs to.

      Port Information

         if the If-Type identifies a physical interface (e.g., If Type:
         1-5), the Port Information consists of a 1-byte Physical Slot
         number followed by a 1-byte Physical port number.

         If-Type identifies a virtual port (e.g., If-Type: 6-7), the
         Port Information consists of a 2 byte logical number of the
         virtual interface.



Hu, et al.              Expires November 24, 2019              [Page 72]


Internet-Draft               S-CUSP for BNG                     May 2019


      Sub-Port number: The number of the Sub-Port.

7.3.5.  IPv6 Address List sub-TLV

   The IPv6 Address List sub-TLV is used to convey one or more IPv6
   addresses.  It is carried in the IPv6 Subscriber TLV.  The sub-TLV
   type is 12, the sub-TLV length is variable.

   The format of IPv6 Addresses sub-TLV 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ~                        IPv6 Address                           ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ~                        IPv6 Address                           ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ~                            ...                                ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ~                        IPv6 Address                           ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 7.3.5. IPv6 Address List sub-TLV

   Where:

      IP Address (IPv6-Address): Each IP Address is an IP-Address type,
      carries an IPv6 address.

7.4.  The Hello TLV

   The Hello TLV is defined to be carried in the Hello message for
   version and capabilities negotiation.  It indicates the S-CUSP sub-
   version and capabilities supported.  The format of Hello TLV 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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                          VerSupported                         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                           Vendor ID                           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                           Capabilities                        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                             Figure 7.4: Hello TLV




Hu, et al.              Expires November 24, 2019              [Page 73]


Internet-Draft               S-CUSP for BNG                     May 2019


   Where:

   The TLV type is 100.

   The TLV length is 12 octets.

   The value field include three parts:

      VerSupported: 32 bits in length.  This is a bit map of the Sub-
      Versions of the S-CUSP protocol that the sender supports.  This
      document specifies Sub-Version zero of Major Version 1, that is,
      Version 1.0.  The VerSupported field must be non-zero.  Bit 0
      indicates support of Sub-Version zero, bit 1 indicates support of
      Sub-Version one, etc.

      Vendor-ID: 4 bytes in length.  Vendor ID, as defined in RADIUS
      [RFC2865].

      Capabilities: 32 bits in length.  Flags that indicate the support
      of particular capabilities by the sender of the Hello.

   After the exchange of Hello messages, the CP and UP each perform a
   logical AND of the Sub-Version supported by the CP and the UP and
   separately perform a logical AND of the Capabilities bits fields for
   the CP and the UP.

   If the result of the AND of the Sub-Versions supported is zero, then
   no session can be established and the connection is torn down.  If
   the result of the AND of the Sub-Versions supported is non-zero, then
   the session uses the highest Sub-Version supported by both the CP and
   UP.

   For example, if one side supports Sub-Versions 1, 3, 4, and 5
   (VerSupported = 0x5C000000) and the other side supports 2, 3, and 4
   (VerSupported = 0x38000000) then 3 and 4 are the Sub-Versions in
   common and 4 is the highest Sub-Version supported by both sides.  So
   Sub-Version 4 is used for the session that has been negotiated.

   The result of the logical AND of the Capabilities bits will show what
   additional capabilities both sides support.  If this result is zero,
   there are no such capabilities so none can be used during the
   session.  If this result is non-zero, it shows the additional
   capabilities that can be used during the session.  The CP and the UP
   must not use a capability unless both advertise support.







Hu, et al.              Expires November 24, 2019              [Page 74]


Internet-Draft               S-CUSP for BNG                     May 2019


7.5.  The Keep Alive TLV

   The Keep Alive TLV is defined to be carried in the Hello message.  It
   provides timing information for the keep alive feature.  The format
   of Hello TLV 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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Keepalive   | DeadTimer     |            Reserved           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                             Figure 7.5: Keep Alive TLV

   Where:

      The TLV type: 102.

      The value of length: 4 octets.

      Keepalive, 8 bits in length.  Indicates the maximum period of time
      (in seconds) between two consecutive S-CUSP messages sent by the
      sender of the message containing this TLV as an unsigned integer.
      The minimum value for the Keepalive is 1 second.  When set to 0,
      once the session is established, no further Keepalive messages are
      sent to the remote peer.  A recommended value for the Keepalive
      frequency is 30 seconds.

      DeadTimer, 8 bits in length.  Specifies the amount of time as an
      unsigned integer number of seconds after the expiration of which
      the S-CUSP peer can declare the session with the sender of the
      Hello message to be down if no S-CUSP message has been received.
      The DeadTimer shouldbe set to 0 and must be ignored if the
      Keepalive is set to 0.  A recommended value for the DeadTimer is 4
      times the value of the Keepalive.

7.6.  The Error Information TLV

   The Error Information TLV is a common TLV that can be used in many
   Response (e.g., Update_Response message) and ACK messages (e.g.,
   Addr_Allocation_Ack message, etc.).  It is used to convey the
   information about an error in the received S-CUSP message.  The
   format of the Error Information TLV is as follows:








Hu, et al.              Expires November 24, 2019              [Page 75]


Internet-Draft               S-CUSP for BNG                     May 2019


        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 |    Reserved   |        TLV Type               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                           Status Code                         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                     Figure 7.6: Error Information TLV

   Where:

      The TLV type: 101.

      The value of length: 8 octets.

      Message-Type(1 byte): This parameter is the message type of the
      message containing an error.

      Reserved (1 byte): Must be sent as zero and ignored on receipt.

      TLV-Type (2 bytes): If the error was inside a TLV, this the TLV-
      Type of that TLV.

      Status Code: 4 bytes in length.  Indicate the specific Error Code
      (see Section 11.2.5).

7.7.  BAS Function Enabler TLV

   The BAS Function Enabler TLV is used by a CP to control the access
   mode, authentication methods, and other related functions of an
   interface on a UP.

   The format of the BAS Function Enabler 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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                          If-Index                             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |  Access-Mode  |  Auth-Method4 |  Auth-Method6 |    Reserved   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                             Flags                             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       ~                         sub-TLVs (optional)                   ~
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                     Figure 7.7: BAS Function Enabler TLV



Hu, et al.              Expires November 24, 2019              [Page 76]


Internet-Draft               S-CUSP for BNG                     May 2019


   Where:

      The TLV type: 1.

      The value of length: variable.

      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, it 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.

      Auth-Method6: 1 byte in length, for IPv6 scenario, it 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;




Hu, et al.              Expires November 24, 2019              [Page 77]


Internet-Draft               S-CUSP for BNG                     May 2019


         0x8: Web fast authentication;

         0x10: Binding authentication;

   The flags field is defined 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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                MBZ                            |Y|X|P|I|N|A|S|F|
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                          Figure 7.7.1: 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.

      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.







Hu, et al.              Expires November 24, 2019              [Page 78]


Internet-Draft               S-CUSP for BNG                     May 2019


7.8.  Routing TLVs

   Normally, after an S-CUSP session established between a UP and CP,
   the CP will allocate one or more blocks of IP addresses to the UP.
   Those IP addresses will be allocated to subscribers who will dial-up
   to the UP.  In order to make sure that other nodes within the network
   learn how to reach those IP addresses, the CP needs to install one or
   more routes that can reach those IP addresses on the UP and notify
   the UP to advertise the routes to the network.

   The Routing TLVs are used by a CP to notify a UP of the network
   routing.  They can be carried in the Update_Request message and
   Data_Sycn message.

7.8.1.  IPv4 Routing TLV

   The IPv4 Routing TLV is used to carry IPv4 network routing related
   information.

   The format of this TLV 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                              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                          Dest-Address                         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                          Next-Hop                             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                          Out-If-Index                         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                          Cost                                 |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                          Tag                                  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |        Route Type             |          Reserved           |A|
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       ~                          sub-TLVs                             ~
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                         Figure 7.8.1: IPv4 Routing TLV

   Where:

      The TLV Type: 7

      The TLV Length: Variable



Hu, et al.              Expires November 24, 2019              [Page 79]


Internet-Draft               S-CUSP for BNG                     May 2019


      User-ID: 4 bytes in length.  Carry the user identifier.  This
      field is filled with all Fs when a non-user route is delivered to
      the UP.

      Dest-Address: IPv4 type.  Identify the destination address.

      Next-Hop: IPv4 type.  Identify the next hop address.

      Out-If-Index: 4 bytes in length.  Indicates the interface index.

      Cost: 4 bytes in length.  The cost value of the route.

      Tag: 4 bytes in length.  The tag value of the route.

      Route-Type: 2 bytes in length.  Indicate the route type.  The
      options are as follows:

         0: User host route

         1: Radius authorization FrameRoute

         2: Network segment route

         3: Gateway route

         4: Radius authorized IP route

         5: L2TP LNS side user route



      Advertise-Flag:1 bit.  Indicates whether the route should be
      advertised by the UP.  Following flags are defined:

         0: Not advertised,

         1: advertised.

      sub-TLVs: VRF-Name Sub-TLV can be carried.

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

7.8.2.  IPv6 Routing TLV

   The IPv6 Routing TLV is used to carry IPv6 network routing
   information.

   The format of the this TLV is as follows:



Hu, et al.              Expires November 24, 2019              [Page 80]


Internet-Draft               S-CUSP for BNG                     May 2019


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

                    Figure 7.8.2: IPv6 Routing TLV

   Where:

      The TLV Type: 7

      The TLV Length: Variable

      User-ID: 4 bytes in length.  Carry the user identifier.  This
      field is filled with all Fs when a non-user route is delivered to
      the UP.

      IPv6 Dest-Address: IPv6 type.  Identify the destination address.

      IPv6 Next-Hop: IPv6 type.  Identify the next hop address.

      Out-If-Index: 4 bytes in length.  Indicates the interface index.

      Cost: 4 bytes in length.  The cost value of the route.

      Tag: 4 bytes in length.  The tag value of the route.

      Route-Type: 2 bytes in length.  Indicate the route type.  The
      options are as follows:

         0: User host route

         1: Radius authorization FrameRoute



Hu, et al.              Expires November 24, 2019              [Page 81]


Internet-Draft               S-CUSP for BNG                     May 2019


         2: Network segment route

         3: Gateway route

         4: Radius authorized IP route

         5: L2TP LNS side user route

      Advertise-Flag:1 bit.  Indicates whether the route should be
      advertised by the UP.  Following flags are defined:

         0: Not advertised,

         1: advertised.

      VRF-Name Sub-TLV: Indicates the subscriber belongs to which VRF.

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

7.9.  Subscriber TLVs

7.9.1.  Basic Subscriber TLV

   The Basic Subscriber TLV is used to carry the basic common
   information for all kinds of access subscribers.  It is carried in a
   UPdate_Request message.

   The format of the Basic Subscriber TLV value part is as follows:























Hu, et al.              Expires November 24, 2019              [Page 82]


Internet-Draft               S-CUSP for BNG                     May 2019


        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 (cont.)  |   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 7.9.1: Basic Subscriber TLV

   Where:

      The TLV Type: 2

      The TLV Length: variable in length;

      User-ID (4 bytes): The identifier of a subscriber.

      User-Mac (MAC-Addr): The MAC Address of a subscriber.

      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 subscriber.  Zero
      means non-PPPoE subscriber.

      Access-Type (1 byte):

         1: PPP access (PPP)

         2: PPP over Ethernet over ATM access (PPPoEoA)

         3: PPP over ATM access (PPPoA)




Hu, et al.              Expires November 24, 2019              [Page 83]


Internet-Draft               S-CUSP for BNG                     May 2019


         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)

      Sub-Access-Type (1 byte): Indicates whether PPP termination or PPP
      relay is used.

         0: Reserved

         1: PPP Relay (for LAC)

         2: PPP termination (for LNS)

      Account-Type(1 byte):

         0: Collects statistics on IPv4 and IPv6 traffic of terminals
         independently.

         1: Collects statistics on IPv4 and IPv6 traffic of terminals.

      Address Family (1 byte)

         1: IPv4

         2: IPv6



Hu, et al.              Expires November 24, 2019              [Page 84]


Internet-Draft               S-CUSP for BNG                     May 2019


         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): Indicates the 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.

7.9.2.  PPP Subscriber TLV

   The PPP Subscriber TLV is defined to carry PPP information of a User,
   from a CP to a UP.  It will be carried in a UPdate_Request message
   when PPPoE or L2TP access is used.

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

                     Figure 7.9.2: PPP Subscriber TLV

   Where:

      The TLV type: 3.




Hu, et al.              Expires November 24, 2019              [Page 85]


Internet-Draft               S-CUSP for BNG                     May 2019


      The TLV length: 12 octets.

      User-ID (4 bytes): The identifier of a subscriber.

      MSS-Value(2 bytes): Indicates the MSS value.

      MSS-Enable(1 bit): Indicates whether the MSS is enabled.

         0: Disabled.

         1: Enabled.

      MRU(2 bytes): PPPoE 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.

7.9.3.  IPv4 Subscriber TLV

   The IPv4 Subscriber TLV is defined to carry IPv4 related information
   for a BNG user.  It will be carried in a UPdate_Request message when
   IPv4 IPoE, PPPoE access are used.

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

                     Figure 7.9.3: IPv4 Subscriber TLV

   Where:

      The TLV type: 4.



Hu, et al.              Expires November 24, 2019              [Page 86]


Internet-Draft               S-CUSP for BNG                     May 2019


      The TLV length: variable.

      User-ID (4 bytes): The identifier of a subscriber.

      User-IPv4 (IPv4-Address): The IPv4 address of the subscriber.

      Gateway-IPv4 (IPv4-Address): The gateway address of the
      subscriber.

      Portal Force (P) (1 bit ): Push advertisement, 0: off, 1: on.

      Web-Force (W) (1 bit): Push IPv4 Web. 0: off, 1: on.

      Echo-Enable (E) (1 bit): UP returns ARP Req or PPP Echo. 0: off,
      1: on.

      IPv4-URPF (U) (1 bit): User Unicast Reverse Path Forwarding (URPF)
      flag. 0: off, 1: on.

      MTU 2 bytes MTU value.  The default value is 1500.

      VRF-Name Sub-TLV: Indicates the subscriber belongs to which VRF.

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

7.9.4.  IPv6 Subscriber TLV

   The IPv6 Subscriber TLV is defined to carry IPv6 related information
   for a BNG user.  It will be carried in a UPdate_Request message when
   IPv6 IPoE, PPPoE access are used.

   The format of the TLV value part is as follows:



















Hu, et al.              Expires November 24, 2019              [Page 87]


Internet-Draft               S-CUSP for BNG                     May 2019


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

                     Figure 7.9.4: IPv6 Subscriber TLV

   Where:

      The TLV type: 5.

      The TLV length: variable.

      User-ID (4 bytes): The identifier of a subscriber.

      User PD-Addresses (IPv6 Address List): Carry a list of Prefix
      Delegation (PD) addresses of the subscriber.

      User ND-Addresses (IPv6 Address List): Carry a list of Neighbor
      Discovery (ND) addresses of the subscriber.

      User IANA-Address (IPv6-Address): The IANA address of the
      subscriber. .

      IPv6 Interface ID (8 bytes): The identifier of an IPv6 interface.

      Portal Force 1 bit (P): Push advertisement, 0: off, 1: on.

      Web-Force 1 bit (W): Push IPv6 Web, 0: off, 1: on.

      Echo-Enable 1 bit (E): The UP returns ARP Req or PPP Echo. 0: off;
      1: on.




Hu, et al.              Expires November 24, 2019              [Page 88]


Internet-Draft               S-CUSP for BNG                     May 2019


      IPv6-URPF 1 bit (U): User Reverse Path Forwarding (URPF) flag, 0:
      off; 1: on.

      MTU (2 bytes): The MTU value.  The default value is 1500.

      VRF-Name Sub-TLV: Indicates the subscriber belongs to which VRF.

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

7.9.5.  IPv4 Static Subscriber TLV

   The IPv4 Static Subscriber TLV is defined to carry IPv4 related
   information for a static access BNG user.  It will be carried in a
   UPdate_Request message when IPv4 static access is used.

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

                 Figure 7.9.5: IPv4 Static Subscriber TLV

   Where:

      The TLV type: 6.

      The TLV length: variable.

      If-Index (4 bytes): The interface index of the interface from
      which the subscriber will dial-up.

      C-VID (VLAN-ID): Indicates the inner VLAN ID.  The value 0
      indicates that the VLAN ID is invalid.  Valid values are 1~4094.



Hu, et al.              Expires November 24, 2019              [Page 89]


Internet-Draft               S-CUSP for BNG                     May 2019


      P-VID (VLAN-ID): Indicates the outer VLAN ID.  The value 0
      indicates that the VLAN ID is invalid.  The format is the same as
      that of the C-VID.  Valid values are 1~4094.  For a single-layer
      VLAN, set this parameter to PeVid.

      User Address (IPv4-Addr): The user's IPv4 address.

      Gateway Address (IPv4-Addr): The gateway's IPv4 Address.

      User-MAC (MAC-Addr): The MAC address of the subscriber.

      VRF-Name Sub-TLV: Indicates the subscriber belongs to which VRF.

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

7.9.6.  IPv6 Static Subscriber TLV

   The IPv6 Static Subscriber TLV is defined to carry IPv6 related
   information for a static access BNG subscriber.  It will be carried
   in a UPdate_Request message when IPv6 static access is used.

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

                 Figure 7.9.6: Static IPv6 Subscriber TLV

   Where:

      The TLV type: 6.

      The TLV length: variable.



Hu, et al.              Expires November 24, 2019              [Page 90]


Internet-Draft               S-CUSP for BNG                     May 2019


      If-Index (4 bytes): The interface index of the interface from
      which the subscriber will dial-up.

      C-VID (VLAN-ID): Indicates the inner VLAN ID.  The value 0
      indicates that the VLAN ID is invalid.  Valid values are 1~4094.

      P-VID (VLAN-ID): Indicates the outer VLAN ID.  The value 0
      indicates that the VLAN ID is invalid.  The format is the same as
      that of the C-VID.  Valid values are 1~4094.  For a single-layer
      VLAN, set this parameter to PeVid.

      User Address (IPv6-Addr): The subscriber's IPv6 address.

      Gateway Address (IPv6-Addr): The gateway's IPv6 Address.

      User-MAC (MAC-Addr): The MAC address of the subscriber.

      VRF-Name Sub-TLV: Indicates the subscriber belongs to which VRF.

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

7.9.7.  L2TP-LAC Subscriber TLV

   The L2TP-LAC Subscriber TLV is defined to carry the related
   information for a L2TP LAC access subscriber.  It will be carried in
   a UPdate_Request message when L2TP LAC access is used.

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

                   Figure 7.9.7: L2TP-LAC Subscriber TLV

   Where:

      The TLV type: 11.

      The TLV length: 12 octets.

      User-ID (4 bytes): The identifier of a user/subscriber.



Hu, et al.              Expires November 24, 2019              [Page 91]


Internet-Draft               S-CUSP for BNG                     May 2019


      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 of the L2TP
      tunnel.

7.9.8.  L2TP-LNS Subscriber TLV

   The L2TP-LAC Subscriber TLV is defined to carry the related
   information for a L2TP LNS access subscriber.  It will be carried in
   a UPdate_Request message when L2TP LNS access is used.

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

                   Figure 7.9.8: L2TP-LAC Subscriber Information TLV

   Where:

      The TLV type: 12.

      The TLV length: 12 octets.

      User-ID (4 bytes): The identifier of a user/subscriber.

      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 of the L2TP
      tunnel.




Hu, et al.              Expires November 24, 2019              [Page 92]


Internet-Draft               S-CUSP for BNG                     May 2019


7.9.9.  L2TP-LAC Tunnel TLV

   The L2TP-LAC Tunnel TLV is defined to carry the L2TP LAC tunnel
   related information.  It will be carried in the Update_Request
   message when L2TP LAC access is used.

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

                        Figure 7.9.9: L2TP-LAC Tunnel TLV

   where:

      The TLV type: 13.

      The TLV length: variable.

      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): The source UDP port number of an L2TP
      subscriber.

      Dest-Port (2 bytes): The destination UDP port number of an L2TP
      subscriber.

      Source-IP (IPv4/v6): The source IP address of the tunnel.

      Dest-IP (IPv4/v6): The destination IP address of the tunnel.

      VRF-Name Sub-TLV: The VRF name to which the L2TP subscriber tunnel
      belongs.





Hu, et al.              Expires November 24, 2019              [Page 93]


Internet-Draft               S-CUSP for BNG                     May 2019


7.9.10.  L2TP-LNS Tunnel TLV

   The L2TP-LNS Tunnel TLV is defined to carry the L2TP LNS tunnel
   related information.  It will be carried in the Update_Request
   message when L2TP LNS access is used.

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

                        Figure 7.9.10: L2TP-LAC Tunnel TLV

   where:

      The TLV type: 14.

      The TLV length: variable.

      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): The source UDP port number of an L2TP
      subscriber.

      Dest-Port (2 bytes): The destination UDP port number of an L2TP
      subscriber.

      Source-IP (IPv4/v6): The source IP address of the tunnel.

      Dest-IP (IPv4/v6): The destination IP address of the tunnel.

      VRF-Name Sub-TLV: The VRF name to which the L2TP subscriber tunnel
      belongs.





Hu, et al.              Expires November 24, 2019              [Page 94]


Internet-Draft               S-CUSP for BNG                     May 2019


7.9.11.  Session Update Response TLV

   The Session Update Response TLV is used to return the operation
   result when updating a subscriber session.  It is carried in the
   Update_Response message as a response to the Update_Request message.

   The format of Session Update Response TLV 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                              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | User-Trans-ID |   Oper Code   |  Oper Result  |  Reserved     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         Error Code                            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                 Figure 7.9.11: Session Update Response TLV

   Where:

      The TLV type: 302.

      The TLV length: 12.

      User-ID (4 bytes): A unique identifier of a user/subscriber.

      User-Trans-ID (1 byte): In the case of dual-stack access or when
      modify a session, User-Trans-ID is used to identify a user
      operation transaction.  It is used by the CP to correlate a
      response to a specific request.

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

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

7.9.12.  Subscriber Policy TLV

   The Subscriber Policy TLV is used to carry the policies that will be
   applied to a subscriber.  It is carried in the Update_Request
   message.



Hu, et al.              Expires November 24, 2019              [Page 95]


Internet-Draft               S-CUSP for BNG                     May 2019


   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 7.9.12: Subscriber Policy TLV

   Where:

      The TLV type: 6.

      The TLV length: variable.

      User-ID (4 bytes): The identifier of a user/subscriber.

      Ingress-Priority (1 byte): Indicates the upstream priority.  The
      value range is 0~7.

      Egress-Priority (1 byte): Indicates the downstream priority.  The
      value range is 0~7.

      sub-TLVs:

         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.




Hu, et al.              Expires November 24, 2019              [Page 96]


Internet-Draft               S-CUSP for BNG                     May 2019


         NAT-Instance Sub-TLV: Indicates the instance ID of a NAT user.

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

7.9.13.  Subscriber CGN Port Range TLV

   The Subscriber CGN Port Range TLV is used to carry the NAT public
   address and port range.  It will be carried in the Update_Response
   message when CGN is used.

   The format of this TLV 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                            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |           NAT Port Start      |          NAT Port End         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                            NAT Address                        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                     Figure 7.9.13: Subscriber CGN Port Range TLV

   Where:

      The TLV type: 15.

      The TLV length: 12 octets.

      User-ID (4 bytes): The identifier of a user/subscriber.

      NAT-Port-Start (2 bytes): The start port number.

      NAT-Port-End (2 bytes): The end port number.

      NAT-Sub-IP (4 bytes): The NAT public network address.

7.10.  Device Status TLVs

7.10.1.  Interface Status TLV

   The Board Status TLV is used to carry the status information of an
   interface on a UP.  It is carried in a Report message.

   The format of this TLV is as follows:





Hu, et al.              Expires November 24, 2019              [Page 97]


Internet-Draft               S-CUSP for BNG                     May 2019


        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.10.1: Interface Status TLV

   Where:

      The TLV type: 200.

      The TLV length: variable.

      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.10.2.  Board Status TLV

   The Board Status TLV is used to carry the status information of a
   board on a UP.  It is carried in a Report message.

   The format of Board Status TLV is as follows:












Hu, et al.              Expires November 24, 2019              [Page 98]


Internet-Draft               S-CUSP for BNG                     May 2019


        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  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |  Board-State  |                  Reserved                     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                      Figure 7.10.2: Board Status TLV

   Where:

      The TLV type: 201.

      The TLV length: 8 octets.

      Chassis (1 byte): The chassis number of the board.

      Slot (1 byte): The slot number of the board.

      Sub-Slot (1 byte): The sub-slot number of the board.

      Board Type (1 byte):

         1: CGN Service Process Unit (SPU) board.

         2: Line Process Unit (LPU) board.

      Board-State (1 byte):

         0: Normal.

         1: Abnormal.

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

7.11.  CGN TLVs

7.11.1.  Address Allocation Request TLV

   The Address Allocation Request TLV is used to request address
   allocation from CP.  An address Pool-Name sub-TLV is carried to
   indicate from which address pool to allocate addresses.  The Address
   Allocation Request TLV is carried in the Addr_Allocation_Req message.

   The format of this TLV is as follows:





Hu, et al.              Expires November 24, 2019              [Page 99]


Internet-Draft               S-CUSP for BNG                     May 2019


        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 7.11.1: Address Allocation Request TLV

   Where:

      The TLV type: 400.

      The TLV length: variable.

      sub-TLV: Carry a Pool-Name Sub-TLV to indicate from which Address
      pool to allocate address.

7.11.2.  Address Allocation Response TLV

   The Address Allocation Response TLV is used to return the address
   allocation result, it is carried the Addr_Allocation_Ack message.

        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           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Return Code   |    Reserved   |                               ~
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+          sub-TLVs             |
       ~                                                               ~
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 7.11.2: Address Assignment Response TLV

   Where:

      The TLV type: 401.

      The TLV length: variable.

      Lease Time (4 bytes): Duration of address lease in seconds.

      IPv4 Addr and Mask (IPv4-Addr): The allocated IPv4 address.




Hu, et al.              Expires November 24, 2019             [Page 100]


Internet-Draft               S-CUSP for BNG                     May 2019


      Return Code (1 byte):

         0: Success.

         1: Failure.

         3001 (Pool-Mismatch): The corresponding address pool cannot be
         found.

         3002 (Pool-Full): The address pool is fully allocated and no
         address segment is available.

      sub-TLVs: Carry a Pool-Name Sub-TLV to indicate from which Address
      pool the address is allocated.

7.11.3.  Address Renewal Request TLV

   The Address Renewal Request TLV is used to request address renewal
   from the CP.  It is carried the Addr_Renew_Req message.

   The format of this TLV 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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     IPv4 Address and Mask                     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     IPv4 Address and Mask continued           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       ~                          sub-TLVs                             ~
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                    Figure 7.11.3: Address Renewal Request TLV

   Where:

      The TLV type: 402.

      The TLV length: variable.

      IPv4 Addr and Mask (IPv4-Addr): The IPv4 address to be renewed.

      sub-TLVs: Carry a Pool-Name Sub-TLV to indicate from which Address
      pool to renew the address.







Hu, et al.              Expires November 24, 2019             [Page 101]


Internet-Draft               S-CUSP for BNG                     May 2019


7.11.4.  Address Renewal Response TLV

   The Address Renewal Response TLV is used to return the address
   renewal result.  It is carried in the Addr_Renew_Ack message.

   The format of this TLV 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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     IPv4 Address and Mask                     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     IPv4 Address and Mask continued           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |  Return-Code  |  Reserved     |                               ~
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+         sub-TLVs              |
       ~                                                               ~
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                   Figure 7.11.4: Address Renewal Response TLV

   Where:

      The TLV type: 403.

      The TLV length: variable.

      Client-IP (IPv4-Addr): The renewed IPv4 address.

      Return-Code (1 bytes):

         0: Renew success.

         1: Renew failed.

         3001 (Pool-Mismatch): The corresponding address pool cannot be
         found.

         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
         assigned to other clients.





Hu, et al.              Expires November 24, 2019             [Page 102]


Internet-Draft               S-CUSP for BNG                     May 2019


      sub-TLVs: Carry a Pool-Name Sub-TLV to indicate from which Address
      pool to renew the address.

7.11.5.  Address Release Request TLV

   The Address Release Request TLV is used to release an IPv4 address.
   It is carried in the Addr_Release_Req message.

   The format of this TLV 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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     IPv4 Address and Mask                     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     IPv4 Address and Mask continued           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       ~                          sub-TLVs                             ~
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                    Figure 7.11.5: Address Release Request TLV

   Where:

      The TLV type: 404.

      The TLV length: variable.

      IPv4 Address and Mask (IPv4-Addr): The IPv4 address be released.

      sub-TLVs: carry a Pool-Name Sub-TLV to indicate from which Address
      pool to release the address.

7.11.6.  Address Release Response TLV

   The Address Release Response TLV is used to return the address
   release result.  It is carried in the Addr_Release_Ack message.

   The format of this TLV is as follows:












Hu, et al.              Expires November 24, 2019             [Page 103]


Internet-Draft               S-CUSP for BNG                     May 2019


        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 7.11.6: Address Release Response TLV

   Where:

      The TLV type: 405.

      The TLV length: variable.

      Client-IP (IPv4-Addr): The released IPv4 address.

      Return-Code (1 bytes):

         0: Address release success.

         1: Address release failed.

         3001 (Pool-Mismatch): The corresponding address pool cannot be
         found.

         3003 (Subnet-Mismatch): The address cannot be found.

         3004 (Subnet-Conflict): The address has been allocated to
         another subscriber.

      sub-TLVs: carry a Pool-Name Sub-TLV to indicate from which address
      pool to release the address.

7.12.  Event TLVs

7.12.1.  Subscriber Traffic Statistics TLV

   The Subscriber Traffic Statistics TLV is used to return the traffic
   statistics of a user/subscriber.  The format of this TLV is as
   follows:





Hu, et al.              Expires November 24, 2019             [Page 104]


Internet-Draft               S-CUSP for BNG                     May 2019


        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 7.12.1: Subscriber Traffic Statistics TLV

   Where:

      The TLV type: 300.

      The TLV length: 72 octets.

      User-ID (4 bytes): The user/subscriber identifier.



Hu, et al.              Expires November 24, 2019             [Page 105]


Internet-Draft               S-CUSP for BNG                     May 2019


      Statistics-Type (4 bytes): Traffic type.  It can be one of the
      following options:

         0: IPv4 traffic.

         1: IPv6 traffic.

         2: Dual stack traffic.

      Ingress Packets (8 bytes): The number of the packets in upstream
      direction.

      Ingress Bytes (8 bytes): The bytes of the upstream traffic.

      Ingress Loss Packets (8 bytes): The number of the lost packets in
      upstream direction.

      Ingress Loss Bytes (8 bytes): The bytes of the lost upstream
      packets.

      Egress Packets (8 bytes): The number of the packets in downstream
      direction.

      Egress Bytes (8 bytes): The bytes of the downstream traffic.

      Egress Loss Packets (8 bytes): The number of the lost packets in
      downstream direction.

      Egress Loss Bytes (8 bytes): The bytes of the lost downstream
      packets.

7.12.2.  Subscriber Detection Result TLV

   The Subscriber Detection Result TLV is used to return the detection
   result of a subscriber.  Subscriber detection is a function to detect
   whether a subscriber is online or not.  The result can be used by the
   CP to determine how to deal with the subscriber session.  (e.g.,
   delete the session if detection failed).

        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 7.12.2: Subscriber Detection Result TLV



Hu, et al.              Expires November 24, 2019             [Page 106]


Internet-Draft               S-CUSP for BNG                     May 2019


   Where:

      The TLV type: 301.

      The TLV length: 8 octets.

      User-ID (4 bytes): a user/subscriber identifier.

      Detect-Type (1 byte):

         0: IPv4 detection.

         1: IPv6 detection.

         2: PPP detection.

      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.

7.13.  Vendor 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 7.13: Vendor TLV

   Where:

      The TLV type: 1024.

      The TLV length: variable.

      Vendor-ID (4 bytes): Vendor ID, which is defined in the RADIUS
      [RFC2865].




Hu, et al.              Expires November 24, 2019             [Page 107]


Internet-Draft               S-CUSP for BNG                     May 2019


      Sub-Type (2 bytes): Used by the Vendor to distinguish multiple
      different vendor messages.

      Sub-Type-Version (2 bytes): Used by the Vendor to distinguish
      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 is desirable 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 assigns a Sub-Type value for each vendor
   message that it defines different from other Sub-Type values that
   vendor has used.  Also, when modifying a vendor defined message in a
   way potentially incompatible with a previous definition, the vendor
   shouldincrease the value it is using in the Sub-Type-Version field.

8.  Implementation Status

   This section is not intended to appear in any resulting RFC.  It
   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 in processing drafts to RFCs.

   Please note that the listing of any individual implementation or test
   results here does not imply endorsement by the RFC Editor or the
   IETF.  Furthermore, no effort has been spent to verify the
   information presented here that was supplied by 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 ... 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.".

8.1.  Implementations

   Information on three S-CUSP implementations appears below.








Hu, et al.              Expires November 24, 2019             [Page 108]


Internet-Draft               S-CUSP for BNG                     May 2019


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

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

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

8.2.  Hackathon

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

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




Hu, et al.              Expires November 24, 2019             [Page 109]


Internet-Draft               S-CUSP for BNG                     May 2019


   Champions: Zhenqiang Li, Michael Wang

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

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

9.  Summary of Major S-CUSP Codepoints

9.1.  Message Types

          Type      Name                Section of this document
         ------    -----------          ------------------------
             0     Reserved
             1     Hello                6.2.1.
             2     Keepalive            6.2.2.
             3     Sync_Request         6.2.3.
             4     Sync_Begin           6.2.4.
             5     Sync_Data            6.2.5.
             6     Sync_End             6.2.6.
             7     Update_Request       6.2.7.
             8     Update_Response      6.2.8.
             9     Report               6.4.
            10     Event                6.3.
            11     Vendor               6.6.
        12-199     Unassigned
           200     Addr_Allocation_Req  6.5.1
           201     Addr_Allocation_Ack  6.5.2
           202     Addr_Renew_Req       6.5.3
           203     Addr_Renew_Ack       6.5.4
           204     Addr_Release_Req     6.5.5
           205     Addr_Release_Ack     6.5.6
       206-254     Unassigned
           255     Reserved







Hu, et al.              Expires November 24, 2019             [Page 110]


Internet-Draft               S-CUSP for BNG                     May 2019


9.2.  TLV Types

      Type     Name                     Usage Description
     -----   ------------               --------------------------
         1   BAS Function Enabler       Carry the BNG accesss functions
                                        to be enabled or disabled on
                                        specified interface(s).
         2   Basic Subscriber           Carry the basic information
                                        about a BNG subscriber.
         3   PPP Subscriber             Carry the PPP information about
                                        a BNG subscriber.
         4   IPv4 Subscriber            Carry the IPv4 information about
                                        a BNG subscriber.
         5   IPv6 Subscriber            Carry the IPv6 information about
                                        a BNG subscriber.
         6   Subscriber Policy          Carry the the policy information
                                        applied to a BNG subscriber.
         7   IPv4 Routing               Carry the IPv4 network routing
                                        information.
         8   IPv6 Routing               Carry the IPv6 network routing
                                        information.
         9   IPv4 Static Subscriber     Carry the static BNG subscriber
                                        information.
        10   IPv6 Static Subscriber     Carry the static BNG subscriber
                                        information.
        11   L2TP-LAC Subscriber        Carry the L2TP LAC subscriber
                                        information.
        12   L2TP-LNS Subscriber        Carry the L2TP LNS subscriber
                                        information.
        13   L2TP-LAC Tunnel            Carry the L2TP LAC tunnel
                                        information.
        14   L2TP-LNS Tunnel            Carry the L2TP LNS tunnel
                                        information.
        15   Subscriber CGN Port Range  Carry the public IPv4 address
                                        and the related port range of
                                        a BNG subscriber.
     16-99                              unassigned
       100   Hello                      Used for version and Keep Alive
                                        timers negotiation.
       101   Error Information          Carried in the Ack of a control
                                        message, carries the processing
                                        result, success, or error.
       102   Keep Alive                 Carried in the Hello message for
                                        Keep alive timers negotiation.
     102-199 unassigned
       200   Interface Status           Interfaces status reported by
                                        the UP including physical
                                        interfaces, sub-interfaces,



Hu, et al.              Expires November 24, 2019             [Page 111]


Internet-Draft               S-CUSP for BNG                     May 2019


                                        trunk interfaces, and tunnel
                                        interfaces.
       201   Board Status               Board information reported by
                                        the UP including the board type
                                        and in-position status.
   202-299                              unassigned
       300   Subscriber Traffic Statistics  User traffic statistics.
       301   Subscriber Detection Result    User detection result
                                            information.
       302   Session Update Response    The processing result of a
                                        subscriber session update.
   303-299                              unassigned
       400   Address Allocation Request Request address allocation.
       401   Address Allocation Response Address allocation response.
       402   Address Renewal Request  Request for address lease renewal.
       403   Address Renewal Response Response to a request for
                                      extending an IP address lease.
       404   Address Release Request  Request to release the address.
       405   Address Release Response Ack of a message releasing an IP
                                      address.
  406-1023                            unassigned
      1024   Vendor                   As implemented by vendor.
 1025-4095                            unassigned

9.3.  TLV Operation Codes

         Code  Operation
         ----  ----------
            0  - reserved
            1  Update
            2  Delete
         3-15  - unassigned

9.4.  Sub-TLV Types

















Hu, et al.              Expires November 24, 2019             [Page 112]


Internet-Draft               S-CUSP for BNG                     May 2019


          Type  Name                 Reference
         -----  ------------------   ---------------
            0   - reserved
            1   VRF Name             7.3.1
            2   Ingress-QoS-Profile  7.3.1
            3   Egress-QoS-Profile   7.3.1
            4   User-ACL-Policy      7.3.1
            5   Multicast-ProfileV4  7.3.1
            6   Multicast-ProfileV6  7.3.1
            7   Ingress-CAR          7.3.2
            8   Egress-CAR           7.3.3
            9   NAT-Instance         7.3.1
           10   Pool-Name            7.3.1
           11   If-Desc              7.3.4
           12   If-Desc              7.3.5
     13-64534  - unassigned
        65535  -reserved

9.5.  Error Codes
































Hu, et al.              Expires November 24, 2019             [Page 113]


Internet-Draft               S-CUSP for BNG                     May 2019


       Code   Name             Remarks
   --------   -------          --------
         0    Success          Success
         1    Failed           Failure. The reason is not classified.
         2    TLV-Unknown      The TLV 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 error codee for version
                               negotiation
      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.
      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 error codes for 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.              Expires November 24, 2019             [Page 114]


Internet-Draft               S-CUSP for BNG                     May 2019


10.  IANA Considerations

   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

11.  Security Considerations

   The Service, Control, and Management Interfaces between the CP and UP
   might be across the general Internet or other hostile environment.
   Thus, appropriate protections must be implemented to provide
   integrity, authenticity, and secrecy of traffic over those
   interfaces.  Whether such protection is used is an operator decision.

   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], DTLS, or IPSEC.  However, such security protocols need not
   always be used and lesser security precautions might be appropriate
   because, in some cases, the communication between the CP and UP is in
   a more benign environment.

12.  Contributors






















Hu, et al.              Expires November 24, 2019             [Page 115]


Internet-Draft               S-CUSP for BNG                     May 2019


         Zhouyi Yu
         Huawei Technologies

         Email: yuzhouyi@huawei.com

         Chengguang Niu
         Huawei Technologies

         Email: chengguang.niu@huawei.com

         Zitao Wang
         Huawei Technologies

         Email: wangzitao@huawei.com

         Jun Song
         Huawei Technologies

         Email: song.jun@huawei.com

         Dan Meng
         H3C Technologies
         No.1Lixing Center?No.8 guangxun south stree, Chaoyang District,
         Bejing, 100102
         China

         Email: mengdan@h3c.com

         Hanlei Liu
         H3C Technologies
         No.1Lixing Center?No.8 guangxun south stree, Chaoyang District,
         Bejing, 100102
         China

         Email: hanlei_liu@h3c.com


13.  Acknowledgements

14.  Informative References

   [RFC793]   Postel, J., "Transmission Control Protocol", STD 7,
              RFC 793, DOI 10.17487/RFC0793, September 1981,
              <https://www.rfc-editor.org/info/rfc793>.

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



Hu, et al.              Expires November 24, 2019             [Page 116]


Internet-Draft               S-CUSP for BNG                     May 2019


   [RFC2131]  Droms, R., "Dynamic Host Configuration Protocol",
              RFC 2131, DOI 10.17487/RFC2131, March 1997,
              <https://www.rfc-editor.org/info/rfc2131>.

   [RFC2661]  Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn,
              G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"",
              RFC 2661, DOI 10.17487/RFC2661, August 1999,
              <https://www.rfc-editor.org/info/rfc2661>.

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

   [RFC6241]  Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
              and A. Bierman, Ed., "Network Configuration Protocol
              (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
              <https://www.rfc-editor.org/info/rfc6241>.

   [RFC7042]  Eastlake 3rd, D. and J. Abley, "IANA Considerations and
              IETF Protocol and Documentation Usage for IEEE 802
              Parameters", BCP 141, RFC 7042, DOI 10.17487/RFC7042,
              October 2013, <https://www.rfc-editor.org/info/rfc7042>.

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

   [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", 2018.

Appendix A.  An Appendix

Authors' Addresses

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

   Email: hushujun@chinamobile.com






Hu, et al.              Expires November 24, 2019             [Page 117]


Internet-Draft               S-CUSP for BNG                     May 2019


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

   Email: d3e3e3@gmail.com


   Mach(Guoyi) Chen
   Huawei Technologies

   Email: mach.chen@huawei.com


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

   Email: qinfengwei@chinamobile.com


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

   Email: lizhenqiang@chinamobile.com


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

   Email: teemong@singtel.com


   Daniel Huang
   ZTE

   Email: huang.guangping@zte.com.cn













Hu, et al.              Expires November 24, 2019             [Page 118]


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