<?xml version='1.0' encoding='utf-8'?> version="1.0" encoding="UTF-8"?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC0020 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.0020.xml">
<!ENTITY RFC0793 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.0793.xml">
<!ENTITY RFC2119 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2661 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2661.xml">
<!ENTITY RFC2865 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2865.xml">
<!ENTITY RFC6241 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6241.xml">
<!ENTITY RFC8174 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml">
<!ENTITY RFC1661 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1661.xml">
<!ENTITY RFC2131 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2131.xml">
<!ENTITY RFC2516 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2516.xml">
<!ENTITY RFC2698 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2698.xml">
<!ENTITY RFC3022 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3022.xml">
<!ENTITY RFC3336 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3336.xml">
<!ENTITY RFC5511 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5511.xml">
<!ENTITY RFC7042 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7042.xml">
<!ENTITY RFC7348 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7348.xml">
<!ENTITY RFC7942 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7942.xml">
<!ENTITY RFC8446 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8446.xml">
]> "rfc2629-xhtml.ent">

<rfc submissionType="IETF" xmlns:xi="http://www.w3.org/2001/XInclude"
submissionType="independent"
docName="draft-chz-simple-cu-separation-bng-protocol-06"
number="8772"
category="info" ipr="trust200902">
	<!-- Generated by id2xml 1.5.0 on 2020-01-09T19:02:41Z -->
	<?rfc compact="yes"?>
	<?rfc text-list-symbols="o*+-"?>
	<?rfc subcompact="no"?>
	<?rfc sortrefs="no"?>
	<?rfc symrefs="yes"?>
	<?rfc strict="yes"?>
	<!--
   draft-chz-simple-cu-separation-bng-protocol-06-manual.txt(16): Warning: Expected
   an expires indication top left, found none
   --><?rfc toc="yes"?>
ipr="trust200902"
obsoletes=""
updates=""
xml:lang="en"
sortRefs="false"
symRefs="true"
tocInclude="true"
version="3">

  <front>
    <title abbrev="Simple BNG CUSP">The China Mobile, Huawei, and ZTE BNG Broadband Network Gateway (BNG) Simple Control and User Plane Separation Protocol (S-CUSP)</title>
    <seriesInfo name="RFC" value="8772" />

    <author fullname="Shujun Hu" initials="S." surname="Hu">
      <organization>China Mobile</organization>
	<address><postal><street>32
      <address>
        <postal>
          <street>32 Xuanwumen West Ave, Xicheng District</street>
	<street>Beijing, Beijing  100053</street>
	<street>China</street> Ave</street>
	  <cityarea>Xicheng District</cityarea>
          <city>Beijing</city><code> 100053</code>
          <country>China</country>
        </postal>
        <email>hushujun@chinamobile.com</email>
      </address>
    </author>

    <author fullname="Donald Eastlake, Eastlake 3rd" initials="D." surname="Eastlake"> surname="Eastlake 3rd">
      <organization>Futurewei Technologies</organization>
	<address><postal><street>2386
      <address>
        <postal>
          <street>2386 Panoramic Circle</street>
	<street>Apopka, FL  32703</street>
	<street>USA</street>
          <city>Apopka</city> <region>FL</region> <code> 32703</code>
          <country>US</country>
        </postal>
        <phone>+1-508-333-2270</phone>
        <email>d3e3e3@gmail.com</email>
      </address>
    </author>
    <author fullname="Fengwei Qin" initials="F." surname="Qin">
      <organization>China Mobile</organization>
	<address><postal><street>32
      <address>
        <postal>
          <street>32 Xuanwumen West Ave, Xicheng District</street>
	<street>Beijing, Beijing  100053</street>
	<street>China</street> Ave</street>
	  <cityarea>Xicheng District</cityarea>
          <city>Beijing</city><code>100053</code>
          <country>China</country>
        </postal>
        <email>qinfengwei@chinamobile.com</email>
      </address>
    </author>
    <author fullname="Tee Mong Chua" initials="T." surname="Chua">
      <organization abbrev="Singapore Telecommunications">Singapore Telecommunications Limited</organization>
	<address><postal><street>31
      <address>
        <postal>
          <street>31 Exeter Road, #05-04 Comcentre Podium Block</street>
	<street>Singapore City  239732</street>
	<street>Singapore</street>
          <city>Singapore</city> <code> 239732</code>
          <country>Singapore</country>
        </postal>
        <email>teemong@singtel.com</email>
      </address>
    </author>
    <author fullname="Daniel Huang" initials="D." surname="Huang">
      <organization>ZTE</organization>
	<address><email>huang.guangping@zte.com.cn</email>
      <address>
        <email>huang.guangping@zte.com.cn</email>
      </address>
    </author>
    <date month="January" month="May" year="2020"/>
	<abstract><t>

<keyword>CUPS</keyword>
<keyword>CUSP</keyword>
<keyword>BRAS</keyword>
<keyword>BBRAS</keyword>

    <abstract>

      <t>
   A Broadband Network Gateway (BNG) in a fixed wireline access network is an
   Ethernet-centric IP edge router and the aggregation point for subscriber
   traffic. Control Plane (CP) and User Plane (UP) Separation (CUPS) for such a BNG improves
   flexibility and scalability but requires various communication between the UP
   User Plane (UP) and the CP. Control Plane (CP).  China Mobile, Huawei
   Technologies, and ZTE have developed a simple CUPS control channel Protocol (S-CUSP) protocol
   to support such communication.</t> communication: the
   Simple Control and User Plane Separation Protocol (S-CUSP). S-CUSP is
   defined in this document.
</t>
      <t>
   This document is not an IETF standard and does not have IETF
   consensus.  S-CUSP is presented here to make its specification
   conveniently available to the Internet community to enable diagnosis
   and interoperability.</t>
    </abstract>
  </front>
  <middle>
    <section title="Introduction" anchor="sect-1"><t> anchor="sect-1" numbered="true" toc="default">
      <name>Introduction</name>
      <t>
   A Broadband Network Gateway (BNG) in a fixed wireline access network is an
   Ethernet-centric IP edge router, router and the aggregation point for subscriber
   traffic.  To provide centralized session management, flexible address
   allocation, high scalability for subscriber management capacity, and
   cost-efficient redundancy, the Control/User
   (CU) separated CU-separated (CP/UP-separated) BNG framework is
   described in a technical report <xref target="TR-384"/> target="TR-384" format="default"/>
   from the Broadband Forum (BBF). The CU separated CU-separated service
   Control Plane (CP), CP, which is
   responsible for user access authentication and setting forwarding entries
   in User Planes (UPs), UPs, can be virtualized and centralized.  The routing
   control and forwarding plane, i.e., the BNG user plane UP (local), can be distributed
   across the infrastructure.  Other structures can also be
   supported supported, such as both
   the CP and UP being virtual or both being physical.</t>
      <t>
   Note: In this document, the terms "user" and "subscriber" are used
   interchangeably.</t>
      <t>
    This document specifies the Simple CU Separation BNG control channel Protocol (S-CUSP) for
    communications over the BNG control channel between a BNG Control Plane (CP) CP
    and a set of User Planes (UPs). UPs.  S-CUSP is designed to be flexible
   and extensible so as to allow for easy addition of messages and data
   items, should further requirements be expressed in the future.</t>
      <t>
   This document is not an IETF standard and does not have IETF
   consensus.  S-CUSP was designed by China Mobile, Huawei Technologies,
   and ZTE. It is presented here to make the S-CUSP specification
   conveniently available to the Internet community to enable diagnosis
   and interoperability.</t>
      <t>
   At the time of writing this document, the Broadband Forum (BBF) BBF is
   working to produce <xref target="WT-459"/> that target="WT-459" format="default"/>, which will describe an architecture and
   requirements for a control CP and user plane UP separation of a
   disaggregated BNG.  Future work may attempt to show how the protocol
   described in this document addresses those requirements and may
   modify this specification to handle unaddressed requirements.</t>
    </section>
    <section title="Terminology" anchor="sect-2"><t> anchor="sect-2" numbered="true" toc="default">
      <name>Terminology</name>
      <t>
   This section specifies implementation requirement keywords and terms
   used in this document. S-CUSP messages are described in this document
   using Routing Backus-Naur Form (RBNF) as defined in <xref target="RFC5511"/>.</t> target="RFC5511" format="default"/>.</t>
      <section title="Implementation anchor="sect-2.1" numbered="true" toc="default">
        <name>Implementation Requirement Keywords" anchor="sect-2.1"><t> Keywords</name>
        <t>
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
    NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and
   "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
    described in BCP
   14 BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
    when, and only when, they appear in all capitals, as shown here.</t> here.
        </t>
      </section>
      <section title="Terms" anchor="sect-2.2"><t> anchor="sect-2.2" numbered="true" toc="default">
        <name>Terms</name>
        <t>
   This section specifies terms used in this document.</t>

        <t><list style="hanging" hangIndent="3">

	<t hangText="AAA:">
        <dl newline="false" spacing="normal" indent="13">
          <dt>AAA:</dt>
          <dd> Authentication Authorization Accounting.</t>

   	<t hangText="ACK:"> Accounting.</dd>
          <dt>ACK:</dt>
          <dd> Acknowledgement message.</t>

	<t hangText="BAS:"> message.</dd>
          <dt>BAS:</dt>
          <dd> Broadband Access Server (BRAS, BNG).</t>

	<t hangText="BNG:"> Server, also known as a BBRAS, BNG, or BRAS.</dd>
          <dt>BNG:</dt>
          <dd> Broadband Network Gateway.  A broadband remote
	access server"> (BRAS (BRoadband BNG (or Broadband Remote Access Server), B-RAS or BBRAS)
       Server (BRAS)) 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.  BNG / BRAS can also be referred to as a BAS or BBRAS.</dd>
          <dt>BRAS:</dt>
          <dd> Broadband Network Gateway (BNG).</t>

	<t hangText="BRAS:"> BRoadband Remote Access Server (BNG).</t>

	<t hangText="CAR:"> Server, also known as a BAS, BBRAS, or BNG.</dd>
          <dt>CAR:</dt>
          <dd> Committed Access Rate.</t>

	<t hangText="CBS:"> Rate.</dd>
          <dt>CBS:</dt>
          <dd> Committed Burst Size.</t>

	<t hangText="CGN:"> Size.</dd>
          <dt>CGN:</dt>
          <dd> Carrier Grade NAT.</t>

	<t hangText="Ci:"> NAT.</dd>
          <dt>Ci:</dt>
          <dd> Control Interface.</t>

	<t hangText="CIR:"> Interface.</dd>
          <dt>CIR:</dt>
          <dd> Committed Information Rate.</t>

	<t hangText="CoA:"> Rate.</dd>
          <dt>CoA:</dt>
          <dd> Change of Authorization.</t>

	<t hangText="CP:"> Authorization.</dd>
          <dt>CP:</dt>
          <dd> Control Plane. CP is a user control management
	component which that supports the management of the UP's resources such as
	the user entry and forwarding policy.</t>

	<t hangText="CPE:"> Customer Premises Equipment.</t>

	<t hangText="CU:"> Control-plane policy.</dd>
          <dt>CU:</dt>
          <dd> Control Plane / User-plane.</t>

	<t hangText="CUSP:"> User Plane.</dd>
          <dt>CUSP:</dt>
          <dd> Control and User plane Plane Separation Protocol.</t>

	<t hangText="DEI:"> Protocol.</dd>
          <dt>DEI:</dt>
          <dd> Drop Eligibility Indicator. Indicator as defined in
      <xref target="IEEE-802.1Q" format="default"/>.  A bit in a VLAN
      tag after the priority and before the VLAN ID.  (This bit was formerly
      the CFI (Canonical Format Indicator).) <xref target="IEEE-802.1Q"/></t>

	<t hangText="DHCP:"> Indicator).)</dd>
          <dt>DHCP:</dt>
          <dd> Dynamic Host Configuration Protocol <xref
	target="RFC2131"/>.</t>

	<t hangText="dial-up:"> target="RFC2131" format="default"/>.</dd>
          <dt>dial-up:</dt>
          <dd> This refers to the initial connection messages
	when a new subscriber appears. The name is left over from when
	subscribers literally dialed up on a modem equipped 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 <xref target="RFC2516"/> target="RFC2516" format="default"/> or IPoE.</t>

	<t hangText="EMS:"> IPoE.</dd>
          <dt>EMS:</dt>
          <dd> Element Management System.</t>

	<t hangText="IPoE:"> System.</dd>
          <dt>IPoE:</dt>
          <dd> IP over Ethernet.</t>

	<t hangText="L2TP:"> Ethernet.</dd>
          <dt>L2TP:</dt>
          <dd> Layer 2 Tunneling Protocol <xref
	target="RFC2661"/>.</t>

	<t hangText="LAC:"> target="RFC2661" format="default"/>.</dd>
          <dt>LAC:</dt>
          <dd> L2TP Access Concentrator.</t>

	<t hangText="LNS:"> Concentrator.</dd>
          <dt>LNS:</dt>
          <dd> L2TP Network Server.</t>

	<t hangText="MAC:"> Server.</dd>
          <dt>MAC:</dt>
          <dd> 48-bit Media Access Control address <xref
	target="RFC7042"/>.</t>

	<t hangText="MANO:"> target="RFC7042" format="default"/>.</dd>
          <dt>MANO:</dt>
          <dd> Management and Orchestration.</t>

	<t hangText="Mi:"> Orchestration.</dd>
          <dt>Mi:</dt>
          <dd> Management Interface.</t>

	<t hangText="MSS:"> Interface.</dd>
          <dt>MSS:</dt>
          <dd> Maximum Segment Size.</t>

	<t hangText="MRU:"> Size.</dd>
          <dt>MRU:</dt>
          <dd> Maximum Receive Unit.</t>

	<t hangText="NAT:"> Unit.</dd>
          <dt>NAT:</dt>
          <dd> Network Address Translation <xref
	target="RFC3022"/>.</t>

	<t hangText="ND:"> target="RFC3022" format="default"/>.</dd>
          <dt>ND:</dt>
          <dd> Neighbor Discovery.</t>

	<t hangText="NFV:"> Discovery.</dd>
          <dt>NFV:</dt>
          <dd> Network Function Virtualization.</t>

	<t hangText="NFVI:"> Virtualization.</dd>
          <dt>NFVI:</dt>
          <dd> NFV Infrastructure</t>

	<t hangText="PBS:"> Infrastructure.</dd>
          <dt>PBS:</dt>
          <dd> Peak Burst Size.</t>

	<t hangText="PD:"> Size.</dd>
          <dt>PD:</dt>
          <dd> Prefix Delegation.</t>

	<t hangText="PIR:"> Delegation.</dd>
          <dt>PIR:</dt>
          <dd> Peak Information Rate.</t>

	<t hangText="PPP:"> Point to Point Rate.</dd>
          <dt>PPP:</dt>
          <dd> Point-to-Point Protocol <xref
	target="RFC1661"/>.</t>

	<t hangText="PPPoE:"> target="RFC1661" format="default"/>.</dd>
          <dt>PPPoE:</dt>
          <dd> PPP over Ethernet <xref target="RFC2516"/>.</t>

	<t hangText="RBNF:"> target="RFC2516" format="default"/>.</dd>
          <dt>RBNF:</dt>
          <dd> Routing Backus-Naur Form <xref
	target="RFC5511"/>.</t>

	<t hangText="RG:"> target="RFC5511" format="default"/>.</dd>
          <dt>RG:</dt>
          <dd> Residential Gateway.</t>

	<t hangText="S-CUSP:"> Gateway.</dd>
          <dt>S-CUSP:</dt>
          <dd> Simple Control and User Plane Separation
	Protocol.</t>

	<t hangText="Subscriber:"> Protocol.</dd>
          <dt>Subscriber:</dt>
          <dd> The remote user gaining network accesses
	via a BNG.</t>

	<t hangText="Si:"> BNG.</dd>
          <dt>Si:</dt>
          <dd> Service Interface.</t>

	<t hangText="TLV:"> Type, Length, Value. Interface.</dd>
          <dt>TLV:</dt>
          <dd> Type-Length-Value.  See Sections 7.1 <xref target="sect-7.1" format="counter"/> and 7.3.</t>

	<t hangText="UP:"> <xref target="sect-7.3" format="counter"/>.</dd>
          <dt>UP:</dt>
          <dd> User Plane.  UP is a network edge and user policy
	implementation component.  The traditional router's Control Plane control plane and
	Forwarding Plane
	forwarding plane are both preserved on BNG devices in the form of a
	user plane.</t>

	<t hangText="URPF:"> plane.</dd>
          <dt>URPF:</dt>
          <dd> Unicast Reverse Path Forwarding.</t>

	<t hangText="User:"> Forwarding.</dd>
          <dt>User:</dt>
          <dd> Equivalent to "customer" or "subscriber".</t>

	<t hangText="VRF:"> "subscriber".</dd>
          <dt>VRF:</dt>
          <dd> Virtual Routing and Forwarding.</t>

      </list>
      </t> Forwarding.</dd>
        </dl>
      </section>
    </section>
    <section title="BNG anchor="sect-3" numbered="true" toc="default">
      <name>BNG CUPS Overview" anchor="sect-3"><section title="BNG Overview</name>
      <section anchor="sect-3.1" numbered="true" toc="default">
        <name>BNG CUPS Motivation" anchor="sect-3.1"><t> Motivation</name>
        <t>
   The rapid development of new services, such as 4K TV, IoT, Internet of Things (IoT), etc., and
   increasing numbers of home broadband service users present some new
   challenges for BNGs such as:</t>

	<t><list style="hanging" hangIndent="3"><t hangText="Low
        <dl newline="false" spacing="normal" indent="3">
          <dt>Low resource
	utilization:">  utilization:</dt>
          <dd> The traditional BNG acts as both a gateway for user
	access authentication and accounting and also 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.
	</t>

	<t hangText="Complex
	</dd>
          <dt>Complex management and maintenance:"> maintenance:</dt>
          <dd> 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 to rectify faults rapidly.
	</t>

	<t hangText="Slow
	</dd>
          <dt>Slow service provisioning:"> provisioning:</dt>
          <dd> The coupling of control
	plane the CP and the forwarding plane, in addition to being a distributed network
	control mechanism, means that any new technology has to rely heavily
	on the existing network devices.
	</t>

	</list>
	</t>
	</dd>
        </dl>
        <t>
   The framework for a cloud-based BNG with Control Plane and User Plane
   (CU)
   CU separation to address these challenges for fixed networks is
   described in <xref target="TR-384"/>. target="TR-384" format="default"/>.  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 CP. The
   traditional router's Control Plane CP and Forwarding Plane forwarding plane are both
   preserved on BNG devices in the form of a User Plane (UP).</t> UP.</t>
      </section>
      <section title="BNG anchor="sect-3.2" numbered="true" toc="default">
        <name>BNG CUPS Architecture Overview" anchor="sect-3.2"><t> Overview</name>
        <t>
    The functions in a traditional BNG can be divided into two parts: one
   is
    (1) the user access management function, the other is function and (2) the router routing
    function.  The user access management function can be deployed as
    a centralized module or device, called the BNG Control Plane
    (BNG-CP).  The other functions, such as the router function routing function, which includes routing control
    and the forwarding engine, can be deployed in the form of the BNG
    User Plane (BNG-UP).</t> (BNG-UP).
</t>
        <t>
    The following figure
    <xref target="fig1" format="default"/> shows the architecture of CU separated a CU-separated BNG:</t>
        <figure title="Architecture anchor="fig1">
          <name>Architecture of CU Separated BNG" anchor="fig1"><artwork><![CDATA[ a CU-Separated BNG</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
 +------------------------------------------------------------------+
 |        Neighboring policy and resource management systems        |
 |                                                                  |
 |   +-------------+   +-----------+   +---------+   +----------+   |
 |   |AAA    Server|   | AAA Server  |   |DHCP Server|   |   EMS   |   |   MANO   |   |
 |   +-------------+   +-----------+   +---------+   +----------+   |
 +------------------------------------------------------------------+

 +------------------------------------------------------------------+
 |                       CU-separated BNG system                    |
 | +--------------------------------------------------------------+ |
 | |   +----------+  +----------+ +------++------++-----------+   | |
 | |   | Address  |  |Subscriber| | AAA  ||Access||    UP     |   | |
 | |   |management|  |management| |      || Mgt mgt  ||management |   | |
 | |   +----------+  +----------+ +------++------++-----------+   | |
 | |                              CP                              | |
 | +--------------------------------------------------------------+ |
 |                                                                  |
 |                                                                  |
 |                                                                  |
 | +---------------------------+      +--------------------------+  |
 | |  +------------------+     |      |  +------------------+    |  |
 | |  | Routing control  |     |      |  | Routing control  |    |  |
 | |  +------------------+     | ...  |  +------------------+    |  |
 | |  +------------------+     |      |  +------------------+    |  |
 | |  |Forwarding engine |     |      |  |Forwarding engine |    |  |
 | |  +------------------+  UP |      |  +------------------+  UP|  |
 | +---------------------------+      +--------------------------+  |
+------------------------------------------------------------------+
]]></artwork>
        </figure>
        <t>
   As shown in <xref target="fig1"/>, target="fig1" format="default"/>, the BNG Control Plane BNG-CP 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 BNG-CP can be implemented as
   Virtual Network Functions (VNFs) and hosted in a Network
   Function Virtualization Infrastructure (NFVI).</t> an NFVI.</t>
        <t>
   The User Plane Management module UP management module in the BNG Control Plane BNG-CP centrally manages
   the distributed BNG User Planes BNG-UPs (e.g., load balancing), as well as the
   setup, deletion, and maintenance of channels between Control Planes CPs and
   User Planes.
   UPs.  Other modules in the BNG control plane, BNG-CP, such as address
   management, AAA, etc., are responsible for the connection with external
   subsystems in order to fulfill those services. Note that the User Plane
   SHOULD UP
   <bcp14>SHOULD</bcp14> support both physical and virtual network functions. For example,
   BNG user plane L3 forwarding related
   network functions related to BNG-UP L3 forwarding can be disaggregated
   and distributed across the physical infrastructure.  And infrastructure, and the other control
   plane and CP
   management plane functions in the CU Separation CU-separated BNG can be moved
   into the NFVI for virtualization <xref target="TR-384"/>.</t> target="TR-384" format="default"/>.</t>
        <t>
   The details of CU separated the CU-separated BNG's function components are as following:</t> follows:</t>
        <t>
   The Control Plane CP is responsible for the following:</t>

	<t><list style="hanging" hangIndent="3"><t hangText="Address
	management:"> unified

        <ul spacing="normal">
          <li>Address  management: Unified address pool management and CGN subscriber
	address traceability management.
	</t>

	<t hangText="AAA:">
	</li>
          <li>AAA: This component performs Authentication,
	Authorization
	Authorization, and Accounting, together with RADIUS/DIAMETER. RADIUS/Diameter. The BNG
	communicates with the AAA server to check whether the subscriber who
	sent an Access-Request access request has network access authority.  Once the
	subscriber goes online, this component together (together with the Service
	Control component implement component) implements accounting, data capacity limitation, and
	QoS enforcement policies.
	</t>

	<t hangText="Subscriber management:"> user
	</li>
          <li>Subscriber management: User entry management and
	forwarding policy management.
	</t>

	<t hangText="Access management:"> process
	</li>
          <li>Access management: Process user dial-up packets, such
	as PPPoE, DHCP, L2TP, etc.
	</t>

	<t hangText="UP management:"> management
	</li>
          <li>UP management: Management of UP interface status, status and
	the setup, deletion, and maintenance of channels between CP and UP.
	</t>

	</list>
	</t>
	</li>
        </ul>

        <t>
   The User Plane UP is responsible for the following:</t>

	<t><list style="hanging" hangIndent="3"><t hangText="Routing
        <ul spacing="normal">
          <li>Routing control
	functions:"> responsible functions: Responsible for constructing instantiating routing forwarding plane
	(e.g., routing, multicast, MPLS, etc.).
	</t>

	<t hangText="Routing
	</li>
          <li>Routing and Service Forwarding service forwarding plane functions:">
	responsible including functions: Responsibilities
          include traffic forwarding, QoS QoS, and traffic statistics collection.
	</t>

	<t hangText="Subscriber detection:"> responsible
	</li>
          <li>Subscriber detection: Responsible for detecting whether
	a subscriber is still online.
	</t>

	</list>
	</t>
	</li>
        </ul>
      </section>
      <section title="BNG anchor="sect-3.3" numbered="true" toc="default">
        <name>BNG CUPS Interfaces" anchor="sect-3.3"><t>
   Three Interfaces</name>
        <t>
   The three interfaces defined below support the communication between the
   Control Plane
   CP and User Plane. UP.  These are referred to as the Service
   Interface (Si), Control Interface (Ci), and Management Interface (Mi)
   as shown in <xref target="fig2"/>.</t> target="fig2" format="default"/>.</t>
        <figure title="Interfaces Between anchor="fig2">
          <name>Interfaces between the CP and UP of the BNG" anchor="fig2"><artwork><![CDATA[ BNG</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
          +-----------------------------------+
          |                                   |
          |               BNG-CP              |
          |                                   |
          +--+--------------+--------------+--+
             |              |              |
  1. Service |   2. Control | 3. Management|
   Interface |    Interface |    Interface |
        (Si) |         (Ci) |         (Mi) |
             |              |              |
             |           ___|___           |
             |       ___(       )___       |
            _|______(               )______|_
           (                                 )
          (         Network/Internet         )
           (________                 ________)
             |      (___         ___)      |
             |          (_______)          |
             |              |              |
             |              |              |
          +--+--------------+--------------+--+
          |                                   |
          |               BNG-UP              |
          |                                   |
          +-----------------------------------+
]]></artwork>
        </figure>
        <section title="Service Interface" anchor="sect-3.3.1"><t> anchor="sect-3.3.1" numbered="true" toc="default">
          <name>Service Interface (Si)</name>
          <t>
   For a traditional BNG (without CU separation), the user dial-up
   signals are terminated and processed by the control plane CP 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.</t>
          <t>
   The Service Interface (Si) Si is used to establish tunnels between the
   CP and UP. The tunnels are responsible for relaying the PPPoE, IPoE, PPPoE-, IPoE-,
   and L2TP related L2TP-related control packets that are received from a Residential
   Gateway (RG) over those tunnels. An appropriate tunnel type is VXLAN
   Virtual eXtensible Local Area Network (VXLAN)
   <xref target="RFC7348"/>.</t> target="RFC7348" format="default"/>.</t>
          <t>
   The detailed definition of Si is out of scope for this document.</t>
        </section>
        <section title="Control Interface" anchor="sect-3.3.2"><t> anchor="sect-3.3.2" numbered="true" toc="default">
          <name>Control Interface (Ci)</name>
          <t>
   The CP uses the Control Interface Ci to deliver subscriber session
   states, network routing entries, etc. etc., to the UP (see <xref target="sect-6.2.7"/>). target="sect-6.2.7" format="default"/>).
   The UP uses this interface to report subscriber service statistics,
   subscriber detection results, etc. etc., to the CP (see Sections 6.3 <xref target="sect-6.3" format="counter"/> and
   6.4).
   <xref target="sect-6.4" format="counter"/>). A carrying protocol for this interface is specified in this
   document.</t>
        </section>
        <section title="Management Interface" anchor="sect-3.3.3"><t>
   NETCONF anchor="sect-3.3.3" numbered="true" toc="default">
          <name>Management Interface (Mi)</name>
          <t>
   The Network Configuration Protocol (NETCONF) <xref target="RFC6241"/> target="RFC6241"
   format="default"/> is the protocol used on the Management Interface Mi between a CP and UP. It
   is used to configure the parameters of the
   Control Interface, Service Interface, the Access interfaces Ci, Si, access interfaces,
   and QoS/ACL Templates. It is expected that implementations will make use of
   existing YANG models where possible, possible but that new YANG models specific to
   S-CUSP will need to be defined. The definitions of the parameters that can
   be configured are out of scope for this document.</t>
        </section>
      </section>
      <section title="BNG anchor="sect-3.4" numbered="true" toc="default">
        <name>BNG CUPS Procedure Overview" anchor="sect-3.4"><t> Overview</name>
        <t>
   The following numbered sequences <xref target="fig3"/> gives (<xref target="fig3" format="default"/>) give a high-level view
   of the main BNG CUPS procedures.</t>

        <figure title="BNG anchor="fig3">
          <name>BNG CUPS Procedures Overview" anchor="fig3"><artwork><![CDATA[ Overview</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
   RG              UP                      CP              AAA
   |               |                        |               |
   |               |Establish S-CUSP Channel|               |
   |              1|<---------------------->|               |
   |               |                        |               |
   |               | Report Board      |               |
   |               | board interface |               |
   |               |      information       |               |
   |              2|------to CP via Ci----->|               |
   |               |                        |               |
   |               |  Update BAS function   |               |
   |              3|   request / response    request/response    |               |
   |               |<-----on UP via Ci----->|               |
   |               |                        |               |
   |               | Update network routing |               |
   |               |   request / response    request/response    |               |
   |              4|<------- via Ci-------->|               |
   |               |                        |               |
   |  Online Req   |                        |               |
5.1|-------------->|                        |               |
   |               | Relay the Online Req   |               |
   |            5.2|-----to CP via Si------>| Authentication|
   |               |                        |    Req/Rep    |
   |               |                     5.3|<------------->|
   |               | Send the Online Rep    |               |
   |            5.4|<----to UP via Si-------|               |
   |  Online Rep   |               |                        |
5.5|<--------------|                        |               |
   |               | Create subscriber      |               |
   |               |    session on UP       |               |
   |            5.6|<--------via            5.5|<--------via Ci-------->|               |
   |  Online Rep   |                        |               |
5.6|<--------------|                        |               |
   |               |                        |  CoA Request  |
   |               |                     6.1|<--------------|
   |               | Update session on UP   |               |
   |            6.2|<--------via Ci-------->|               |
   |               |                        |  CoA Response |
   |               |                     6.3|-------------->|
   |               |                        |               |
   |  Offline Req  |                        |               |                     6.3|-------------->|
7.1|-------------->|                        |               |
   |               | Relay the Offline Req  |               |
   |            7.2|------to CP via Si----->|               |
   |               |                        |               |
   |               | Send the Offline Rep   |               |
   |            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 synchronization   |               |
   |              9|<--------via Ci-------->|               |
   |               |                        |               |
   |               | CGN Address Allocation address allocation |               |
   |             10|<--------via Ci-------->|               |
   |               |                        |               |
]]></artwork>               |]]></artwork>
        </figure>

	<t><list style="format (%d)">

	<t>

        <ol spacing="normal" type="(%d)">
          <li> S-CUSP session establishment: This is the first step of the BNG
	CUPS procedures. Once the Control Interface Ci parameters are
	configured on a UP, it will start to setup set up S-CUSP sessions with the
	specified CPs. The detailed definition of S-CUSP session establishment
	can be found in <xref target="sect-4.1.1"/>.
	</t>

	<t> target="sect-4.1.1" format="default"/>.
	</li>
          <li> Board and interface report: Once the S-CUSP session is
          established between the UP and a CP, the UP will report status
          information on the boards and subscriber-facing interfaces of this
          UP to the CP. A board can also be called a Line/Service Process Unit
          (LPU/SPU) card. The subscriber-facing interfaces refer to the
          interfaces that connect the
	Access Network access network nodes (e.g., OLT: Optical Line Terminal, DSLAM: Digital
	Subscriber Line Access Multiplexer,
          Terminal (OLT), DSLAM, etc.). The CP can use this information to
          enable the Broadband Access Service Server (BAS) function (e.g., IPoE,
          PPPoE, etc.) on the specified interfaces. See Sections
	4.2.1 <xref
          target="sect-4.2.1" format="counter"/> and 7.10 <xref target="sect-7.10"
          format="counter"/> for more details on Resource resource reporting.
	</t>

	<t>
	</li>
          <li> BAS (Broadband Access Service) function enable: To enable the BAS
	function on the specified interfaces of a UP.
	</t>

	<t>
	</li>
          <li> Subscriber network route advertisement: The CP will allocate one
	or more IP 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 to the network the routes that can reach
	those IP addresses.
	</t>

	<t>
	</li>
          <li> 5.1-5.6 is a complete call flow of a subscriber dial-up (as
	defined in <xref target="sect-2.1"/>) target="sect-4.3.1" format="default"/>) process.  When a UP receives a
	dial-up request, it will relay the request packet to a CP through the
	Service Interface.
	Si. The CP will parse the request. If everything is OK,
	it will send an authentication request to the AAA server to
	authenticate the 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
	enabling the subscriber to access the network.  For different access
	types, the process may be a bit different.  But different, but the high-level process
	is similar. For each access type, the detail detailed process can be found in
	<xref target="sect-5"/>.
	</t>

	<t> target="sect-5" format="default"/>.
	</li>
          <li> 6.1-6.3 is the sequence when updating an existing subscriber
	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 <xref target="sect-4.3.2"/> target="sect-4.3.2" format="default"/> for more detail on CP
	messages updating UP tables.
	</t>

	<t>
	</li>
          <li> 7.1-7.5 is the sequence for deleting an existing subscriber
	session. When a UP receives an offline request, Offline Request, it will relay the
	request to a CP through the Service Interface. Si. The CP will send back a
	response to the UP through the Service Interface. Si. The UP will then
	forward the offline response Offline Response to the subscriber.  Then the CP will
	delete the session on the UP through the Control Interface.
	</t> Ci.
	</li>
          <li>
            <t> Event reports include the following two parts (more detail can
            be found in <xref target="sect-4.3.4"/>) target="sect-4.3.4" format="default"/>). Both
            are reported using the Event
       message.

        <vspace blankLines="1"/> message: </t>

          <ul empty="true" spacing="normal">
            <li>
        8.1. Subscriber Traffic Statistics Report
	<vspace blankLines="1"/>
            </li>
            <li>
	8.2.  Subscriber Detection Result Report
	</t>

	<t>
            </li>
</ul>
          </li>
          <li> Data synchronization: See Sections 4.2.5 <xref target="sect-4.2.5" format="default"/> for more detail on CP and
	UP Synchronization.
	</t>

	<t> synchronization.
	</li>
          <li> CGN address allocation: See Sections 4.2.4 <xref target="sect-4.2.4" format="default"/> for more detail on CGN
	Address Allocation.
	</t>

	</list>
	</t>
	address allocation.
	</li>
        </ol>
      </section>
    </section>
    <section title="S-CUSP anchor="sect-4" numbered="true" toc="default">
      <name>S-CUSP Protocol Overview" anchor="sect-4"><section title="Control Overview</name>
      <section anchor="sect-4.1" numbered="true" toc="default">
        <name>Control Channel Related Procedures" anchor="sect-4.1"><section title="S-CUSP Procedures</name>
        <section anchor="sect-4.1.1" numbered="true" toc="default">
          <name>S-CUSP Session Establishment" anchor="sect-4.1.1"><t> Establishment</name>
          <t>
   A UP is associated with a CP and is controlled by that CP. In the
   case of a hot-standby or cold-standby, a UP is associated with two
   CPs, one called
   CPs: the Master master CP and the other called the Standby standby CP.
   The association between a UP and its CPs is implemented by dynamic
   configuration.</t>
          <t>
   Once a UP knows its CPs, the UP starts to establish S-CUSP sessions
   with those CPs, as shown in <xref target="fig4"/>.</t> target="fig4" format="default"/>.</t>
          <figure title="S-CUSP anchor="fig4">
            <name>S-CUSP Session Establishment" anchor="fig4"><artwork><![CDATA[ Establishment</name>
            <artwork name="" type="" align="left" alt=""><![CDATA[
                 UP                               CP
                 |                                 |
                 |   TCP Session Establishment     |
                 |<------------------------------->|
                 |                                 |
                 |   HELLO   Hello (version, capability)   |
                 |-------------------------------->|
                 |                                 |
                 |   HELLO   Hello (version, capability)   |
                 |<--------------------------------|
                 |                                 |
]]></artwork>                                 |]]></artwork>
          </figure>
          <t>
   The S-CUSP session establishment consists of two successive steps:</t>

	<t><list style="format (%d)">

   <t>
          <ol spacing="normal" type="(%d)">
            <li> Establishment of a TCP [RFC793] connection (3-way handshake) <xref target="RFC0793" format="default"/> between the CP and
            the UP using a configured port from the dynamic port range
            (49152-65535).
	</t>

   <t>
	</li>
            <li> Establishment of an S-CUSP session over the TCP connection.</t>

       </list>
       </t> connection.</li>
          </ol>
          <t> Once the TCP connection is established, the CP and the UP initialize
   the S-CUSP session session, during which the version and Keepalive timers are
   negotiated.</t>
          <t>
   The version information (Hello TLV, see <xref target="sect-7.4"/>) target="sect-7.4" format="default"/>) is carried
   within Hello messages (see <xref target="sect-6.2.1"/>). target="sect-6.2.1" format="default"/>).  A CP can support multiple
   versions, but a UP can only support one version.  So, version; thus the version
   negotiation is based on whether a version can be supported by both
   the CP and the UP.  For
   If a CP or UP, if UP receives a Hello message is received that does not indicate
   a version supported by both, it responds with a subsequent Hello message with
   containing an Error Information TLV will be sent to the peer to notify the peer of the "Version-Mismatch" error
   Version-Mismatch error, and the session establishment phase
   fails.</t>
          <t>
   Keepalive negotiation is performed by carrying a Keepalive TLV in the
   Hello message.  The Keepalive TLV includes a Keepalive timer and Dead
   Timer
   DeadTimer field. The CP and UP have to agree on the Keepalive Timer and
   Dead Timer.
   DeadTimer.  Otherwise, a subsequent Hello message with an Error
   Information TLV will be sent to its peer peer, and the session
   establishment phase fails.</t>
          <t>
   The S-CUSP session establishment phase fails if the CP or UP disagree
   on the version and keepalive parameters or if 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. Successive retries are permitted, but an
   implementation SHOULD <bcp14>SHOULD</bcp14> make use of an exponential back-off backoff session
   establishment retry procedure.</t>
          <t>
   The S-CUSP session timer values that need to be configured are
   summarized in the table below.</t>

	<figure><artwork><![CDATA[
 Timer               Range in   Default
 Name                seconds    Value
-------------        -------   -------
Establishment Timer  1-32767   45
Keepalive Timer        0-255   30
DeadTimer            1-32767   4 <xref target="tab-sess-timers"/>.</t>
<table anchor="tab-sess-timers">
<name>S-CUSP Session Timers</name>
 <thead>
   <tr>
    <th>Timer Name</th><th>Range in Seconds</th><th>Default Value</th>
   </tr>
 </thead>
 <tbody>
  <tr>
    <td>Establishment Timer</td><td>1-32767</td><td>45</td>
  </tr>
  <tr>
    <td>Keepalive Timer</td><td>0-255</td><td>30</td>
  </tr>
  <tr>
    <td>DeadTimer</td><td>1-32767</td><td>4 * Keepalive
]]></artwork>
	</figure> Keepalive</td>
  </tr>
 </tbody>
</table>
        </section>
        <section title="Keepalive anchor="sect-4.1.2" numbered="true" toc="default">
          <name>Keepalive Timer and DeadTimer" anchor="sect-4.1.2"><t> DeadTimer</name>
          <t>
   Once an S-CUSP session has been established, a UP or CP may want to
   know that its S-CUSP peer is still connected.</t>
          <t>
   Each end of an 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. Thus, a message is
   transmitted at least as often as the value to which the Keepalive timer is
   reset to,
   reset, unless, as explained below, that value is the special value
   zero.</t>
          <t>
   Each end of a an S-CUSP session also run runs a DeadTimer, DeadTimer and restarts that
   DeadTimer whenever a message is received on the session.  If the
   DeadTimer expires at an end of the session expires, session, that end declares the
   session dead and the session will be closed, unless their DeadTimer
   is set to the special value zero zero, in which case the session will not
   time out.</t>
          <t>
   The minimum value of the Keepalive timer is 1 second, and it is
   specified in units of 1 second.  The RECOMMENDED <bcp14>RECOMMENDED</bcp14> default value is 30
   seconds.  The recommended default for the DeadTimer is four times the
   value of the Keepalive timer used by the remote peer.  As above, the
   timers may be disabled by setting them to zero.</t>
          <t>
   The Keepalive timer and DeadTimer are negotiated through the
   Keepalive TLV carried in the Hello Message.</t> message.</t>
        </section>
      </section>
      <section title="Node Related Procedures" anchor="sect-4.2"><section title="UP anchor="sect-4.2" numbered="true" toc="default">
        <name>Node Procedures</name>
        <section anchor="sect-4.2.1" numbered="true" toc="default">
          <name>UP Resource Report" anchor="sect-4.2.1"><t> Report</name>
          <t>
   Once an S-CUSP session has been established between a CP and an a UP, the UP
   reports the state information of the Boards boards and access-facing interfaces on
   the UP to the CP, as shown in <xref target="fig5"/>. target="fig5" format="default"/>. Report messages are
   unacknowledged and are assumed to be delivered because the session runs
   over TCP.</t>
          <t>
   The CP can use that information to activate/enable the Broadband
   Access Service (BAS)
   BAS functions (e.g., IPoE, PPPoE, etc.) on the
   specified interfaces.</t>
          <t>
   In addition, the UP resource report may trigger a UP warm-standby
   process.  In the case of warm-standby, a failure on a UP may trigger
   the CP to start a warm-standby process, by moving the on-line online
   subscriber sessions to a standby UP and then direct directing the affected
   subscribers to access the Internet through the standby UP.</t>
          <figure title="UP anchor="fig5">
            <name>UP Board and Interface Report" anchor="fig5"><artwork><![CDATA[ Report</name>
            <artwork name="" type="" align="left" alt=""><![CDATA[
                     UP                      CP
                     |                        |
                     |  Report Board Status   |
                     |------to CP via Ci----->|
                     |                        |
                     | Report Interface Status|
                     |------to CP via Ci----->|
                     |                        |
]]></artwork>                        |]]></artwork>
          </figure>
          <t>
   Board status information is carried in the Board Status TLV (<xref
   target="sect-7.10.2"/>) target="sect-7.10.2" format="default"/>),
   and Interface interface status information is carried in the
   Interface Status TLV (<xref target="sect-7.10.1"/>). target="sect-7.10.1" format="default"/>). Both Board Status and
   Interface Status TLVs are carried in the Report Message message (<xref
   target="sect-6.4"/>).</t> target="sect-6.4" format="default"/>).</t>
        </section>
        <section title="Update anchor="sect-4.2.2" numbered="true" toc="default">
          <name>Update BAS Function on Access Interface"
	anchor="sect-4.2.2"><t> Interface</name>
          <t> Once the CP collects the interface status of a
	UP, it will activate/de-activate/modify activate/deactivate/modify the BAS functions on specified
	interfaces through the Update_Request and Update_Response message exchanges
	(<xref target="sect-6.2"/>) exchanges, target="sect-6.2" format="default"/>), carrying the BAS Function TLV
	(<xref target="sect-7.7"/>).</t> target="sect-7.7" format="default"/>).</t>
          <figure title="Update anchor="fig6">
            <name>Update BAS Function" anchor="fig6"><artwork><![CDATA[ Function</name>
            <artwork name="" type="" align="left" alt=""><![CDATA[
                     UP                       CP
                     |                         |
                     |   Update BAS function Function   |
                     |         Request         |
                     |<-----on UP via Ci-------|
                     |                         |
                     |   Update BAS function Function   |
                     |         Response        |
                     |------on UP via Ci------>|
                     |                         |
]]></artwork>                         |]]></artwork>
          </figure>
        </section>
        <section title="Update anchor="sect-4.2.3" numbered="true" toc="default">
          <name>Update Network Routing" anchor="sect-4.2.3"><t> Routing</name>
          <t>
   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
   assigned to subscribers who are dialing up to the UP. To enable the
   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.</t>
          <figure title="Update anchor="fig7">
            <name>Update Network Routing" anchor="fig7"><artwork><![CDATA[ Routing</name>
            <artwork name="" type="" align="left" alt=""><![CDATA[
                     UP                       CP
                     |                         |
                     | Subscriber network route|
                     |      update request     |
                     |<------- via Ci----------|
                     |                         |
                     | Subscriber network route|
                     |      update response    |
                     |-------- via Ci--------->|
                     |                         | ]]></artwork>
          </figure>
          <t>
   The Update Request Update_Request and Response Message Update_Response message exchanges, carrying the
   IPv4/IPv6 Routing Information TLVs (<xref target="sect-7.8"/>), target="sect-7.8" format="default"/>), update the
   subscriber's network routing information.</t>
        </section>
        <section title="CGN anchor="sect-4.2.4" numbered="true" toc="default">
          <name>CGN Public IP Address Allocation" anchor="sect-4.2.4"><t> Allocation</name>
          <t>
   The following sequences (<xref target="fig8" format="default"/>) describe the procedures related to CGN address management related
   procedures.
   management.  Three independent procedures are defined, defined: one each
   for CGN address allocation request/response, CGN address renewal
   request/response, and CGN address release request/response.</t>
          <t>
   CGN address allocation/renew/release procedures are designed for the case
   where the CGN function is running on the UP.  The UP has to map the
   subscriber private IP addresses to a public IP addresses, and such mapping
   is performed by the UP locally when a subscriber dials-up. dials up.  That means the
   UP has to ask for public IPv4 address blocks for CGN subscribers from the
   CP.</t>
          <t>
   In addition, when a public IP address is allocated to a UP, there
   will be a lease time (e.g., one day). Before the lease time expires,
   the UP can ask for renewal of the IP address lease from the CP. It is
   achieved by the exchange of the Addr_Renew_Req and Addr_Renew_Ack
   messages.</t>
          <t>
   If the public IP address will not be used anymore, the UP SHOULD <bcp14>SHOULD</bcp14>
   release the address by sending an Addr_Release_Req message to the CP.</t>
          <t>
   If the CP wishes to withdraw addresses that it has previously leased
   to a UP, it uses the same procedures as above.  The "Oper" Oper code
   (see <xref target="sect-7.1" format="default"/>) in the IPv4/IPv6 Routing TLV
   (see <xref target="sect-7.1"/>) target="sect-7.8" format="default"/>) determines whether the
   request is an update or withdraw.</t>
          <t>
   The relevant messages are defined in Section 6.5.</t> <xref target="sect-6.5" format="default"/>.</t>
          <figure title="CGN anchor="fig8">
            <name>CGN Public IP Address Allocation" anchor="fig8"><artwork><![CDATA[ Allocation</name>
            <artwork name="" type="" align="left" alt=""><![CDATA[
                 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----------|
                 |                         |
]]></artwork>                         |]]></artwork>
          </figure>
        </section>
        <section title="Data anchor="sect-4.2.5" numbered="true" toc="default">
          <name>Data Synchronization between the CP and UP" anchor="sect-4.2.5"><t> UP</name>
          <t>
   For a CU separated CU-separated BNG, the UP will continue to function using the
   state that has been installed in it even if the CP fails or the
   session between the UP and CP fails.</t>
          <t>
   Under some circumstances, it is necessary to synchronize state
   between the CP and UP, for example example, if a CP fails and the UP is
   switched to a different CP.</t>
          <t>
   Synchronization includes two directions.  One direction is from UP to
   CP; in that case, the synchronization information is mainly about the
   board/interface status of the UP.  The other direction is from CP to
   UP; in that case, the subscriber sessions, subscriber network routes,
   L2TP tunnels, etc. etc., will be synchronized to the UP.</t>
          <t>
   The synchronization is triggered by a Sync_Request message, to which
   the receiver will (1) reply with a Sync_Begin message to notify the
   requester that synchronization will begin, begin and (2) then start the
   synchronization using the Sync_Data message.  When synchronization
   finished,
   finishes, a Sync_End message will be sent.</t>
          <t>
   The following figure
   <xref target="fig9" format="default"/> shows the process of data synchronization
   between a UP and a CP.</t>
          <figure title="Data Synchronization" anchor="fig9"><artwork><![CDATA[ anchor="fig9">
            <name>Data Synchronization</name>
            <artwork name="" type="" align="left" alt=""><![CDATA[
                     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       |
                     |Subscriber Session States|
                     |  Network Route Entries  |
                     |<------- via Ci----------|
                     |                         |
                     | Synchronization End     |
                     |<-------- via Ci---------|
                     |                         |
                    2) Synchronization from CP to UP ]]></artwork>
          </figure>
        </section>
      </section>
      <section title="Subscriber anchor="sect-4.3" numbered="true" toc="default">
        <name>Subscriber Session Related Procedures" anchor="sect-4.3"><t> Procedures</name>
        <t>
   A subscriber session consists of a set of forwarding states, policies, and
   security rules that are applied to the subscriber.  It is used for
   forwarding subscriber traffic in a UP.  To initialize a session on a UP, A a
   collection of hardware resources (e.g., NP, TCAM TCAM, etc.) have has to be allocated to
   a session on a UP as part of its initiation.</t>
        <t>
   Subscriber session
   Procedures related procedures to subscriber sessions include subscriber session create, creation,
   update, delete, deletion, and statistics report. reporting.  The following sub-sections subsections give a
   high-level view of the procedures.</t>
        <section title="Create anchor="sect-4.3.1" numbered="true" toc="default">
          <name>Create Subscriber Session" anchor="sect-4.3.1"><t> Session</name>
          <t>
   The below sequence below (<xref target="fig10" format="default"/>) describes the DHCP IPv4 dial-up process. It is an
   example that shows how a subscriber session is created. (An example
   for IPv6 appears in <xref target="sect-5.1.2"/>.)</t> target="sect-5.1.2" format="default"/>.)</t>

          <figure title="Subscriber Session Create" anchor="fig10"><artwork><![CDATA[ anchor="fig10">
            <name>Creating a Subscriber Session</name>
            <artwork name="" type="" align="left" alt=""><![CDATA[
     RG              UP                       CP             AAA
     |               |                        |               |
     | Online Request|                        |               |
    1|-------------->|                        |               |
     |               |Relay the Online Request|               |
     |              2|-----to CP via Si------>| Authentication|
     |               |                        |    Req/Rep    |
     |               |                       3|<------------->|
     |               |  Create subscriber Subscriber     |               |
     |               |   session   Session Request      |               |
     |              4|<--------via Ci---------|               |
     |               |                        |               |
     |               |  Create subscriber Subscriber     |               |
     |               |   session   Session Response     |               |
     |              5|---------via Ci-------->|               |
     |               |                        |               |
     |               |                        |   Accounting  |
     |               |                       6|<------------->|
     |               |                        |               |
     |               |  Send Online Response  |               |
     |              7|<----to UP via Si-------|               |
     |               |                        |               |
     |Online Response|                        |               |
   12|<--------------|                        |
    8|<--------------|                        |               |
     |               |                        |
]]></artwork>               |]]></artwork>
          </figure>
          <t>
   The request starts from an Online Request message (step 1) from the
   RG (for example, a DHCP Discovery packet).  When the UP receives the
   Online Request from the RG, it will tunnel the Online Request to the
   CP through the Service Interface (Step Si (step 2). A tunneling technology
   implements the Service Interface.</t> Si.</t>
          <t>
   When the CP receives the Online Request from the UP, it will send an
   authentication request to the AAA server to authenticate and
   authorize the subscriber (step 3).  When a positive reply is received
   from the AAA server, the CP starts to create a subscriber session for
   the request.  Relevant resources (e.g., IP address, bandwidth, etc.)
   will be allocated to the subscriber. Policies and security rules will
   be generated for the subscriber. Then the CP sends a request to
   create a session to the UP through the Control Interface (Ci) Ci (step
   4), and a response is expected from the UP to confirm the creation
   (step 5).</t>
          <t>
   Finally, the CP will notify the AAA server to start accounting (step
   6).  At the same time, an Online Response message (for example, a
   DHCP Ack packet) will be sent to the UP through the Si (step 7).  And
   the
   The UP will then forward the Online Response to the RG (step 8).</t>
          <t>
   That completes the subscriber activation process.</t>
        </section>
        <section title="Update anchor="sect-4.3.2" numbered="true" toc="default">
          <name>Update Subscriber Session" anchor="sect-4.3.2"><t> Session</name>
          <t>
   The following numbered sequence (<xref target="fig11" format="default"/>) shows the process of updating the
   subscriber session.</t>
          <figure title="Subscriber Session Update" anchor="fig11"><artwork><![CDATA[ anchor="fig11">
            <name>Updating a Subscriber Session</name>
            <artwork name="" type="" align="left" alt=""><![CDATA[
            UP                       CP             AAA
            |                        |  COA  CoA Request  |
            |                       1|<--------------|
            | Session update Update Request |               |
           2|<--------via Ci---------|               |
            |                        |               |
            | Session update Update Response|               |
           3|---------via Ci-------->|               |
            |                        |  COA  CoA Response |
            |                       4|-------------->|
            |                        |               |
]]></artwork>               |]]></artwork>
          </figure>
          <t>
   When a subscriber session has been created on a UP, there may be
   requirements to update the session with new parameters (e.g.,
   Bandwidth,
   bandwidth, QoS, policies, etc.).</t>
          <t>
   This procedure is triggered by a Change of Authorization (COA) (CoA)
   request message sent by the AAA server.  The CP will update the
   session on the UP according to the new parameters through the Control
   Interface.</t> Ci.</t>
        </section>
        <section title="Delete anchor="sect-4.3.3" numbered="true" toc="default">
          <name>Delete Subscriber Session" anchor="sect-4.3.3"><t> Session</name>
          <t>
   The below call flow below shows how S-CUPS S-CUSP deals with a subscriber offline
   request.</t> Offline
   Request.</t>
          <figure title="Subscriber Session Delete" anchor="fig12"><artwork><![CDATA[ anchor="fig12">
            <name>Deleting a Subscriber Session</name>
            <artwork name="" type="" align="left" alt=""><![CDATA[
           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 Delete     |
            |                |        Request         |
            |                |<--------via Ci---------|
            |                |     Session delete Delete     |
            |                |       Response         |
            |                |---------via Ci-------->|
            |                |                        |
]]></artwork>                        |]]></artwork>
          </figure>
          <t>
   Similar to the session creation process, when a UP receives an
   offline request
   Offline Request from an RG, it will tunnel the request to a CP
   through the Si.</t>
          <t>
   When the CP receives the offline request, Offline Request, it will withdraw/release
   the resources (e.g., IP address, bandwidth) that have been allocated
   to the subscriber.  Then, it  It then sends a reply to the UP through the
   Service Interface
   Si, and the UP will forward the reply to the RG.  At
   the same time, it will delete all the status of the session on the UP
   through the Ci.</t>
        </section>
        <section title="Subscriber anchor="sect-4.3.4" numbered="true" toc="default">
          <name>Subscriber Session Events Report" anchor="sect-4.3.4"><figure title="Events Report" anchor="fig13"><artwork><![CDATA[ Report</name>
          <figure anchor="fig13">
            <name>Events Report</name>
            <artwork name="" type="" align="left" alt=""><![CDATA[
                     UP                       CP
                     |                        |
                     | Statistic/Detect report| Report|
                     |---------via Ci-------->|
                     |                        |
]]></artwork>                        |]]></artwork>
          </figure>
          <t>
   When a session is created on a UP, the UP will periodically report statistics
   information and detect subscriber detection results of the session to the CP.</t> CP. </t>
        </section>
      </section>
    </section>
    <section title="S-CUSP anchor="sect-5" numbered="true" toc="default">
      <name>S-CUSP Call Flows" anchor="sect-5"><t> Flows</name>
      <t>
   The subsections below give an overview of various "dial-up"
   interactions over the Service Interface Si followed by an overview of
   the setting of information in the UP by the CP using S-CUSP over the
   Control Interface.</t>
   Ci.</t>
      <t>
   S-CUSP messages are described in this document using Routing Backus
   Naur Form (RBNF) as defined in <xref target="RFC5511"/>.</t> target="RFC5511" format="default"/>.</t>
      <section title="IPoE" anchor="sect-5.1"><section title="DHCPv4 Access"
		anchor="sect-5.1.1"> anchor="sect-5.1" numbered="true" toc="default">
        <name>IPoE</name>
        <section anchor="sect-5.1.1" numbered="true" toc="default">
          <name>DHCPv4 Access</name>
          <t>The following sequence (<xref target="fig14" format="default"/>) shows detailed procedures for DHCPv4 access.</t>
          <figure title="DHCPv4 Access" anchor="fig14"><artwork><![CDATA[ anchor="fig14">
            <name>DHCPv4 Access</name>
            <artwork name="" type="" align="left" alt=""><![CDATA[
     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 via Si-------|               |
     |  DHCP Offer   |                        |               |
    5|<--------------|                        |               |
     |  DHCP Request |                        |               |
    6|-------------->|                        |               |
     |               | Relay the DHCP Request| Request |               |
     |              7|-----to CP via Si------>|               |
     |               |                        |               |
     |               |  Create subscriber Subscriber     |               |
     |               |   session   Session Request      |               |
     |              8|<--------via Ci---------|               |
     |               |  Create subscriber Subscriber     |               |
     |               |   session   Session Response     |               |
     |              9|---------via Ci-------->|               |
     |               |                        |   Accounting  |
     |               |                      10|<------------->|
     |               |                        |               |
     |               |  Send DHCP ACK         |               |
     |             11|<----to UP via Si-------|               |
     |               |                        |               |
     |  DHCP ACK     |                        |               |
   12|<--------------|                        |               |
     |               |                        |               |
]]></artwork>               |]]></artwork>
          </figure>
          <t>
   The
   S-CUSP protocol implements steps 8 and 9.</t>
          <t>
   After a subscriber is authenticated and authorized by the AAA server,
   the CP creates a new subscriber session on the UP.  This is achieved
   by sending an Update_Request message to the UP.</t>
          <t>
   The format of the Update_Request message is shown as follows using
   RBNF:</t>

	<figure><artwork><![CDATA[
          <sourcecode type="rbnf"><![CDATA[
<Update_Request Message> ::= <Common Header>
                  <Basic Subscriber TLV>
                  <IPv4 Subscriber TLV>
                  <IPv4 Routing TLV>
                  [<Subscriber Policy TLV>]
]]></artwork>
	</figure>
]]></sourcecode>
          <t>
   The UP will reply with an Update_Response message, the message. The format of the
   Update_Response message is as follows:</t>

	<figure><artwork><![CDATA[
          <sourcecode type="rbnf"><![CDATA[
<Update_Response Message> ::= <Common Header>
                 <Update Response TLV>
                 [<Subscriber CGN Port Range TLV>]
]]></artwork>
	</figure>
]]></sourcecode>
        </section>
        <section title="DHCPv6 Access" anchor="sect-5.1.2"> anchor="sect-5.1.2" numbered="true" toc="default">
          <name>DHCPv6 Access</name>
          <t> The following sequence (<xref target="fig15" format="default"/>) shows detailed procedures for DHCPv6 access.
          </t>
          <figure title="DHCPv6 Access" anchor="fig15"><artwork><![CDATA[ anchor="fig15">
            <name>DHCPv6 Access</name>
            <artwork name="" type="" align="left" alt=""><![CDATA[
     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 via Si-------|               |
     |  Advertise    |                        |               |
    5|<--------------|                        |               |
     |               |                        |               |
     |  Request      |                        |               |
    6|-------------->|                        |               |
     |               |  Relay the Request     |               |
     |              7|-----to CP via Si------>|               |
     |               |                        |               |
     |               |                        |               |
     |               |  Create subscriber Subscriber     |               |
     |               |   session   Session Request      |               |
     |              8|<--------via Ci-------->|               |
     |               |                        |               |
     |               |  Create subscriber Subscriber     |               |
     |               |   session   Session Response     |               |
     |              9|---------via Ci-------->|               |
     |               |                        |               |
     |               |                        |   Accounting  |
     |               |                      10|<------------->|
     |               |                        |               |
     |               |  Send Reply            |               |
     |             11|<----to UP via Si-------|               |
     |               |                        |               |
     |  Reply        |                        |               |
   12|<--------------|                        |               |
     |               |                        |               |
]]></artwork>               |]]></artwork>
          </figure>
          <t>
   Steps 1-7 are a standard DHCP IPv6 access process.  The subscriber
   creation is triggered by a DHCP IPv6 request message.  When this
   message is received, it 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 an
   Update_Request message to the UP (Step (step 8).</t>
          <t>
   The format of the Update_Request message is as follows:</t>

	<figure><artwork><![CDATA[
          <sourcecode type="rbnf"><![CDATA[
<Update_Request Message> ::= <Common Header>
                  <Basic Subscriber TLV>
                  <IPv6 Subscriber TLV>
                  <IPv6 Routing TLV>
                  [<Subscriber Policy TLV>]
]]></artwork>
	</figure>
]]></sourcecode>
          <t>
   The UP will reply with an Update_Response message (Step (step 9). The
   format of the Update_Response message is as follows:</t>

	<figure><artwork><![CDATA[
          <sourcecode type="rbnf"><![CDATA[
<Update_Response Message> ::= <Common Header>
                 <Update Response TLV>
]]></artwork>
	</figure>
]]></sourcecode>
        </section>
        <section title="IPv6 SLAAC Access" anchor="sect-5.1.3"> anchor="sect-5.1.3" numbered="true" toc="default">
          <name>IPv6 Stateless Address Autoconfiguration (SLAAC) Access</name>
          <t>The following flow (<xref target="fig16" format="default"/>) shows the IPv6 SLAAC access process.</t>
          <figure title="IPv6 anchor="fig16">
            <name>IPv6 SLAAC Access" anchor="fig16"><artwork><![CDATA[ Access</name>
            <artwork name="" type="" align="left" alt=""><![CDATA[
     RG              UP                       CP             AAA
     |               |                        |               |
     |      RS       |                        |               |
    1|-------------->|                        |               |
     |               |  Relay the Router      |               |
     |               |    Solicit (RS)        |               |
     |              2|-----to CP via Si------>|      AAA      |
     |               |                        |    Req/Rep    |
     |               |                       3|<------------->|
     |               |                        |               |
     |               |  Create subscriber Subscriber     |               |
     |               |   session   Session Request      |               |
     |              4|<--------via Ci---------|               |
     |               |                        |               |
     |               |  Create subscriber Subscriber     |               |
     |               |   session   Session Response     |               |
     |              5|---------via Ci-------->|               |
     |               |                        |               |
     |               |  Send Router Advertise |               |
     |               |         (RA)           |               |
     |              6|<----to UP vis via 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|<--------------|                        |               |
     |               |                        |               |
]]></artwork>               |]]></artwork>
          </figure>
          <t>
   It starts with a Router Solicit (RS) request from an RG that is
   tunneled to the CP by the UP.  After the AAA authentication and
   authorization, the CP will create a subscriber session on the UP.</t>
          <t>
   This is achieved by sending an Update_Request message to the UP (step
   4).</t>
          <t>
   The format of the Update_Request message is as follows:</t>

	<figure><artwork><![CDATA[
          <sourcecode type="rbnf"><![CDATA[
<Update_Request Message> ::= <Common Header>
                  <Basic Subscriber TLV>
                  <IPv6 Subscriber TLV>
                  <IPv6 Routing TLV>
                  [<Subscriber Policy TLV>]
]]></artwork>
	</figure>
]]></sourcecode>
          <t>
   The UP will reply with an Update_Response message (step 5), the 5). The
   format of the Update_Response message is as follows:</t>

	<figure><artwork><![CDATA[
          <sourcecode type="rbnf"><![CDATA[
<Update_Response Message> ::= <Common Header>
                 <Update Response TLV>
]]></artwork>
	</figure>
]]></sourcecode>
        </section>
        <section title="DHCPv6 + anchor="sect-5.1.4" numbered="true" toc="default">
          <name>DHCPv6 and SLAAC Access" anchor="sect-5.1.4"> Access</name>
          <t> The following call flow (<xref target="fig17" format="default"/>) shows the DHCP IPv6 and SLAAC access
        process.</t>
          <figure title="DHCPv6 + anchor="fig17">
            <name>DHCPv6 and SLAAC Access" anchor="fig17"><artwork><![CDATA[ Access</name>
            <artwork name="" type="" align="left" alt=""><![CDATA[
     RG              UP                       CP             AAA
     |               |                        |               |
     |      RS       |                        |               |
    1|-------------->|                        |               |
     |               |  Relay the Router      |               |
     |               |    Solicit (RA) RS          |               |
     |              2|-----to CP via Si------>|      AAA      |
     |               |                        |    Req/Rep    |
     |               |                       3|<------------->|
     |               |                        |               |
     |               |  Create subscriber Subscriber     |               |
     |               |   session   Session Request      |               |
     |              4|<--------via Ci---------|               |
     |               |                        |               |
     |               |  Create subscriber Subscriber     |               |
     |               |   session   Session Response     |               |
     |              5|---------via Ci-------->|               |
     |               |                        |               |
     |               |  Send Router Advertise |               |
     |               |         (RA) RA               |               |
     |              6|<----to UP vis via Si-------|               |
     |      RA       |                        |               |
    7|<--------------|                        |               |
     |               |                        |               |
     |DHCPv6 Solicit |                        |               |
    8|-------------->|                        |               |
     |               |  Relay DHCPv6 Solicit  |               |
     |              9|-----to CP via Si------>|               |
     |               |                        |               |
     |               |  Update subscriber Subscriber     |               |
     |               |   session   Session Request      |               |
     |             10|<--------via Ci---------|               |
     |               |                        |               |
     |               |  Update subscriber Subscriber     |               |
     |               |   session   Session Response     |               |
     |             11|---------via Ci-------->|               |
     |               |                        |               |
     |               |                        |   Accounting  |
     |               |                      12|<------------->|
     |               |                        |               |
     |               |  Send DHCPv6 Reply     |               |
     |             13|<----to UP via Si-------|               |
     |               |                        |               |
     | DHCPv6 Reply  |                        |               |
   14|<--------------|                        |               |
     |               |                        |               |
]]></artwork>               |]]></artwork>
          </figure>
          <t>
   When a subscriber passes AAA authentication, the CP will create a
   subscriber session on the UP.  This is achieved by sending an
   Update_Request message to the UP (step 4).</t>

	<figure><artwork><![CDATA[
          <sourcecode type="rbnf"><![CDATA[
<Update_Request Message> ::= <Common Header>
                  <Basic Subscriber TLV>
                  <IPv6 Subscriber TLV>
                  <IPv6 Routing TLV>
                  [<Subscriber Policy TLV>]
]]></artwork>
	</figure>
]]></sourcecode>
          <t>
   The UP will reply with an Update_Response message (step 5). The
   format of the Update_Response is as follows:</t>

	<figure><artwork><![CDATA[
          <sourcecode type="rbnf"><![CDATA[
<Update_Response Message> ::= <Common Header>
                 <Update Response TLV>
]]></artwork>
	</figure>
]]></sourcecode>
          <t>
   After receiving a DHCPv6 Solicit, the CP will update the subscriber
   session by sending an Update_Request message with new parameters to
   the UP (Step (step 10).</t>
          <t>
   The format of the Update_Request message is as follows:</t>

	<figure><artwork><![CDATA[
          <sourcecode type="rbnf"><![CDATA[
<Update_Request Message> ::= <Common Header>
                  <Basic Subscriber TLV>
                  <IPv6 Subscriber TLV>
                  <IPv6 Routing TLV>
                  [<Subscriber Policy TLV>]
]]></artwork>
	</figure>
]]></sourcecode>
          <t>
   The UP will reply with an Update_Response message (step 11).  The
   format of the Update_Response is as follows:</t>

	<figure><artwork><![CDATA[
          <sourcecode type="rbnf"><![CDATA[
<Update_Response Message> ::= <Common Header>
                 <Update Response TLV>
]]></artwork>
	</figure>
]]></sourcecode>
        </section>
        <section title="DHCP Dual Stack Access" anchor="sect-5.1.5"><t> anchor="sect-5.1.5" numbered="true" toc="default">
          <name>DHCP Dual-Stack Access</name>
          <t>
   The following sequence (<xref target="fig18" format="default"/>) is a combination of DHCP IPv4 and DHCP IPv6
   access processes.</t>
          <figure title="DHCP Dual Stack Access" anchor="fig18"><artwork><![CDATA[ anchor="fig18">
            <name>DHCP Dual-Stack Access</name>
            <artwork name="" type="" align="left" alt=""><![CDATA[
     RG              UP                       CP             AAA
     |               |                        |               |
     | DHCP Discovery|                        |               |
    1|-------------->|                        |               |
     |               |Relay the DHCP Discovery|               |
     |              2|-----to CP via Si------>|     AAA       |
     |               |                        |   Req/Resp    |
     |               |                       3|<------------->|
     |               |                        |               |
     |               |  Send the DHCP Offer   |               |
     |              4|<----to UP vis via Si-------|               |
     |  DHCP Offer   |                        |               |
    5|<--------------|                        |               |
     |  DHCP Request |                        |               |
    6|-------------->|                        |               |
     |               |  Relay the DHCP Request|               |
     |              7|-----to CP via Si------>|               |
     |               |                        |               |
     |               |  Create subscriber Subscriber     |               |
     |               |   session   Session Request      |               |
     |              8|<--------via Ci-------->|               |
     |               |  Create subscriber Subscriber     |               |
     |               |   session   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) RS          |               |
     |             14|-----to CP via Si------>|      AAA      |
     |               |                        |    Req/Rep    |
     |               |                      15|<------------->|
     |               |                        |               |
     |               |  Create subscriber Subscriber     |               |
     |               |   session   Session Request      |               |
     |             16|<--------via Ci---------|               |
     |               |  Create subscriber Subscriber     |               |
     |               |   session   Session Response     |               |
     |             17|---------via Ci-------->|               |
     |               |                        |               |
     |               |  Send Router Advertise |               |
     |               |         (RA) the RA           |               |
     |             18|<----to UP vis via Si-------|               |
     |      RA       |                        |               |
   19|<--------------|                        |               |
     |               |                        |               |
     |DHCPv6 Solicit |                        |               |
   20|-------------->|                        |               |
     |               |  Relay DHCPv6 Solicit  |               |
     |             21|-----to CP via Si------>|               |
     |               |                        |               |
     |               |  Update subscriber Subscriber     |               |
     |               |   session   Session Request      |               |
     |             22|<--------via Ci---------|               |
     |               |  Update subscriber Subscriber     |               |
     |               |   session   Session Response     |               |
     |             23|---------via Ci-------->|               |
     |               |                        |   Accounting  |
     |               |                      24|<------------->|
     |               |  Send DHCPv6 Reply     |               |
     |             25|<----to UP via Si-------|               |
     | DHCPv6 Reply  |                        |               |
   26|<--------------|                        |               |
     |               |                        |               |
]]></artwork>               |]]></artwork>
          </figure>
          <t>
   The DHCP dual stack dual-stack access includes three sets of Update_Request /
   Update_Response
   Update_Request/Update_Response exchanges to create/update a DHCPv4/v6
   subscriber session.</t>

	<t><list style="format (%d)">
          <ol spacing="normal" type="(%d)">
            <li>
              <t>Create a DHCPv4 session (step (steps 8 and 9)

	<figure><artwork><![CDATA[ 9):

              </t>
              <sourcecode type="rbnf"><![CDATA[
<Update_Request Message> ::= <Common Header>
                  <Basic Subscriber TLV>
                  <IPv4 Subscriber TLV>
                  <IPv4 Routing TLV>
                  [<Subscriber Policy TLV>]

<Update_Response Message> ::= <Common Header>
                 <Update Response TLV>
                 [<Subscriber CGN Port Range TLV>]
]]></artwork>
	</figure></t>
]]></sourcecode>
            </li>
            <li>
              <t>Create a DHCPv6 session (step (steps 16 and 17)

	<figure><artwork><![CDATA[ 17):

              </t>
              <sourcecode type="rbnf"><![CDATA[
<Update_Request Message> ::= <Common Header>
                  <Basic Subscriber TLV>
                  <IPv6 Subscriber TLV>
                  <IPv6 Routing TLV>
                  [<Subscriber Policy TLV>]

<Update_Response Message> ::= <Common Header>
                 <Update Response TLV>
]]></artwork>
	</figure></t>
]]></sourcecode>
            </li>
            <li>
              <t>Update DHCPv6 session (step (steps 22 and 23)

	<figure><artwork><![CDATA[ 23):

              </t>
              <sourcecode type="rbnf"><![CDATA[
<Update_Request Message> ::= <Common Header>
                  <Basic Subscriber TLV>
                  <IPv6 Subscriber TLV>
                  <IPv6 Routing TLV>
                  [<Subscriber Policy TLV>]

<Update_Response Message> ::= <Common Header>
                 <Update Response TLV>
]]></artwork>
	</figure></t>

      </list>
	</t>
]]></sourcecode>
            </li>
          </ol>
        </section>
        <section title="L2 anchor="sect-5.1.6" numbered="true" toc="default">
          <name>L2 Static Subscriber Access" anchor="sect-5.1.6"> Access</name>
          <t>L2 static subscriber access processes are as follows:</t>
          <figure title="L2 anchor="fig19">
            <name>L2 Static Subscriber Access" anchor="fig19"><artwork><![CDATA[ Access</name>
            <artwork name="" type="" align="left" alt=""><![CDATA[
     RG              UP                      CP              AAA
     |               |                        |               |
     |               |    Static Subscriber   |               |
     |               |     Detection Req.     |               |
     |              1|<-----to UP via Ci------|               |
     |               |    Static Subscriber   |               |
     |               |     Detection Rep.     |               |
     |              2|------to UP 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 Subscriber     |               |
     |               |   session   Session Request      |               |
     |            3.5|<--------via Ci---------|               |
     |               |  Create subscriber Subscriber     |               |
     |               |   session   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 Subscriber     |               |
     |               |   session   Session Request      |               |
     |            4.4|<--------via Ci---------|               |
     |               |  Create subscriber Subscriber     |               |
     |               |   session   Session Response     |               |
     |            4.5|---------via Ci-------->|               |
     |  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 Subscriber     |               |
     |               |   session   Session Request      |               |
     |            5.4|<--------via Ci-------->|               |
     |               |  Create subscriber Subscriber     |               |
     |               |   session   Session Response     |               |
     |            5.5|---------via Ci-------->|               |
     |               |                        |               |
     |  ARP/ND(REQ)  |                        |               |
  5.6|<--------------|                        |               |
     |  ARP/ND(ACK)  |                        |               |
  5.7|-------------->|                        |               |
     |               |                        |               |
]]></artwork>               |]]></artwork>
          </figure>
          <t>
   For L2 static subscriber access, the process starts with a CP
   installing a static subscriber detection list on a UP.  The list
   determines which subscribers will be detected.  That is implemented
   by exchanging Update_Request and Update_Response messages between CP
   and UP.  The format formats of the messages are as follows:</t>

	<figure><artwork><![CDATA[
          <sourcecode type="rbnf"><![CDATA[
<Update_Request Message> ::= <Common Header>
                  <IPv4 Static Subscriber Detect TLVs>
                  <IPv6 Static Subscriber Detect TLVs>

<Update_Response Message> ::= <Common Header>
                 <Update Response TLV>
]]></artwork>
	</figure>
]]></sourcecode>
          <t>
   For L2 Static static subscriber access, there are three ways to trigger the
   access process:</t>

	<t><list style="format (%d)">

       <t>
          <ol spacing="normal" type="(%d)">
            <li> Triggered by UP (3.1-3.6): (steps 3.1-3.6): This assumes that the UP knows the IP
       address, the access interface, and the 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 to the UP.  The UP
       will tunnel the ARP/ND to the CP through the Si.  The CP then triggers
       the authentication process.  If the authentication result is positive.
       The positive,
       the CP will create a corresponding subscriber session on the UP.
	</t>

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

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

	</list>
	</t>
	</li>
          </ol>
          <t>
   From a subscriber session point of view, the procedures and the
   message formats for the above three cases above are the same, as follows:</t>

	<figure><artwork><![CDATA[
IPv4 Case: follows.</t>

<t>IPv4 Case:</t>
          <sourcecode type="rbnf"><![CDATA[
<Update_Request Message> ::= <Common Header>
                  <Basic Subscriber TLV>
                  <IPv4 Subscriber TLV>
                  <IPv4 Routing TLV>
                  [<Subscriber Policy TLV>]

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

IPv6 Case:
]]></sourcecode>

<t>IPv6 Case:</t>
          <sourcecode type="rbnf"><![CDATA[
<Update_Request Message> ::= <Common Header>
                  <Basic Subscriber TLV>
                  <IPv6 Subscriber TLV>
                  <IPv6 Routing TLV>
                  [<Subscriber Policy TLV>]

<Update_Response Message> ::= <Common Header>
                 <Update Response TLV>
]]></artwork>
	</figure>
]]></sourcecode>
        </section>
      </section>
      <section title="PPPoE" anchor="sect-5.2"><section title="IPv4 anchor="sect-5.2" numbered="true" toc="default">
        <name>PPPoE</name>
        <section anchor="sect-5.2.1" numbered="true" toc="default">
          <name>IPv4 PPPoE Access" anchor="sect-5.2.1">

<t> The following figure Access</name>
          <t><xref target="fig20" format="default"/> shows the IPv4 PPPoE access call flow.
          </t>
          <figure title="IPv4 anchor="fig20">
            <name>IPv4 PPPoE Access" anchor="fig20"><artwork><![CDATA[ Access</name>
            <artwork name="" type="" align="left" alt=""><![CDATA[
     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 Subscriber     |               |
     |               |   session   Session Request      |               |
     |              5|<--------via Ci---------|               |
     |               |                        |               |
     |               |  Create subscriber Subscriber     |               |
     |               |   session   Session Response     |               |
     |              6|---------via Ci-------->|               |
     |               |                        |               |
     |               |                        |   Accounting  |
     |               |                       7|<------------->|
     |               |                        |               |
]]></artwork>               |]]></artwork>
          </figure>
          <t>
   From
   In the above sequence, step 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.</t>
          <t>
   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:</t>

	<figure><artwork><![CDATA[
          <sourcecode type="rbnf"><![CDATA[
<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>
                 <Update Response TLV>
                 [<Subscriber CGN Port Range TLV>]
]]></artwork>
	</figure>
]]></sourcecode>
        </section>
        <section title="IPv6 anchor="sect-5.2.2" numbered="true" toc="default">
          <name>IPv6 PPPoE Access" anchor="sect-5.2.2">

        <t>The following figure Access</name>
          <t><xref target="fig21" format="default"/> describes the IPv6 PPPoE access call flow.</t>
          <figure title="IPv6 anchor="fig21">
            <name>IPv6 PPPoE Access" anchor="fig21"><artwork><![CDATA[ Access</name>
            <artwork name="" type="" align="left" alt=""><![CDATA[
     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 Subscriber     |               |
     |               |   session   Session Request      |               |
     |              5|<--------via Ci---------|               |
     |               |                        |               |
     |               |  Create subscriber Subscriber     |               |
     |               |   session   Session Response     |               |
     |              6|---------via Ci-------->|               |
     |               |                        |               |
     | ND Negotiation|        ND Negotiation  |               |
    7|<------------->|<---------via Si------->|               |
     |               |                        |               |
     |               |  Update subscriber Subscriber     |               |
     |               |   session   Session Request      |               |
     |              8|<--------via Ci---------|               |
     |               |                        |               |
     |               |  Update subscriber Subscriber     |               |
     |               |   session   Session Response     |               |
     |              9|---------via Ci-------->|               |
     |               |                        |               |
     |               |                        |   Accounting  |
     |               |                      10|<------------->|
     |               |                        |               |
     |    DHCPv6     |        DHCPv6          |               |
     |  Negotiation  |      Negotiation       |               |
   7'|<------------->|<---------via Si------->|               |
     |               |                        |               |
     |               |  Update subscriber Subscriber     |               |
     |               |   session   Session Request      |               |
     |             8'|<---------via Ci--------|               |
     |               |                        |               |
     |               |  Update subscriber Subscriber     |               |
     |               |   session   Session Response     |               |
     |             9'|---------via Ci-------->|               |
     |               |                        |               |
     |               |                        |   Accounting  |
     |               |                     10'|<------------->|
     |               |                        |               |
]]></artwork>               |]]></artwork>
          </figure>
          <t>
   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.</t>
          <t>
   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:</t>

	<figure><artwork><![CDATA[
          <sourcecode type="rbnf"><![CDATA[
<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>
                 <Update Response TLV>
]]></artwork>
	</figure>
]]></sourcecode>
          <t>
   Then, the RG will initialize an ND/DHCPv6 negotiation process with
   the CP (see step steps 7 and 7'), 7'); after that, it will trigger an update
   (8-9,
   (steps 8-9 and 8'-9') to the subscriber session. The formats of the update
   messages are as follows:</t>

	<figure><artwork><![CDATA[
          <sourcecode type="rbnf"><![CDATA[
<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>
                 <Update Response TLV>
]]></artwork>
	</figure>
]]></sourcecode>
        </section>
        <section title="PPPoE Dual Stack Access" anchor="sect-5.2.3"><t>
   The following figure anchor="sect-5.2.3" numbered="true" toc="default">
          <name>PPPoE Dual-Stack Access</name>
          <t>
   <xref target="fig22" format="default"/> shows a combination of IPv4 and IPv6 PPPoE
   access call flow.</t> flows.</t>
          <figure title="PPPoE Dual Stack Access" anchor="fig22"><artwork><![CDATA[ anchor="fig22">
            <name>PPPoE Dual-Stack Access</name>
            <artwork name="" type="" align="left" alt=""><![CDATA[
     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 Subscriber  |               |
     |               |   session   Session Request      |               |
     |              5|<--------via Ci---------|               |
     |               |  Create v4 subscriber Subscriber  |               |
     |               |   session   Session Response     |               |
     |              6|---------via Ci-------->|               |
     |               |                        |   Accounting  |
     |               |                       7|<------------->|
     |  PPP IP6CP    |        PPP IP6CP       |               |
   4'|<------------->|<---------via Si------->|               |
     |               |                        |               |
     |               |  Create V6 subscriber Subscriber  |               |
     |               |   session   Session Request      |               |
     |             5'|<--------via Ci---------|               |
     |               |  Create v6 subscriber Subscriber  |               |
     |               |   session   Session Response     |               |
     |             6'|---------via Ci-------->|               |
     |               |                        |               |
     | ND Negotiation|     ND Negotiation     |               |
    8|<------------->|<---------via Si------->|               |
     |               |                        |               |
     |               |  Update v6 subscriber Subscriber  |               |
     |               |   session   Session Request      |               |
     |              9|<---------via Ci--------|               |
     |               |  Update v6 subscriber Subscriber  |               |
     |               |   session   Session Response     |               |
     |             10|---------via Ci-------->|               |
     |               |                        |   Accounting  |
     |               |                      7'|<------------->|
     |    DHCPv6     |        DHCPv6          |               |
     |  Negotiation  |      Negotiation       |               |
   8'|<------------->|<---------via Si------->|               |
     |               |                        |               |
     |               |  Update v6 subscriber Subscriber  |               |
     |               |   session   Session Request      |               |
     |             9'|<--------via Ci---------|               |
     |               |                        |               |
     |               |  Update v6 subscriber Subscriber  |               |
     |               |   session   Session Response     |               |
     |            10'|---------via Ci-------->|               |
     |               |                        |               |
     |               |                        |   Accounting  |
     |               |                      7"|<------------->|
     |               |                        |               |
]]></artwork>               |]]></artwork>
          </figure>
          <t>
   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:</t>

   <t><list style="format (%d)">
          <ol spacing="normal" type="(%d)">
            <li>
              <t> Create an IPv4 PPPoE subscriber session (5-6)

	<figure><artwork><![CDATA[ (steps 5-6):

              </t>
              <sourcecode type="rbnf"><![CDATA[
<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>
                 <Update Response TLV>
                 [<Subscriber CGN Port Range TLV>]
]]></artwork>
	</figure></t>
]]></sourcecode>
            </li>
            <li>
              <t> Create an IPv6 PPPoE subscriber session (5'-6')

	<figure><artwork><![CDATA[ (steps 5'-6'):

              </t>
              <sourcecode type="rbnf"><![CDATA[
<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>
                 <Update Response TLV>
]]></artwork>
	</figure></t>
]]></sourcecode>
            </li>
            <li>
              <t> Update the IPv6 PPPoE subscriber session (9-10, 9'-10')

	<figure><artwork><![CDATA[ (steps 9-10 and 9'-10'):

              </t>
              <sourcecode type="rbnf"><![CDATA[
<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>
                 <Update Response TLV>
]]></artwork>
	</figure></t>

      </list>
      </t>
]]></sourcecode>
            </li>
          </ol>
        </section>
      </section>
      <section title="WLAN Access" anchor="sect-5.3">

        <t>The following figure anchor="sect-5.3" numbered="true" toc="default">
        <name>WLAN Access</name>
        <t><xref target="fig23" format="default"/> shows the WLAN access call flow.</t>
        <figure title="WLAN Access" anchor="fig23"><artwork><![CDATA[ anchor="fig23">
          <name>WLAN Access</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
     RG            UP              CP         AAA      WEB      Web Server
     |             |                |          |           |
     |    DHCP     |                |          |           |
     |  Discovery  |                |          |           |
    1|------------>|                |          |           |
     |             | DHCP      |          |           |
     |             | Discovery |          |           |
     |            2|-----via Si---->|   AAA    |           |
     |             |   DHCP Offer   |<-------->|           |
     |            3|<----via Si-----|          |           |
     |  DHCP Offer |                |          |           |
    4|<------------|                |          |           |
     | DHCP    |                |          |           |
     |    Request  | Request|                |          |           |
    5|------------>|                |          |           |
     |             |  DHCP Request  |          |           |
     |            6|-----via Si---->|          |           |
     |             |                |          |           |
     |             | Create session Session |          |           |
     |             |    Request     |          |           |
     |            7|<----via Ci-----|          |           |
     |             | Create session Session |          |           |
     |             |    Response    |          |           |
     |            8|----via Ci----->|          |           |
     |             |                |          |           |
     |             |  DHCP ACK      |          |           |
     |            9|<----via Si-----|          |           |
     |             |                |          |           |
     |  DHCP ACK   |                |          |           |
   10|<------------|                |          |           |
     |             |                |          |           |
     | Subscriber  |                |          |           |
     | HTTP Traffic|                |          |           |
   11|------------>|-->             |          |           |
     |             |  | WEB Web URL     |          |           |
     |  Traffic    |  | Redirect    |          |           |
     | Redirection |  |             |          |           |
   12|<------------|<-+             |          |           |
     |                                                     |          |           |
     |                                                     |
   13|-----------------Redirect to Web server------------->| Server------------->|
     |                                                     |
   14|<----------------Push HTTP log-in page---------------| Log-in Page---------------|
     |                                                     |
   15|-----------------User Authentication---------------->|
     |                                                     |
     |             |                |  Portal Interchange  |
     |             |              16|<-------------------->|
     |             |                |                      |
     |             |                |   AAA    |           |
     |             |                |  Req/Rep |           |
     |             |              17|<-------->|           |
     |             |                |          |           |
     |             | Update session Session |          |           |
     |             |    Request     |          |           |
     |           18|<----via Ci-----|          |           |
     |             |                |          |           |
     |             | Update session Session |          |           |
     |             |    Response    |          |           |
     |           19|-----via Ci---->|          |           |
     |             |                |          |           |
]]></artwork>           |]]></artwork>
        </figure>
        <t>
   WLAN access starts with the DHCP dial-up process (steps 1-6), after
   that 1-6). After
   that, the CP will create a subscriber session on the UP (steps 7-8).
   The formats of the session creation messages are as follows:</t>

	<figure><artwork><![CDATA[
IPv4 Case:

<t>IPv4 Case:</t>
        <sourcecode type="rbnf"><![CDATA[
<Update_Request Message> ::= <Common Header>
                  <Basic Subscriber TLV>
                  <IPv4 Subscriber TLV>
                  <IPv4 Routing TLV>
                  [<Subscriber Policy TLV>]

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

IPv6 Case:
]]></sourcecode>

<t>IPv6 Case:</t>
<sourcecode type="rbnf"><![CDATA[
<Update_Request Message> ::= <Common Header>
                  <Basic Subscriber TLV>
                  <IPv6 Subscriber TLV>
                  <IPv6 Routing TLV>
                  [<Subscriber Policy TLV>]

<Update_Response Message> ::= <Common Header>
                 <Update Response TLV>
]]></artwork>
	</figure>
]]></sourcecode>
        <t>
   After step 10, the RG will be allocated an IP address address, and its first
   HTTP packet will be redirected to a WEB web server for subscriber
   authentication (steps 11-17).  After the WEB web authentication, if the
   result is positive, the CP will update the subscriber session by
   using the following message exchanges:</t>

	<figure><artwork><![CDATA[
IPv4 Case:

<t>IPv4 Case:</t>
        <sourcecode type="rbnf"><![CDATA[
<Update_Request Message> ::= <Common Header>
                  <Basic Subscriber TLV>
                  <IPv4 Subscriber TLV>
                  <IPv4 Routing TLV>
                  [<Subscriber Policy TLV>]

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

IPv6 Case:
]]></sourcecode>

<t>IPv6 Case:</t>
        <sourcecode type="rbnf"><![CDATA[
<Update_Request Message> ::= <Common Header>
                  <Basic Subscriber TLV>
                  <IPv6 Subscriber TLV>
                  <IPv6 Routing TLV>
                  [<Subscriber Policy TLV>]

<Update_Response Message> ::= <Common Header>
                 <Update Response TLV>
]]></artwork>
	</figure>
]]></sourcecode>
      </section>
      <section title="L2TP" anchor="sect-5.4"><section title="L2TP anchor="sect-5.4" numbered="true" toc="default">
        <name>L2TP</name>
        <section anchor="sect-5.4.1" numbered="true" toc="default">
          <name>L2TP LAC Access" anchor="sect-5.4.1"><figure title="L2TP-LAC Access" anchor="fig24"><artwork><![CDATA[ Access</name>
          <figure anchor="fig24">
            <name>L2TP LAC Access</name>
            <artwork name="" type="" align="left" alt=""><![CDATA[
     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 Tunnel  |        |          |
     |            | negotiation Negotiation  |        |          |
     |            |   SCCRQ/     |        |          |
     |            |   SCCRP/     |        |          |
     |            |   SCCCN      |        |          |
     |           5|<---via Si--->|        |          |
     |            | /\                               |
     |            | || forward Forward                       |
     |            | \/                               |
     |            |<-----------via routing---------->| Routing---------->|
     |            |                                  |
     |            | L2TP session Session |        |          |
     |            | negotiation Negotiation  |        |          |
     |            |    ICRQ/     |        |          |
     |            |    ICRP/     |        |          |
     |            |    ICCN      |        |          |
     |           6|<---via Si--->|        |          |
     |            | /\                               |
     |            | || forward Forward                       |
     |            | \/                               |
     |            |<-----------via routing---------->| Routing---------->|
     |            |                                  |
     |            |    Create    |         |         |
     |            |   subscriber |         |         |
     |            |    session  Subscriber  |         |         |
     |            |    Request  Session Req |         |         |
     |           7|<---via Ci----|         |         |
     |            |              |         |         |
     |            |    Create    |         |         |
     |            |   subscriber |         |         |
     |            |    session  Subscriber  |         |         |
     |            |    Response  Session Rep |         |         |
     |           8|----via Ci--->|         |         |
     |            |              |         |         |
     |                                               |
     |         PAP/CHAP (Triggered by LNS)           |
    9|<-----------------via routing?---------------->| Routing----------------->|
     |                                               |
]]></artwork>                                               |]]></artwork>
          </figure>
          <t>
   Steps 1-4 are a standard PPPoE access process.  After that, the LAC-CP
   starts to negotiate an L2TP session and tunnel with the LNS.  After the
   negotiation, the CP will create an L2TP LAC subscriber session on the UP
   through the following messages:</t>

	<figure><artwork><![CDATA[
          <sourcecode type="rbnf"><![CDATA[
<Update_Request Message> ::= <Common Header>
                  <Basic Subscriber TLV>
                  <L2TP-LAC Subscriber TLV>
                  <L2TP-LAC Tunnel TLV>

<Update_Response Message> ::= <Common Header>
                 <Update Response TLV>
]]></artwork>
	</figure>
]]></sourcecode>
        </section>
        <section title="L2TP anchor="sect-5.4.2" numbered="true" toc="default">
          <name>L2TP LNS IPv4 Access" anchor="sect-5.4.2"><figure title="IPv4 L2TP-LNS Access" anchor="fig25"><artwork><![CDATA[ Access</name>
          <figure anchor="fig25">
            <name>L2TP LNS IPv4 Access</name>
            <artwork name="" type="" align="left" alt=""><![CDATA[
     RG          LAC            UP(LNS)  AAA      CP(LNS)
     |            |              |        |          |
     |    PPPoE   |              |        |          |
     |  Discovery |              |        |          |
    1|<---------->|              |        |          |
     |            |              |        |          |
     |  PPP LCP   |              |        |          |
    2|<---------->|                       |          |
     |            |          AAA          |          |
     |PPP PAP/CHAP|        Req/Rep        |          |
    3|<---------->|<--------------------->|          |
     |            |                                  |
     |            |                                  |
     |            | L2TP tunnel Tunnel  |     L2TP tunnel Tunnel   |
     |            | negotiation Negotiation  |     negotiation     Negotiation   |
     |            |   SCCRQ/     |       SCCRQ/      |
     |            |   SCCRP/     |       SCCRP/      |
     |            |   SCCCN      |       SCCCN       |
     |           4|<------------>|<------via Si----->|
     |            |              |                   |
     |            | L2TP session Session |     L2TP session Session  |
     |            | negotiation Negotiation  |     negotiation     Negotiation   |
     |            |    ICRQ/     |        ICRQ/      |
     |            |    ICRP/     |        ICRP/      |
     |            |    ICCN      |        ICCN       |
     |           5|<------------>|<------via Si----->|
     |            |              |                   |
     |            |              | Create Subscriber |
     |            |              |   subscriber      |
     |            |              |    session        |
     |            |              | Session Request   |
     |            |             6|<-----via Ci-------|
     |            |              | Create Subscriber |
     |            |              |   subscriber      |
     |            |              |    session        |
     |            |              | Session Response  |
     |            |             7|------via Ci------>|
     |                                               |
     |          PAP/CHAP (Triggered by LNS)          |
    8|<--------------------------------------------->|
     |                                               |
     |            |              |        |    AAA   |
     |            |              |        |  Req/Rep |
     |            |              |       9|<-------->|
     |            |              |                   |
     |                                               |
     |                   PPP IPCP                    |
   10|<--------------------------------------------->|
     |                                               |
     |            |              | Update Subscriber |
     |            |              |   subscriber      |
     |            |              |    session        |
     |            |              | Session Request   |
     |            |            11|<-----via Ci-------|
     |            |              | Update Subscriber |
     |            |              |   subscriber      |
     |            |              |    session        |
     |            |              | Session Response  |
     |            |            12|------via Ci------>|
     |            |              |                   |
]]></artwork>                   |]]></artwork>
          </figure>
          <t>
   In this case, the BNG is running as an LNS and separated into LNS-CP
   and LNS-UP.  Steps 1-5 finish the normal L2TP dial-up process.  When
   the L2TP session and tunnel negotiations are finished, the LNS-CP
   will create an L2TP LNS subscriber session on the LNS-UP.  The format
   of the messages is as follows:</t>

	<figure><artwork><![CDATA[
          <sourcecode type="rbnf"><![CDATA[
<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>
                 <Update Response TLV>
                 [<Subscriber CGN Port Range TLV>]
]]></artwork>
	</figure>
]]></sourcecode>
          <t>
   After that, the LNS-CP will trigger an a AAA authentication.  If the
   authentication result is positive, a PPP IPCP IP Control Protocol (IPCP) process
   will follow, and
   then the CP will update the session with the following message
   exchanges:</t>

	<figure><artwork><![CDATA[
          <sourcecode type="rbnf"><![CDATA[
<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>
                 <Update Response TLV>
                 [<Subscriber CGN Port Range TLV>]
]]></artwork>
	</figure>
]]></sourcecode>
        </section>
        <section title="L2TP anchor="sect-5.4.3" numbered="true" toc="default">
          <name>L2TP LNS IPv6 Access" anchor="sect-5.4.3"><figure title="L2TP-LNS Access</name>
          <figure anchor="fig26">
            <name>L2TP LNS IPv6 Access" anchor="fig26"><artwork><![CDATA[ Access</name>
            <artwork name="" type="" align="left" alt=""><![CDATA[
     RG          LAC          UP(LNS)    AAA      CP(LNS)
     |            |              |        |          |
     |    PPPoE   |              |        |          |
     |  Discovery |              |        |          |
    1|<---------->|              |        |          |
     |            |              |        |          |
     |  PPP LCP   |              |        |          |
    2|<---------->|                       |          |
     |            |          AAA          |          |
     |PPP PAP/CHAP|        Req/Rep        |          |
    3|<---------->|<--------------------->|          |
     |            |                                  |
     |            |                                  |
     |            | L2TP tunnel Tunnel  |     L2TP tunnel Tunnel   |
     |            | negotiation Negotiation  |     negotiation     Negotiation   |
     |            |   SCCRQ/     |       SCCRQ/      |
     |            |   SCCRP/     |       SCCRP/      |
     |            |   SCCCN      |       SCCCN       |
     |           4|<------------>|<------via Si----->|
     |            |              |                   |
     |            | L2TP session Session |     L2TP session Session  |
     |            | negotiation Negotiation  |     negotiation     Negotiation   |
     |            |    ICRQ/     |        ICRQ/      |
     |            |    ICRP/     |        ICRP/      |
     |            |    ICCN      |        ICCN       |
     |           5|<------------>|<------via Si----->|
     |            |              |                   |
     |            |              | Create Subscriber |
     |            |              |   subscriber      |
     |            |              |    session        |
     |            |              | Session Request   |
     |            |             6|<-----via Ci-------|
     |            |              | Create Subscriber |
     |            |              |   subscriber      |
     |            |              |    session        |
     |            |              | Session Response  |
     |            |             7|------via Ci------>|
     |                                               |
     |          PAP/CHAP (Triggered by LNS)          |
    8|<--------------------------------------------->|
     |                                               |
     |            |              |        |    AAA   |
     |            |              |        |  Req/Rep |
     |            |              |       9|<-------->|
     |            |              |        |          |
     |                                               |
     |                   PPP IP6CP                   |
   10|<--------------------------------------------->|
     |                                               |
     |            |              | Update Subscriber |
     |            |              |   subscriber      |
     |            |              |    session        |
     |            |              | Session Request   |
     |            |            11|<-----via Ci-------|
     |            |              | Update Subscriber |
     |            |              |   subscriber      |
     |            |              |    session        |
     |            |              | Session Response  |
     |            |            12|------via Ci------>|
     |                           |                   |
     |
     |                           |                   |
     |       ND negotiation Negotiation      |   ND negotiation Negotiation  |
   13|<------------------------->|<-----via Si------>|
     |                           |                   |
     |            |              | Update Subscriber |
     |            |              |   subscriber      |
     |            |              |    session        |
     |            |              | Session Request   |
     |            |            14|<-----via Ci-------|
     |            |              | Update Subscriber |
     |            |              |   subscriber      |
     |            |              |    session        |
     |            |              | Session Response  |
     |            |            15|------via Ci------>|
     |            |              |                   |
]]></artwork>                   |]]></artwork>
          </figure>

          <t>
   Steps 1-12 are the same as L2TP and LNS IPv4 Access. access.  Steps 1-5
   finish the normal L2TP dial-up process.  When the L2TP session and
   tunnel negotiations are finished, the LNS-CP will create an L2TP LNS
   subscriber session on the LNS-UP.  The format of the messages is as
   follows:</t>

	<figure><artwork><![CDATA[
          <sourcecode type="rbnf"><![CDATA[
<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>
                 <Update Response TLV>
]]></artwork>
	</figure>
]]></sourcecode>
          <t>
   After that, the LNS-CP will trigger a AAA authentication. If the
   authentication result is positive, a PPP IP6CP process will follow, and
   then the CP will update the session with the following message
   exchanges:</t>

	<figure><artwork><![CDATA[
          <sourcecode type="rbnf"><![CDATA[
<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>
                 <Update Response TLV>
]]></artwork>
	</figure>
]]></sourcecode>
          <t>
   Then, an ND negotiation will be triggered by the RG.  After the ND
   negotiation, the CP will update the session with the following
   message exchanges:</t>

	<figure><artwork><![CDATA[
          <sourcecode type="rbnf"><![CDATA[
<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>
                 <Update Response TLV>
]]></artwork>
	</figure>
]]></sourcecode>
        </section>
      </section>
      <section title="CGN anchor="sect-5.5" numbered="true" toc="default">
        <name>CGN (Carrier Grade NAT)" anchor="sect-5.5"><figure title="CGN Access" anchor="fig27"><artwork><![CDATA[ NAT)</name>
        <figure anchor="fig27">
          <name>CGN Access</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
       RG              UP                       CP             AAA
       |               |                        |               |
       |               |  Public Address Block  |               |
       |               |   Allocation Request   |               |
       |              1|<--------via Ci-------->|               |
       |               |  Public Address Block  |               |
       |               |   Allocation Reply     |               |
       |              2|---------via Ci-------->|               |
       |               |                        |               |
       |   Subscriber  |                        |               |
       | access request| Access Request|        Subscriber      |               |
      3|-------------->|      access request      Access Request    |               |
       |              4|----------via Si------->|               |
       |               |                        |      AAA      |
       |               |       Subscriber       |    Req/Rep    |
       |  Subscriber   |      access reply      Access Reply     5|<------------->|
       | access reply Access Reply 6|<---------via Si--------|               |
      7|<--------------|                        |               |
       |               |                        |               |
       |               |  Create subscriber Subscriber     |               |
       |               |   session   Session Request      |               |
       |              8|<--------via Ci---------|               |
       |               |                        |               |
       |               |  Create subscriber Subscriber     |               |
       |               |   session   Session Response     |               |
       |               | (with NAT information) |               |
       |              9|---------via Ci-------->|               |
       |               |                        |               |
       |               |                        |   Accounting  |
       |               |                        |  with source  |
       |               |                        |   information |
       |               |                      10|<------------->|
       |               |                        |  Public IP +  |
       |               |                        |  Port range Range   |
       |               |                        |  to Private IP|
       |               |                        |  mapping      |  Mapping      |
       |               |                        |
]]></artwork>               |]]></artwork>
        </figure>
        <t>
   The first steps allocate one or more CGN address blocks to the UP
   (steps 1-2).  This is achieved by the following message exchanges
   between CP and UP.</t>

	<figure><artwork><![CDATA[ UP:</t>
        <sourcecode type="rbnf"><![CDATA[
<Addr_Allocation_Req Message> ::= <Common Header>
                  <Request Address
                  <Address Allocation Request TLV>

<Addr_Allocation_Ack Message> ::= <Common Header>
                 <Address Assignment Allocation Response TLV>
]]></artwork>
	</figure>
]]></sourcecode>
        <t>
   Steps 3-9 show 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.</t>
        <t>
   If a subscriber is a CGN subscriber, once the subscriber session is
   created/updated, the UP will report the NAT information to the CP.
   This is achieved by carrying the "Subscriber Subscriber CGN Port Range TLV" TLV in
   the Update_Response message.</t>
      </section>
      <section title="L3 anchor="sect-5.6" numbered="true" toc="default">
        <name>L3 Leased Line Access" anchor="sect-5.6"> Access</name>
        <section title="Web Authentication" anchor="sect-5.6.1"> anchor="sect-5.6.1" numbered="true" toc="default">
          <name>Web Authentication</name>
          <figure title="Web Authentication based anchor="fig28">
            <name>Web Authentication-Based L3 Leased Line Access" anchor="fig28"><artwork><![CDATA[ Access</name>
            <artwork name="" type="" align="left" alt=""><![CDATA[
     RG            UP              CP         AAA      WEB      Web Server
     |             |                |          |           |
     | User     |                |          |           |
     |   traffic   | traffic|                |          |           |
    1|------------>|                |          |           |
     |             | User      |          |           |
     |             | traffic   |          |           |
     |            2|-----via Si---->|    AAA   |           |
     |             |                |  Req/Rep |           |
     |             |               3|<-------->|           |
     |             | Create session Session |          |           |
     |             |    Request     |          |           |
     |            4|<----via Ci-----|          |           |
     |             |                |          |           |
     |             | Create session Session |          |           |
     |             |    Response    |          |           |
     |            5|----via Ci----->|          |           |
     |    HTTP     |             |                |          |           |   traffic
     | HTTP traffic|                |          |           |
    6|------------>|                |          |           |
     |             |                |          |           |
     | Redirect to |                |          |           |
     |   Web URL   |                |          |           |
    7|<------------|                |          |           |
     |             |                |          |           |
     |                                                     |
    8|-----------------Redirected to Web server----------->| Server----------->|
     |                                                     |
    9|<----------------Push HTTP Log-in page---------------| Page---------------|
     |                                                     |
   10|-----------------User Authentication---------------->|
     |                                                     |
     |             |                |  Portal Interchange  |
     |             |              11|<-------------------->|
     |             |                |                      |
     |             |                |   AAA    |           |
     |             |                |  Req/Rep |           |
     |             |              12|<-------->|           |
     |             |                |          |           |
     |             |                |          |           |
     |             | Update session Session |          |           |
     |             |    Request     |          |           |
     |           13|<----via Ci-----|          |           |
     |             |                |          |           |
     |             | Update session Session |          |           |
     |             |    Response    |          |           |
     |           14|----via Ci----->|          |           |
     |             |                |          |           |
]]></artwork>           |]]></artwork>
          </figure>
          <t>
   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 has passed the authentication, the CP will
   create a corresponding subscriber session on the UP through the
   following message exchanges:</t>

	<figure><artwork><![CDATA[
IPv4 Case:

<t>IPv4 Case:</t>
          <sourcecode type="rbnf"><![CDATA[
<Update_Request Message> ::= <Common Header>
                  <Basic Subscriber TLV>
                  <IPv4 Subscriber TLV>
                  <IPv4 Routing TLV>
                  [<Subscriber Policy TLV>]

<Update_Response Message> ::= <Common Header>

                 <Update Response TLV>
                 [<Subscriber CGN Port Range TLV>]

IPv6 Case:
]]></sourcecode>

<t>IPv6 Case:</t>
          <sourcecode type="rbnf"><![CDATA[
<Update_Request Message> ::= <Common Header>
                  <Basic Subscriber TLV>
                  <IPv6 Subscriber TLV>
                  <IPv6 Routing TLV>
                  [<Subscriber Policy TLV>]

<Update_Response Message> ::= <Common Header>
                 <Update Response TLV>
]]></artwork>
	</figure>
]]></sourcecode>
          <t>
   Then, the HTTP traffic from the RG will be redirected to a WEB web server
   to finish the WEB web authentication.  Once the WEB web authentication is
   passed, the CP will trigger another AAA authentication.  After the
   AAA authentication, the CP will update the session with the following
   message exchanges:</t>

	<figure><artwork><![CDATA[
IPv4 Case:

<t>IPv4 Case:</t>
          <sourcecode type="rbnf"><![CDATA[
<Update_Request Message> ::= <Common Header>
                  <Basic Subscriber TLV>
                  <IPv4 Subscriber TLV>
                  <IPv4 Routing TLV>
                  [<Subscriber Policy TLV>]

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

IPv6 Case:
]]></sourcecode>

<t>IPv6 Case:</t>
          <sourcecode type="rbnf"><![CDATA[
<Update_Request Message> ::= <Common Header>
                  <Basic Subscriber TLV>
                  <IPv6 Subscriber TLV>
                  <IPv6 Routing TLV>
                  [<Subscriber Policy TLV>]

<Update_Response Message> ::= <Common Header>
                 <Update Response TLV>
]]></artwork>
	</figure>
]]></sourcecode>
        </section>
        <section title="User anchor="sect-5.6.2" numbered="true" toc="default">
          <name>User Traffic Trigger" anchor="sect-5.6.2"> Trigger</name>
          <figure title="User anchor="fig29">
            <name>User Traffic Triggered L3 Leased Line Access" anchor="fig29"><artwork><![CDATA[ Access</name>
            <artwork name="" type="" align="left" alt=""><![CDATA[
     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 Session |          |
     |             |    Request     |          |
     |            5|<----via Ci-----|          |
     |             | Create session Session |          |
     |             |    Response    |          |
     |            6|----via Ci----->|          |
     |             |                |          |
]]></artwork>          |]]></artwork>
          </figure>
          <t>
   In this user traffic triggered case, the CP must install on the UP an access
   control list on the UP, list, which is used by the UP to determine whether or not
   an RG is legal or not. legal.  If the traffic is from a legal RG, it will be
   redirected to the CP though the Si.  The CP will trigger a AAA
   interchange with the AAA server.  After that, the CP will create a
   corresponding subscriber session on the UP with the following message
   exchanges:</t>

	<figure><artwork><![CDATA[
IPv4 Case:

<t>IPv4 Case:</t>
          <sourcecode type="rbnf"><![CDATA[
<Update_Request Message> ::= <Common Header>
                  <Basic Subscriber TLV>
                  <IPv4 Subscriber TLV>
                  <IPv4 Routing TLV>
                  [<Subscriber Policy TLV>]

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

IPv6 Case:
]]></sourcecode>

<t>IPv6 Case:</t>
          <sourcecode type="rbnf"><![CDATA[
<Update_Request Message> ::= <Common Header>
                  <Basic Subscriber TLV>
                  <IPv6 Subscriber TLV>
                  <IPv6 Routing TLV>
                  [<Subscriber Policy TLV>]

<Update_Response Message> ::= <Common Header>
                 <Update Response TLV>
]]></artwork>
	</figure>
]]></sourcecode>
        </section>
      </section>
      <section title="Multicast anchor="sect-5.7" numbered="true" toc="default">
        <name>Multicast Service Access" anchor="sect-5.7"><figure title="Multicast Access" anchor="fig30"><artwork><![CDATA[ Access</name>
        <figure anchor="fig30">
          <name>Multicast Access</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
           RG            UP              CP         AAA
           |             |                |          |
           | User access Access |  User access Access   |   AAA    |
           |   request   Request   |    request    Request     |  Req/Rep |
          1|<----------->|<----via Si---->|<-------->|
           |             |      User                |          |
           |             |                |          |
           |             |                |          |
           |             | Create session Create Session |          |
           |             |    Request     |          |
           |            2|<----via Ci---->|          |
           |             |                |          |
           |             | Create session Session |          |
           |             |    Response    |          |
           |            3|----via Ci----->|          |
           |             |                |          |
           |  Multicast  |                |          |
           | negotiation |                |          |
          4|<----------->|                |          |
           |             |                |          |
]]></artwork>          |]]></artwork>
        </figure>
        <t>
   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:</t>

	<figure><artwork><![CDATA[
IPv4 Case:

<t>IPv4 Case, there will be a Multicast-ProfileV4 sub-TLV present in
   the Subscriber Policy TLV:</t>
        <sourcecode type="rbnf"><![CDATA[
<Update_Request Message> ::= <Common Header>
               <Multicast Group Information TLV>
               <Basic Subscriber TLV>
               <IPv4 Subscriber TLV>
               <IPv4 Routing TLV>
               [<Subscriber
               <Subscriber Policy TLV>] TLV>

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

IPv6 Case:
]]></sourcecode>

<t>IPv6 Case, there will be a Multicast-ProfileV6 sub-TLV present in
   the Subscriber Policy TLV:</t>
        <sourcecode type="rbnf"><![CDATA[
<Update_Request Message> ::= <Common Header>
               <Multicast Group Information TLV>
               <Basic Subscriber TLV>
               <IPv6 Subscriber TLV>
               <IPv6 Routing TLV>
               [<Subscriber
               <Subscriber Policy TLV>] TLV>

<Update_Response Message> ::= <Common Header>
              <Update Response TLV>
]]></artwork>
	</figure>
]]></sourcecode>
      </section>
    </section>
    <section title="S-CUSP anchor="sect-6" numbered="true" toc="default">
      <name>S-CUSP Message Formats" anchor="sect-6"><t> Formats</name>
      <t>
   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 an
   unknown message type or missing mandatory TLV MUST <bcp14>MUST</bcp14> trigger an Error message
   (see <xref target="sect-6.7"/>) target="sect-6.7" format="default"/>) or a response Response message with an Error Information TLV (see
   <xref target="sect-7.6"/>).</t> target="sect-7.6" format="default"/>).</t>
      <t>
   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.</t>
      <t>
   This section specifies the format of the common S-CUSP message header
   and lists the defined messages.</t>
      <t>
   Network byte order is used for all multi-byte fields.</t>
      <section title="Common anchor="sect-6.1" numbered="true" toc="default">
        <name>Common Message Header" anchor="sect-6.1"><figure title="S-CUSP Header</name>
        <figure anchor="fig31">
          <name>S-CUSP Message Common Header" anchor="fig31"><artwork><![CDATA[
S-CUSP Common Message Header: Header</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
    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         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
        </figure>

	<t><list style="hanging" hangIndent="3">

      <t hangText="Ver
        <dl newline="false" spacing="normal" indent="3">
          <dt>Ver (4 bits):"> bits):</dt>
          <dd> The major version of the protocol. This
      document specifies version 1. Different major versions of the protocol
      may have significantly different message structure structures and format formats 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 the UP
      both using the same major version of the protocol.
	</t>

	<t hangText="Resv
	</dd>
          <dt>Resv (4 bits):"> bits):</dt>
          <dd> Reserved. MUST <bcp14>MUST</bcp14> be sent as zero and
	ignored on receipt.
	</t>

	<t hangText="Message-Type
	</dd>
          <dt>Message-Type (8 bits):"> bits):</dt>
          <dd> The set of message types
	specified in this document is listed in <xref target="sect-9.1"/>.
	</t>

	<t hangText="Message-Length target="sect-9.1" format="default"/>.
	</dd>
          <dt>Message-Length (16 bits):"> bits):</dt>
          <dd> Total length of the S-CUSP
	message including the common header, expressed in number of bytes as
	an unsigned integer.
	</t>

	<t hangText="Transaction ID
	</dd>
          <dt>Transaction-ID (16 bits):"> bits):</dt>
          <dd> This field is used to
	identify requests. It is echoed back in any corresponding
	ACK/Response/Error message. It is RECOMMENDED <bcp14>RECOMMENDED</bcp14> that a monotonically
	increasing value be used in successive message messages and that the value wrap wraps
	back to zero after 0xFFFF.  The contents content of this field is an opaque
	value that the receiver MUST NOT <bcp14>MUST NOT</bcp14> use for any purpose except to echo
	back in a corresponding response and, optionally, for logging.
	</t>

	</list>
	</t>
	</dd>
        </dl>
      </section>
      <section title="Control Messages" anchor="sect-6.2"><t> anchor="sect-6.2" numbered="true" toc="default">
        <name>Control Messages</name>
        <t>
   This document defines the following control messages:</t>

	<figure><artwork><![CDATA[
Type  Name               Notes

        <table>
	<name>Control Messages</name>
	<thead>
	<tr>
		<th>Type</th>
		<th>Name</th>
		<th>Notes and TLVs that can be carried
----  ----               ------------------------------------
   1  Hello              Hello carried</th>
	</tr>
	</thead>
	<tbody>
	<tr>
		<td>1</td>
		<td>Hello</td>
		<td>Hello TLV, Keepalive TLV.
   2  Keepalive          A TLV</td>
	</tr>
	<tr>
		<td>2</td>
		<td>Keepalive</td>
		<td>A common header with the Keepalive message
                             type.
   3  Sync_Request       Synchronization request.
   4  Sync_Begin         Synchronization starts.
   5  Sync_Data          Synchronization type</td>
	</tr>
	<tr>
		<td>3</td>
		<td>Sync_Request</td>
		<td>Synchronization request</td>
	</tr>
	<tr>
		<td>4</td>
		<td>Sync_Begin</td>
		<td>Synchronization starts</td>
	</tr>
	<tr>
		<td>5</td>
		<td>Sync_Data</td>
		<td>Synchronization data: TLVs specified in
                         Section 5.
   6  Sync_End           End synchronization.
   7  Update_Request     TLVs <xref target="sect-7" format="default"/></td>
	</tr>
	<tr>
		<td>6</td>
		<td>Sync_End</td>
		<td>End synchronization</td>
	</tr>
	<tr>
		<td>7</td>
		<td>Update_Request</td>
		<td>TLVs specified in Sections 7.6-7.9.
   8  Update_Response    TLVs <xref target="sect-7.6" format="counter"/>-<xref target="sect-7.9" format="counter"/></td>
	</tr>
	<tr>
		<td>8</td>
		<td>Update_Response</td>
		<td>TLVs specified in Sections 7.6-7.9.
]]></artwork>
	</figure>

	<section title="Hello Message" anchor="sect-6.2.1"><t> <xref target="sect-7.6" format="counter"/>-<xref target="sect-7.9" format="counter"/></td>
	</tr>
	</tbody>
</table>
        <section anchor="sect-6.2.1" numbered="true" toc="default">
          <name>Hello Message</name>
          <t>
   The Hello message is used for S-CUSP session establishment and version
   negotiation.  The detail details of S-CUSP session establishment and version
   negotiation can be found in <xref target="sect-4.1.1"/>.</t> target="sect-4.1.1" format="default"/>.</t>
          <t>
   The format of the Hello message is as follows:</t>

	<figure><artwork><![CDATA[
          <sourcecode type="rbnf"><![CDATA[
<Hello Message> ::= <Common Header>
                     <Hello TLV>
                     <Keepalive TLV>
                     [<Error Information TLV>]
]]></artwork>
	</figure>
]]></sourcecode>
          <t>
   The return code and negotiation result will be carried in the Error
   Information TLV.  They are listed as follows:</t>

	<t>
   0: Success, version
          <dl newline="false" spacing="normal" indent="3">
            <dt>0:</dt>
          <dd> Success. Version negotiation success.</t>

	<t>
   1: Failure, malformed success.
        </dd>
            <dt>1:</dt>
            <dd> Failure. Malformed message received.</t>

	<t>
   2: received.
         </dd>
            <dt>2:</dt>
            <dd> TLV-Unknown. One or more of the TLVs was not understood.</t>

	<t><list style="hanging" hangIndent="3"><t hangText="1001:"> understood.
         </dd>
            <dt>1001:</dt>
            <dd> Version-Mismatch. The
	version negotiation fails.  The S-CUSP session establishment phase
	fails.
	</t>

	<t hangText="1002:">
	</dd>
            <dt>1002:</dt>
            <dd> Keepalive Error. The keepalive negotiation fails.  The S-CUSP
	session establishment phase fails.
	</t>

	<t hangText="1003:">
	</dd>
            <dt>1003:</dt>
            <dd> Timer Expires. The establishment timer expires.  session expired.  Session
	establishment phase fails.
	</t>

	</list>
	</t>
	</dd>
          </dl>
        </section>
        <section title="Keepalive Message" anchor="sect-6.2.2"><t> anchor="sect-6.2.2" numbered="true" toc="default">
          <name>Keepalive Message</name>
          <t>
   Each end of an S-CUSP session periodically sends a Keepalive message.
   It is used to detect whether the peer end is still alive.  The
   Keepalive procedures are defined in <xref target="sect-4.1.2"/>.</t> target="sect-4.1.2" format="default"/>.</t>
          <t>
   The format of the Keepalive message is as follows:</t>

	<figure><artwork><![CDATA[
          <sourcecode type="rbnf"><![CDATA[
<Keepalive Message> ::= <Common Header>
]]></artwork>
	</figure>
]]></sourcecode>
        </section>
        <section title="Sync_Request Message" anchor="sect-6.2.3"><t> anchor="sect-6.2.3" numbered="true" toc="default">
          <name>Sync_Request Message</name>
          <t>
   The Sync_Request message is used to request synchronization from an
   S-CUSP peer.  Both CP and UP can request their peer to synchronize
   data.</t>
          <t>
   The format of the Sync_Request message is as follows:</t>

	<figure><artwork><![CDATA[
          <sourcecode type="rbnf"><![CDATA[
<Sync_Request Message> ::= <Common Header>
]]></artwork>
	</figure>
]]></sourcecode>
          <t>
   A Sync_Request message may result in a Sync_Begin message from its
   peer.  The Sync_Begin message is defined in <xref target="sect-6.2.4"/>.</t> target="sect-6.2.4" format="default"/>.</t>
        </section>
        <section title="Sync_Begin Message" anchor="sect-6.2.4"><t> anchor="sect-6.2.4" numbered="true" toc="default">
          <name>Sync_Begin Message</name>
          <t>
   The Sync_Begin message is a reply to a Sync_Request message.  It is
   used to notify the synchronization requester whether the
   synchronization can be started.</t>
          <t>
   The format of the Sync_Begin message is as follows:</t>

	<figure><artwork><![CDATA[
          <sourcecode type="rbnf"><![CDATA[
<Sync_Begin Message> ::= <Common Header>
                        <Error Information TLV>
]]></artwork>
	</figure>
]]></sourcecode>
          <t>
   The return codes are carried in the Error Information TLV.  The codes
   are listed below:</t>

	<t>
   0: Success, be
          <dl newline="false" spacing="normal" indent="3">
          <dt>
   0:</dt><dd> Success. Be ready to synchronize.</t>

	<t>
   1: Failure, malformed synchronize.</dd>
          <dt>
   1:</dt><dd> Failure. Malformed message received.</t>

	<t>
   2: received.</dd>
          <dt>
   2:</dt><dd> TLV-Unknown. One or more of the TLVs was not understood.</t>

	<t>
   2001: understood.</dd>
          <dt>
   2001:</dt><dd> Synch-NoReady.  The data to be synchronized is not ready.</t>

	<t>
   2002: ready.</dd>
          <dt>
   2002:</dt><dd> Synch-Unsupport.  The data synchronization is not supported.</t> supported.</dd>
         </dl>
        </section>
        <section title="Sync_Data Message" anchor="sect-6.2.5"><t> anchor="sect-6.2.5" numbered="true" toc="default">
          <name>Sync_Data Message</name>
          <t>
   The Sync_Data message is used to send data being synchronized between
   the CP and UP.  The Sync_Data message has the same function and
   format as the Update_Request message.  The difference is that there
   is no ACK for a Sync_Data message.  An error caused by the Sync_Data
   message will result in a Sync_End message.</t>
          <t>
   There are two scenarios:

	<list>

          </t>
          <ul spacing="normal">
            <li>
              <t>Synchronization from UP to CP: Synchronize the resource data to CP.

	<figure><artwork><![CDATA[

              </t>
              <sourcecode type="rbnf"><![CDATA[
      <Sync_Data Message> ::= <Common Header>
                              [<Resource Reporting TLVs>]
]]></artwork>
	</figure> </t>
                              [<Interface Status TLV>]
                              [<Board Status TLV>]
]]></sourcecode>
            </li>
            <li>
              <t>Synchronization from CP to UP: Synchronize all subscriber
   sessions to the UP.  The Subscriber TLVs carried are those appearing in
   <xref target="sect-7.9" format="default"/>. As for which TLVs should be carried, it depends on the
   specific session data to be synchronized.  The process is equivalent to the
   creation of a particular session.  Refer to <xref target="sect-5"/> target="sect-5" format="default"/> to see
   more details.

	<figure><artwork><![CDATA[

              </t>
<sourcecode type="rbnf"><![CDATA[
      <Sync_Data Message> ::= <Common Header>
                           [<User
                           [<IPv4 Routing TLVs>]
                           [<User Information TLVs>]
                           [<L2TP Subscriber TLVs>]
                           [<Subscriber CGN Port Range TLV>]
                           [<Subscriber Policy
                           [<IPv6 Routing TLV>]
]]></artwork>
	</figure></t>

      </list>
	</t>
                           [<Subscriber TLVs>]
]]></sourcecode>
            </li>
          </ul>
        </section>
        <section title="Sync_End Message" anchor="sect-6.2.6"><t> anchor="sect-6.2.6" numbered="true" toc="default">
          <name>Sync_End Message</name>
          <t>
   The Sync_End message is used to indicate the end of a synchronization
   process.  The format of a Sync_End message is as follows:</t>

	<figure><artwork><![CDATA[
<sourcecode type="rbnf"><![CDATA[
<Sync_End Message> ::= <Common Header>
                        <Error Information TLV>
]]></artwork>
	</figure>
]]></sourcecode>
          <t>The return/error codes are listed as follows:

<list>
<t>0: Success, synchronization finished.</t>

<t>1: Failure, malformed

</t>
          <dl newline="false" spacing="normal" indent="3">
            <dt>0:</dt><dd> Success. Synchronization finished.</dd>
            <dt>1:</dt><dd> Failure. Malformed message received.</t>

<t>2: received.</dd>
            <dt>2:</dt><dd> TLV-Unknown. One or more of the TLVs was not understood.</t>
</list>
</t> understood.</dd>
          </dl>
        </section>
        <section title="Update_Request Message" anchor="sect-6.2.7"><t> anchor="sect-6.2.7" numbered="true" toc="default">
          <name>Update_Request Message</name>
          <t>
   The Update_Request message is a multi-purpose message, multipurpose message; it can be used
   to create, update, and delete subscriber sessions on a UP.</t>
          <t>
   For session operations, the specific operation is controlled by the
   "Oper"
   Oper field of the carried TLVs.  As defined in <xref target="sect-7.1"/>, target="sect-7.1" format="default"/>, the
   "Oper"
   Oper field can be set to either "Update" Update or "Delete" Delete when a TLV is
   carried in an Update_Request message.</t>
          <t>
   When the "Oper" Oper field is set to Update, it means to create or update a
   subscriber session. If the "Oper" Oper field is set to Delete, it is a request to
   delete a corresponding session.</t>
          <t>
   The format of the Update_Request message is as follows:</t>

	<figure><artwork><![CDATA[
              <sourcecode type="rbnf"><![CDATA[
<Update_Request Message> ::= <Common Header>
                        [<User
                        [<IPv4 Routing TLVs>]
                        [<User Information TLVs>]
                        [<L2TP Subscriber TLVs>]
                        [<Subscriber CGN Port Range TLV>]
                        [<Subscriber Policy
                        [<IPv6 Routing TLV>]
]]></artwork>
	</figure>
                        [<Subscriber TLVs>]
]]></sourcecode>
          <t>
   Where the Subscriber TLVs are those appearing in
   <xref target="sect-7.9" format="default"/>.
   Each Update_Request message will result in an Update_Response message
   that message,
   which is defined in <xref target="sect-6.2.8"/>.</t> target="sect-6.2.8" format="default"/>.</t>
        </section>
        <section title="Update_Response Message" anchor="sect-6.2.8"><t> anchor="sect-6.2.8" numbered="true" toc="default">
          <name>Update_Response Message</name>
          <t>
   The Update_Response message is a response to an Update_Request
   message.  It is used to confirm the update request (or reject it in
   the case of an error).  The format of an Update_Response message is
   as follows:</t>

	<figure><artwork><![CDATA[
              <sourcecode type="rbnf"><![CDATA[
<Update_Response Message> ::= <Common Header>
                        [<Subscriber CGN Port Range TLV>]
                        <Error Information TLV>
]]></artwork>
	</figure>
]]></sourcecode>
          <t>
   The return/error codes are carried in the Error Information TLV.
   They are listed as follows:</t>

	<t><list style="hanging" hangIndent="3">

   	<t hangText="0:"> Success.</t>

	<t hangText="1:"> Failure, malformed message received.</t>

	<t hangText="2:">
          <dl newline="false" spacing="normal" indent="3">
            <dt>0:</dt>
            <dd> Success.</dd>
            <dt>1:</dt>
            <dd> Failure. Malformed message received.</dd>
            <dt>2:</dt>
            <dd> TLV-Unknown. One or more of the TLVs was not understood.</t>

        <t hangText="3001(Pool-Mismatch):"> understood.</dd>
            <dt>3001:</dt>
            <dd> Pool-Mismatch. The corresponding address pool
        cannot be found.</t>

	<t hangText="3002 (Pool-Full):"> found.</dd>
            <dt>3002:</dt>
            <dd> Pool-Full. The address pool is fully allocated allocated,
	and no address segment is available.</t>

	<t hangText="3003 (Subnet-Mismatch):"> available.</dd>
            <dt>3003:</dt>
            <dd> Subnet-Mismatch. The address pool subnet cannot
	be found.</t>

	<t hangText="3004 (Subnet-Conflict):"> found.</dd>
            <dt>3004:</dt>
            <dd> Subnet-Conflict. Subnets in the address pool
	have been classified into other clients.</t>

	<t hangText="4001 (Update-Fail-No-Res):"> clients.</dd>
            <dt>4001:</dt>
            <dd> Update-Fail-No-Res. The forwarding table fails
	to be delivered because the forwarding resources are insufficient.</t>

	<t hangText="4002 (QoS-Update-Success):"> insufficient.</dd>
            <dt>4002:</dt>
            <dd> QoS-Update-Success. The QoS policy takes effect.</t>

	<t hangText="4003 (QoS-Update-Sq-Fail):"> effect.</dd>
            <dt>4003:</dt>
            <dd> QoS-Update-Sq-Fail. Failed to process the queue
	in the QoS policy.</t>

	<t hangText="4004 (QoS-Update-CAR-Fail):"> policy.</dd>
            <dt>4004:</dt>
            <dd> QoS-Update-CAR-Fail. Processing of the CAR in
	the QoS policy fails.</t>

	<t hangText="4005 (Statistic-Fail-No-Res):"> fails.</dd>
            <dt>4005:</dt>
            <dd> Statistic-Fail-No-Res. Statistics processing
	failed due to insufficient statistics resources.</t>

	</list>
	</t> resources.</dd>
          </dl>
        </section>
      </section>
      <section title="Event Message" anchor="sect-6.3"><t> anchor="sect-6.3" numbered="true" toc="default">
        <name>Event Message</name>
        <t>
   The Event message is used to report subscriber session traffic
   statistics and detection information.  The format of the Event message is
   as follows:</t>

	<figure><artwork><![CDATA[
              <sourcecode type="rbnf"><![CDATA[
<Event Message> ::= <Common Header>
                        [<User
                        [<Subscriber Traffic Statistics Report TLV>]
                        [<User
                        [<Subscriber Detection Result Report TLV>]
]]></artwork>
	</figure>
]]></sourcecode>
      </section>
      <section title="Report Message" anchor="sect-6.4"><t> anchor="sect-6.4" numbered="true" toc="default">
        <name>Report Message</name>
        <t>
   The Report message is used to report board and interface status on a
   UP.  The format of the Report message is as follows:</t>

	<figure><artwork><![CDATA[
              <sourcecode type="rbnf"><![CDATA[
<Report Message> ::= <Common Header>
                        [<Board Status TLVs>]
                        [<Interface Status TLVs>]
]]></artwork>
	</figure>
]]></sourcecode>
      </section>
      <section title="CGN Messages" anchor="sect-6.5"><t> anchor="sect-6.5" numbered="true" toc="default">
        <name>CGN Messages</name>
        <t>
   This document defines the following resource allocation messages:</t>

	<figure><artwork><![CDATA[
Type   Message Name         TLV
<table>
  <name>Resource Allocation Messages</name>
  <thead>
    <tr>
      <th>Type</th><th>Message Name</th><th>TLV that is carried
----  -------------------  ------------------------
 200  Addr_Allocation_Req  Address carried</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>200</td><td>Addr_Allocation_Req</td><td>Address Allocation Request
 201  Addr_Allocation_Ack  Address Request</td>
    </tr>
    <tr>
      <td>201</td><td>Addr_Allocation_Ack</td><td>Address Allocation Response
 202  Addr_Renew_Req       Address Response</td>
    </tr>
    <tr>
      <td>202</td><td>Addr_Renew_Req</td><td>Address Renewal Request
 203  Addr_Renew_Ack       Address Request</td>
    </tr>
    <tr>
      <td>203</td><td>Addr_Renew_Ack</td><td>Address Renewal Response
 204  Addr_Release_Req     Address Response</td>
    </tr>
    <tr>
      <td>204</td><td>Addr_Release_Req</td><td>Address Release Request
 205  Addr_Release_Ack     Address Request</td>
    </tr>
    <tr>
      <td>205</td><td>Addr_Release_Ack</td><td>Address Release Response
]]></artwork>
	</figure>
	<section title="Addr_Allocation_Req Message" anchor="sect-6.5.1"><t> Response</td>
    </tr>
  </tbody>
</table>
        <section anchor="sect-6.5.1" numbered="true" toc="default">
          <name>Addr_Allocation_Req Message</name>
          <t>
   The Addr_Allocation_Req message is used to request CGN address
   allocation.  The format of the Addr_Allocation_Req message is as follows:</t>

	<figure><artwork><![CDATA[
              <sourcecode type="rbnf"><![CDATA[
<Addr_Allocation_Req Message> ::= <Common Header>
                        <Address Allocation Request TLV>
]]></artwork>
	</figure>
]]></sourcecode>
        </section>
        <section title="Addr_Allocation_Ack Message" anchor="sect-6.5.2"><t> anchor="sect-6.5.2" numbered="true" toc="default">
          <name>Addr_Allocation_Ack Message</name>
          <t>
   The Addr_Allocation_Ack message is a response to an
   Addr_Allocation_Req message.  The format of the Addr_Allocation_Ack
   message is as follows:</t>

	<figure><artwork><![CDATA[
              <sourcecode type="rbnf"><![CDATA[
<Addr_Allocation_Ack Message> ::= <Common Header>
                        <Address Allocation Response TLV>
]]></artwork>
	</figure>
]]></sourcecode>
        </section>
        <section title="Addr_Renew_Req Message" anchor="sect-6.5.3"><t> anchor="sect-6.5.3" numbered="true" toc="default">
          <name>Addr_Renew_Req Message</name>
          <t>
   The Addr_Renew_Req message is used to request address renewal.  The
   format of the Addr_Renew_Req message is as follows:</t>

	<figure><artwork><![CDATA[
              <sourcecode type="rbnf"><![CDATA[
<Addr_Renew_Req Message> ::= <Common Header>
                        <Address Renewal Request TLV>
]]></artwork>
	</figure>
]]></sourcecode>
        </section>
        <section title="Addr_Renew_Ack Message" anchor="sect-6.5.4"><t> anchor="sect-6.5.4" numbered="true" toc="default">
          <name>Addr_Renew_Ack Message</name>
          <t>
   The Addr_Renew_Ack message is a response to an Addr_Renew_Req
   message.  The format of the Addr_Renew_Req message is as follows:</t>

	<figure><artwork><![CDATA[
              <sourcecode type="rbnf"><![CDATA[
<Addr_Renew_Ack Message> ::= <Common Header>
                        <Address Renewal Response TLV>
]]></artwork>
	</figure>
]]></sourcecode>
        </section>
        <section title="Addr_Release_Req Message" anchor="sect-6.5.5"><t> anchor="sect-6.5.5" numbered="true" toc="default">
          <name>Addr_Release_Req Message</name>
          <t>
   The Addr_Release_Req message is used to request address release.  The
   format of the Addr_Release_Req message is as follows:</t>

	<figure><artwork><![CDATA[
              <sourcecode type="rbnf"><![CDATA[
<Addr_Release_Req Message> ::= <Common Header>
                        <Address Release Request TLV>
]]></artwork>
	</figure>
]]></sourcecode>
        </section>
        <section title="Addr_Release_Ack Message" anchor="sect-6.5.6"><t> anchor="sect-6.5.6" numbered="true" toc="default">
          <name>Addr_Release_Ack Message</name>
          <t>
   The Addr_Release_Ack message is a response to an Addr_Release_Req
   message.  The format of the Addr_Release_Ack message is as follows:</t>

	<figure><artwork><![CDATA[
              <sourcecode type="rbnf"><![CDATA[
<Addr_Release_Ack Message> ::= <Common Header>
                        <Address Release Response TLV>
]]></artwork>
	</figure>
]]></sourcecode>
        </section>
      </section>
      <section title="Vendor Message" anchor="sect-6.6"><t> anchor="sect-6.6" numbered="true" toc="default">
        <name>Vendor Message</name>
        <t>
   The Vendor message, in conjunction with the vendor Vendor TLV and vendor Vendor
   sub-TLV, can be used by vendors to extend the S-CUSP protocol. S-CUSP. The
   message type
   Message-Type is 11. If the receiver does not recognize the message,
   an Error message will be returned to the sender.</t>
        <t>
   The format of the Vendor message is as follows:</t>

	<figure><artwork><![CDATA[
              <sourcecode type="rbnf"><![CDATA[
<Vendor Message> ::= <Common Header>
                     <Vendor TLV>
                     [<any other TLVs as specified by the vendor>]
]]></artwork>
	</figure>
]]></sourcecode>
      </section>
      <section title="Error Message" anchor="sect-6.7"><t> anchor="sect-6.7" numbered="true" toc="default">
        <name>Error Message</name>
        <t>
   The Error message is defined to return some critical error
   information to the sender.  If a receiver does not support the type
   of the received message, it MUST <bcp14>MUST</bcp14> return an Error message to the
   sender.</t>
        <t>
   The format of the Error message is as below:</t>

	<figure><artwork><![CDATA[
              <sourcecode type="rbnf"><![CDATA[
<Error Message> ::= <Common Header>
                    <Error Information TLV>
]]></artwork>
	</figure>
]]></sourcecode>
      </section>
    </section>

    <section title="S-CUSP anchor="sect-7" numbered="true" toc="default">
      <name>S-CUSP TLVs and Sub-TLVs" anchor="sect-7"><t> Sub-TLVs</name>
      <t>
   This section specifies the following:</t>

	<t><list style="symbols"><t>the
      <ul spacing="normal">
        <li>The format of the TLVs that appear in S-CUSP messages,</t>

	<t>the messages,</li>
        <li>The format of the sub-TLVs that appear within the values of some
     TLVs, and</t>

	<t>the and</li>
        <li>The format of some basic data fields that appear within TLVs or
     sub-TLVs.</t>

	</list>
	</t>
     sub-TLVs.</li>
      </ul>
      <t>
   See <xref target="sect-9"/> target="sect-9" format="default"/> for a list of all defined TLVs and sub-TLVs.</t>
      <section title="Common anchor="sect-7.1" numbered="true" toc="default">
        <name>Common TLV Header" anchor="sect-7.1"><t> Header</name>
        <t>
   S-CUSP messages consist of the common header specified in <xref target="sect-6.1"/> target="sect-6.1" format="default"/>
   followed by TLVs formatted as specified in this section.</t>
        <figure title="Common anchor="fig32">
          <name>Common TLV Header" anchor="fig32"><artwork><![CDATA[ Header</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
    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                             ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
        </figure>
	<t><list style="hanging" hangIndent="3">

        <t hangText="Oper
        <dl newline="false" spacing="normal" indent="3">
          <dt>Oper (4 bits):"> bits):</dt>
          <dd> For Message-Types that specify an
        operation on a data set, the Oper field is interpreted as Update,
        Delete, or Reserved as specified in <xref target="sect-9.3"/>. target="sect-9.3" format="default"/>. For all
        other Message-Types, the Oper field MUST <bcp14>MUST</bcp14> be sent as zero and ignored
        on receipt.</t>

	<t hangText="TLV-Type receipt.</dd>
          <dt>TLV-Type (12 bits):"> bits):</dt>
          <dd> The Type type of a TLV. TLV-Type
	specifies the interpretation and format of the Value field of the TLV.
	See <xref target="sect-9.2"/>.</t>

	<t hangText="TLV-Length target="sect-9.2" format="default"/>.</dd>
          <dt>TLV-Length (2 bytes):"> bytes):</dt>
          <dd> The length of the Value portion
	of the TLV in bytes as an unsigned integer.
	</t>

	<t hangText="Value
	</dd>
          <dt>Value (variable length):"> length):</dt>
          <dd> This is the value portion of
	the TLV whose size is given by TLV-Length. The value portion It consists
	of fields, frequently using one of the basic data field types (see
	<xref target="sect-7.2"/>) target="sect-7.2" format="default"/>) and sub-TLVs (see <xref
	target="sect-7.3"/>).
	</t>

	</list>
	</t> target="sect-7.3" format="default"/>).
	</dd>
        </dl>
      </section>
      <section title="Basic anchor="sect-7.2" numbered="true" toc="default">
        <name>Basic Data Fields" anchor="sect-7.2"><t> Fields</name>
        <t>
   This section specifies the binary format of several standard basic
   data fields that are used within other data structures in this
   specification.</t>

	<t><list style="hanging" hangIndent="3">

        <t hangText="STRING:">
        <dl newline="false" spacing="normal" indent="3">
          <dt>STRING:</dt>
          <dd> 0 to 255 octets. Will be encoded as a sub-TLV
        (see Section 7.3) <xref target="sect-7.3" format="default"/>) to provide the length. The use of this data type in
        S-CUSP is to provide convenient labels for use by network operators in
        configuring and debugging their networks and interpreting S-CUSP
        messages.  Subscribers will not normally see these labels. They are
        normally interpreted as ASCII [RFC20]. </t>

	<t hangText="MAC-Addr:"> <xref target="RFC0020" format="default"/>. </dd>
          <dt>MAC-Addr:</dt>
          <dd> 6 octets. Ethernet MAC Address address <xref target="RFC7042"/>.</t>

	<t hangText="IPv4-Address:"> target="RFC7042" format="default"/>.</dd>
          <dt>IPv4-Address:</dt>
          <dd> 8 octets. 4 octets of the IPv4 address
	value followed by a 4 octet 4-octet address mask in the format
	XXX.XXX.XXX.XXX.</t>

	<t hangText="IPv6-Address:">
	XXX.XXX.XXX.XXX.</dd>
          <dt>IPv6-Address:</dt>
          <dd> 20 octets. 16 octets of the IPv6 address
	followed by a 4 octet 4-octet integer n in the range of 0 to 128 128, which gives
	the address mask as the one's complement of 2**(128-n) - 1.
	</t>

	<t hangText="VLAN ID:"> 2
	</dd>
          <dt>VLAN ID:</dt>
          <dd> <t>2 octets. As follows [802.1Q]:</t>

	</list>
	</t>

	<figure><artwork><![CDATA[ <xref target="IEEE-802.1Q" format="default"/>:</t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
       0                   1
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | PRI |D|      VLAN-ID          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
	</figure>

	<t><list style="hanging" hangIndent="3">

      <t hangText="PRI:">
        <dl newline="false" spacing="normal" indent="3">
          <dt>PRI:</dt>
          <dd> Priority. Default value 7.</t>

      <t hangText="D:"> 7.</dd>
          <dt>D:</dt>
          <dd> Drop Eligibility Indicator (DEI). Default value 0.</t>

      <t hangText="VLAN-ID:"> 0.</dd>
          <dt>VLAN-ID:</dt>
          <dd> Unsigned integer in the range 1-4094. (0 and
      4095 are not valid VLAN IDs <xref target="IEEE-802.1Q"/>.)</t>

	</list>
	</t> target="IEEE-802.1Q" format="default"/>.)</dd>
        </dl></dd>
        </dl>
      </section>
      <section title="Sub-TLV anchor="sect-7.3" numbered="true" toc="default">
        <name>Sub-TLV Format and Sub-TLVs" anchor="sect-7.3"><t> Sub-TLVs</name>
        <t>
   In some cases, the Value portion of a TLV, as specified above, in <xref target="sect-7.1" format="default"/>, can
   contain one or more Sub-TLVs sub-TLVs formatted as follows:</t>
        <figure title="Sub-TLV Header" anchor="fig33"><artwork><![CDATA[ anchor="fig33">
          <name>Sub-TLV Header</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
    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                                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
]]></artwork>
        </figure>

       <t><list style="hanging" hangIndent="3">

        <t hangText="Type
        <dl newline="false" spacing="normal" indent="3">
          <dt>Type (2 bytes):"> bytes):</dt>
          <dd> The Type type of a Sub-TLV. sub-TLV. The Type field
        specified
        specifies the interpretation and format of the Value field of the TLV.
        Sub-TLV Type type values have the same meaning regardless of the TLV Type type of
        the TLV within which the sub-TLV occurs. See <xref target="sect-9.4"/>.</t>

        <t hangText="Length target="sect-9.4" format="default"/>.</dd>
          <dt>Length (2 bytes):"> bytes):</dt>
          <dd> The length of the Value portion of
        the sub-TLV in bytes as an unsigned integer.</t>

	<t hangText="Value integer.</dd>
          <dt>Value (variable length):"> length):</dt>
          <dd> This is the value Value portion of
	the sub-TLV whose size is given by Length.</t>

	</list>
	</t> Length.</dd>
        </dl>
        <t>
   The sub-TLVs currently specified are defined in the following
   subsections.</t>
        <section title="Name sub-TLVs" anchor="sect-7.3.1"><t> anchor="sect-7.3.1" numbered="true" toc="default">
          <name>Name Sub-TLVs</name>
          <t>
   This document defines the following name sub-TLVs that are used to
   carry the name of the corresponding object.  The length of each of
   these sub-TLVs is variable from 1 to 255 octets. The value is of
   type STRING padded with zeros zero octets to 4-octet alignment.</t>

	<figure><artwork><![CDATA[
 Type   Sub-TLV Name            Meaning
-----   --------------------    -------------------
   1    VRF-Name                The a length in octets that is
   an integer multiple of 4.</t>
<table>
  <name>Name Sub-TLVs</name>
  <thead>
    <tr>
      <th>Type</th><th>Sub-TLV Name</th><th>Meaning</th>
    </tr>
  </thead>
  <tbody>
    <tr>
       <td>1</td><td>VRF-Name</td><td>The name of a VRF
   2    Ingress-QoS-Profile     The VRF</td>
    </tr>
    <tr>
       <td>2</td><td>Ingress-QoS-Profile</td><td>The name of an ingress QoS profile
   3    Egress-QoS-Profile      The profile</td>
    </tr>
    <tr>
       <td>3</td><td>Egress-QoS-Profile</td><td>The name of an egress QoS profile
   4    User-ACL-Policy         The profile</td>
    </tr>
    <tr>
       <td>4</td><td>User-ACL-Policy</td><td>The name of an ACL policy
   5    Multicast-ProfileV4     The policy</td>
    </tr>
    <tr>
       <td>5</td><td>Multicast-ProfileV4</td><td>The name of an IPv4 multicast profile
   6    Multicast-ProfileV6     The profile</td>
    </tr>
    <tr>
       <td>6</td><td>Multicast-ProfileV6</td><td>The name of an IPv6 multicast profile
   7    NAT-Instance            The profile</td>
    </tr>
    <tr>
       <td>9</td><td>NAT-Instance</td><td>The name of a NAT instance
   8    Pool-Name               The instance</td>
    </tr>
    <tr>
       <td>10</td><td>Pool-Name</td><td>The name of an address pool
]]></artwork>
	</figure> pool</td>
    </tr>
  </tbody>
</table>
        </section>

        <section title="Ingress-CAR sub-TLV" anchor="sect-7.3.2"><t> anchor="sect-7.3.2" numbered="true" toc="default">
          <name>Ingress-CAR Sub-TLV</name>
          <t>
   The Ingress-CAR sub-TLV indicates the authorized upstream Committed
   Access Rate (CAR) parameters. The sub-TLV type of the Ingress-CAR
   sub-TLV is 9. 7. The sub-TLV length is 16. The format is as shown in
   Figure 34.</t>
   <xref target="fig34" format="default"/>.</t>
          <figure title="Ingress-CAR sub-TLV" anchor="fig34"><artwork><![CDATA[ anchor="fig34">
            <name>Ingress-CAR Sub-TLV</name>
            <artwork name="" type="" align="left" alt=""><![CDATA[
    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 (Committed Information Rate)             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  PIR (Peak Information Rate)                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  CBS (Committed Burst Size)                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  PBS (Peak Burst Size)                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
          </figure>

          <t> Where:

   <list>
   <t> CIR
          </t>

<ul empty="true"><li>
          <dl newline="false" spacing="normal">
            <dt>CIR (4 bytes): Guaranteed bytes):</dt><dd>Guaranteed rate in bits/second.</t>

   <t> PIR bits/second.</dd>
            <dt>PIR (4 bytes): Burst bytes):</dt><dd>Burst rate in bits/second.</t>

   <t> CBS bits/second.</dd>
            <dt>CBS (4 bytes): The bytes):</dt><dd>The token bucket in bytes.</t>

   <t> PBS bytes.</dd>
            <dt>PBS (4 bytes): Burst bytes):</dt><dd>Burst token bucket in bytes.</t>

	</list>
	</t> bytes.</dd>
          </dl>
</li></ul>
          <t>
   These fields are unsigned integers. More details about CIR, PIR, CBS,
   and PBS can be found in <xref target="RFC2698"/>.</t> target="RFC2698" format="default"/>.</t>
        </section>
        <section title="Egress-CAR sub-TLV" anchor="sect-7.3.3"><t> anchor="sect-7.3.3" numbered="true" toc="default">
          <name>Egress-CAR Sub-TLV</name>
          <t>
   The Egress-CAR sub-TLV indicates the authorized downstream Committed Access
   Rate (CAR) parameters. The sub-TLV type of the Egress-CAR sub-TLV is
   10.
   8. Its sub-TLV length is 16 octets. The format of the value part is as
   defined below.</t>
          <figure title="Egress-CAR sub-TLV" anchor="fig35"><artwork><![CDATA[ anchor="fig35">
            <name>Egress-CAR Sub-TLV</name>
            <artwork name="" type="" align="left" alt=""><![CDATA[
    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 (Committed Information Rate)             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  PIR (Peak Information Rate)                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  CBS (Committed Burst Size)                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  PBS (Peak Burst Size)                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
          </figure>
          <t>Where:

      <list>
	<t>CIR
          </t>

<ul empty="true"><li>
          <dl newline="false" spacing="normal">
            <dt>CIR (4 bytes): Guaranteed bytes):</dt><dd>Guaranteed rate in bits/second.</t>

	<t>PIR bits/second.</dd>
            <dt>PIR (4 bytes): Burst bytes):</dt><dd>Burst rate in bits/second.</t>

	<t>CBS bits/second.</dd>
            <dt>CBS (4 bytes): The bytes):</dt><dd>The token bucket in bytes.</t>

	<t>PBS bytes.</dd>
            <dt>PBS (4 bytes): Burst bytes):</dt><dd>Burst token bucket in bytes.</t>

      </list>
      </t> bytes.</dd>
          </dl>

</li></ul>

          <t>
   These fields are unsigned integers. More details about CIR, PIR, CBS,
   and PBS can be found in <xref target="RFC2698"/>.</t> target="RFC2698" format="default"/>.</t>
        </section>
        <section title="If-Desc sub-TLV" anchor="sect-7.3.4"><t> anchor="sect-7.3.4" numbered="true" toc="default">
          <name>If-Desc Sub-TLV</name>
          <t>
   The If-Desc sub-TLV is defined to designate an interface.  It is an
   optional sub-TLV that may be carried in those TLVs that have an "if-index" If-Index
   or "out-if-index" Out-If-Index field. The If-Desc sub-TLV is used as a locally unique
   identifier within a BNG.</t>
          <t>
   The sub-TLV type is 11.  The sub-TLV length is 12 octets.  The format
   depends on the If-Type. If-Type (<xref target="sect-9.6" format="default"/>).
   The format of the value part is as follows:</t>
          <figure title="If-Desc sub-TLV Formats" anchor="fig36"><artwork><![CDATA[ anchor="fig36">
            <name>If-Desc Sub-TLV Formats</name>
            <artwork name="" type="" align="left" alt=""><![CDATA[
 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 (1-5)|    Chassis    |             Slot              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           Sub-Slot            |            Port Number        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         Sub-Port Number                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                 If-Desc sub-TLV Sub-TLV (Physical Port)

 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 (6-7) |                Reserved                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                            Logic-ID                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         Sub-Port Number                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                  If-Desc sub-TLV Sub-TLV (Virtual Port)
]]></artwork>
          </figure>

          <t>Where:

     <list>

      <t>If-Type: 8
          </t>

<ul empty="true"><li>
          <dl newline="false" spacing="normal">
            <dt>If-Type:</dt><dd>8 bits in length. The value of this field indicates the
      type of an interface.  The If-Type values defined in this document
      are listed in <xref target="sect-9.6"/>.</t>

      <t>Chassis target="sect-9.6" format="default"/>.</dd>
            <dt>Chassis (8 bits): Identifies bits):</dt><dd>Identifies the chassis that the interface
      belongs to.</t>

      <t>Slot to.</dd>
            <dt>Slot (16 bits): Identifies bits):</dt><dd>Identifies the slot that the interface belongs to.</t>

      <t>Sub-slot to.</dd>
            <dt>Sub-Slot (16 bits): Identifies bits):</dt><dd>Identifies the sub-slot the interface belongs to.</t>

      <t>Port to.</dd>
            <dt>Port Number (16 bits): An bits):</dt><dd>An identifier of a physical port/interface
      (e.g., If-Type: 1-5). It is locally significant within the
      slot/sub-slot.</t>

      <t>Sub-port
      slot/sub-slot.</dd>
            <dt>Sub-Port Number (32 bits): An bits):</dt><dd>An identifier of the sub-port. Locally
      significant within its "parent" port (physical or virtual).</t>

      <t>Logic-ID virtual).</dd>
            <dt>Logic-ID (32 bits): An bits):</dt><dd>An identifier of a virtual interface (e.g.,
      If-Type: 6-7)</t>

	</list>
	</t> 6-7).</dd>

          </dl>
</li></ul>

        </section>
        <section title="IPv6 anchor="sect-7.3.5" numbered="true" toc="default">
          <name>IPv6 Address List sub-TLV" anchor="sect-7.3.5"><t> Sub-TLV</name>
          <t>
   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.</t>
          <t>The format of the value part of the IPv6 Addresses Address List sub-TLV is as follows:</t>
          <figure title="IPv6 anchor="fig37">
            <name>IPv6 Address List sub-TLV" anchor="fig37"><artwork><![CDATA[ Sub-TLV</name>
            <artwork name="" type="" align="left" alt=""><![CDATA[
    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                           ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
          </figure>
          <t>Where:

	<list>

	<t>IP
          </t>
<ul empty="true"><li>
          <dl newline="false" spacing="normal">

            <dt>IPv6 Address (IPv6-Address): Each (IPv6-Address):</dt><dd>Each IP Address is an of
            type IP-Address type, and carries an IPv6 address.</t>

	</list>
	</t> address and length.</dd>

          </dl>
</li></ul>

        </section>
        <section title="Vendor sub-TLV" anchor="sect-7.3.6"><t> anchor="sect-7.3.6" numbered="true" toc="default">
          <name>Vendor Sub-TLV</name>
          <t>
   The Vendor sub-TLV is intended to be used inside the value Value portion of
   the Vendor TLV (<xref target="sect-7.13"/>). target="sect-7.13" format="default"/>). It provides a Sub-Type that
   effectively extends the sub-TLV type in the sub-TLV header and
   provides for versioning of vendor Vendor sub-TLVs.</t>
          <t>The value part of the Vendor sub-TLV is formatted as follows:</t>
          <figure title="Vendor sub-TLV" anchor="fig38"><artwork><![CDATA[ anchor="fig38">
            <name>Vendor Sub-TLV</name>
            <artwork name="" type="" align="left" alt=""><![CDATA[
    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                           Vendor-ID                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Sub-Type            |       Sub-Type-Version        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~             value             Value (other as specified by vendor)              ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
          </figure>
          <t>Where:

	<list>
	<t>The sub-TLV type: 13.</t>

	<t>The sub-TLV length: variable.</t>

	<t>Vendor-ID
          </t>

<ul empty="true"><li>
          <dl newline="false" spacing="normal">

            <dt>Sub-TLV type:</dt><dd>13.</dd>
            <dt>Sub-TLV length:</dt><dd>Variable.</dd>
            <dt>Vendor-ID (4 bytes): Vendor bytes):</dt><dd>Vendor ID as defined in RADIUS <xref
	target="RFC2865"/>.</t>

	<t>Sub-Type target="RFC2865" format="default"/>.</dd>
            <dt>Sub-Type (2 bytes): Used bytes):</dt><dd>Used by the Vendor vendor to distinguish multiple
	different sub-TLVs.</t>

	<t>Sub-Type-Version sub-TLVs.</dd>
            <dt>Sub-Type-Version (2 bytes): Used bytes):</dt><dd>Used by the Vendor vendor to distinguish
	different versions of a Vendor-Defined vendor-defined sub-TLV sub-Type.</t>

	<t>value: as Sub-Type.</dd>
            <dt>Value:</dt><dd>As specified by the vendor.</t>

	</list>
	</t> vendor.</dd>
          </dl>
</li></ul>

          <t>
   Since Vendor vendor code will be handling the sub-TLV after the Vendor ID Vendor-ID
   field is recognized, the remainder of the sub-TLV can be organized
   however the vendor wants. But it desirable for a vendor to be able to
   define multiple different vendor Vendor sub-TLVs and to keep track of
   different versions of its vendor-defined sub-TLVs. Thus, it is
   RECOMMENDED
   <bcp14>RECOMMENDED</bcp14> that the vendor assign a Sub-Type value for each of that
   vendor's sub-TLVs that is different from other Sub-Type values that
   vendor has used. Also, when modifying a vendor-defined sub-TLV in a
   way potentially incompatible with a previous definition, the vendor
   SHOULD
   <bcp14>SHOULD</bcp14> increase the value it is using in the Sub-Type-Version field.</t>
        </section>
      </section>
      <section title="The Hello TLV" anchor="sect-7.4"><t> anchor="sect-7.4" numbered="true" toc="default">
        <name>Hello TLV</name>
        <t>
   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 the value part of the Hello TLV is as follows:</t>
        <figure title="Hello TLV" anchor="fig39"><artwork><![CDATA[ anchor="fig39">
          <name>Hello TLV</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
    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                           Vendor-ID                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Capabilities                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
        </figure>
        <t>Where:

	<list>
	<t>The TLV type is 100.</t>

	<t>The TLV length is 12 octets.</t>

        <t>The value field consists of three parts:

	<list style="format (%d)">

	<t>VerSupported: 32
        </t>

<ul empty="true"><li>
          <dl newline="false" spacing="normal">
          <dt>TLV type:</dt><dd>100.</dd>
          <dt>TLV length:</dt><dd>12 octets.</dd>
          <dt>VerSupported:</dt><dd>32 bits in length. It 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 <bcp14>MUST</bcp14> be non-zero. nonzero. The
              VerSupported bits are numbered from 0 as the most significant
              bit. Bit 0 indicates support of Sub-Version zero, bit 1
              indicates support of Sub-Version one, etc.</t>

	<t>Vendor-ID: 4 etc.</dd>
          <dt>Vendor-ID:</dt><dd>4 bytes in length. Vendor ID, as defined in RADIUS
              <xref target="RFC2865"/>.</t>

	<t>Capabilities: 32 target="RFC2865" format="default"/>.</dd>
          <dt>Capabilities:</dt><dd>32 bits in length. Flags that indicate the
              support of particular capabilities by the sender of the Hello.
              No Capabilities capabilities are defined in this document, so implementations
              of the version specified herein will set this field to zero. The
              Capabilities field of the Hello TLV MUST <bcp14>MUST</bcp14> be
              checked before any other TLVs in the Hello because capabilities
              defined in the future might extend existing TLVs or permit new TLVs.</t>
        </list>
	</t>
        </list>
	</t>
              TLVs.</dd>
          </dl>
</li></ul>

        <t>
   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 field for
   the CP and the UP.</t>
        <t>
   If the result of the AND of the Sub-Versions supported is zero, then
   no session can be established established, and the connection is torn down. If the
   result of the AND of the Sub-Versions supported is non-zero, nonzero, then the
   session uses the highest Sub-Version supported by both the CP and UP.</t>
        <t>
   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
   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.</t>
        <t>
   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 capabilities, so none can be used during the
   session. If this result is non-zero, nonzero, it shows the additional
   capabilities that can be used during the session. The CP and the UP
   MUST NOT
   <bcp14>MUST NOT</bcp14> use a capability unless both advertise support.</t>
      </section>
      <section title="The Keepalive TLV" anchor="sect-7.5"><t> anchor="sect-7.5" numbered="true" toc="default">
        <name>Keepalive TLV</name>
        <t>
   The Keepalive TLV is carried in the Hello message.  It provides
   timing information for this feature.  The format of Hello the value part of
   the Keepalive TLV is as follows:</t>
        <figure title="Keepalive TLV" anchor="fig40"><artwork><![CDATA[ anchor="fig40">
          <name>Keepalive TLV</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
    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           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
        </figure>
        <t>Where:

	<list>

	<t>The TLV type: 102.</t>

	<t>The value of the Length field is 4 octets.</t>

	<t>Keepalive
        </t>

<ul empty="true"><li>
          <dl newline="false" spacing="normal">

          <dt>TLV type:</dt><dd>102.</dd>
          <dt>TLV length:</dt><dd>4 octets.</dd>

<dt>Keepalive (8 bits): Indicates bits):</dt><dd>Indicates the maximum interval (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 field is 1 second. When set to 0, once the session is established,
no further Keepalive messages are sent to the remote peer. A RECOMMENDED
<bcp14>RECOMMENDED</bcp14> value for the Keepalive frequency is 30 seconds.</t>

	<t>DeadTimer
seconds.</dd>

<dt>DeadTimer (8 bits in length): Specifies length):</dt><dd>Specifies the amount
of time as an unsigned integer number of seconds seconds, after the expiration of which
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 SHOULD
<bcp14>SHOULD</bcp14> be set to 0 and MUST <bcp14>MUST</bcp14> be ignored if the
Keepalive is set to 0. A RECOMMENDED <bcp14>RECOMMENDED</bcp14> value for the DeadTimer is
4 times the value of the Keepalive.</t>

	<t>The Keepalive.</dd>

          <dt>Reserved:</dt><dd>The Reserved bits MUST <bcp14>MUST</bcp14> be sent as zero and
          ignored on receipt.</t>

	</list>
	</t> receipt.</dd>

          </dl>
</li></ul>

      </section>

      <section title="The Error anchor="sect-7.6" numbered="true" toc="default">
        <name>Error Information TLV" anchor="sect-7.6"><t> TLV</name>
        <t>
   The Error Information TLV is a common TLV that can be used in many
   Response
   responses (e.g., Update_Response message) and ACK messages (e.g.,
   Addr_Allocation_Ack message, etc.). message).  It is used to convey the
   information about an error in the received S-CUSP message.  The
   format of the value part of the Error Information TLV is as follows:</t>
        <figure title="Error anchor="fig41">
          <name>Error Information TLV" anchor="fig41"><artwork><![CDATA[ TLV</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
    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             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Error Code                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
        </figure>
        <t>Where:

        <list>
	<t>The TLV type: 101.</t>

	<t>The value of the Length field is 8 octets.</t>

	<t>Message-Type(1 byte): This
        </t>

<ul empty="true"><li>
          <dl newline="false" spacing="normal">

          <dt>TLV type:</dt><dd>101.</dd>
          <dt>TLV length:</dt><dd>8 octets.</dd>
          <dt>Message-Type (1 byte):</dt><dd>This parameter is the message type of the
	message containing an error.</t>

	<t>Reserved error.</dd>
          <dt>Reserved (1 byte): MUST byte):</dt><dd><bcp14>MUST</bcp14> be sent as zero and ignored on receipt.</t>

	<t>TLV-Type receipt.</dd>
          <dt>TLV-Type (2 bytes): Indicates bytes):</dt><dd>Indicates which TLV caused the error.</t>

	<t>Error Code: 4 error.</dd>
          <dt>Error Code:</dt><dd>4 bytes in length.  Indicate the specific Error Code
	(see <xref target="sect-9.5"/>).</t>

	</list>
	</t> target="sect-9.5" format="default"/>).</dd>

          </dl>
</li></ul>

      </section>
      <section title="BAS anchor="sect-7.7" numbered="true" toc="default">
        <name>BAS Function TLV" anchor="sect-7.7"><t> TLV</name>
        <t>
   The BAS Function TLV is used by a CP to control the access mode,
   authentication methods, and other related functions of an interface
   on a UP.</t>
        <t>The format of the BAS Function TLV value part is as follows:</t>
        <figure title="BAS anchor="fig42">
          <name>BAS Function TLV" anchor="fig42"><artwork><![CDATA[ TLV</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
    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                         Sub-TLVs (optional)                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
        </figure>

        <t>Where:

	<list>
	<t>The TLV type: 1.</t>

	<t>The value of the Length field is variable.</t>

	<t>If-Index: 4
        </t>

<ul empty="true"><li>
          <dl newline="false" spacing="normal">

          <dt>TLV type:</dt><dd>1.</dd>

          <dt>TLV length:</dt><dd>Variable.</dd>

          <dt>If-Index:</dt><dd>4 bytes in length, a unique identifier of an interface of
	a BNG.</t>

	<t>Access-Mode: 1 BNG.</dd>

          <dt>Access-Mode:</dt><dd>1 byte in length. It indicates the access mode of the
	interface.  The defined values are listed in <xref
	target="sect-9.7"/>.</t>

	<t>Auth-Method4: 1 target="sect-9.7"
	format="default"/>.</dd>

          <dt>Auth-Method4:</dt><dd>1 byte in length. It indicates the authentication on
	this interface for the IPv4 scenario. This field is defined as a
	bitmap.  The bits defined in this document are listed in <xref
	target="sect-9.8"/>. target="sect-9.8" format="default"/>. Other bits are reserved and MUST <bcp14>MUST</bcp14> be sent as zero
	and ignored on receipt.</t>

	<t>Auth-Method6: 1 receipt.</dd>

          <dt>Auth-Method6:</dt><dd>1 byte in length. It indicates the authentication on
	this interface for the IPv6 scenario. This field is defined as a
	bitmap.  The bits defined in this document are listed in <xref
	target="sect-9.8"/>. target="sect-9.8" format="default"/>. Other bits are reserved and MUST <bcp14>MUST</bcp14> be sent as zero
	and ignored on receipt.</t>

	<t>sub-TLVs:
	<list>
	<t>The receipt.</dd>

          <dt>Sub-TLVs:</dt><dd><t>The IF-Desc sub-TLV can be carried.</t>
        <t> If-Desc sub-TLV: carries

          <dl newline="false" spacing="normal">
          <dt>If-Desc sub-TLV:</dt><dd>Carries the interface information.</t>
        </list>
	</t>

	<t>The flags information.</dd>
          </dl>
        </dd>

          <dt>Flags:</dt><dd>The Flags field is defined as follows:</t>

	</list>
	</t> follows:</dd>

	</dl>
</li></ul>

        <figure title="Interface Flags" anchor="fig43"><artwork><![CDATA[ anchor="fig43">
          <name>Interface Flags</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
    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|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
        </figure>

        <t>Where:
        <list>
	<t>F
        </t>

<ul empty="true">
  <li>
    <dl newline="false" spacing="normal">

      <dt>F (IPv4 Trigger) bit: Indicates bit:</dt>
         <dd>
           <t>Indicates whether IPv4 packets can trigger a
	      subscriber to go online. 1: enabled, 0: disabled.</t>

	<t>S online.</t>
           <dl newline= "false" spacing="normal">
              <dt>1:</dt><dd>Enabled.</dd>
              <dt>0:</dt><dd>Disabled.</dd>
           </dl>
         </dd>

      <dt>S (IPv6 Trigger) bit: Indicates bit:</dt><dd><t>Indicates whether IPv6 packets can trigger a
	subscriber to go online. 1: enabled, 0: disabled.</t>

	<t>A online.</t>

          <dl newline= "false" spacing="normal">
            <dt>1:</dt><dd>Enabled.</dd>
            <dt>0:</dt><dd>Disabled.</dd>
          </dl>

        </dd>

     <dt>A (ARP Trigger) bit: Indicates bit:</dt><dd><t>Indicates whether ARP packets can trigger
	a subscriber to go online. 1: enabled, 0: disabled.</t>

	<t>N online.</t>

          <dl newline= "false" spacing="normal">
            <dt>1:</dt><dd>Enabled.</dd>
            <dt>0:</dt><dd>Disabled.</dd>
          </dl>

        </dd>

      <dt>N (ND Trigger) bit: Indicates bit:</dt><dd><t>Indicates whether ND packets can trigger a
	subscriber to go online. 1: enabled, 0: disabled.</t>

	<t>I (IPoE-Flow-Check): Used online.</t>

          <dl newline= "false" spacing="normal">
            <dt>1:</dt><dd>Enabled.</dd>
            <dt>0:</dt><dd>Disabled.</dd>
          </dl>

        </dd>

      <dt>I (IPoE-Flow-Check):</dt><dd><t>Used for UP detection. IPoE 1: Enable detection.</t>

          <dl newline= "false" spacing="normal">
            <dt>1:</dt><dd>Enable traffic
	detection. 0: Disable detection.</dd>
            <dt>0:</dt><dd>Disable traffic detection.</t>

	<t>P detection.</dd>
          </dl>

        </dd>

      <dt>P (PPP-Flow-Check) bit: Used bit:</dt><dd><t>Used for UP detection. PPP 1: Enable detection.</t>

          <dl newline= "false" spacing="normal">
            <dt>1:</dt><dd>Enable traffic detection. 0: Disable detection.</dd>
            <dt>0:</dt><dd>Disable traffic detection.</t>

	<t>X detection.</dd>
          </dl>

        </dd>
       <dt>X (ARP-Proxy) bit: 1: The bit:</dt><dd><t>Indicates whether ARP proxy is enabled on the interface.</t>
          <dl newline= "false" spacing="normal">
            <dt>1:</dt><dd>The interface is enabled with ARP proxy and can
            process ARP requests across different Port+VLANs. 0: The network ports and VLANs.</dd>
            <dt>0:</dt><dd>The ARP proxy is not enabled on the interface and
            only the ARP requests of the same
	Port+VLAN network port and VLAN are processed.</t>

	<t>Y processed.</dd>
          </dl>

        </dd>

       <dt>Y (ND-Proxy) bit: 1: The bit:</dt><dd><t>Indicates whether ND proxy is enabled on the interface.</t>
          <dl newline= "false" spacing="normal">
            <dt>1:</dt><dd>The interface is enabled with ND proxy and can
            process ND requests across different Port+VLANs. 0: The network ports and VLANs.</dd>
            <dt>0:</dt><dd>The ND proxy is not enabled on the interface and
            only the ND requests of the same
	Port+VLAN network port and VLAN are processed.</t>

	<t>MBZ: Reserved processed.</dd>
          </dl>

        </dd>

       <dt>MBZ:</dt><dd>Reserved bits that MUST <bcp14>MUST</bcp14> be sent as
          zero and ignored on receipt.
	</t>

	</list>
	</t> receipt.</dd>
          </dl>

  </li>
</ul>

      </section>
      <section title="Routing TLVs" anchor="sect-7.8"><t> anchor="sect-7.8" numbered="true" toc="default">
        <name>Routing TLVs</name>
        <t>
   Typically, after an S-CUSP session is established between a UP and a
   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 (as defined in <xref target="sect-2.1"/>) target="sect-4.3.1" format="default"/>) to the UP.  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.</t>
        <t>
   The Routing TLVs are used by a CP to notify a UP of the updates to
   network routing information.  They can be carried in the
   Update_Request message and Sync_Data message.</t>
        <section title="IPv4 anchor="sect-7.8.1" numbered="true" toc="default">
          <name>IPv4 Routing TLV" anchor="sect-7.8.1"><t> TLV</name>
          <t>
   The IPv4 Routing TLV is used to carry information related to IPv4
   network routing.</t>
          <t>The format of the TLV value part is as below:</t>
          <figure title="IPv4 anchor="fig44">
            <name>IPv4 Routing TLV" anchor="fig44"><artwork><![CDATA[ TLV</name>
            <artwork name="" type="" align="left" alt=""><![CDATA[
    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-ID                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Dest-Address                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Next-Hop                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Out-If-Index                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Cost                                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Tag                                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Route Type        Route-Type             |          Reserved           |A|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                          sub-TLVs                          Sub-TLVs  (optional)                 ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
          </figure>
          <t>Where:

        <list>
	<t>The TLV Type: 7</t>

	<t>The TLV Length: Variable</t>

	<t>User-ID: 4
          </t>

<ul empty="true"><li>
          <dl newline="false" spacing="normal">
            <dt>TLV type:</dt><dd>7.</dd>
            <dt>TLV length:</dt><dd>Variable.</dd>
            <dt>User-ID:</dt><dd>4 bytes in length.  This field carries the user
	identifier.  It is filled with all Fs when a non-user route is
	delivered to the UP.</t>

	<t>Dest-Address UP.</dd>
            <dt>Dest-Address (IPv4-Address type): Identifies type):</dt><dd>Identifies the destination
	address.</t>

	<t>Next-Hop:
	address.</dd>
            <dt>Next-Hop (IPv4-Address type): Identifies type):</dt><dd>Identifies the next hop address.</t>

	<t>Out-If-Index next-hop address.</dd>
            <dt>Out-If-Index (4 bytes): Indicates bytes):</dt><dd>Indicates the interface index.</t>

	<t>Cost index.</dd>
            <dt>Cost (4 bytes): The bytes):</dt><dd>The cost value of the route.</t>

	<t>Tag route.</dd>
            <dt>Tag (4 bytes): The bytes):</dt><dd>The tag value of the route.</t>

	<t>Route-Type route.</dd>
            <dt>Route-Type (2 bytes): The bytes):</dt><dd>The value of this field
            indicates the route type.  The values defined in this document are
            listed in <xref
	target="sect-9.9"/>.</t>

	<t>Advertise-Flag: 1 target="sect-9.9" format="default"/>.</dd>
            <dt>Advertise-Flag:</dt><dd><t>1 bit shown as &quot;A&quot; is "A" in the figure above. above
            (<xref target="fig44" format="default"/>).  Indicates whether the IP
            UP should advertise the route.  The following flag values are defined:

	<list>
	  <t>0: Not advertised,</t>
	  <t>1: Advertised.</t>
	</list>
	</t>

        <t>sub-TLVs: The
            defined:</t>

              <dl newline="false" spacing="normal">
                <dt>0:</dt><dd>Not advertised.</dd>
                <dt>1:</dt><dd>Advertised.</dd>
              </dl>
            </dd>

              <dt>Sub-TLVs:</dt><dd><t>The VRF-Name and/or If-Desc sub-TLVs
              can be carried.

	<list>
	<t>VRF-Name sub-TLV: indicates carried.</t>

              <dl newline="false" spacing="normal">
                <dt>VRF-Name sub-TLV:</dt><dd>Indicates which VRF the route
                belongs to.</t>
        <t> If-Desc sub-TLV: carries to.</dd>
                <dt>If-Desc sub-TLV:</dt><dd>Carries the interface information.</t>
	</list>
	</t>

	<t> The information.</dd>
              </dl>
            </dd>
            <dt>Reserved:</dt><dd>The Reserved field MUST <bcp14>MUST</bcp14> be
            sent as zero and ignored on receipt.</t>

	</list>
	</t> receipt.</dd>

          </dl>
</li></ul>
        </section>
        <section title="IPv6 anchor="sect-7.8.2" numbered="true" toc="default">
          <name>IPv6 Routing TLV" anchor="sect-7.8.2"><t> TLV</name>
          <t>
   The IPv6 Routing TLV is used to carry IPv6 network routing
   information.</t>
          <t>The format of the value part of this TLV is as follows:</t>
          <figure title="IPv6 anchor="fig45">
            <name>IPv6 Routing TLV" anchor="fig45"><artwork><![CDATA[ TLV</name>
            <artwork name="" type="" align="left" alt=""><![CDATA[
    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-ID                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                          IPv6 Dest-Address                    ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                          IPv6 Next-Hop                        ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Out-If-Index                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Cost                                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Tag                                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Route Type        Route-Type             |          Reserved           |A|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                          sub-TLVs                          Sub-TLVs (optional)                  ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
          </figure>
          <t>Where:

	<list>
	<t>The TLV Type: 7</t>

	<t>The TLV Length is Variable.</t>

	<t>User-ID: 4
          </t>

<ul empty="true"><li>
          <dl newline="false" spacing="normal">

            <dt>TLV type:</dt><dd>8.</dd>
            <dt>TLV length:</dt><dd>Variable.</dd>
            <dt>User-ID:</dt><dd>4 bytes in length. This field carries the user identifier.
	This field is filled with all Fs when a non-user route is delivered to
	the UP.</t>

	<t>IPv6 UP.</dd>
            <dt>IPv6 Dest-Address (IPv6-Address type): Identifies type):</dt><dd>Identifies the destination
	address.</t>

	<t>IPv6 Next-Hop:
	address.</dd>
            <dt>IPv6 Next-Hop (IPv6-Address type): Identifies type):</dt><dd>Identifies the next hop
	address.</t>

	<t>Out-If-Index next-hop
	address.</dd>
            <dt>Out-If-Index (4 bytes): Indicates bytes):</dt><dd>Indicates the interface index.</t>

	<t>Cost index.</dd>
            <dt>Cost (4 bytes): This bytes):</dt><dd>This is the cost value of the route.</t>

	<t>Tag route.</dd>
            <dt>Tag (4 bytes): The bytes):</dt><dd>The tag value of the route.</t>

	<t>Route-Type: route.</dd>
            <dt>Route-Type (2 bytes): The bytes):</dt><dd>The value of this field
            indicates the route type. The values defined in this document are
            listed in <xref
	target="sect-9.9"/>.</t>

	<t>Advertise-Flag: 1 target="sect-9.9" format="default"/>.</dd>

            <dt>Advertise-Flag:</dt><dd><t>1 bit shown as &quot;A&quot; is "A" in the figure above.
            above (<xref target="fig45" format="default"/>).  Indicates
            whether the UP should advertise the route.  Following  The following flags
            are
	defined:

	<list>
	  <t>0: Not advertised,</t>
	  <t>1: Advertised.</t>
	</list>
	</t>

        <t>sub-TLVs: defined:</t>

              <dl newline="false" spacing="normal">
                <dt>0:</dt><dd>Not advertised.</dd>
                <dt>1:</dt><dd>Advertised.</dd>
              </dl>
            </dd>

            <dt>Sub-TLVs:</dt><dd><t>The If-Desc and VRF-Name sub-TLVs can be carried.

        <list>
	<t>VRF-Name sub-TLV: Indicates carried.</t>

              <dl newline="false" spacing="normal">
                <dt>VRF-Name sub-TLV:</dt><dd>Indicates the VRF to which the subscriber
	belongs.</t>
	<t> If-Desc sub TLV: carries
	belongs.</dd>
                <dt>If-Desc sub-TLV:</dt><dd>Carries the interface information.</t>
	</list>
	</t>

	<t> The information.</dd>
              </dl>
            </dd>

            <dt>Reserved:</dt><dd>The Reserved field MUST <bcp14>MUST</bcp14> be sent as zero and ignored on receipt.</t>

	</list>
	</t> receipt.</dd>

          </dl>
</li></ul>

        </section>
      </section>
      <section title="Subscriber TLVs" anchor="sect-7.9"><t> anchor="sect-7.9" numbered="true" toc="default">
        <name>Subscriber TLVs</name>
        <t>
   The Subscriber TLVs are defined for a CP to send the basic
   information about a user to a UP.</t>
        <section title="Basic anchor="sect-7.9.1" numbered="true" toc="default">
          <name>Basic Subscriber TLV" anchor="sect-7.9.1"><t> TLV</name>
          <t>
   The Basic Subscriber TLV is used to carry the basic common
   information for all kinds of access subscribers.  It is carried in an
   Update_Request message.</t>
          <t>The format of the Basic Subscriber TLV value part is as follows:</t>
          <figure title="Basic anchor="fig46">
            <name>Basic Subscriber TLV" anchor="fig46"><artwork><![CDATA[ TLV</name>
            <artwork name="" type="" align="left" alt=""><![CDATA[
    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-ID                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Session ID                          Session-ID                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          User MAC                          User-MAC                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             User MAC        User-MAC (cont.)       |   Oper ID   Oper-ID     |    Reserved   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Access Type   |Sub-access Type|  Account Type Access-Type   |Sub-Access-Type|  Account-Type | Address Family|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               C-VID           |          P-VID                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               Detect Times               Detect-Times    |          Detect Interval          Detect-Interval      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            If-Index                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                            sub-TLVs                            Sub-TLVs (optional)                ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
          </figure>
          <t>Where:

	<list>

	<t>The TLV Type: 2.</t>

	<t>The TLV is variable in length.</t>

	<t>User-ID
          </t>

<ul empty="true">
  <li>
    <dl newline="false" spacing="normal">
      <dt>TLV type:</dt><dd>2.</dd>
      <dt>TLV length:</dt><dd>Variable.</dd>
      <dt>User-ID (4 bytes): The bytes):</dt><dd>The identifier of a subscriber.</t>

	<t>Session-ID subscriber.</dd>
      <dt>Session-ID (4 bytes): Session bytes):</dt><dd>Session ID of a PPPoE subscriber.
           The value zero identifies a non-PPPoE subscriber.</t>

	<t>User-Mac subscriber.</dd>
      <dt>User-MAC (MAC-Addr type): The type):</dt><dd>The MAC Address address of a subscriber.</t>

	<t>Oper-ID subscriber.</dd>
      <dt>Oper-ID (1 byte): Indicates byte):</dt><dd>Indicates the ID of an operation performed by a
	   user. This field is carried in the response from the UP.</t>

	<t>Reserved UP.</dd>
      <dt>Reserved (1 byte): MUST byte):</dt><dd><bcp14>MUST</bcp14> be sent as zero
           and ignored on receipt.</t>

	<t>Access-Type receipt.</dd>
      <dt>Access-Type (1 byte): Indicates byte):</dt><dd>Indicates the type of subscriber
           access. Values defined in this document are listed in <xref target="sect-9.10"/>.</t>

	<t>Sub-Access-Type
           target="sect-9.10" format="default"/>.</dd>
      <dt>Sub-Access-Type (1 byte): Indicates byte):</dt>
          <dd>
            <t>Indicates whether PPP termination or PPP relay is used.

      <list>
      <t>0: Reserved</t>
      <t>1: PPP used.</t>
            <dl newline="false" spacing="normal">
                  <dt>0:</dt><dd>Reserved.</dd>
                  <dt>1:</dt><dd>PPP Relay (for LAC)</t>
      <t>2: PPP LAC).</dd>
                  <dt>2:</dt><dd>PPP termination (for LNS)</t>
      </list>
      </t>

	<t>Account-Type LNS).</dd>
            </dl>
	  </dd>

      <dt>Account-Type (1 byte):
        <list>
	<t>0: Collects byte):</dt>
          <dd>
          <t>Indicates whether traffic statistics are collected independently. </t>
            <dl newline="false" spacing="normal">
                  <dt>0:</dt><dd>Collects statistics on IPv4 and
                                 IPv6 traffic of terminals
                 independently.</t>
        <t>1: Collects independently.</dd>
                  <dt>1:</dt><dd>Collects statistics on IPv4 and IPv6
                                 traffic of terminals.</t>

	</list>
	</t>

	<t>Address terminals.</dd>
             </dl>
           </dd>

       <dt>Address Family (1 byte)
	<list>
	 <t>1: IPv4</t>
         <t>2: IPv6</t>
         <t>3: dual stack</t>
	 </list>
	</t>

	<t>C-VID (VLAN-ID): Indicates byte):</dt>
          <dd>
          <t>The type of IP address.</t>
            <dl newline="false" spacing="normal">
                  <dt>1:</dt><dd>IPv4.</dd>
                  <dt>2:</dt><dd>IPv6.</dd>
                  <dt>3:</dt><dd>Dual stack.</dd>
            </dl>
         </dd>

      <dt>C-VID (VLAN-ID):</dt><dd>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. 1-4094.  The PRI value
	can also be obtained by parsing terminal packets.</t>

	<t>P-VID (VLAN-ID): Indicates packets.</dd>

      <dt>P-VID (VLAN-ID):</dt><dd>Indicates the outer VLAN ID.  The value 0
	indicates that the VLAN ID is invalid.  The format is the same as that
	for C-VID.</t>

	<t>Detect-Times C-VID.</dd>

      <dt>Detect-Times (2 bytes): Number bytes):</dt><dd>Number of detection timeout times.  The
	    value 0 indicates that no detection is performed.</t>

	<t>Detect-Interval performed.</dd>

      <dt>Detect-Interval (2 bytes): Detection bytes):</dt><dd>Detection interval in seconds.</t>

	<t>If-Index
	    seconds.</dd>

      <dt>If-Index (4 bytes): Interface index.</t>

	<t> Sub-TLVs: bytes):</dt><dd>Interface index.</dd>

      <dt>Sub-TLVs:</dt>
         <dd>
           <t>The VRF-Name sub-TLV and If-Desc sub-TLV can
              be carried.</t>

	<t>VRF-Name sub-TLV: Indicates
           <dl newline="false" spacing="normal">
                 <dt>VRF-Name sub-TLV:</dt><dd>Indicates the VRF to which the
                     subscriber
	belongs.</t>

	<t>If-Desc sub-TLV: carries belongs.</dd>
                 <dt>If-Desc sub-TLV:</dt><dd>Carries the interface information.</t>

	<t>The information.</dd>
           </dl>
         </dd>

      <dt>Reserved:</dt><dd>The Reserved field MUST <bcp14>MUST</bcp14> be sent as
                            zero and ignored on receipt.</t>

	</list>
	</t> receipt.</dd>
    </dl>
  </li>
</ul>

        </section>
        <section title="PPP anchor="sect-7.9.2" numbered="true" toc="default">
          <name>PPP Subscriber TLV" anchor="sect-7.9.2"><t> TLV</name>
          <t>
   The PPP Subscriber TLV is defined to carry PPP information of a User user
   from a CP to a UP. It will be carried in an Update_Request message
   when PPPoE or L2TP access is used.</t>
          <t>The format of the TLV value part is as follows:</t>
          <figure title="PPP anchor="fig47">
            <name>PPP Subscriber TLV" anchor="fig47"><artwork><![CDATA[ TLV</name>
            <artwork name="" type="" align="left" alt=""><![CDATA[
    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-ID                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        MSS        MSS-Value              |        Reserved             |M|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        MRU                    |        Reserved               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Magic Number                          Magic-Number                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Peer Magic Number                          Peer-Magic-Number                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
          </figure>
          <t>Where:

	<list>
	<t>The TLV type: 3.</t>

	<t>The TLV length is 12 octets.</t>

	<t>User-ID
          </t>

<ul empty="true"><li>
          <dl newline="false" spacing="normal">

            <dt>TLV type:</dt><dd>3.</dd>
            <dt>TLV length:</dt><dd>12 octets.</dd>
            <dt>User-ID (4 bytes): The bytes):</dt><dd>The identifier of a subscriber.</t>

	<t>MSS-Value subscriber.</dd>
            <dt>MSS-Value (2 bytes): Indicates bytes):</dt><dd>Indicates the MSS value (in bytes).</t>

	<t>MSS-Enable
            bytes).</dd>

            <dt>MSS-Enable (M) (1 bit): Indicates bit):</dt><dd><t>Indicates whether the MSS
            is enabled.

	<list>
	  <t>0: Disabled.</t>
	  <t>1: Enabled.</t>
	</list>
	</t>

	<t>MRU enabled.</t>

              <dl newline="false" spacing="normal">
                <dt>0:</dt><dd>Disabled.</dd>
                <dt>1:</dt><dd>Enabled.</dd>
              </dl>
            </dd>

            <dt>MRU (2 bytes): PPPoE bytes):</dt><dd>PPPoE local MRU (in bytes).</t>

	<t>Magic-Number bytes).</dd>
            <dt>Magic-Number (4 bytes): Local bytes):</dt><dd>Local magic number in PPP negotiation
	packets.</t>

	<t>Peer-Magic-Number
	packets.</dd>
            <dt>Peer-Magic-Number (4 bytes): Remote bytes):</dt><dd>Remote peer magic number.</t>

	<t>The number.</dd>
            <dt>Reserved:</dt><dd>The Reserved fields MUST <bcp14>MUST</bcp14> be
            sent as zero and ignored on
	receipt.</t>

	</list>
	</t> receipt.</dd>

          </dl>
</li></ul>

        </section>
        <section title="IPv4 anchor="sect-7.9.3" numbered="true" toc="default">
          <name>IPv4 Subscriber TLV" anchor="sect-7.9.3"><t> TLV</name>
          <t>
   The IPv4 Subscriber TLV is defined to carry IPv4 related IPv4-related information
   for a BNG user.  It will be carried in an Update_Request message when
   IPv4 IPoE or PPPoE access is used.</t>
          <t>The format of the TLV value part is as follows:</t>
          <figure title="IPv4 anchor="fig48">
            <name>IPv4 Subscriber TLV" anchor="fig48"><artwork><![CDATA[ TLV</name>
            <artwork name="" type="" align="left" alt=""><![CDATA[
    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-ID                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          User IPv4 Address                          User-IPv4                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Gateway IPv4 Address                          Gateway-IPv4                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          MTU                  |   Reserved            |U|E|W|P|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                          VRF-Name sub-TLV Sub-TLV                     ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
          </figure>
          <t>Where:

	<list>
	<t>The TLV type: 4.</t>

	<t>The TLV length is variable.</t>

	<t>User-ID
          </t>

<ul empty="true"><li>
          <dl newline="false" spacing="normal">
            <dt>TLV type:</dt><dd>4.</dd>
            <dt>TLV length:</dt><dd>Variable.</dd>
            <dt>User-ID (4 bytes): The bytes):</dt><dd>The identifier of a subscriber.</t>

	<t>User-IPv4 (IPv4-Address): The subscriber.</dd>
            <dt>User-IPv4 (IPv4-Address):</dt><dd>The IPv4 address of the subscriber.</t>

	<t>Gateway-IPv4 (IPv4-Address): The subscriber.</dd>
            <dt>Gateway-IPv4 (IPv4-Address):</dt><dd>The gateway address of the
	subscriber.</t>

	<t>Portal Force
	subscriber.</dd>

            <dt>Portal-Force (P) (1 bit ): Push advertisement, 0: off, 1: on.</t>

	<t>Web-Force bit):</dt><dd><t>Push advertisement.</t>

          <dl newline= "false" spacing="normal">
            <dt>0:</dt><dd>Off.</dd>
            <dt>1:</dt><dd>On.</dd>
          </dl>

          </dd>

            <dt>Web-Force (W) (1 bit): Push bit):</dt><dd><t>Push IPv4 Web. 0: off, 1: on.	</t>

	<t>Echo-Enable Web.</t>

          <dl newline= "false" spacing="normal">
            <dt>0:</dt><dd>Off.</dd>
            <dt>1:</dt><dd>On.</dd>
          </dl>

        </dd>

            <dt>Echo-Enable (E) (1 bit): UP bit):</dt><dd><t>UP returns ARP Req or PPP Echo. 0: off,
	1: on.</t>

	<t>IPv4-URPF Echo.</t>

          <dl newline= "false" spacing="normal">
            <dt>0:</dt><dd>Off.</dd>
            <dt>1:</dt><dd>On.</dd>
          </dl>

        </dd>

            <dt>IPv4-URPF (U) (1 bit): User bit):</dt><dd><t>User Unicast Reverse Path Forwarding (URPF)
	flag. 0: off, 1: on.</t>

	<t>MTU 2 bytes MTU
	flag.</t>

          <dl newline= "false" spacing="normal">
            <dt>0:</dt><dd>Off.</dd>
            <dt>1:</dt><dd>On.</dd>
          </dl>

          </dd>

            <dt>MTU (2 bytes):</dt><dd>MTU value.  The default value is 1500.</t>

	<t>VRF-Name Sub-TLV: Indicates 1500.</dd>
            <dt>VRF-Name Sub-TLV:</dt><dd>Indicates the subscriber belongs to which VRF.</t>

	<t>The VRF.</dd>
            <dt>Reserved:</dt><dd>The Reserved field MUST <bcp14>MUST</bcp14> be sent as zero and ignored on receipt.</t>

	</list>
	</t> receipt.</dd>

          </dl>
</li></ul>

        </section>
        <section title="IPv6 anchor="sect-7.9.4" numbered="true" toc="default">
          <name>IPv6 Subscriber TLV" anchor="sect-7.9.4"><t> TLV</name>
          <t>
   The IPv6 Subscriber TLV is defined to carry IPv6 related IPv6-related information
   for a BNG user.  It will be carried in an Update_Request message when
   IPv6 IPoE or PPPoE access is used.</t>
          <t>The format of the TLV value part is as follows:</t>
          <figure title="IPv6 anchor="fig49">
            <name>IPv6 Subscriber TLV" anchor="fig49"><artwork><![CDATA[ TLV</name>
            <artwork name="" type="" align="left" alt=""><![CDATA[
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          User-ID                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~           User PD-Address (IPv6 Address List sub-TLV) Sub-TLV)         ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~        Gateway ND-Address (IPv6 Address List sub-TLV) Sub-TLV)         ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          User Link-Local-Address              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          IPv6 Interface ID                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          IPv6 Interface ID (cont.)            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          MTU                  |   Reserved            |U|E|W|P|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                    VRF Name sub-TLV Sub-TLV (optional)                ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
          </figure>
          <t>Where:

	<list>
	<t>The TLV type: 5.</t>

	<t>The TLV length is variable.</t>

	<t>User-ID
          </t>

<ul empty="true"><li>
          <dl newline="false" spacing="normal">

            <dt>TLV type:</dt><dd>5.</dd>
            <dt>TLV length:</dt><dd>Variable.</dd>
            <dt>User-ID (4 bytes): The bytes):</dt><dd>The identifier of a subscriber.</t>

	<t>User subscriber.</dd>
            <dt>User PD-Addresses (IPv6 Address List): Carries List):</dt><dd>Carries a list of Prefix
	Delegation (PD) addresses of the subscriber.</t>

	<t>User subscriber.</dd>
            <dt>User ND-Addresses (IPv6 Address List): Carries List):</dt><dd>Carries a list of Neighbor
	Discovery (ND) addresses of the subscriber.</t>

	<t>User subscriber.</dd>
            <dt>User Link-Local-Address (IPv6-Address): The (IPv6-Address):</dt><dd>The link-local address of
	the subscriber.</t>

	<t>IPv6 subscriber.</dd>
            <dt>IPv6 Interface ID (8 bytes): The bytes):</dt><dd>The identifier of an IPv6
	interface.</t>

	<t>Portal Force
	interface.</dd>

            <dt>Portal-Force 1 bit (P): Push advertisement, 0: off, 1: on.</t>

	<t>Web-Force (P):</dt><dd><t>Push advertisement.</t>

          <dl newline= "false" spacing="normal">
            <dt>0:</dt><dd>Off.</dd>
            <dt>1:</dt><dd>On.</dd>
          </dl>

        </dd>

            <dt>Web-Force 1 bit (W): Push (W):</dt><dd><t>Push IPv6 Web, 0: off, 1: on.</t>

	<t>Echo-Enable Web.</t>

          <dl newline= "false" spacing="normal">
            <dt>0:</dt><dd>Off.</dd>
            <dt>1:</dt><dd>On.</dd>
          </dl>

          </dd>

            <dt>Echo-Enable 1 bit (E): The (E):</dt><dd><t>The UP returns ARP Req or
            PPP Echo. 0: off;
	1: on.</t>

	<t>IPv6-URPF Echo.</t>

          <dl newline= "false" spacing="normal">
            <dt>0:</dt><dd>Off.</dd>
            <dt>1:</dt><dd>On.</dd>
          </dl>

          </dd>

            <dt>IPv6-URPF 1 bit (U): User (U):</dt><dd><t>User Reverse Path Forwarding
            (URPF) flag, 0:
	off; 1: on.</t>

	<t>MTU flag.</t>

          <dl newline= "false" spacing="normal">
            <dt>0:</dt><dd>Off.</dd>
            <dt>1:</dt><dd>On.</dd>
          </dl>

          </dd>

            <dt>MTU (2 bytes): The bytes):</dt><dd>The MTU value. The default value is 1500.</t>

	<t>VRF-Name Sub-TLV: Indicates 1500.</dd>
            <dt>VRF-Name Sub-TLV:</dt><dd>Indicates the VRF to which the subscriber
	belongs.</t>

	<t> The
	belongs.</dd>
            <dt>Reserved:</dt><dd>The Reserved field MUST <bcp14>MUST</bcp14> be sent as zero and ignored on
	receipt.</t>

	</list>
	</t>
	receipt.</dd>

          </dl>
</li></ul>

        </section>
        <section title="IPv4 anchor="sect-7.9.5" numbered="true" toc="default">
          <name>IPv4 Static Subscriber Detect TLV" anchor="sect-7.9.5"><t> TLV</name>
          <t>
   The IPv4 Static Subscriber Detect TLV is defined to carry IPv4
   related IPv4-related
   information for a static access subscriber.  It will be
   carried in an Update_Request message when IPv4 static access on a UP
   needs to be enabled.</t>
          <t>The format of the TLV value part is as follows:</t>
          <figure title="IPv4 anchor="fig50">
            <name>IPv4 Static Subscriber TLV" anchor="fig50"><artwork><![CDATA[ TLV</name>
            <artwork name="" type="" align="left" alt=""><![CDATA[
    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                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        User MAC        User-MAC (cont.)       |           Reserved            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                       sub-TLVs                       Sub-TLVs (optional)                     ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
          </figure>
          <t>Where:

	<list>
	<t>The TLV type: 6.</t>

	<t>The TLV length is variable.</t>

	<t>If-Index
          </t>

<ul empty="true"><li>
          <dl newline="false" spacing="normal">

            <dt>TLV type:</dt><dd>9.</dd>
            <dt>TLV length:</dt><dd>Variable.</dd>
            <dt>If-Index (4 bytes): The bytes):</dt><dd>The interface index of the interface from which
	the subscriber will dial-up.</t>

	<t>C-VID (VLAN-ID): Indicates dial-up.</dd>
            <dt>C-VID (VLAN-ID):</dt><dd>Indicates the inner VLAN ID.  The value 0
	indicates that the VLAN ID is invalid.  A valid value is 1~4094.</t>

	<t>P-VID (VLAN-ID): Indicates 1-4094.</dd>
            <dt>P-VID (VLAN-ID):</dt><dd>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.  A valid value is 1~4094.  For a single-layer VLAN, set
	this parameter to PeVid.</t>

	<t>User 1-4094. </dd>
            <dt>User Address (IPv4-Addr): The (IPv4-Addr):</dt><dd>The user's IPv4 address.</t>

	<t>Gateway address.</dd>
            <dt>Gateway Address (IPv4-Addr): The (IPv4-Addr):</dt><dd>The gateway's IPv4 Address.</t>

	<t>User-MAC address.</dd>
            <dt>User-MAC (MAC-Addr type): The type):</dt><dd>The MAC address of the subscriber.</t>

	<t>Sub-TLVs: subscriber.</dd>

            <dt>Sub-TLVs:</dt><dd><t>The VRF-Name and If-Desc sub-TLVs may be
	    carried.</t>

	<t>VRF-Name sub-TLV: Indicates

          <dl newline="false" spacing="normal">
                <dt>VRF-Name sub-TLV:</dt><dd>Indicates the VEF VRF to which the subscriber
	belongs.</t>

	<t>If-Desc sub-TLV: Carries
	belongs.</dd>
                <dt>If-Desc sub-TLV:</dt><dd>Carries the interface information.</t>

	<t> The information.</dd>
          </dl>
           </dd>

            <dt>Reserved:</dt><dd>The Reserved field MUST <bcp14>MUST</bcp14> be
            sent as zero and ignored on
	receipt.</t>

	</list>
	</t> receipt.</dd>

          </dl>
</li></ul>

        </section>
        <section title="IPv6 anchor="sect-7.9.6" numbered="true" toc="default">
          <name>IPv6 Static Subscriber Detect TLV" anchor="sect-7.9.6"><t> TLV</name>
          <t>
   The IPv6 Static Subscriber Detect TLV is defined to carry IPv6
   related IPv6-related
   information for a static access subscriber.  It will be
   carried in an Update_Request message when needed to enable IPv6
   static subscriber detection on a UP.</t>
          <t>The format of the TLV value part is as follows:</t>
          <figure title="IPv6 anchor="fig51">
            <name>IPv6 Static Subscriber Detect TLV" anchor="fig51"><artwork><![CDATA[ TLV</name>
            <artwork name="" type="" align="left" alt=""><![CDATA[
    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                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        User MAC        User-MAC (cont.)       |           Reserved            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                        sub-TLVs                        Sub-TLVs (optional)                     ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
          </figure>
          <t>Where:

	<list>
	<t>The TLV type: 6.</t>

	<t>The TLV length is variable.</t>

	<t>If-Index
          </t>

<ul empty="true"><li>
          <dl newline="false" spacing="normal">
            <dt>TLV type:</dt><dd>10.</dd>
            <dt>TLV length:</dt><dd>Variable.</dd>
            <dt>If-Index (4 bytes): The bytes):</dt><dd>The interface index of the interface from which
	the subscriber will dial-up.</t>

	<t>C-VID (VLAN-ID): Indicates dial-up.</dd>
            <dt>C-VID (VLAN-ID):</dt><dd>Indicates the inner VLAN ID.  The value 0
	indicates that the VLAN ID is invalid.  A valid value is 1~4094.</t>

	<t>P-VID (VLAN-ID): Indicates 1-4094.</dd>
            <dt>P-VID (VLAN-ID):</dt><dd>Indicates the outer VLAN ID.  The value 0
	indicates that the VLAN ID is invalid.  The format is the same as that
	the of C-VID.  A valid value is 1~4094. 1-4094.  For a single-layer VLAN, set
	this parameter to PeVid.</t>

	<t>User PeVid.</dd>
            <dt>User Address (IPv6-Address type): The type):</dt><dd>The subscriber's IPv6 address.</t>

	<t>Gateway address.</dd>
            <dt>Gateway Address (IPv6-Address type): The type):</dt><dd>The gateway's
            IPv6 Address.</t>

	<t>User-MAC Address.</dd>
            <dt>User-MAC (MAC-Addr type): The type):</dt><dd>The MAC
            address of the subscriber.</t>

	<t>sub-TLVs: VRF-Name subscriber.</dd>

            <dt>Sub-TLVs:</dt><dd><t>VRF-Name and If-Desc sub-TLVs may be carried

	<list>
	<t>VRF-Name Sub-TLV: Indicates carried</t>

          <dl newline="false" spacing="normal">
                <dt>VRF-Name sub-TLV:</dt><dd>Indicates the VRF to which the
                subscriber belongs.</t>

	<t>If-Desc sub-TLV: Carries belongs.</dd>
                <dt>If-Desc sub-TLV:</dt><dd>Carries the interface information.</t>

	</list>
	</t>

	<t> The information.</dd>
          </dl>

            </dd>

            <dt>Reserved:</dt><dd>The Reserved field MUST <bcp14>MUST</bcp14> be
            sent as zero and ignored on receipt.</t>

	</list>
	</t> receipt.</dd>

          </dl>
</li></ul>

        </section>
        <section title="L2TP-LAC anchor="sect-7.9.7" numbered="true" toc="default">
          <name>L2TP-LAC Subscriber TLV" anchor="sect-7.9.7"><t> TLV</name>
          <t>
   The L2TP-LAC Subscriber TLV is defined to carry the related
   information for an L2TP LAC access subscriber.  It will be carried in
   an Update_Request message when L2TP LAC access is used.</t>
          <t>The format of the TLV value part is as follows:</t>
          <figure title="L2TP-LAC anchor="fig52">
            <name>L2TP-LAC Subscriber TLV" anchor="fig52"><artwork><![CDATA[ TLV</name>
            <artwork name="" type="" align="left" alt=""><![CDATA[
    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-ID                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Local Tunnel ID      Local-Tunnel-ID          |     Local Session ID     Local-Session-ID          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Remote Tunnel ID      Remote-Tunnel-ID         |     Remote Session ID     Remote-Session-ID         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
          </figure>
          <t>Where:

	<list>
	<t>The TLV type: 11.</t>

	<t>The TLV is 12 octets long.</t>

	<t>User-ID
          </t>

<ul empty="true"><li>

          <dl newline="false" spacing="normal">

            <dt>TLV type:</dt><dd>11.</dd>
            <dt>TLV length:</dt><dd>12 octets.</dd>
            <dt>User-ID (4 bytes): The bytes):</dt><dd>The identifier of a user/subscriber.</t>

	<t>Local-Tunnel-ID user/subscriber.</dd>
            <dt>Local-Tunnel-ID (2 bytes): The bytes):</dt><dd>The local ID of the L2TP tunnel.</t>

	<t>Local-Session-ID tunnel.</dd>
            <dt>Local-Session-ID (2 bytes): The bytes):</dt><dd>The local session ID with the L2TP
	tunnel.</t>

	<t>Remote-Tunnel-ID
	tunnel.</dd>
            <dt>Remote-Tunnel-ID (2 bytes): The bytes):</dt><dd>The identifier of the L2TP tunnel at
	the remote end-point.</t>

	<t>Remote-Session-ID endpoint.</dd>
            <dt>Remote-Session-ID (2 bytes): The bytes):</dt><dd>The session ID of the L2TP tunnel at
	the remote end-point.</t>

	</list>
	</t> endpoint.</dd>
          </dl>
	</li></ul>

        </section>
        <section title="L2TP-LNS anchor="sect-7.9.8" numbered="true" toc="default">
          <name>L2TP-LNS Subscriber TLV" anchor="sect-7.9.8"><t> TLV</name>
          <t>
   The L2TP-LNS Subscriber TLV is defined to carry the related
   information for a L2TP LNS access subscriber.  It will be carried in
   an Update_Request message when L2TP LNS access is used.</t>
          <t>The format of the TLV value part is as follows:</t>
          <figure title="L2TP-LNS anchor="fig53">
            <name>L2TP-LNS Subscriber TLV" anchor="fig53"><artwork><![CDATA[ TLV</name>
            <artwork name="" type="" align="left" alt=""><![CDATA[
    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-ID                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Local Tunnel ID      Local-Tunnel-ID          |     Local Session ID     Local-Session-ID          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Remote Tunnel ID      Remote-Tunnel-ID         |     Remote Session ID     Remote-Session-ID         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
          </figure>
          <t>Where:

	<list>
	<t>The TLV type: 12.</t>

	<t>The TLV length is 12 octets.</t>

	<t>User-ID
          </t>

<ul empty="true"><li>

          <dl newline="false" spacing="normal">
            <dt>TLV type:</dt><dd>12.</dd>
            <dt>TLV length:</dt><dd>12 octets.</dd>
            <dt>User-ID (4 bytes): The bytes):</dt><dd>The identifier of a user/subscriber.</t>

	<t>Local-Tunnel-ID user/subscriber.</dd>
            <dt>Local-Tunnel-ID (2 bytes): The bytes):</dt><dd>The local ID of the L2TP tunnel.</t>

	<t>Local-Session-ID tunnel.</dd>
            <dt>Local-Session-ID (2 bytes): The bytes):</dt><dd>The local session ID with the L2TP tunnel.</t>

	<t>Remote-Tunnel-ID tunnel.</dd>
            <dt>Remote-Tunnel-ID (2 bytes): The bytes):</dt><dd>The identifier of the L2TP tunnel at
	the remote end-point.</t>

	<t>Remote-Session-ID endpoint.</dd>
            <dt>Remote-Session-ID (2 bytes): The bytes):</dt><dd>The session ID of the L2TP tunnel at
	the remote end-point.</t>

	</list>
	</t> endpoint.</dd>

          </dl>

	</li></ul>

        </section>
        <section title="L2TP-LAC anchor="sect-7.9.9" numbered="true" toc="default">
          <name>L2TP-LAC Tunnel TLV" anchor="sect-7.9.9"><t> TLV</name>
          <t>
   The L2TP-LAC Tunnel TLV is defined to carry information related to the L2TP LAC tunnel
   related information. tunnel.
   It will be carried in the Update_Request
   message when L2TP LAC access is used.</t>
          <t>The format of the TLV value part is as follows:</t>
          <figure title="L2TP-LAC anchor="fig54">
            <name>L2TP-LAC Tunnel TLV" anchor="fig54"><artwork><![CDATA[ TLV</name>
            <artwork name="" type="" align="left" alt=""><![CDATA[
    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       Local-Tunnel-ID         |       Remote Tunnel ID       Remote-Tunnel-ID        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Source Port           Source-Port         |        Destination Port           Dest-Port           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                          Tunnel Source Address                          Source-IP                            ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                          Tunnel Destination Address                          Dest-IP                              ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                          VRF Name sub-TLV                          VRF-Name Sub-TLV                     ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
          </figure>
          <t>Where:

	<list>
	<t>The TLV type: 13.</t>

	<t>The TLV length is variable.</t>

	<t>Local-Tunnel-ID
          </t>

<ul empty="true"><li>

          <dl newline= "false" spacing="normal">

            <dt>TLV type:</dt><dd>13.</dd>
            <dt>TLV length:</dt><dd>Variable.</dd>
            <dt>Local-Tunnel-ID (2 bytes): The bytes):</dt><dd>The local ID of the L2TP tunnel.</t>

	<t>Remote-Tunnel-ID tunnel.</dd>
            <dt>Remote-Tunnel-ID (2 bytes): The bytes):</dt><dd>The remote ID of the L2TP tunnel.</t>

	<t>Source-Port tunnel.</dd>
            <dt>Source-Port (2 bytes): The bytes):</dt><dd>The source UDP port number of an L2TP subscriber.</t>

	<t>Dest-Port subscriber.</dd>
            <dt>Dest-Port (2 bytes): The bytes):</dt><dd>The destination UDP port number of an L2TP
	subscriber.</t>

	<t>Source-IP (IPv4/v6): The
	subscriber.</dd>
            <dt>Source-IP (IPv4/v6):</dt><dd>The source IP address of the tunnel.</t>

	<t>Dest-IP (IPv4/v6): The tunnel.</dd>
            <dt>Dest-IP (IPv4/v6):</dt><dd>The destination IP address of the tunnel.</t>

	<t>VRF-Name Sub-TLV: The tunnel.</dd>
            <dt>VRF-Name Sub-TLV:</dt><dd>The VRF name to which the L2TP subscriber tunnel
	belongs.</t>

	</list>
	</t>
	belongs.</dd>

          </dl>

</li></ul>

        </section>
        <section title="L2TP-LNS anchor="sect-7.9.10" numbered="true" toc="default">
          <name>L2TP-LNS Tunnel TLV" anchor="sect-7.9.10"><t> TLV</name>
          <t>
   The L2TP-LNS Tunnel TLV is defined to carry information related to the L2TP LNS tunnel
   related information. tunnel.
   It will be carried in the Update_Request
   message when L2TP LNS access is used.</t>
          <t>The format of the TLV value part is as follows:</t>
          <figure title="L2TP-LNS anchor="fig55">
            <name>L2TP-LNS Tunnel TLV" anchor="fig55"><artwork><![CDATA[ TLV</name>
            <artwork name="" type="" align="left" alt=""><![CDATA[
    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        Local-Tunnel-ID        |       Remote Tunnel ID       Remote-Tunnel-ID        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Source Port        Source-Port            |       Destination Port         Dest-Port             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                       Tunnel Source Address                       Source-IP                               ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                       Tunnel Destination Address                       Dest-IP                                 ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                       VRF Name sub-TLV                       VRF-Name Sub-TLV                        ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
          </figure>
          <t>Where:

	<list>
	<t>The TLV type: 14.</t>

	<t>The TLV length is variable.</t>

	<t>Local-Tunnel-ID
          </t>

<ul empty="true"><li>

          <dl newline= "false" spacing="normal">

            <dt>TLV type:</dt><dd>14.</dd>
            <dt>TLV length:</dt><dd>Variable.</dd>
            <dt>Local-Tunnel-ID (2 bytes): The bytes):</dt><dd>The local ID of the L2TP tunnel.</t>

	<t>Remote-Tunnel-ID tunnel.</dd>
            <dt>Remote-Tunnel-ID (2 bytes): The bytes):</dt><dd>The remote ID of the L2TP tunnel.</t>

	<t>Source-Port tunnel.</dd>
            <dt>Source-Port (2 bytes): The bytes):</dt><dd>The source UDP port number of an L2TP subscriber.</t>

	<t>Dest-Port subscriber.</dd>
            <dt>Dest-Port (2 bytes): The bytes):</dt><dd>The destination UDP port number of an L2TP subscriber.</t>

	<t>Source-IP (IPv4/v6): The subscriber.</dd>
            <dt>Source-IP (IPv4/v6):</dt><dd>The source IP address of the tunnel.</t>

	<t>Dest-IP (IPv4/v6): The tunnel.</dd>
            <dt>Dest-IP (IPv4/v6):</dt><dd>The destination IP address of the tunnel.</t>

	<t>VRF-Name Sub-TLV: The tunnel.</dd>
            <dt>VRF-Name Sub-TLV:</dt><dd>The VRF name to which the L2TP subscriber tunnel
	belongs.</t>

	</list>
	</t>
	belongs.</dd>

          </dl>

</li></ul>

        </section>
        <section title="Update anchor="sect-7.9.11" numbered="true" toc="default">
          <name>Update Response TLV" anchor="sect-7.9.11"><t> TLV</name>
          <t>
   The Update Response TLV is used to return the operation result of an
   update request.  It is carried in the Update_Response message as a
   response to the Update_Request message.</t>
          <t>The format of the value part of the Update Response TLV
   is as follows:</t>
          <figure title="Update anchor="fig56">
            <name>Update Response TLV" anchor="fig56"><artwork><![CDATA[ TLV</name>
            <artwork name="" type="" align="left" alt=""><![CDATA[
     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                            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
          </figure>
          <t>Where:

	<list>
	<t>The TLV type: 302.</t>

	<t>The TLV length is 12.</t>

	<t>User-ID
          </t>

<ul empty="true"><li>

          <dl newline= "false" spacing="normal">

            <dt>TLV type:</dt><dd>302.</dd>
            <dt>TLV length:</dt><dd>12.</dd>
            <dt>User-ID (4 bytes): A bytes):</dt><dd>A unique identifier of a user/subscriber.</t>

	<t>User-Trans-ID user/subscriber.</dd>
            <dt>User-Trans-ID (1 byte): In byte):</dt><dd>In the case of dual-stack access or when
	modifying 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.</t>

	<t>Oper-Code request.</dd>

            <dt>Oper-Code (1 byte): Operation code. 1: update, 2: delete.</t>

	<t>Oper-Result byte):</dt><dd><t>Operation code.</t>

          <dl newline= "false" spacing="normal">
            <dt>1:</dt><dd>Update.</dd>
            <dt>2:</dt><dd>Delete.</dd>
          </dl>

          </dd>

            <dt>Oper-Result (1 byte): Operation Result. 0: Success, Others: Failure.</t>

	<t>Error-Code byte):</dt><dd><t>Operation Result.</t>

          <dl newline= "false" spacing="normal">
            <dt>0:</dt><dd>Success.</dd>
            <dt>Others:</dt><dd>Failure.</dd>
          </dl>

          </dd>

            <dt>Error-Code (4 bytes): Operation bytes):</dt><dd>Operation failure cause code.  for  For details,
	see <xref target="sect-9.5"/>.</t>

	<t>The target="sect-9.5" format="default"/>.</dd>
            <dt>Reserved:</dt><dd>The Reserved field MUST <bcp14>MUST</bcp14> be sent as zero and ignored on receipt.</t>

	</list>
	</t> receipt.</dd>

          </dl>

	</li></ul>

        </section>
        <section title="Subscriber anchor="sect-7.9.12" numbered="true" toc="default">
          <name>Subscriber Policy TLV" anchor="sect-7.9.12"><t> TLV</name>
          <t>
   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.</t>
          <t>The format of the TLV value part is as follows:</t>
          <figure title="User QoS anchor="fig57">
            <name>Subscriber Policy Information TLV" anchor="fig57"><artwork><![CDATA[ TLV</name>
            <artwork name="" type="" align="left" alt=""><![CDATA[
    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-ID                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   I-Priority  |   E-Priority  |   Reserved                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                          sub-TLVs                          Sub-TLVs                             ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
          </figure>
          <t>Where:

	<list>
	<t>The TLV type: 6.</t>

	<t>The TLV length is variable.</t>

	<t>User-ID
          </t>

<ul empty="true"><li>

          <dl newline= "false" spacing="normal">

            <dt>TLV type:</dt><dd>6.</dd>
            <dt>TLV length:</dt><dd>Variable.</dd>
            <dt>User-ID (4 bytes): The bytes):</dt><dd>The identifier of a user/subscriber.</t>

	<t>Ingress-Priority user/subscriber.</dd>
            <dt>Ingress-Priority (1 byte): Indicates byte):</dt><dd>Indicates the upstream priority. The
	value range is 0~7.</t>

	<t>Egress-Priority 0~7.</dd>
            <dt>Egress-Priority (1 byte): Indicates byte):</dt><dd>Indicates the downstream priority. The
	value range is 0~7.</t>

	<t>sub-TLVs: The 0~7.</dd>
            <dt>Sub-TLVs:</dt><dd><t>The sub-TLVs that are present can occur
            in any order.

	<list>
	<t>Ingress-CAR sub-TLV: Upstream CAR.</t>

	<t>Egress-CAR sub-TLV: Downstream CAR.</t>

	<t>Ingress-QoS-Profile sub-TLV: Indicates order.</t>

          <dl newline= "false" spacing="normal">
                <dt>Ingress-CAR sub-TLV:</dt><dd>Upstream CAR.</dd>
                <dt>Egress-CAR sub-TLV:</dt><dd>Downstream CAR.</dd>
                <dt>Ingress-QoS-Profile sub-TLV:</dt><dd>Indicates the name of
                the QoS-Profile that is the profile in the upstream direction.</t>

	<t>Egress-QoS-Profile Sub-TLV: Indicates
                direction.</dd>
                <dt>Egress-QoS-Profile sub-TLV:</dt><dd>Indicates the name of
                the QoS-Profile that is the profile in the downstream direction.</t>

	<t>User-ACL-Policy Sub-TLV: All
                direction.</dd>
                <dt>User-ACL-Policy sub-TLV:</dt><dd>All ACL user policies,
                including v4ACLIN, v4ACLOUT, v6ACLIN, v6ACLOUT, v4WEBACL,
                v6WEBACL, v4SpecialACL, and
	v6SpecialACL.</t>

	<t>Multicast-Profile4 Sub-TLV: IPv4 v6SpecialACL.</dd>
                <dt>Multicast-Profile4 sub-TLV:</dt><dd>IPv4 multicast policy name.</t>

	<t>Multicast-Profile6 Sub-TLV: IPv6 name.</dd>
                <dt>Multicast-Profile6 sub-TLV:</dt><dd>IPv6 multicast policy name.</t>

	<t>NAT-Instance Sub-TLV: Indicates name.</dd>
                <dt>NAT-Instance sub-TLV:</dt><dd>Indicates the instance ID of
                a NAT user. </t>

	</list>
	</t>

	<t> The </dd>

          </dl>

            </dd>

            <dt>Reserved:</dt><dd>The Reserved field MUST <bcp14>MUST</bcp14> be sent as
            zero and ignored on
	receipt.</t>

	</list>
	</t> receipt.</dd>

          </dl>

	</li></ul>

        </section>
        <section title="Subscriber anchor="sect-7.9.13" numbered="true" toc="default">
          <name>Subscriber CGN Port Range TLV" anchor="sect-7.9.13"><t> TLV</name>
          <t>
   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.</t>
          <t>The format of the value part of this TLV is as follows:</t>
          <figure title="Subscriber anchor="fig58">
            <name>Subscriber CGN Port Range TLV" anchor="fig58"><artwork><![CDATA[ TLV</name>
            <artwork name="" type="" align="left" alt=""><![CDATA[
    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-ID                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           NAT-Port-Start      |          NAT-Port-End         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            NAT-Address                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
          </figure>
          <t>Where:

	<list>
	<t>The TLV type: 15.</t>

	<t>The TLV length is 12 octets.</t>

	<t>User-ID
          </t>

<ul empty="true"><li>

          <dl newline= "false" spacing="normal">

            <dt>TLV type:</dt><dd>15.</dd>
            <dt>TLV length:</dt><dd>12 octets.</dd>
            <dt>User-ID (4 bytes): The bytes):</dt><dd>The identifier of a user/subscriber.</t>

	<t>NAT-Port-Start user/subscriber.</dd>
            <dt>NAT-Port-Start (2 bytes): The bytes):</dt><dd>The start port number.</t>

	<t>NAT-Port-End number.</dd>
            <dt>NAT-Port-End (2 bytes): The bytes):</dt><dd>The end port number.</t>

	<t>NAT-Address number.</dd>
            <dt>NAT-Address (4 bytes): The bytes):</dt><dd>The NAT public network address.</t>

	</list>
	</t> address.</dd>

          </dl>

</li></ul>

        </section>
      </section>
      <section title="Device anchor="sect-7.10" numbered="true" toc="default">
        <name>Device Status TLVs" anchor="sect-7.10"><t> TLVs</name>
        <t>
   The TLVs in this section are for reporting Interface interface and Board level board-level
   information from the UP to the CP.</t>
        <section title="Interface anchor="sect-7.10.1" numbered="true" toc="default">
          <name>Interface Status TLV" anchor="sect-7.10.1"><t> TLV</name>
          <t>
   The Interface Status TLV is used to carry the status information of
   an interface on a UP.  It is carried in a Report message.</t>
          <t>The format of the value part of this TLV is as follows:</t>
          <figure title="Interface anchor="fig59">
            <name>Interface Status TLV" anchor="fig59"><artwork><![CDATA[ TLV</name>
            <artwork name="" type="" align="left" alt=""><![CDATA[
    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                          MAC-Address (upper part)             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   MAC Address   MAC-Address (lower part)    |   Phy-State   |   Reserved    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          MTU                                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          sub-TLVs                          Sub-TLVs (optional)                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
          </figure>
          <t>Where:

	<list>
	<t>The TLV type: 200.</t>

	<t>The TLV length is variable.</t>

	<t>If-Index
          </t>

<ul empty="true"><li>

          <dl newline= "false" spacing="normal">

            <dt>TLV type:</dt><dd>200.</dd>
            <dt>TLV length:</dt><dd>Variable.</dd>
            <dt>If-Index (4 bytes): Indicates bytes):</dt><dd>Indicates the interface index.</t>

	<t>MAC-Address index.</dd>
            <dt>MAC-Address (MAC-Addr type): Interface type):</dt><dd>Interface MAC address.</t>

	<t>Phy-State address.</dd>

            <dt>Phy-State (1 byte): Physical byte):</dt><dd><t>Physical status of the interface. 0: down, 1:
	Up</t>

	<t>MTU
            interface.</t>

          <dl newline= "false" spacing="normal">
            <dt>0:</dt><dd>Down.</dd>
            <dt>1:</dt><dd>Up.</dd>
          </dl>

          </dd>

            <dt>MTU (4 bytes): Interface bytes):</dt><dd>Interface MTU value.</t>

	<t>sub-TLVs: The value.</dd>
            <dt>Sub-TLVs:</dt><dd>The If-Desc and VRF-Name sub-TLVs can be carried.</t>

	<t>The carried.</dd>
            <dt>Reserved:</dt><dd>The Reserved field MUST <bcp14>MUST</bcp14> be
            sent as zero and ignored on receipt.</t>

	</list>
	</t> receipt.</dd>

          </dl>

	</li></ul>

        </section>
        <section title="Board anchor="sect-7.10.2" numbered="true" toc="default">
          <name>Board Status TLV" anchor="sect-7.10.2"><t> TLV</name>
          <t>
   The Board Status TLV is used to carry the status information of a
   board on an UP.  It is carried in a Report message.</t>
          <t>The format of the value part of the Board Status TLV is as follows:</t>

          <figure title="Interface Resource TLV" anchor="fig60"><artwork><![CDATA[ anchor="fig60">
            <name>Board Status TLV</name>
            <artwork name="" type="" align="left" alt=""><![CDATA[
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Board-Type  | Board-State   |   Reserved    |   Chassis     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               Slot            |           Reserved           Sub-Slot            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
          </figure>
          <t>Where:

	<list>
	<t>The TLV type: 201.</t>

	<t>The TLV length is 8 octets.</t>

	<t>Chassis
          </t>

<ul empty="true"><li>

          <dl newline= "false" spacing="normal">

            <dt>TLV type:</dt><dd>201.</dd>
            <dt>TLV length:</dt><dd>8 octets.</dd>
            <dt>Chassis (1 byte): The byte):</dt><dd>The chassis number of the Board.</t>

	<t>Slot (1 byte): The board.</dd>
            <dt>Slot (16 bits):</dt><dd>The slot number of the Board.</t>

	<t>Sub-Slot (1 byte): The board.</dd>
            <dt>Sub-Slot (16 bits):</dt><dd>The sub-slot number of the Board.</t>

	<t>Board-Type board.</dd>
            <dt>Board-Type (1 byte):

	<list>
	   <t>1: CGN byte):</dt><dd>
              <t>The type of board used.</t>
              <dl newline= "false" spacing="normal">
                <dt>1:</dt><dd>CGN Service Process Unit (SPU) board.</t>
           <t>2: Line board.</dd>
                <dt>2:</dt><dd>Line Process Unit (LPU) Board.</t>
	</list>
	</t>

	<t>Board-State board.</dd>
             </dl>
            </dd>

            <dt>Board-State (1 byte):

	   <list>
	      <t>0: Normal.</t>
              <t>1: Abnormal.</t>
	   </list>
	</t>

	<t>The reserved byte):</dt><dd>
                <t>Indicates whether there are issues with the board.</t>
                <dl newline= "false" spacing="normal">
                  <dt>0:</dt><dd>Normal.</dd>
                  <dt>1:</dt><dd>Abnormal.</dd>
                </dl>
              </dd>

            <dt>Reserved:</dt><dd>The Reserved field MUST <bcp14>MUST</bcp14> be sent as zero and ignored on receipt.</t>

	</list>
	</t> receipt.</dd>

          </dl>

	</li></ul>

        </section>
      </section>
      <section title="CGN TLVs" anchor="sect-7.11"><section title="Address anchor="sect-7.11" numbered="true" toc="default">
        <name>CGN TLVs</name>
        <section anchor="sect-7.11.1" numbered="true" toc="default">
          <name>Address Allocation Request TLV" anchor="sect-7.11.1"><t> TLV</name>
          <t>
   The Address Allocation Request TLV is used to request address
   allocation from the CP.  An address  A 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.</t>
          <t>The format of the value part of this TLV is as follows:</t>
          <figure title="Address anchor="fig61">
            <name>Address Allocation Request TLV" anchor="fig61"><artwork><![CDATA[ TLV</name>
            <artwork name="" type="" align="left" alt=""><![CDATA[
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                          Pool-Name sub-TLV Sub-TLV                    ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
          </figure>
          <t>Where:

	<list>
	<t>The TLV type: 400.</t>

	<t>The TLV length is variable.</t>

	<t>Pool-Name sub-TLV: Indicates
          </t>

<ul empty="true"><li>

          <dl newline= "false" spacing="normal">

            <dt>TLV type:</dt><dd>400.</dd>
            <dt>TLV length:</dt><dd>Variable.</dd>
            <dt>Pool-Name sub-TLV:</dt><dd>Indicates from which Address address pool
            to allocate
	address.</t>

	</list>
	</t> address.</dd>

          </dl>

</li></ul>

        </section>
        <section title="Address anchor="sect-7.11.2" numbered="true" toc="default">
          <name>Address Allocation Response TLV" anchor="sect-7.11.2"><t> TLV</name>
          <t>
   The Address Allocation Response TLV is used to return the address
   allocation result, result; it is carried in the Addr_Allocation_Ack message.</t>
          <t>
   The value part of the Address Allocation Response TLV is formatted as
   follows:</t>
          <figure title="Address Assignment anchor="fig62">
            <name>Address Allocation Response TLV" anchor="fig62"><artwork><![CDATA[ TLV</name>
            <artwork name="" type="" align="left" alt=""><![CDATA[
    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                        Client-IP                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        IPv4 Addr and Mask continued                        Client-IP (cont.)                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Error-Code                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                        Pool-Name sub-TLV Sub-TLV                      ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
          </figure>
          <t>Where:

	<list>
	<t>The TLV type: 401.</t>

	<t>The TLV length is variable.</t>

	<t>Lease
          </t>

<ul empty="true"><li>

          <dl newline= "false" spacing="normal">

            <dt>TLV type:</dt><dd>401.</dd>
            <dt>TLV length:</dt><dd>Variable.</dd>

            <dt>Lease Time (4 bytes): Duration bytes):</dt><dd>Duration of address lease in seconds.</t>

	<t>IPv4 Addr and Mask seconds.</dd>
            <dt>Client-IP (IPv4-Address type): The type):</dt><dd>The allocated
            IPv4
	address.</t>

	<t>Error-Code address and mask.</dd>
            <dt>Error-Code (4 bytes): Indicates bytes):</dt><dd><t>Indicates success or an error.

	<list>
	   <t>0: Success.</t>

	   <t>1: Failure.</t>

	   <t>3001 (Pool-Mismatch): error.</t>

          <dl newline= "false" spacing="normal">
                <dt>0:</dt><dd>Success.</dd>
                <dt>1:</dt><dd>Failure.</dd>
                <dt>3001:</dt><dd>Pool-Mismatch. The corresponding address pool cannot be
	   found.</t>

	   <t>3002 (Pool-Full):
	   found.</dd>
                <dt>3002:</dt><dd>Pool-Full. The address pool is fully allocated allocated, and no
	   address segment is available.</t>

	</list>
	</t>

	<t>Pool-Name sub-TLV: A Pool-Name sub-TLV to indicate available.</dd>

          </dl>
        </dd>

            <dt>Pool-Name sub-TLV:</dt><dd>Indicates from which
	Address
	address pool the address is allocated.</t>

	</list>
	</t> allocated.</dd>

          </dl>

</li></ul>

        </section>
        <section title="Address anchor="sect-7.11.3" numbered="true" toc="default">
          <name>Address Renewal Request TLV" anchor="sect-7.11.3"><t> TLV</name>
          <t>
   The Address Renewal Request TLV is used to request address renewal
   from the CP.  It is carried in the Addr_Renew_Req message.</t>
          <t>The format of this TLV value is as follows:</t>
          <figure title="Address anchor="fig63">
            <name>Address Renewal Request TLV" anchor="fig63"><artwork><![CDATA[ TLV</name>
            <artwork name="" type="" align="left" alt=""><![CDATA[
    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                     Client-IP                                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     IPv4 Address and Mask continued                     Client-IP (cont.)                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                     Pool-Name sub-TLV Sub-TLV                         ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
          </figure>
          <t>Where:

	<list>
	<t>The TLV type: 402.</t>

	<t>The TLV length is variable.</t>

	<t>IPv4 Addr and Mask (IPv4-Addr): The
          </t>

<ul empty="true"><li>

          <dl newline= "false" spacing="normal">

            <dt>TLV type:</dt><dd>402.</dd>
            <dt>TLV length:</dt><dd>Variable.</dd>
            <dt>Client-IP (IPv4-Address type):</dt><dd>The IPv4 address and mask to be renewed.</t>

	<t>Pool Name sub-TLV: A Pool-Name sub-TLV to indicate
            renewed.</dd>
            <dt>Pool-Name sub-TLV:</dt><dd>Indicates from which
	Address
	address pool to renew the address.</t>

	</list>
	</t> address.</dd>

          </dl>

</li></ul>

        </section>
        <section title="The Address anchor="sect-7.11.4" numbered="true" toc="default">
          <name>Address Renewal Response TLV" anchor="sect-7.11.4"><t> TLV</name>
          <t>
   The Address Renewal Response TLV is used to return the address
   renewal result.  It is carried in the Addr_Renew_Ack message.</t>
          <t>The format of this TLV value is as follows:</t>

          <figure title="Address anchor="fig64">
            <name>Address Renewal Response TLV" anchor="fig64"><artwork><![CDATA[ TLV</name>
            <artwork name="" type="" align="left" alt=""><![CDATA[
    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                     Client-IP                                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     IPv4 Address and Mask continued                     Client-IP (cont.)                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Error-Code                                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                     Pool-Name sub-TLV Sub-TLV                         ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
          </figure>
          <t>Where:

	<list>
	<t>The TLV type: 403.</t>

	<t>The TLV length is variable.</t>

	<t>Client-IP
          </t>

<ul empty="true"><li>

          <dl newline= "false" spacing="normal">

            <dt>TLV type:</dt><dd>403.</dd>
            <dt>TLV length:</dt><dd>Variable.</dd>
            <dt>Client-IP (IPv4-Address type): The type):</dt><dd>The renewed IPv4 address.</t>

	<t>Error Code address and mask.</dd>
            <dt>Error-Code (4 bytes): Indicates bytes):</dt><dd><t>Indicates success or an error:

	<list>
	   <t>0: Renew succeeded.</t>

	   <t>1: Renew failed.</t>

	   <t>3001 (Pool-Mismatch): error:</t>

          <dl newline= "false" spacing="normal">
                <dt>0:</dt><dd>Success.</dd>
                <dt>1:</dt><dd>Failure.</dd>
                <dt>3001:</dt><dd>Pool-Mismatch. The corresponding address
                pool cannot be
	   found.</t>

	   <t>3002 (Pool-Full): found.</dd>
                <dt>3002:</dt><dd>Pool-Full. The address pool is fully allocated allocated, and no
	   address segment is available.</t>

	   <t>3003 (Subnet-Mismatch): available.</dd>
                <dt>3003:</dt><dd>Subnet-Mismatch. The address pool subnet
                cannot be found.</t>

	   <t>3004 (Subnet-Conflict): found.</dd>
                <dt>3004:</dt><dd>Subnet-Conflict. Subnets in the address pool have been
	   assigned to other clients.</t>

	</list>
	</t>

	<t>Pool Name sub-TLV: A Pool-Name Sub-TLV to indicate clients.</dd>

          </dl>
            </dd>

            <dt>Pool-Name sub-TLV:</dt><dd>Indicates from which
	Address
	address pool to renew the address.</t>

	</list>
	</t> address.</dd>

          </dl>

</li></ul>

        </section>
        <section title="Address anchor="sect-7.11.5" numbered="true" toc="default">
          <name>Address Release Request TLV" anchor="sect-7.11.5"><t> TLV</name>
          <t>
   The Address Release Request TLV is used to release an IPv4 address.
   It is carried in the Addr_Release_Req message.</t>
          <t>The value part of this TLV is formatted as follows:</t>
          <figure title="Address anchor="fig65">
            <name>Address Release Request TLV" anchor="fig65"><artwork><![CDATA[ TLV</name>
            <artwork name="" type="" align="left" alt=""><![CDATA[
    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                     Client-IP                                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     IPv4 Address and Mask continued                     Client-IP (cont.)                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                     Pool-Name sub-TLV                         ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
          </figure>
          <t>Where:

	<list>
	<t>The TLV type: 404.</t>

	<t>The TLV length is variable.</t>

	<t>IPv4 Address and Mask
          </t>

<ul empty="true"><li>

          <dl newline= "false" spacing="normal">

            <dt>TLV type:</dt><dd>404.</dd>
            <dt>TLV length:</dt><dd>Variable.</dd>
            <dt>Client-IP (IPv4-Address type): The type):</dt><dd>The IPv4
            address be released.</t>

	<t>Pool-Name sub-TLV: A Pool-Name Sub-TLV and mask to indicate be released.</dd>
            <dt>Pool-Name sub-TLV:</dt><dd>Indicates from which
	Address
	address pool to release the address.</t>

	</list>
	</t> address.</dd>

          </dl>

</li></ul>

        </section>
        <section title="The Address anchor="sect-7.11.6" numbered="true" toc="default">
          <name>Address Release Response TLV" anchor="sect-7.11.6"><t> TLV</name>
          <t>
   The Address Release Response TLV is used to return the address
   release result.  It is carried in the Addr_Release_Ack message.</t>
          <t>The format of the value part of this TLV is as follows:</t>
          <figure title="Address Renewal anchor="fig66">
            <name>Address Release Response TLV" anchor="fig66"><artwork><![CDATA[ TLV</name>
            <artwork name="" type="" align="left" alt=""><![CDATA[
    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                     Client-IP                                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     IPv4 Address and Mask continued                     Client-IP (cont.)                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Error-Code                                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                     Pool-Name sub-TLV                         ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
          </figure>
          <t>Where:

	<list>
	<t>The TLV type: 405.</t>

	<t>The TLV length is variable.</t>

	<t>Client-IP
          </t>

<ul empty="true"><li>

          <dl newline= "false" spacing="normal">

            <dt>TLV type:</dt><dd>405.</dd>
            <dt>TLV length:</dt><dd>Variable.</dd>
            <dt>Client-IP (IPv4-Address type): The type):</dt><dd>The released IPv4 address.</t>

	<t>Error-Code address and mask.</dd>
            <dt>Error-Code (4 bytes): Indicates bytes):</dt><dd><t>Indicates success or an error.

	   <list>
              <t>0: error.</t>

          <dl newline= "false" spacing="normal">
                <dt>0:</dt><dd>Success. Address release success.</t>

	      <t>1: success.</dd>
                <dt>1:</dt><dd>Failure. Address release failed.</t>

	      <t>3001 (Pool-Mismatch): failed.</dd>
                <dt>3001:</dt><dd>Pool-Mismatch. The corresponding address
                pool cannot be found.</t>

	      <t>3003 (Subnet-Mismatch): found.</dd>

                <dt>3003:</dt><dd>Subnet-Mismatch. The address cannot be found.</t>

	      <t>3004 (Subnet-Conflict): found.</dd>

                <dt>3004:</dt><dd>Subnet-Conflict. The address has been
                allocated to another subscriber.</t>

	   </list>
	</t>

	<t>Pool-Name sub-TLV: A Pool-Name Sub-TLV to indicate subscriber.</dd>
          </dl>
            </dd>

            <dt>Pool-Name sub-TLV:</dt><dd>Indicates from which
	address pool to release the address.</t>

	</list>
	</t> address.</dd>

          </dl>

</li></ul>

        </section>
      </section>
      <section title="Event TLVs" anchor="sect-7.12"><section title="Subscriber anchor="sect-7.12" numbered="true" toc="default">
        <name>Event TLVs</name>
        <section anchor="sect-7.12.1" numbered="true" toc="default">
          <name>Subscriber Traffic Statistics TLV" anchor="sect-7.12.1"><t> TLV</name>
          <t>
   The Subscriber Traffic Statistics TLV is used to return the traffic
   statistics of a user/subscriber.  The format of the value part of this TLV is as
   follows:</t>
          <figure title="Subscriber anchor="fig67">
            <name>Subscriber Traffic Statistics TLV" anchor="fig67"><artwork><![CDATA[ TLV</name>
            <artwork name="" type="" align="left" alt=""><![CDATA[
    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                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)                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
          </figure>
          <t>Where:

	<list>
	<t>The TLV type: 300.</t>

	<t>The TLV length is 72 octets.</t>

	<t>User-ID
          </t>

<ul empty="true"><li>

          <dl newline= "false" spacing="normal">

            <dt>TLV type:</dt><dd>300.</dd>
            <dt>TLV length:</dt><dd>72 octets.</dd>
            <dt>User-ID (4 bytes): The bytes):</dt><dd>The subscriber identifier.</t>

	<t>Statistics-Type identifier.</dd>
            <dt>Statistics-Type (4 bytes): Traffic bytes):</dt><dd><t>Traffic type.  It can be one of the
	following options:

	<list>
           <t>0: IPv4 traffic.</t>
           <t>1: IPv6 traffic.</t>
           <t>2: Dual stack traffic.</t>
	</list>
	</t>

	<t>Ingress options:</t>

          <dl newline= "false" spacing="normal">
                <dt>0:</dt><dd>IPv4 traffic.</dd>
                <dt>1:</dt><dd>IPv6 traffic.</dd>
                <dt>2:</dt><dd>Dual-stack traffic.</dd>
          </dl>
            </dd>

            <dt>Ingress Packets (8 bytes): The bytes):</dt><dd>The number of the packets
            in the upstream
	direction.</t>

        <t>Ingress direction.</dd>
            <dt>Ingress Bytes (8 bytes): The bytes):</dt><dd>The bytes of the upstream traffic.</t>

	<t>Ingress traffic.</dd>
            <dt>Ingress Loss Packets (8 bytes): The bytes):</dt><dd>The number of the lost
            packets in the upstream direction.</t>

	<t>Ingress direction.</dd>
            <dt>Ingress Loss Bytes (8 bytes): The bytes):</dt><dd>The bytes of the lost
            upstream packets.</t>

	<t>Egress packets.</dd>
            <dt>Egress Packets (8 bytes): The bytes):</dt><dd>The number of the packets in
            the downstream
	direction.</t>

	<t>Egress direction.</dd>
            <dt>Egress Bytes (8 bytes): The bytes):</dt><dd>The bytes of the downstream traffic.</t>

	<t>Egress traffic.</dd>
            <dt>Egress Loss Packets (8 bytes): The bytes):</dt><dd>The number of the lost
            packets in the downstream direction.</t>

	<t>Egress direction.</dd>
            <dt>Egress Loss Bytes (8 bytes): The bytes):</dt><dd>The bytes of the lost downstream
	packets.</t>

	</list>
	</t>
	packets.</dd>

          </dl>

</li></ul>

        </section>
        <section title="Subscriber anchor="sect-7.12.2" numbered="true" toc="default">
          <name>Subscriber Detection Result TLV" anchor="sect-7.12.2"><t> TLV</name>
          <t>
   The Subscriber Detection Result TLV is used to return the detection
   result of a subscriber.  Subscriber detection is a function to detect
   whether or not a subscriber is online or not. online.  The result can be used by the
   CP to determine how to deal with the subscriber session. session (e.g.,
   delete the session if detection failed).</t>
          <t>The format of this TLV value part is as follows:</t>
          <figure title="Subscriber anchor="fig68">
            <name>Subscriber Detection Result TLV"	anchor="fig68"><artwork><![CDATA[ TLV</name>
            <artwork name="" type="" align="left" alt=""><![CDATA[
    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-Type   | Detect Result Detect-Result |          Reserved             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
          </figure>
          <t>Where:

	<list>
	<t>The TLV type: 301.</t>

	<t>The TLV length is 8 octets.</t>

	<t>User-ID
          </t>

<ul empty="true"><li>

          <dl newline= "false" spacing="normal">

            <dt>TLV type:</dt><dd>301.</dd>
            <dt>TLV length:</dt><dd>8 octets.</dd>
            <dt>User-ID (4 bytes): The bytes):</dt><dd>The subscriber identifier.</t>

	<t>Detect-Type identifier.</dd>
            <dt>Detect-Type (1 byte):

	<list>
	  <t>0: IPv4 detection.</t>

	  <t>1: IPv6 detection.</t>

	  <t>2: PPP detection.</t>

	</list>
	</t>

	<t>Detect-Result byte):</dt><dd>
                <t>Type of traffic detected.</t>
                <dl newline= "false" spacing="normal">
                  <dt>0:</dt><dd>IPv4 detection.</dd>
                  <dt>1:</dt><dd>IPv6 detection.</dd>
                  <dt>2:</dt><dd>PPP detection.</dd>
               </dl>
              </dd>

            <dt>Detect-Result (1 byte):

	<list>
	   <t>0: Indicates byte):</dt><dd>
                <t>Indicates whether the detection was successful. </t>
                <dl newline= "false" spacing="normal">
                  <dt>0:</dt><dd>Indicates that the detection is successful.</t>

           <t>1: Detection successful.</dd>
                  <dt>1:</dt><dd>Detection failure.  The UP needs to report only
                                  when the detection fails.</t>
	</list>
	</t>

	<t>The fails.</dd>
                </dl>
            </dd>

            <dt>Reserved:</dt><dd>The Reserved field MUST <bcp14>MUST</bcp14> be sent as zero and ignored on receipt.</t>

	</list>
	</t> receipt.</dd>

          </dl>

	</li></ul>

        </section>
      </section>
      <section title="Vendor TLV" anchor="sect-7.13"><t> anchor="sect-7.13" numbered="true" toc="default">
        <name>Vendor TLV</name>
        <t>
   The Vendor ID TLV occurs as the first TLV in the Vendor message
   (<xref target="sect-6.6"/>). target="sect-6.6" format="default"/>). It provides a Sub-Type that effectively extends the
   message type in the message header, provides for versioning of vendor
   TLVs, and can accommodate sub-TLVs.</t>
        <t>The value part of the Vendor TLV is formatted as follows:</t>
        <figure title="Vendor TLV" anchor="fig69"><artwork><![CDATA[ anchor="fig69">
          <name>Vendor TLV</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
    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                           Vendor-ID                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Sub-Type            |       Sub-Type-Version        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                      sub-TLVs                      Sub-TLVs (optional)                      ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
        </figure>
        <t>Where:

	<list>
	<t>The TLV type: 1024.</t>

	<t>The TLV length is variable.</t>

	<t>Vendor-ID
        </t>

<ul empty="true"><li>

          <dl newline="false" spacing="normal" indent="3">

          <dt>TLV type:</dt><dd>1024.</dd>
          <dt>TLV length:</dt><dd>Variable.</dd>
          <dt>Vendor-ID (4 bytes): Vendor bytes):</dt><dd>Vendor ID ass as defined in RADIUS
          <xref
	target="RFC2865"/>.</t>

	<t>Sub-Type target="RFC2865" format="default"/>.</dd>
          <dt>Sub-Type (2 bytes): Used bytes):</dt><dd>Used by the Vendor vendor to distinguish multiple
	different vendor messages.</t>

	<t>Sub-Type-Version messages.</dd>
          <dt>Sub-Type-Version (2 bytes): Used bytes):</dt><dd>Used by the Vendor vendor to distinguish
	different versions of a Vendor-Defined vendor-defined message sub-type.</t>

	<t>Sub-TLVs (variable): Sub-TLVs Sub-Type.</dd>
          <dt>Sub-TLVs (variable):</dt><dd>Sub-TLVs as specified by the vendor.</t>

	</list>
	</t> vendor.</dd>
          </dl>

	</li></ul>

        <t>
   Since Vendor vendor code will be handling the TLV after the Vendor ID Vendor-ID field
   is recognized, the remainder of the TLV value values 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
   <bcp14>RECOMMENDED</bcp14> that the vendor assign 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
   SHOULD
   <bcp14>SHOULD</bcp14> increase the value it is using in the Sub-Type-Version field.</t>
      </section>
    </section>

    <section title="Implementation Status" anchor="sect-8"><t>
   RFC Editor: Please remove this section before publication.</t> anchor="sect-9" numbered="true" toc="default">
      <name>Tables of S-CUSP Codepoints</name>

      <t>
   This section discusses the status of implementations that have provided
   information and the testing provides tables of this protocol at the time of posting of this
   Internet-Draft, S-CUSP codepoints, particularly
   message types, TLV types, TLV operation codes, sub-TLV types, and is based on the proposal in <xref target="RFC7942"/>
   ("Improving Awareness of Running Code: The Implementation Status
   Section"). The description of implementations in this section is intended
   error codes. In most cases, references are provided to assist relevant
   sections elsewhere in processing drafts to RFCs.</t>

	<t>
   Please note that the listing this document.</t>
      <section anchor="sect-9.1" numbered="true" toc="default">
        <name>Message Types</name>
<table>
	<name>Message Types</name>
	<thead>
	<tr>
		<th>Type</th>
		<th>Name</th>
		<th>Section of any individual implementation or test
   results here does not imply endorsement by This Document</th>
	</tr>
	</thead>
	<tbody>
	<tr>
		<td>0</td>
		<td>Reserved</td>
		<td></td>
	</tr>
	<tr>
		<td>1</td>
		<td>Hello</td>
		<td><xref target="sect-6.2.1" format="counter"/></td>
	</tr>
	<tr>
		<td>2</td>
		<td>Keepalive</td>
		<td><xref target="sect-6.2.2" format="counter"/></td>
	</tr>
	<tr>
		<td>3</td>
		<td>Sync_Request</td>
		<td><xref target="sect-6.2.3" format="counter"/></td>
	</tr>
	<tr>
		<td>4</td>
		<td>Sync_Begin</td>
		<td><xref target="sect-6.2.4" format="counter"/></td>
	</tr>
	<tr>
		<td>5</td>
		<td>Sync_Data</td>
		<td><xref target="sect-6.2.5" format="counter"/></td>
	</tr>
	<tr>
		<td>6</td>
		<td>Sync_End</td>
		<td><xref target="sect-6.2.6" format="counter"/></td>
	</tr>
	<tr>
		<td>7</td>
		<td>Update_Request</td>
		<td><xref target="sect-6.2.7" format="counter"/></td>
	</tr>
	<tr>
		<td>8</td>
		<td>Update_Response</td>
		<td><xref target="sect-6.2.8" format="counter"/></td>
	</tr>
	<tr>
		<td>9</td>
		<td>Report</td>
		<td><xref target="sect-6.4" format="counter"/></td>
	</tr>
	<tr>
		<td>10</td>
		<td>Event</td>
		<td><xref target="sect-6.3" format="counter"/></td>
	</tr>
	<tr>
		<td>11</td>
		<td>Vendor</td>
		<td><xref target="sect-6.6" format="counter"/></td>
	</tr>
	<tr>
		<td>12</td>
		<td>Error</td>
		<td><xref target="sect-6.7" format="counter"/></td>
	</tr>
	<tr>
		<td>13-199</td>
		<td>Unassigned</td>
		<td></td>
	</tr>
	<tr>
		<td>200</td>
		<td>Addr_Allocation_Req</td>
		<td><xref target="sect-6.5.1" format="counter"/></td>
	</tr>
	<tr>
		<td>201</td>
		<td>Addr_Allocation_Ack</td>
		<td><xref target="sect-6.5.2" format="counter"/></td>
	</tr>
	<tr>
		<td>202</td>
		<td>Addr_Renew_Req</td>
		<td><xref target="sect-6.5.3" format="counter"/></td>
	</tr>
	<tr>
		<td>203</td>
		<td>Addr_Renew_Ack</td>
		<td><xref target="sect-6.5.4" format="counter"/></td>
	</tr>
	<tr>
		<td>204</td>
		<td>Addr_Release_Req</td>
		<td><xref target="sect-6.5.5" format="counter"/></td>
	</tr>
	<tr>
		<td>205</td>
		<td>Addr_Release_Ack</td>
		<td><xref target="sect-6.5.6" format="counter"/></td>
	</tr>
	<tr>
		<td>206-254</td>
		<td>Unassigned</td>
		<td></td>
	</tr>
	<tr>
		<td>255</td>
		<td>Reserved</td>
		<td></td>
	</tr>
	</tbody>
</table>
      </section>
      <section anchor="sect-9.2" numbered="true" toc="default">
        <name>TLV Types</name>

<table>
<name>TLV Types</name>
  <thead>
    <tr>
      <th>Type</th><th>Name</th><th>Usage Description</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>0</td><td>Reserved</td><td>-</td>
    </tr>
    <tr>
      <td>1</td><td>BAS Function</td><td>Carries the RFC Series Editor
   (RSE), the Independent Submissions Editor (ISE), BNG access functions to be enabled or disabled on specified interfaces.</td>
    </tr>
    <tr>
      <td>2</td><td>Basic Subscriber</td><td>Carries the IETF.
   Furthermore, no effort has been spent to verify basic information about a BNG subscriber.</td>
    </tr>
    <tr>
      <td>3</td><td>PPP Subscriber</td><td>Carries the PPP information
   presented here that was supplied by contributors.  This is not
   intended as, and must not be construed to be, about a catalog of available
   implementations or their testing or features.  Readers are advised to
   note that other implementations may exist.</t>

	<t>
   According to <xref target="RFC7942"/>, "this will allow reviewers ... to
   assign due consideration to documents that have BNG subscriber.</td>
    </tr>
    <tr>
      <td>4</td><td>IPv4 Subscriber</td><td>Carries the benefit IPv4 address of running
   code, which may serve as evidence a BNG subscriber.</td>
    </tr>
    <tr>
      <td>5</td><td>IPv6 Subscriber</td><td>Carries the IPv6 address of valuable experimentation and feedback
   that have made a BNG subscriber.</td>
    </tr>
    <tr>
      <td>6</td><td>Subscriber Policy</td><td>Carries the implemented protocols more mature.".</t>

	<section title="Implementations" anchor="sect-8.1"><t>
   Information on three S-CUSP implementations appears below.</t>

	<section title="Huawei Technologies" anchor="sect-8.1.1"><t>
   Name: Cloud-based BNG.</t>

	<t>
   Maturity: Production.</t>

	<t>
   Coverage: According policy information applied to S-CUSP protocol.</t>

	<t><list style="hanging" hangIndent="3"><t hangText="Contact information:">
	<vspace blankLines="0"/>
	Zhouyi Yu: yuzhouyi@huawei.com
	</t>

	</list>
	</t>

	<t>
   Date: 2018-11-01</t>

	</section>

	<section title="ZTE" anchor="sect-8.1.2"><t>
   Name: ZXR10 V6000 vBRAS</t>

	<t>
   Maturity: Production</t>

	<t>
   Coverage: According to S-CUSP protocol.</t>

   <t>Contact information:
      <list>
	<t>Yong Chen: 10056167@zte.com.cn</t>
        <t>Huaibin Wang: 10008729@zte.com.cn</t>
      </list>
      </t>

	<t>
	Date: 2018-12-01
	</t>

	</section>

	<section title="H3C" anchor="sect-8.1.3"><t>
   Name: CUSP protocol for BRAS Control Plane and User Plane Separation</t>

	<t>
   Maturity: Research</t>

	<t>
   Coverage: According to S-CUSP protocol</t>

	<t>
   Contact information: mengdan@h3c.com; liuhanlei@h3c.com</t>

	<t>
   Date: 2019-1-30</t>

	</section>

	</section>

	<section title="Hackathon" anchor="sect-8.2"><t>
   Successful use of the protocol at the IETF-102 Hackathon, Montreal,
   Quebec, in 2018.</t>

	<t><list style="hanging" hangIndent="3">
        <t hangText="Hackathon Project:"> Control Plane and User Plane
        Separation BNG control channel Protocol (CUSP)
	</t>
	</list>
	</t>

	<t>
   Champions: Zhenqiang Li, Michael Wang</t>

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

	<section title="EANTC Testing" anchor="sect-8.3"><t> 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."</t>

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

	</section>

	</section>

	<section title="Tables of S-CUSP Codepoints" anchor="sect-9"><t>
   This section provides tables of the S-CUSP codepoints, particularly
   message types, TLV types, TLV operation codes, sub-TLV types, and
   error codes. In most cases, references are provided to relevant
   sections elsewhere in this document.</t>

	<section title="Message Types" anchor="sect-9.1"><figure><artwork><![CDATA[
     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     Error                 6.7.
    13-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
]]></artwork>
	</figure>
	</section>

	<section title="TLV Types" anchor="sect-9.2"><figure><artwork><![CDATA[
 Type     Name                         Usage Description
------   ------------                  --------------------------
    0    reserved                        -
    1   BAS Function                   Carries the BNG access
                                       functions to be enabled or
                                       disabled on specified
                                       interfaces.
    2   Basic Subscriber               Carries the basic information
                                       about a BNG subscriber.
    3   PPP Subscriber                 Carries the PPP information
                                       about a BNG subscriber.
    4   IPv4 Subscriber                Carries the IPv4 address of a
                                       BNG subscriber.
    5   IPv6 Subscriber                Carries the IPv6 address of a
                                       BNG subscriber.
    6   Subscriber Policy              Carries the policy information
                                       applied to a BNG subscriber.
    7   IPv4 Routing                   Carries subscriber.</td>
    </tr>
    <tr>
      <td>7</td><td>IPv4 Routing</td><td>Carries the IPv4 network routing information.
    8   IPv6 Routing                   Carries information.</td>
    </tr>
    <tr>
      <td>8</td><td>IPv6 Routing</td><td>Carries the IPv6 network routing information.
    9   IPv4 information.</td>
    </tr>
    <tr>
      <td>9</td><td>IPv4 Static Subscriber Detect  Carries Detect</td><td>Carries the IPv4 static subscriber detect information.
   10   IPv6 information.</td>
    </tr>
    <tr>
     <td>10</td><td>IPv6 Static Subscriber Detect  Carries Detect</td><td>Carries the IPv6 static subscriber detect information.
   11   L2TP-LAC Subscriber            Carries information.</td>
    </tr>
    <tr>
     <td>11</td><td>L2TP-LAC Subscriber</td><td>Carries the L2TP LAC subscriber information.
   12   L2TP-LNS Subscriber            Carries information.</td>
    </tr>
    <tr>
     <td>12</td><td>L2TP-LNS Subscriber</td><td>Carries the L2TP LNS subscriber information.
   13   L2TP-LAC-Tunnel                Carries information.</td>
    </tr>
    <tr>
     <td>13</td><td>L2TP-LAC Tunnel</td><td>Carries the L2TP LAC tunnel subscriber information.
   14   L2TP-LNS-Tunnel                Carries information.</td>
    </tr>
    <tr>
     <td>14</td><td>L2TP-LNS Tunnel</td><td>Carries the L2TP LNS tunnel subscriber information.
   15   Subscriber information.</td>
    </tr>
    <tr>
     <td>15</td><td>Subscriber CGN Port Range      Carries Range</td><td>Carries the public IPv4 address and related port range of a BNG subscriber.
16-99    unassigned                     -
  100   Hello                          Used subscriber.</td>
    </tr>
    <tr>
     <td>16-99</td><td>Unassigned</td><td>-</td>
    </tr>
    <tr>
     <td>100</td><td>Hello</td><td>Used for version and Keepalive timers negotiation.
  101   Error Information              Carried negotiation.</td>
    </tr>
    <tr>
     <td>101</td><td>Error Information</td><td>Carried in the Ack of the control message.  Carries the processing result, success, or
                                       error.
  102   Keepalive                      Carried error.</td>
    </tr>
    <tr>
     <td>102</td><td>Keepalive</td><td>Carried in the Hello message for Keepalive timers
                                       negotiation.
103-199  unassigned                     -
  200   Interface Status               Interfaces negotiation.</td>
    </tr>
    <tr>
  <td>103-199</td><td>Unassigned</td><td> -</td>
    </tr>
    <tr>
    <td>200</td><td>Interface Status</td><td>Interfaces status reported by the UP including physical interfaces, sub-interfaces, trunk interfaces, and tunnel
                                       interfaces.
  201   Board Status                   Board interfaces.</td>
    </tr>
    <tr>
    <td>201</td><td>Board Status</td><td>Board information reported by the UP including the board type and in-position status.
202-299  unassigned                     -
  300   Subscriber status.</td>
    </tr>
    <tr>
  <td>202-299</td><td>Unassigned</td><td>-</td>
    </tr>
    <tr>
    <td>300</td><td>Subscriber Traffic Statistics  User Statistics</td><td>User traffic statistics.
  301   Subscriber statistics.</td>
    </tr>
    <tr>
    <td>301</td><td>Subscriber Detection Results   User Result</td><td>User detection information.
  302   Update Response                The information.</td>
    </tr>
    <tr>
    <td>302</td><td>Update Response</td><td>The processing result of a subscriber session update.
303-299  unassigned                     -
  400   Address update.</td>
    </tr>
    <tr>
  <td>303-299</td><td>Unassigned</td><td> -</td>
    </tr>
    <tr>
    <td>400</td><td>Address Allocation Request     Request Request</td><td>Request address allocation.
  401   Address allocation.</td>
    </tr>
    <tr>
    <td>401</td><td>Address Allocation Response    Address Response</td><td>Address allocation response.
  402   Address response.</td>
    </tr>
    <tr>
    <td>402</td><td>Address Renewal Request        Request Request</td><td>Request for address lease
                                       renewal.
  403   Address renewal.</td>
    </tr>
    <tr>
    <td>403</td><td>Address Renewal Response       Response Response</td><td>Response to a request for extending an IP address lease.
  404   Address lease.</td>
    </tr>
    <tr>
    <td>404</td><td>Address Release Request        Request Request</td><td>Request to release the
                                       address.
  405   Address address.</td>
    </tr>
    <tr>
    <td>405</td><td>Address Release Response       Ack Response</td><td>Ack of a message releasing an IP address.
406-1023 unassigned                     -
 1024   Vendor                         As address.</td>
    </tr>
    <tr>
  <td>406-1023</td><td>Unassigned</td><td> -</td>
    </tr>
    <tr>
   <td>1024</td><td>Vendor</td><td>As implemented by vendor.
1039-4095 unassigned                    -
]]></artwork>
	</figure> the vendor.</td>
    </tr>
    <tr>
  <td>1039-4095</td><td>Unassigned</td><td> -</td>
    </tr>
</tbody>
</table>
      </section>
      <section title="TLV anchor="sect-9.3" numbered="true" toc="default">
        <name>TLV Operation Codes" anchor="sect-9.3"><t> Codes</name>
        <t>
   TLV operation codes appear in the Oper field in the header of some
   TLVs. See <xref target="sect-7.1"/>.</t>

	<figure><artwork><![CDATA[
   Code target="sect-7.1" format="default"/>.</t>

<table>
<name>TLV Operation
   ----   ----------
      0   reserved
      1   Update
      2   Delete
   3-15   unassigned
]]></artwork>
	</figure>
	</section>

	<section title="Sub-TLV Types" anchor="sect-9.4"> Codes</name>
       <thead>
	<tr>
		<th>Code</th>
		<th>Operation</th>
	</tr>
	</thead>
	<tbody>
	<tr>
		<td>0</td>
		<td>Reserved</td>
	</tr>
	<tr>
		<td>1</td>
		<td>Update</td>
	</tr>
	<tr>
		<td>2</td>
		<td>Delete</td>
	</tr>
	<tr>
		<td>3-15</td>
		<td>Unassigned</td>
	</tr>
	</tbody>
</table>
      </section>
      <section anchor="sect-9.4" numbered="true" toc="default">
        <name>Sub-TLV Types</name>
        <t>See Section 7.3.</t>

	<figure><artwork><![CDATA[
    Type   Name                Section <xref target="sect-7.3" format="default"/>.</t>
<table>
        <name>Sub-TLV Types</name>
        <thead>
        <tr>
                <th>Type</th>
                <th>Name</th>
                <th>Section of this document
    ----  ------------------   ------------------------
        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   IPv6-Address List    7.3.5.
       13   Vendor               7.3.6.
 12-64534   unassigned
    65535   reserved
]]></artwork>
	</figure>
	</section>

	<section title="Error Codes" anchor="sect-9.5"><figure><artwork><![CDATA[
 Value     Name             Remarks
-------   -------          --------
     0    Success          Success

     1    Fail             Malformed message received.
     2    TLV-Unknown      One This Document</th>
        </tr>
        </thead>
        <tbody>
        <tr>
                <td>0</td>
                <td>Reserved</td>
                <td></td>
        </tr>
        <tr>
                <td>1</td>
                <td>VRF Name</td>
                <td><xref target="sect-7.3.1" format="counter"/></td>
        </tr>
        <tr>
                <td>2</td>
                <td>Ingress-QoS-Profile</td>
                <td><xref target="sect-7.3.1" format="counter"/></td>
        </tr>
        <tr>
                <td>3</td>
                <td>Egress-QoS-Profile</td>
                <td><xref target="sect-7.3.1" format="counter"/></td>
        </tr>
        <tr>
                <td>4</td>
                <td>User-ACL-Policy</td>
                <td><xref target="sect-7.3.1" format="counter"/></td>
        </tr>
        <tr>
                <td>5</td>
                <td>Multicast-ProfileV4</td>
                <td><xref target="sect-7.3.1" format="counter"/></td>
        </tr>
        <tr>
                <td>6</td>
                <td>Multicast-ProfileV6</td>
                <td><xref target="sect-7.3.1" format="counter"/></td>
        </tr>
        <tr>
                <td>7</td>
                <td>Ingress-CAR</td>
                <td><xref target="sect-7.3.2" format="counter"/></td>
        </tr>
        <tr>
                <td>8</td>
                <td>Egress-CAR</td>
                <td><xref target="sect-7.3.3" format="counter"/></td>
        </tr>
        <tr>
                <td>9</td>
                <td>NAT-Instance</td>
                <td><xref target="sect-7.3.1" format="counter"/></td>
        </tr>
        <tr>
                <td>10</td>
                <td>Pool-Name</td>
                <td><xref target="sect-7.3.1" format="counter"/></td>
        </tr>
        <tr>
                <td>11</td>
                <td>If-Desc</td>
                <td><xref target="sect-7.3.4" format="counter"/></td>
        </tr>
        <tr>
                <td>12</td>
                <td>IPv6-Address List</td>
                <td><xref target="sect-7.3.5" format="counter"/></td>
        </tr>
        <tr>
                <td>13</td>
                <td>Vendor</td>
                <td><xref target="sect-7.3.6" format="counter"/></td>
        </tr>
        <tr>
                <td>12-64534</td>
                <td>Unassigned</td>
                <td></td>
        </tr>
        <tr>
                <td>65535</td>
                <td>Reserved</td>
                <td></td>
        </tr>
        </tbody>
</table>
      </section>
      <section anchor="sect-9.5" numbered="true" toc="default">

        <name>Error Codes</name>
<table>
        <name>Error Codes</name>
<thead>
	<tr>
		<th>Value</th>
		<th>Name</th>
		<th>Remarks</th>
	</tr>
</thead>
<tbody>
        <tr>
                <td>0</td><td>Success</td><td>Success</td>
        </tr>
        <tr>
                <td>1</td><td>Failure</td><td>Malformed message received.</td>
        </tr>
        <tr>
                 <td>2</td><td>TLV-Unknown</td><td>One or more of the TLVs was not
                           understood.
     3    TLV-Length       The understood.</td>
        </tr>
        <tr>
                 <td>3</td><td>TLV-Length</td><td>The TLV length is abnormal.
 4-999    unassigned       Unassigned abnormal.</td>
        </tr>
        <tr>
                 <td>4-999</td><td>Unassigned</td><td>Unassigned basic error codes.
  1000    reserved
  1001    Version-Mismatch The codes.</td>
        </tr>
        <tr>
                 <td>1000</td><td>Reserved</td><td></td>
        </tr>
        <tr>
                 <td>1001</td><td>Version-Mismatch</td><td>The version negotiation fails. Terminate.  The subsequent service processes corresponding to the UP are suspended.
  1002    Keepalive Error  The UP are suspended.</td>
        </tr>
        <tr>
                 <td>1002</td><td>Keepalive Error</td><td>The keepalive negotiation fails.
  1003    Timer Expires    The fails.</td>
        </tr>
        <tr>
                 <td>1003</td><td>Timer Expires</td><td>The establishment timer expired.
1004-1999  unassigned      Unassigned expired.</td>
        </tr>
        <tr>
                 <td>1004-1999</td><td>Unassigned</td><td>Unassigned error codes for version
                           negotiation.
  2000    reserved
  2001    Synch-NoReady    The negotiation.</td>
        </tr>
        <tr>
                 <td>2000</td><td>Reserved</td><td></td>
        </tr>
        <tr>
                 <td>2001</td><td>Synch-NoReady</td><td>The data to be smoothed is not ready.
  2002    Synch-Unsupport  The ready.</td>
        </tr>
        <tr>
                 <td>2002</td><td>Synch-Unsupport</td><td>The request for smooth data is not
                           supported.
2003-2999  unassigned      Unassigned supported.</td>
        </tr>
        <tr>
                 <td>2003-2999</td><td>Unassigned</td><td>Unassigned data synchronization error
                           codes.
  3000    reserved
  3001    Pool-Mismatch    The codes.</td>
        </tr>
        <tr>
                 <td>3000</td><td>Reserved</td><td></td>
        </tr>
        <tr>
                 <td>3001</td><td>Pool-Mismatch</td><td>The corresponding address pool cannot be
                           found.
  3002    Pool-Full        The found.</td>
        </tr>
        <tr>
                 <td>3002</td><td>Pool-Full</td><td>The address pool is fully allocated allocated, and no address segment is available.
  3003    Subnet-Mismatch  The available.</td>
        </tr>
        <tr>
                 <td>3003</td><td>Subnet-Mismatch</td><td>The address pool subnet cannot be found.
  3004    Subnet-Conflict  Subnets found.</td></tr>
        <tr>
                 <td>3004</td><td>Subnet-Conflict</td><td>Subnets in the address pool have been classified into other clients.
3005-3999  unassigned      Unassigned clients.</td>
        </tr>
        <tr>
                 <td>3005-3999</td><td>Unassigned</td><td>Unassigned error codes for address
                           allocation.
  4000    reserved
  4001    Update-Fail-No-Res  The allocation.</td>
        </tr>
        <tr>
                 <td>4000</td><td>Reserved</td><td></td>
        </tr>
        <tr>
                 <td>4001</td><td>Update-Fail-No-Res</td><td>The forwarding table fails to be delivered because the forwarding resources are insufficient.
  4002    QoS-Update-Success  The insufficient.</td>
        </tr>
        <tr>
                 <td>4002</td><td>QoS-Update-Success</td><td>The QoS policy takes effect.
  4003    QoS-Update-Sq-Fail  Failed effect.</td>
        </tr>
        <tr>
                 <td>4003</td><td>QoS-Update-Sq-Fail</td><td>Failed to process the queue in the QoS
                           policy.
  4004    QoS-Update-CAR-Fail  Processing policy.</td>
        </tr>
        <tr>
                 <td>4004</td><td>QoS-Update-CAR-Fail</td><td>Processing of the CAR in the QoS policy fails.
  4005    Statistic-Fail-No-Res  Statistics fails.</td>
        </tr>
        <tr>
                 <td>4005</td><td>Statistic-Fail-No-Res</td><td>Statistics processing failed due to insufficient statistics resources.
4006-4999  unassigned resources.</td>
        </tr>
        <tr>
                 <td>4006-4999</td><td>Unassigned </td><td>Unassigned forwarding table delivery error codes.

5000-4294967295 reserved
]]></artwork>
	</figure> codes.</td>
        </tr>
        <tr>
                 <td>5000-4294967295</td><td>Reserved</td><td></td>
        </tr>
</tbody>
</table>
      </section>
      <section title="If-Type Values" anchor="sect-9.6"><t> anchor="sect-9.6" numbered="true" toc="default">
        <name>If-Type Values</name>
        <t>
   Defined values of the If-Type field in the If-Desc sub-TLV (see
   <xref target="sect-7.3.4"/>) target="sect-7.3.4" format="default"/>) are as follows:</t>

	<figure><artwork><![CDATA[
   Value   Meaning
   -----  ------------
       0  reserved
       1  Fast

<table>
        <name>If-Type Values</name>
        <thead>
        <tr>
                <th>Value</th> <th>Meaning</th>
        </tr>
        </thead>
        <tbody>
        <tr>
                <td>0</td><td>Reserved</td>
        </tr>
        <tr>
                <td>1</td><td>Fast Ethernet (FE)
       2  GE
       3  10GE
       4  100GE
       5  Eth-Trunk
       6  Tunnel
       7  VE
   8-254  unassigned
     255  reserved
]]></artwork>
	</figure>
	</section>

	<section title="Access-Mode Values" anchor="sect-9.7"><t> (FE)</td>
        </tr>
        <tr>
                <td>2</td><td>GE</td>
        </tr>
        <tr>
                <td>3</td><td>10GE</td>
        </tr>
        <tr>
                <td>4</td><td>100GE</td>
        </tr>
        <tr>
                <td>5</td><td>Eth-Trunk</td>
        </tr>
        <tr>
                <td>6</td><td>Tunnel</td>
        </tr>
        <tr>
                <td>7</td><td>VE</td>
        </tr>
        <tr>
                <td>8-254</td><td>Unassigned</td>
        </tr>
        <tr>
                <td>255</td><td>Reserved</td>
        </tr>
        </tbody>
</table>
      </section>
      <section anchor="sect-9.7" numbered="true" toc="default">
        <name>Access-Mode Values</name>
        <t>
   Defined values of the Access-Mode field in the BAS Function TLV (see
   <xref target="sect-7.7"/>) target="sect-7.7" format="default"/>) are as follows:</t>

	<figure><artwork><![CDATA[
   Value   Meaning
   -----  ----------
       0  Layer 2 subscriber
       1  Layer 3 subscriber
       2  Layer
<table>
	<name>Access-Mode Values</name>
	<thead>
	<tr>
		<th>Value</th> <th>Meaning</th>
	</tr>
	</thead>
	<tbody>
	<tr>
		<td>0</td><td>Layer 2 subscriber</td>
	</tr>
	<tr>
		<td>1</td><td>Layer 3 subscriber</td>
	</tr>
	<tr>
		<td>2</td><td>Layer 2 leased line
       3  Layer line</td>
	</tr>
	<tr>
		<td>3</td><td>Layer 3 leased line
   4-254  unassigned
     255  reserved.
]]></artwork>
	</figure>
	</section>

	<section title="Access line</td>
	</tr>
	<tr>
		<td>4-254</td><td>Unassigned</td>
	</tr>
	<tr>
		<td>255</td><td>Reserved</td>
	</tr>
	</tbody>
</table>
      </section>
      <section anchor="sect-9.8" numbered="true" toc="default">
        <name>Access Method Bits" anchor="sect-9.8"><t> Bits</name>
        <t>
   Defined values of the Auth-Method4 and Auth-Method6 fields in the BAS
   Function TLV (see <xref target="sect-7.7"/>) target="sect-7.7" format="default"/>) are defined as bit fields as follows:</t>

	<figure><artwork><![CDATA[
    Auth-Method4
    Bit   Meaning
   ----  ---------
   0x01  PPPoE authentication
   0x02  DOT1X authentication
   0x04  Web authentication
   0x08  Web
<table>
	<name>Auth-Method4 Values</name>
	<thead>
	<tr>
		<th>Bit</th>
		<th>Meaning</th>
	</tr>
	</thead>
	<tbody>
	<tr>
		<td>0x01</td><td>PPPoE authentication</td>
	</tr>
	<tr>
		<td>0x02</td><td>DOT1X authentication</td>
	</tr>
	<tr>
		<td>0x04</td><td>Web authentication</td>
	</tr>
	<tr>
		<td>0x08</td><td>Web fast authentication
   0x10  Binding authentication
   0x20  reserved
   0x40  reserved
   0x80  reserved

    Auth-Method6
    Bit   Meaning
   ----  ---------
   0x01  PPPoE authentication
   0x02  DOT1X authentication
   0x04  Web authentication
   0x08  Web authentication</td>
	</tr>
	<tr>
		<td>0x10</td><td>Binding authentication</td>
	</tr>
	<tr>
		<td>0x20</td><td>Reserved</td>
	</tr>
	<tr>
		<td>0x40</td><td>Reserved</td>
	</tr>
	<tr>
		<td>0x80</td><td>Reserved</td>
	</tr>
	</tbody>
</table>

<table>
	<name>Auth-Method6 Values</name>
	<thead>
	<tr>
		<th>Bit</th>
		<th>Meaning</th>
	</tr>
	</thead>
	<tbody>
	<tr>
		<td>0x01</td><td>PPPoE authentication</td>
	</tr>
	<tr>
		<td>0x02</td><td>DOT1X authentication</td>
	</tr>
	<tr>
		<td>0x04</td><td>Web authentication</td>
	</tr>
	<tr>
		<td>0x08</td><td>Web fast authentication
   0x10  Binding authentication
   0x20  reserved
   0x40  reserved
   0x80  reserved
]]></artwork>
	</figure>
	</section>

	<section title="Route-Type Values" anchor="sect-9.9"><t> authentication</td>
	</tr>
	<tr>
		<td>0x10</td><td>Binding authentication</td>
	</tr>
	<tr>
		<td>0x20</td><td>Reserved</td>
	</tr>
	<tr>
		<td>0x40</td><td>Reserved</td>
	</tr>
	<tr>
		<td>0x80</td><td>Reserved</td>
	</tr>
	</tbody>
</table>
      </section>
      <section anchor="sect-9.9" numbered="true" toc="default">
        <name>Route-Type Values</name>
        <t>
   Values of the Route-Type field in the IPv4 and IPv6 Routing TLVs (see Sections
   <xref target="sect-7.8.1"/> target="sect-7.8.1" format="counter"/> and 7.8.2) <xref target="sect-7.8.2" format="counter"/>) defined in this document are as follows:</t>

	<figure><artwork><![CDATA[
    Value    Meaning
   -------  ---------
         0  User
<table>
	<name>Route-Type Values</name>
	<thead>
	<tr>
		<th>Value</th> <th>Meaning</th>
	</tr>
	</thead>
	<tbody>
	<tr>
		<td>0</td><td>User host route
         1  Radius route</td>
	</tr>
	<tr>
		<td>1</td><td>Radius authorization FrameRoute
         2  Network FrameRoute</td>
	</tr>
	<tr>
		<td>2</td><td>Network segment route
         3  Gateway route
         4  Radius route</td>
	</tr>
	<tr>
		<td>3</td><td>Gateway route</td>
	</tr>
	<tr>
		<td>4</td><td>Radius authorized IP route
         5  L2TP route</td>
	</tr>
	<tr>
		<td>5</td><td>L2TP LNS side user route
   6-65534  unassigned
     65535  reserved
]]></artwork>
	</figure>
	</section>

	<section title="Access-Type Values" anchor="sect-9.10"><t> route</td>
	</tr>
	<tr>
		<td>6-65534</td><td>Unassigned</td>
	</tr>
	<tr>
		<td>65535</td><td>Reserved</td>
	</tr>
	</tbody>
</table>
      </section>
      <section anchor="sect-9.10" numbered="true" toc="default">
        <name>Access-Type Values</name>
        <t>
   Values of the Access-Type field in the Basic Subscriber TLV (see
   <xref target="sect-7.9.1"/>) target="sect-7.9.1" format="default"/>) defined in this document are as follows:</t>

	<figure><artwork><![CDATA[
      Access-Type
    Value   Meaning
   ------   ----------
        0   reserved
        1   PPP
<table>
 <name>Access-Type Values</name>
 <thead>
   <tr>
      <th>Value</th><th>Meaning</th>
   </tr>
 </thead>
 <tbody>
   <tr>
       <td>0</td><td>Reserved</td>
   </tr>
   <tr>
       <td>1</td><td>PPP access (PPP [RFC1661])
        2   PPP <xref target="RFC1661" format="default"/>)</td>
   </tr>
   <tr>
       <td>2</td><td>PPP over Ethernet over ATM access (PPPoEoA)
        3   PPP (PPPoEoA)</td>
   </tr>
   <tr>
       <td>3</td><td>PPP over ATM access (PPPoA [RFC3336])
        4   PPP <xref target="RFC3336" format="default"/>)</td>
   </tr>
   <tr>
       <td>4</td><td>PPP over Ethernet access (PPPoE [RFC2516])
        5   PPPoE <xref target="RFC2516" format="default"/>)</td>
   </tr>
   <tr>
       <td>5</td><td>PPPoE over VLAN access (PPPoEoVLAN [RFC2516])
        6   PPP <xref target="RFC2516" format="default"/>)</td>
   </tr>
   <tr>
       <td>6</td><td>PPP over LNS access (PPPoLNS)
        7   IP (PPPoLNS)</td>
   </tr>
   <tr>
       <td>7</td><td>IP over Ethernet DHCP access (IPoE_DHCP)
        8   IP (IPoE_DHCP)</td>
   </tr>
   <tr>
       <td>8</td><td>IP over Ethernet EAP authentication access (IPoE_EAP)
        9   IP (IPoE_EAP)</td>
   </tr>
   <tr>
       <td>9</td><td>IP over Ethernet Layer 3 access (IPoE_L3)
       10   IP (IPoE_L3)</td>
   </tr>
   <tr>
       <td>10</td><td>IP over Ethernet Layer 2 Static access (IPoE_L2_STATIC)
       11   Layer (IPoE_L2_STATIC)</td>
   </tr>
   <tr>
       <td>11</td><td>Layer 2 Leased Line access (L2_Leased_Line)
       12   Layer (L2_Leased_Line)</td>
   </tr>
   <tr>
       <td>12</td><td>Layer 2 VPN Leased Line access (L2VPN_Leased_Line)
       13   Layer (L2VPN_Leased_Line)</td>
   </tr>
   <tr>
       <td>13</td><td>Layer 3 Leased Line access (L3_Leased_Line)
       14   Layer (L3_Leased_Line)</td>
   </tr>
   <tr>
       <td>14</td><td>Layer 2 Leased line Sub-User access
               (L2_Leased_Line_SUB_USER)
       15   L2TP
               (L2_Leased_Line_SUB_USER)</td>
   </tr>
   <tr>
       <td>15</td><td>L2TP LAC tunnel access (L2TP_LAC)
       16   L2TP (L2TP_LAC)</td>
   </tr>
   <tr>
       <td>16</td><td>L2TP LNS tunnel access (L2TP_LNS)
   17-254   unassigned
      255   reserved
]]></artwork>
	</figure> (L2TP_LNS)</td>
   </tr>
   <tr>
       <td>17-254</td><td>Unassigned</td>
   </tr>
   <tr>
       <td>255</td><td>Reserved</td>
   </tr>
 </tbody>
</table>
      </section>
    </section>
    <section title="IANA Considerations" anchor="sect-10"><t> anchor="sect-10" numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>
   This document requires has no IANA actions.</t>
    </section>
    <section title="Security Considerations" anchor="sect-11"><t> anchor="sect-11" numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>
   The Service, Control, and Management Interfaces between the CP and UP
   might be across the general Internet or other hostile environment.
   The ability of an adversary to block or corrupt messages or introduce
   spurious messages on any one or more of these interfaces would give
   the adversary the ability to stop subscribers from accessing network
   services, disrupt existing subscriber sessions, divert traffic, mess
   up accounting statistics, and generally cause havoc. Damage would not
   necessarily be limited to one or a few subscribers but could disrupt
   routing or deny service to one or more instances of the CP or
   otherwise cause extensive interference. If the adversary knows the
   details of the UP equipment and its forwarding rule capabilities, the
   adversary may be able to cause a copy of most or all user data to be
   sent to an address of the adversary's choosing, thus enabling
   eavesdropping.</t>
      <t>
   Thus, appropriate protections MUST <bcp14>MUST</bcp14> be implemented to provide
   integrity, authenticity, and secrecy of traffic over those
   interfaces. Whether such protection is used is a the decision of the network operator
   decision. operator.
   See <xref target="RFC6241"/> target="RFC6241" format="default"/> for Management Interface / NETCONF Mi/NETCONF security.
   Security on the Service Interface Si is dependent on the tunneling
   protocol used used, which is out of scope for this document.  Security for
   the Control Interface, Ci, over which the S-CUSP protocol flows, is
   further discussed below.</t>
      <t>
   S-CUSP messages do not provide security. Thus, if these messages are
   exchanged in an environment where security is a concern, that
   security MUST <bcp14>MUST</bcp14> be provided by another protocol such as TLS 1.3
   <xref target="RFC8446"/> target="RFC8446" format="default"/> or IPSEC. IPsec. TLS 1.3 is the mandatory to implement mandatory-to-implement protocol
   for interoperability. The use of a particular security protocol on
   the Control Interface Ci is determined by configuration. Such security
   protocols need not always be used used, and lesser security precautions
   might be appropriate because, in some cases, the communication
   between the CP and UP is in a benign environment.</t>
    </section>
  </middle>
  <back>
	<references title="Normative References">
	&RFC0020;
	&RFC0793;
	&RFC2119;
	&RFC2661;
	&RFC2865;
	&RFC6241;
	&RFC8174;

<displayreference target="RFC0020" to="RFC20"/>
<displayreference target="RFC0793" to="RFC793"/>
<displayreference target="IEEE-802.1Q" to="802.1Q"/>

    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.0020.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.0793.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2661.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2865.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6241.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
      </references>
	<references title="Informative References">
      <references>

        <name>Informative References</name>

<reference anchor="IEEE-802.1Q"><front> anchor="IEEE-802.1Q" >
  <front>
    <title>IEEE Standard for Local and metropolitan area networks / Bridges networks--Bridges and Bridged Networks</title>
    <author>
      <organization>IEEE</organization>
    </author>
  <date month="3" year="November 2013"/> month="July" year="2018" />
  </front>
  <seriesInfo name="IEEE" value="Std 802.1Q-2014"/> value="802.1Q-2018"/>
  <seriesInfo name="DOI" value="10.1109/IEEESTD.2018.8403927"/>
</reference>
	&RFC1661;
	&RFC2131;
	&RFC2516;
	&RFC2698;
	&RFC3022;
	&RFC3336;
	&RFC5511;
	&RFC7042;
	&RFC7348;
	&RFC7942;
	&RFC8446;

        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.1661.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2131.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2516.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2698.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3022.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3336.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5511.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7042.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7348.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8446.xml"/>

        <reference anchor="TR-384"><front> anchor="TR-384">
          <front>
            <title>Cloud Central Office Reference Architectural Framework</title>
            <seriesInfo name="BBF" value="TR-384"/>
            <author>
              <organization>Broadband Forum</organization>
            </author>
            <date month="January" year="2018"/>
          </front>

	<seriesInfo name="BBF" value="TR-384"/>
        </reference>

        <reference anchor="WT-459"><front> anchor="WT-459">
          <front>
            <title>Control and User Plane Separation for a Disaggregated BNG</title>
            <seriesInfo name="BBF" value="WT-459"/>
            <author>
              <organization>Broadband Forum</organization>
            </author>
            <date year="2019"/>
          </front>

	<seriesInfo name="BBF" value="WT-459"/>
        </reference>
      </references>
    </references>
    <section title="Acknowledgements" numbered="no" anchor="acknowledgements"><t> numbered="false" anchor="acknowledgements" toc="default">
      <name>Acknowledgements</name>
      <t>
   The helpful comments and suggestions of from the following individuals are hereby
   acknowledged:

	<list>
         <t>Loa Andersson</t>
         <t>Greg Mirsky</t>
	</list>

      </t>

	</section>

	<section title="Contributors" numbered="no" anchor="contributors"><figure><artwork><![CDATA[
   Zhenqiang Li
   China Mobile
   32
      <ul spacing="normal">
        <li><t><contact fullname="Loa Andersson"/></t></li>
        <li><t><contact fullname="Greg Mirsky"/></t></li>
      </ul>
    </section>

    <section numbered="false" anchor="contributors" toc="default">
      <name>Contributors</name>

      <contact fullname="Zhenqiang Li" >
        <organization>China Mobile</organization>
        <address>
          <postal>
            <street>32 Xuanwumen West Ave, Xicheng District
   Beijing, Beijing  100053
   China

   Email: lizhenqiang@chinamobile.com

   Mach (Guoyi) Chen
   Huawei Technologies
   Huawei Ave</street>
            <cityarea>Xicheng District</cityarea>
            <city>Beijing</city>
            <region></region><code>100053</code>
            <country>China</country>
          </postal>
          <email>lizhenqiang@chinamobile.com</email>
        </address>
	</contact>

      <contact fullname="Mach(Guoyi) Chen" >
        <organization>Huawei Technologies</organization>
        <address>
          <postal>
            <street>Huawei Bldg., No. 156 Beiqing Road
   Beijing 100095 China

   Email: mach.chen@huawei.com

   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.1 Road</street>
            <city>Beijing</city>
            <region></region><code>100095</code>
            <country>China</country>
          </postal>
          <email>mach.chen@huawei.com</email>
        </address>
	</contact>

      <contact fullname="Zhouyi Yu" >
        <organization>Huawei Technologies</organization>
        <address>
          <postal>
            <street></street>
            <city></city>
            <region></region><code></code>
            <country></country>
          </postal>
          <email>yuzhouyi@huawei.com</email>
        </address>
	</contact>

      <contact fullname="Chengguang Niu" >
        <organization>Huawei Technologies</organization>
        <address>
          <postal>
            <street></street>
            <city></city>
            <region></region><code></code>
            <country></country>
          </postal>
          <email>chengguang.niu@huawei.com</email>
        </address>
	</contact>

      <contact fullname="Zitao Wang" >
        <organization>Huawei Technologies</organization>
        <address>
          <postal>
            <street></street>
            <city></city>
            <region></region><code></code>
            <country></country>
          </postal>
          <email>wangzitao@huawei.com</email>
        </address>
	</contact>

      <contact fullname="Jun Song" >
        <organization>Huawei Technologies</organization>
        <address>
          <postal>
            <street></street>
            <city></city>
            <region></region><code></code>
            <country></country>
          </postal>
          <email>song.jun@huawei.com</email>
        </address>
	</contact>

      <contact fullname="Dan Meng" >
        <organization>H3C Technologies</organization>
        <address>
          <postal>
            <extaddr>No. 1 Lixing Center
   No.8 guangxun south street, Chaoyang District,
   Beijing, 100102
   China

   Email: mengdan@h3c.com

   Hanlei Liu
   H3C Technologies
   No.1 Center</extaddr>
            <street>No. 8 Guangxun South Street</street>
            <cityarea>Chaoyang District</cityarea>
            <city>Beijing</city>
            <region></region><code>100102</code>
            <country>China</country>
          </postal>
          <email>mengdan@h3c.com</email>
        </address>
	</contact>

      <contact fullname="Hanlei Liu" >
        <organization>H3C Technologies</organization>
        <address>
          <postal>
            <extaddr>No. 1 Lixing Center
   No.8 guangxun south street, Chaoyang District,
   Beijing, 100102
   China

   Email: hanlei_liu@h3c.com

   Victor Lopez
   Telefonica
   Spain

   Email: victor.lopezalvarez@telefonica.com
]]></artwork>
	</figure> Center</extaddr>
            <street>No. 8 Guangxun South Street</street>
            <cityarea>Chaoyang District</cityarea>
            <city>Beijing</city>
            <region></region><code>100102</code>
            <country>China</country>
          </postal>
          <email>hanlei_liu@h3c.com</email>
        </address>
	</contact>

      <contact fullname="Victor Lopez" >
        <organization>Telefonica</organization>
        <address>
          <postal>
            <street></street>
            <city></city>
            <region></region><code></code>
            <country>Spain</country>
          </postal>
          <email>victor.lopezalvarez@telefonica.com</email>
        </address>
	</contact>

    </section>
  </back>
</rfc>