rfc8772xml2.original.xml   rfc8772.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC0020 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.0020.xml">
<!ENTITY RFC0793 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.0793.xml">
<!ENTITY RFC2119 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.2119.xml">
<!ENTITY RFC2661 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.2661.xml">
<!ENTITY RFC2865 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.2865.xml">
<!ENTITY RFC6241 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.6241.xml">
<!ENTITY RFC8174 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.8174.xml">
<!ENTITY RFC1661 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.1661.xml">
<!ENTITY RFC2131 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.2131.xml">
<!ENTITY RFC2516 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.2516.xml">
<!ENTITY RFC2698 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.2698.xml">
<!ENTITY RFC3022 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.3022.xml">
<!ENTITY RFC3336 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.3336.xml">
<!ENTITY RFC5511 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.5511.xml">
<!ENTITY RFC7042 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.7042.xml">
<!ENTITY RFC7348 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.7348.xml">
<!ENTITY RFC7942 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.7942.xml">
<!ENTITY RFC8446 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.8446.xml">
]>
<rfc submissionType="IETF" docName="draft-chz-simple-cu-separation-bng-protocol-
06" 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: Expec
ted
an expires indication top left, found none
--><?rfc toc="yes"?>
<front>
<title abbrev="Simple BNG CUSP">The China Mobile, Huawei, and ZTE BNG Sim
ple Control and User Plane Separation Protocol (S-CUSP)</title>
<author fullname="Shujun Hu" initials="S." surname="Hu">
<organization>China Mobile</organization>
<address><postal><street>32 Xuanwumen West Ave, Xicheng District</street>
<street>Beijing, Beijing 100053</street>
<street>China</street>
</postal>
<email>hushujun@chinamobile.com</email>
</address>
</author>
<author fullname="Donald Eastlake, 3rd" initials="D." surname="Eastlake"> <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<organization>Futurewei Technologies</organization>
<address><postal><street>2386 Panoramic Circle</street>
<street>Apopka, FL 32703</street>
<street>USA</street>
</postal>
<phone>+1-508-333-2270</phone>
<email>d3e3e3@gmail.com</email>
</address>
</author>
<author fullname="Fengwei Qin" initials="F." surname="Qin"> <rfc xmlns:xi="http://www.w3.org/2001/XInclude"
<organization>China Mobile</organization> submissionType="independent"
<address><postal><street>32 Xuanwumen West Ave, Xicheng District</street> docName="draft-chz-simple-cu-separation-bng-protocol-06"
<street>Beijing, Beijing 100053</street> number="8772"
<street>China</street> category="info"
</postal> ipr="trust200902"
<email>qinfengwei@chinamobile.com</email> obsoletes=""
</address> updates=""
</author> xml:lang="en"
sortRefs="false"
symRefs="true"
tocInclude="true"
version="3">
<author fullname="Tee Mong Chua" initials="T." surname="Chua"> <front>
<organization abbrev="Singapore Telecommunications">Singapore Telecommuni <title abbrev="Simple BNG CUSP">The China Mobile, Huawei, and ZTE Broadband
cations Limited</organization> Network Gateway (BNG) Simple Control and User Plane Separation Protocol (S-CUSP)
<address><postal><street>31 Exeter Road, #05-04 Comcentre Podium Block</s </title>
treet> <seriesInfo name="RFC" value="8772" />
<street>Singapore City 239732</street>
<street>Singapore</street>
</postal>
<email>teemong@singtel.com</email>
</address>
</author>
<author fullname="Daniel Huang" initials="D." surname="Huang"> <author fullname="Shujun Hu" initials="S." surname="Hu">
<organization>ZTE</organization> <organization>China Mobile</organization>
<address><email>huang.guangping@zte.com.cn</email> <address>
</address> <postal>
</author> <street>32 Xuanwumen West Ave</street>
<cityarea>Xicheng District</cityarea>
<city>Beijing</city><code> 100053</code>
<country>China</country>
</postal>
<email>hushujun@chinamobile.com</email>
</address>
</author>
<date month="January" year="2020"/> <author fullname="Donald Eastlake 3rd" initials="D." surname="Eastlake 3rd">
<abstract><t> <organization>Futurewei Technologies</organization>
A Broadband Network Gateway (BNG) in a fixed wireline access network <address>
is an Ethernet-centric IP edge router and the aggregation point for <postal>
subscriber traffic. Control Plane (CP) and User Plane (UP) Separation <street>2386 Panoramic Circle</street>
(CUPS) for such a BNG improves flexibility and scalability but <city>Apopka</city> <region>FL</region> <code> 32703</code>
requires various communication between the UP and the CP. China <country>US</country>
Mobile, Huawei Technologies, and ZTE have developed a simple CUPS </postal>
control channel Protocol (S-CUSP) to support such communication.</t> <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 Xuanwumen West 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 Telecommunic
ations Limited</organization>
<address>
<postal>
<street>31 Exeter Road, #05-04 Comcentre Podium Block</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>
</author>
<date month="May" year="2020"/>
<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 and User Plane Separation (CUPS) for such a BNG improves
flexibility and scalability but requires various communication between the
User Plane (UP) and the Control Plane (CP). China Mobile, Huawei
Technologies, and ZTE have developed a simple CUPS control channel protocol
to support such 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 This document is not an IETF standard and does not have IETF
consensus. S-CUSP is presented here to make its specification consensus. S-CUSP is presented here to make its specification
conveniently available to the Internet community to enable diagnosis conveniently available to the Internet community to enable diagnosis
and interoperability.</t> and interoperability.</t>
</abstract>
</abstract> </front>
</front> <middle>
<section anchor="sect-1" numbered="true" toc="default">
<middle> <name>Introduction</name>
<section title="Introduction" anchor="sect-1"><t> <t>
A Broadband Network Gateway (BNG) in a fixed wireline access network A Broadband Network Gateway (BNG) in a fixed wireline access network is an
is an Ethernet-centric IP edge router, and the aggregation point for Ethernet-centric IP edge router and the aggregation point for subscriber
subscriber traffic. To provide centralized session management, traffic. To provide centralized session management, flexible address
flexible address allocation, high scalability for subscriber allocation, high scalability for subscriber management capacity, and
management capacity, and cost-efficient redundancy, the Control/User cost-efficient redundancy, the CU-separated (CP/UP-separated) BNG framework i
(CU) separated BNG framework is described in technical report s
<xref target="TR-384"/> from the Broadband Forum (BBF). The CU separated serv described in a technical report <xref target="TR-384" format="default"/>
ice from the Broadband Forum (BBF). The CU-separated service CP, which is
Control Plane (CP), which is responsible for user access responsible for user access authentication and setting forwarding entries
authentication and setting forwarding entries in User Planes (UPs), in UPs, can be virtualized and centralized. The routing
can be virtualized and centralized. The routing control and control and forwarding plane, i.e., the BNG UP (local), can be distributed
forwarding plane, i.e., the BNG user plane (local), can be across the infrastructure. Other structures can also be supported, such as
distributed across the infrastructure. Other structures can also be the CP and UP being virtual or both being physical.</t>
supported such as both CP and UP being virtual or both being <t>
physical.</t>
<t>
Note: In this document, the terms "user" and "subscriber" are used Note: In this document, the terms "user" and "subscriber" are used
interchangeably.</t> interchangeably.</t>
<t>
<t> This document specifies the Simple CU Separation Protocol (S-CUSP) for
This document specifies the Simple CU Separation BNG control channel communications over the BNG control channel between a BNG CP
Protocol (S-CUSP) for communications between a BNG Control Plane (CP) and a set of UPs. S-CUSP is designed to be flexible
and a set of User Planes (UPs). S-CUSP is designed to be flexible
and extensible so as to allow for easy addition of messages and data and extensible so as to allow for easy addition of messages and data
items, should further requirements be expressed in the future.</t> items, should further requirements be expressed in the future.</t>
<t>
<t>
This document is not an IETF standard and does not have IETF This document is not an IETF standard and does not have IETF
consensus. S-CUSP was designed by China Mobile, Huawei Technologies, consensus. S-CUSP was designed by China Mobile, Huawei Technologies,
and ZTE. It is presented here to make the S-CUSP specification and ZTE. It is presented here to make the S-CUSP specification
conveniently available to the Internet community to enable diagnosis conveniently available to the Internet community to enable diagnosis
and interoperability.</t> and interoperability.</t>
<t>
<t> At the time of writing this document, the BBF is
At the time of writing this document, the Broadband Forum (BBF) is working to produce <xref target="WT-459" format="default"/>, which will descr
working to produce <xref target="WT-459"/> that will describe an architecture ibe an architecture and
and requirements for a CP and UP separation of a
requirements for a control and user plane separation of a
disaggregated BNG. Future work may attempt to show how the protocol disaggregated BNG. Future work may attempt to show how the protocol
described in this document addresses those requirements and may described in this document addresses those requirements and may
modify this specification to handle unaddressed requirements.</t> modify this specification to handle unaddressed requirements.</t>
</section>
</section> <section anchor="sect-2" numbered="true" toc="default">
<name>Terminology</name>
<section title="Terminology" anchor="sect-2"><t> <t>
This section specifies implementation requirement keywords and terms This section specifies implementation requirement keywords and terms
used in this document. S-CUSP messages are described in this document used in this document. S-CUSP messages are described in this document
using Routing Backus-Naur Form (RBNF) as defined in <xref target="RFC5511"/>. using Routing Backus-Naur Form (RBNF) as defined in <xref target="RFC5511" fo
</t> rmat="default"/>.</t>
<section anchor="sect-2.1" numbered="true" toc="default">
<section title="Implementation Requirement Keywords" anchor="sect-2.1"><t <name>Implementation Requirement Keywords</name>
> <t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
"OPTIONAL" in this document are to be interpreted as described in BCP NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, the RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
y appear in all "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
capitals, as shown here.</t> be interpreted as
described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
</section> when, and only when, they appear in all capitals, as shown here.
</t>
<section title="Terms" anchor="sect-2.2"><t> </section>
<section anchor="sect-2.2" numbered="true" toc="default">
<name>Terms</name>
<t>
This section specifies terms used in this document.</t> This section specifies terms used in this document.</t>
<dl newline="false" spacing="normal" indent="13">
<t><list style="hanging" hangIndent="3"> <dt>AAA:</dt>
<dd> Authentication Authorization Accounting.</dd>
<t hangText="AAA:"> Authentication Authorization Accounting.</t> <dt>ACK:</dt>
<dd> Acknowledgement message.</dd>
<t hangText="ACK:"> Acknowledgement message.</t> <dt>BAS:</dt>
<dd> Broadband Access Server, also known as a BBRAS, BNG, or BRAS.</dd
<t hangText="BAS:"> Broadband Access Server (BRAS, BNG).</t> >
<dt>BNG:</dt>
<t hangText="BNG:"> Broadband Network Gateway. A broadband remote <dd> Broadband Network Gateway. A BNG (or Broadband Remote Access
access server"> (BRAS (BRoadband Access Server), B-RAS or BBRAS) Server (BRAS)) routes traffic to and from broadband remote
routes traffic to and from broadband remote access devices such as access devices such as digital subscriber line access
digital subscriber line access multiplexers (DSLAM) on an Internet multiplexers (DSLAM) on an Internet Service Provider's (ISP)
Service Provider's (ISP) network. BRAS can also be referred to as a network. BNG / BRAS can also be referred to as a BAS or BBRAS.</dd>
Broadband Network Gateway (BNG).</t> <dt>BRAS:</dt>
<dd> Broadband Remote Access Server, also known as a BAS, BBRAS, or BN
<t hangText="BRAS:"> BRoadband Access Server (BNG).</t> G.</dd>
<dt>CAR:</dt>
<t hangText="CAR:"> Committed Access Rate.</t> <dd> Committed Access Rate.</dd>
<dt>CBS:</dt>
<t hangText="CBS:"> Committed Burst Size.</t> <dd> Committed Burst Size.</dd>
<dt>CGN:</dt>
<t hangText="CGN:"> Carrier Grade NAT.</t> <dd> Carrier Grade NAT.</dd>
<dt>Ci:</dt>
<t hangText="Ci:"> Control Interface.</t> <dd> Control Interface.</dd>
<dt>CIR:</dt>
<t hangText="CIR:"> Committed Information Rate.</t> <dd> Committed Information Rate.</dd>
<dt>CoA:</dt>
<t hangText="CoA:"> Change of Authorization.</t> <dd> Change of Authorization.</dd>
<dt>CP:</dt>
<t hangText="CP:"> Control Plane. CP is a user control management <dd> Control Plane. CP is a user control management
component which supports the management of the UP's resources such as component that supports the management of the UP's resources such as
the user entry and forwarding policy.</t> the user entry and forwarding policy.</dd>
<dt>CU:</dt>
<t hangText="CPE:"> Customer Premises Equipment.</t> <dd> Control Plane / User Plane.</dd>
<dt>CUSP:</dt>
<t hangText="CU:"> Control-plane / User-plane.</t> <dd> Control and User Plane Separation Protocol.</dd>
<dt>DEI:</dt>
<t hangText="CUSP:"> Control and User plane Separation Protocol.</t> <dd> Drop Eligibility Indicator as defined in
<xref target="IEEE-802.1Q" format="default"/>. A bit in a VLAN
<t hangText="DEI:"> Drop Eligibility Indicator. A bit in a VLAN tag tag after the priority and before the VLAN ID. (This bit was formerly
after the priority and before the VLAN ID. (This bit was formerly the the CFI (Canonical Format Indicator).)</dd>
CFI (Canonical Format Indicator).) <xref target="IEEE-802.1Q"/></t> <dt>DHCP:</dt>
<dd> Dynamic Host Configuration Protocol <xref target="RFC2131" format
<t hangText="DHCP:"> Dynamic Host Configuration Protocol <xref ="default"/>.</dd>
target="RFC2131"/>.</t> <dt>dial-up:</dt>
<dd> This refers to the initial connection messages
<t hangText="dial-up:"> This refers to the initial connection messages
when a new subscriber appears. The name is left over from when when a new subscriber appears. The name is left over from when
subscribers literally dialed up on a modem equipped phone line but subscribers literally dialed up on a modem-equipped phone line but
herein is applied to other initial connection techniques. Initial herein is applied to other initial connection techniques. Initial
connection is frequently indicated by the receipt of packets over connection is frequently indicated by the receipt of packets over
PPPoE <xref target="RFC2516"/> or IPoE.</t> PPPoE <xref target="RFC2516" format="default"/> or IPoE.</dd>
<dt>EMS:</dt>
<t hangText="EMS:"> Element Management System.</t> <dd> Element Management System.</dd>
<dt>IPoE:</dt>
<t hangText="IPoE:"> IP over Ethernet.</t> <dd> IP over Ethernet.</dd>
<dt>L2TP:</dt>
<t hangText="L2TP:"> Layer 2 Tunneling Protocol <xref <dd> Layer 2 Tunneling Protocol <xref target="RFC2661" format="default
target="RFC2661"/>.</t> "/>.</dd>
<dt>LAC:</dt>
<t hangText="LAC:"> L2TP Access Concentrator.</t> <dd> L2TP Access Concentrator.</dd>
<dt>LNS:</dt>
<t hangText="LNS:"> L2TP Network Server.</t> <dd> L2TP Network Server.</dd>
<dt>MAC:</dt>
<t hangText="MAC:"> 48-bit Media Access Control address <xref <dd> 48-bit Media Access Control address <xref target="RFC7042" format
target="RFC7042"/>.</t> ="default"/>.</dd>
<dt>MANO:</dt>
<t hangText="MANO:"> Management and Orchestration.</t> <dd> Management and Orchestration.</dd>
<dt>Mi:</dt>
<t hangText="Mi:"> Management Interface.</t> <dd> Management Interface.</dd>
<dt>MSS:</dt>
<t hangText="MSS:"> Maximum Segment Size.</t> <dd> Maximum Segment Size.</dd>
<dt>MRU:</dt>
<t hangText="MRU:"> Maximum Receive Unit.</t> <dd> Maximum Receive Unit.</dd>
<dt>NAT:</dt>
<t hangText="NAT:"> Network Address Translation <xref <dd> Network Address Translation <xref target="RFC3022" format="defaul
target="RFC3022"/>.</t> t"/>.</dd>
<dt>ND:</dt>
<t hangText="ND:"> Neighbor Discovery.</t> <dd> Neighbor Discovery.</dd>
<dt>NFV:</dt>
<t hangText="NFV:"> Network Function Virtualization.</t> <dd> Network Function Virtualization.</dd>
<dt>NFVI:</dt>
<t hangText="NFVI:"> NFV Infrastructure</t> <dd> NFV Infrastructure.</dd>
<dt>PBS:</dt>
<t hangText="PBS:"> Peak Burst Size.</t> <dd> Peak Burst Size.</dd>
<dt>PD:</dt>
<t hangText="PD:"> Prefix Delegation.</t> <dd> Prefix Delegation.</dd>
<dt>PIR:</dt>
<t hangText="PIR:"> Peak Information Rate.</t> <dd> Peak Information Rate.</dd>
<dt>PPP:</dt>
<t hangText="PPP:"> Point to Point Protocol <xref <dd> Point-to-Point Protocol <xref target="RFC1661" format="default"/>
target="RFC1661"/>.</t> .</dd>
<dt>PPPoE:</dt>
<t hangText="PPPoE:"> PPP over Ethernet <xref target="RFC2516"/>.</t> <dd> PPP over Ethernet <xref target="RFC2516" format="default"/>.</dd>
<dt>RBNF:</dt>
<t hangText="RBNF:"> Routing Backus-Naur Form <xref <dd> Routing Backus-Naur Form <xref target="RFC5511" format="default"/
target="RFC5511"/>.</t> >.</dd>
<dt>RG:</dt>
<t hangText="RG:"> Residential Gateway.</t> <dd> Residential Gateway.</dd>
<dt>S-CUSP:</dt>
<t hangText="S-CUSP:"> Simple Control and User Plane Separation <dd> Simple Control and User Plane Separation Protocol.</dd>
Protocol.</t> <dt>Subscriber:</dt>
<dd> The remote user gaining network accesses
<t hangText="Subscriber:"> The remote user gaining network accesses via a BNG.</dd>
via a BNG.</t> <dt>Si:</dt>
<dd> Service Interface.</dd>
<t hangText="Si:"> Service Interface.</t> <dt>TLV:</dt>
<dd> Type-Length-Value. See Sections <xref target="sect-7.1" format="
<t hangText="TLV:"> Type, Length, Value. See Sections 7.1 and 7.3.</t> counter"/> and <xref target="sect-7.3" format="counter"/>.</dd>
<dt>UP:</dt>
<t hangText="UP:"> User Plane. UP is a network edge and user policy <dd> User Plane. UP is a network edge and user policy
implementation component. The traditional router's Control Plane and implementation component. The traditional router's control plane and
Forwarding Plane are both preserved on BNG devices in the form of a forwarding plane are both preserved on BNG devices in the form of a
user plane.</t> user plane.</dd>
<dt>URPF:</dt>
<t hangText="URPF:"> Unicast Reverse Path Forwarding.</t> <dd> Unicast Reverse Path Forwarding.</dd>
<dt>User:</dt>
<t hangText="User:"> Equivalent to "customer" or "subscriber".</t> <dd> Equivalent to "customer" or "subscriber".</dd>
<dt>VRF:</dt>
<t hangText="VRF:"> Virtual Routing and Forwarding.</t> <dd> Virtual Routing and Forwarding.</dd>
</dl>
</list> </section>
</t> </section>
<section anchor="sect-3" numbered="true" toc="default">
</section> <name>BNG CUPS Overview</name>
<section anchor="sect-3.1" numbered="true" toc="default">
</section> <name>BNG CUPS Motivation</name>
<t>
<section title="BNG CUPS Overview" anchor="sect-3"><section title="BNG CU The rapid development of new services, such as 4K TV, Internet of Things (IoT
PS Motivation" anchor="sect-3.1"><t> ), etc., and
The rapid development of new services, such as 4K TV, IoT, etc., and
increasing numbers of home broadband service users present some new increasing numbers of home broadband service users present some new
challenges for BNGs such as:</t> challenges for BNGs such as:</t>
<dl newline="false" spacing="normal" indent="3">
<t><list style="hanging" hangIndent="3"><t hangText="Low resource <dt>Low resource utilization:</dt>
utilization:"> The traditional BNG acts as both a gateway for user <dd> The traditional BNG acts as both a gateway for user
access authentication and accounting and an IP network's Layer 3 access authentication and accounting and also an IP network's Layer 3
edge. The mutually affecting nature of the tightly coupled control edge. The mutually affecting nature of the tightly coupled control
plane and forwarding plane makes it difficult to achieve the maximum plane and forwarding plane makes it difficult to achieve the maximum
performance of either plane. performance of either plane.
</t> </dd>
<dt>Complex management and maintenance:</dt>
<t hangText="Complex management and maintenance:"> Due to the large <dd> Due to the large
numbers of traditional BNGs, configuring each device in a network is numbers of traditional BNGs, configuring each device in a network is
very tedious when deploying global service policies. As the network very tedious when deploying global service policies. As the network
expands and new services are introduced, this deployment mode will expands and new services are introduced, this deployment mode will
cease to be feasible as it is unable to manage services effectively cease to be feasible as it is unable to manage services effectively
and rectify faults rapidly. and to rectify faults rapidly.
</t> </dd>
<dt>Slow service provisioning:</dt>
<t hangText="Slow service provisioning:"> The coupling of control <dd> The coupling of the CP and the forwarding plane, in addition to b
plane and forwarding plane, in addition to a distributed network eing a distributed network
control mechanism, means that any new technology has to rely heavily control mechanism, means that any new technology has to rely heavily
on the existing network devices. on the existing network devices.
</t> </dd>
</dl>
</list> <t>
</t> The framework for a cloud-based BNG with
CU separation to address these challenges for fixed networks is
<t> described in <xref target="TR-384" format="default"/>. The main idea of CU s
The framework for a cloud-based BNG with Control Plane and User Plane eparation is to extract
(CU) separation to address these challenges for fixed networks is
described in <xref target="TR-384"/>. The main idea of CU separation is to e
xtract
and centralize the user management functions of multiple BNG devices, and centralize the user management functions of multiple BNG devices,
forming a unified and centralized Control Plane (CP). And the forming a unified and centralized CP. The
traditional router's Control Plane and Forwarding Plane are both traditional router's CP and forwarding plane are both
preserved on BNG devices in the form of a User Plane (UP).</t> preserved on BNG devices in the form of a UP.</t>
</section>
</section> <section anchor="sect-3.2" numbered="true" toc="default">
<name>BNG CUPS Architecture Overview</name>
<section title="BNG CUPS Architecture Overview" anchor="sect-3.2"><t>
The functions in a traditional BNG can be divided into two parts: one
is the user access management function, the other is the router
function. The user 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 and forwarding
engine, can be deployed in the form of the BNG User Plane (BNG-UP).</t>
<t> <t>
The following figure shows the architecture of CU separated BNG:</t> The functions in a traditional BNG can be divided into two parts:
(1) the user access management function and (2) the routing
<figure title="Architecture of CU Separated BNG" anchor="fig1"><artwork>< function. The user access management function can be deployed as
![CDATA[ a centralized module or device, called the BNG Control Plane
(BNG-CP). The routing function, which includes routing control
and the forwarding engine, can be deployed in the form of the BNG
User Plane (BNG-UP).
</t>
<t>
<xref target="fig1" format="default"/> shows the architecture of a CU-separa
ted BNG:</t>
<figure anchor="fig1">
<name>Architecture of a CU-Separated BNG</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
+------------------------------------------------------------------+ +------------------------------------------------------------------+
| Neighboring policy and resource management systems | | Neighboring policy and resource management systems |
| | | |
| +-------------+ +-----------+ +---------+ +----------+ | | +-------------+ +-----------+ +---------+ +----------+ |
| |AAA Server| |DHCP Server| | EMS | | MANO | | | | AAA Server | |DHCP Server| | EMS | | MANO | |
| +-------------+ +-----------+ +---------+ +----------+ | | +-------------+ +-----------+ +---------+ +----------+ |
+------------------------------------------------------------------+ +------------------------------------------------------------------+
+------------------------------------------------------------------+ +------------------------------------------------------------------+
| CU-separated BNG system | | CU-separated BNG system |
| +--------------------------------------------------------------+ | | +--------------------------------------------------------------+ |
| | +----------+ +----------+ +------++------++-----------+ | | | | +----------+ +----------+ +------++------++-----------+ | |
| | | Address | |Subscriber| | AAA ||Access|| UP | | | | | | Address | |Subscriber| | AAA ||Access|| UP | | |
| | |management| |management| | || Mgt ||management | | | | | |management| |management| | || mgt ||management | | |
| | +----------+ +----------+ +------++------++-----------+ | | | | +----------+ +----------+ +------++------++-----------+ | |
| | CP | | | | CP | |
| +--------------------------------------------------------------+ | | +--------------------------------------------------------------+ |
| | | |
| | | |
| | | |
| +---------------------------+ +--------------------------+ | | +---------------------------+ +--------------------------+ |
| | +------------------+ | | +------------------+ | | | | +------------------+ | | +------------------+ | |
| | | Routing control | | | | Routing control | | | | | | Routing control | | | | Routing control | | |
| | +------------------+ | ... | +------------------+ | | | | +------------------+ | ... | +------------------+ | |
| | +------------------+ | | +------------------+ | | | | +------------------+ | | +------------------+ | |
| | |Forwarding engine | | | |Forwarding engine | | | | | |Forwarding engine | | | |Forwarding engine | | |
| | +------------------+ UP | | +------------------+ UP| | | | +------------------+ UP | | +------------------+ UP| |
| +---------------------------+ +--------------------------+ | | +---------------------------+ +--------------------------+ |
+------------------------------------------------------------------+ +------------------------------------------------------------------+
]]></artwork> ]]></artwork>
</figure> </figure>
<t> <t>
As shown in <xref target="fig1"/>, the BNG Control Plane could be As shown in <xref target="fig1" format="default"/>, the BNG-CP could be
virtualized and centralized, which provides benefits such as centralized virtualized and centralized, which provides benefits such as centralized
session management, flexible address allocation, high scalability for session management, flexible address allocation, high scalability for
subscriber management capacity, and cost-efficient redundancy, etc. The subscriber management capacity, cost-efficient redundancy, etc. The
functional components inside the BNG Service Control Plane can be functional components inside the BNG-CP can be implemented as
implemented as Virtual Network Functions (VNFs) and hosted in a Network Virtual Network Functions (VNFs) and hosted in an NFVI.</t>
Function Virtualization Infrastructure (NFVI).</t> <t>
The UP management module in the BNG-CP centrally manages
<t> the distributed BNG-UPs (e.g., load balancing), as well as the
The User Plane Management module in the BNG Control Plane centrally manages setup, deletion, and maintenance of channels between CPs and
the distributed BNG User Planes (e.g., load balancing), as well as the UPs. Other modules in the BNG-CP, such as address
setup, deletion, and maintenance of channels between Control Planes and
User Planes. Other modules in the BNG control plane, such as address
management, AAA, etc., are responsible for the connection with external management, AAA, etc., are responsible for the connection with external
subsystems in order to fulfill those services. Note that the User Plane subsystems in order to fulfill those services. Note that the UP
SHOULD support both physical and virtual network functions. For example, <bcp14>SHOULD</bcp14> support both physical and virtual network functions. Fo
BNG user plane L3 forwarding related network functions can be disaggregated r example,
and distributed across the physical infrastructure. And the other control network functions related to BNG-UP L3 forwarding can be disaggregated
plane and management plane functions in the CU Separation BNG can be moved and distributed across the physical infrastructure, and the other CP
into the NFVI for virtualization <xref target="TR-384"/>.</t> management functions in the CU-separated BNG can be moved
into the NFVI for virtualization <xref target="TR-384" format="default"/>.</t
<t> >
The details of CU separated BNG's function components are as following:</t> <t>
The details of the CU-separated BNG's function components are as follows:</t>
<t> <t>
The Control Plane is responsible for the following:</t> The CP is responsible for the following:</t>
<t><list style="hanging" hangIndent="3"><t hangText="Address <ul spacing="normal">
management:"> unified address pool management and CGN subscriber <li>Address management: Unified address pool management and CGN subsc
riber
address traceability management. address traceability management.
</t> </li>
<li>AAA: This component performs Authentication,
<t hangText="AAA:"> This component performs Authentication, Authorization, and Accounting, together with RADIUS/Diameter. The BNG
Authorization and Accounting, together with RADIUS/DIAMETER. The BNG
communicates with the AAA server to check whether the subscriber who communicates with the AAA server to check whether the subscriber who
sent an Access-Request has network access authority. Once the sent an access request has network access authority. Once the
subscriber goes online, this component together with the Service subscriber goes online, this component (together with the Service
Control component implement accounting, data capacity limitation, and Control component) implements accounting, data capacity limitation, and
QoS enforcement policies. QoS enforcement policies.
</t> </li>
<li>Subscriber management: User entry management and
<t hangText="Subscriber management:"> user entry management and
forwarding policy management. forwarding policy management.
</t> </li>
<li>Access management: Process user dial-up packets, such
<t hangText="Access management:"> process user dial-up packets, such
as PPPoE, DHCP, L2TP, etc. as PPPoE, DHCP, L2TP, etc.
</t> </li>
<li>UP management: Management of UP interface status and
<t hangText="UP management:"> management of UP interface status, and
the setup, deletion, and maintenance of channels between CP and UP. the setup, deletion, and maintenance of channels between CP and UP.
</t> </li>
</ul>
</list>
</t>
<t>
The User Plane is responsible for the following:</t>
<t><list style="hanging" hangIndent="3"><t hangText="Routing control <t>
functions:"> responsible for constructing routing forwarding plane The UP is responsible for the following:</t>
<ul spacing="normal">
<li>Routing control functions: Responsible for instantiating routing f
orwarding plane
(e.g., routing, multicast, MPLS, etc.). (e.g., routing, multicast, MPLS, etc.).
</t> </li>
<li>Routing and service forwarding plane functions: Responsibilities
<t hangText="Routing and Service Forwarding plane functions:"> include traffic forwarding, QoS, and traffic statistics collection.
responsible including traffic forwarding, QoS and traffic statistics </li>
collection. <li>Subscriber detection: Responsible for detecting whether
</t>
<t hangText="Subscriber detection:"> responsible for detecting whether
a subscriber is still online. a subscriber is still online.
</t> </li>
</ul>
</list> </section>
</t> <section anchor="sect-3.3" numbered="true" toc="default">
<name>BNG CUPS Interfaces</name>
</section> <t>
The three interfaces defined below support the communication between the
<section title="BNG CUPS Interfaces" anchor="sect-3.3"><t> CP and UP. These are referred to as the Service
Three interfaces defined below support the communication between the
Control Plane and User Plane. These are referred to as the Service
Interface (Si), Control Interface (Ci), and Management Interface (Mi) Interface (Si), Control Interface (Ci), and Management Interface (Mi)
as shown in <xref target="fig2"/>.</t> as shown in <xref target="fig2" format="default"/>.</t>
<figure anchor="fig2">
<figure title="Interfaces Between the CP and UP of the BNG" anchor="fig2" <name>Interfaces between the CP and UP of the BNG</name>
><artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
+-----------------------------------+ +-----------------------------------+
| | | |
| BNG-CP | | BNG-CP |
| | | |
+--+--------------+--------------+--+ +--+--------------+--------------+--+
| | | | | |
1. Service | 2. Control | 3. Management| 1. Service | 2. Control | 3. Management|
Interface | Interface | Interface | Interface | Interface | Interface |
(Si) | (Ci) | (Mi) | (Si) | (Ci) | (Mi) |
| | | | | |
skipping to change at line 488 skipping to change at line 460
| (___ ___) | | (___ ___) |
| (_______) | | (_______) |
| | | | | |
| | | | | |
+--+--------------+--------------+--+ +--+--------------+--------------+--+
| | | |
| BNG-UP | | BNG-UP |
| | | |
+-----------------------------------+ +-----------------------------------+
]]></artwork> ]]></artwork>
</figure> </figure>
<section title="Service Interface" anchor="sect-3.3.1"><t> <section 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 For a traditional BNG (without CU separation), the user dial-up
signals are terminated and processed by the control plane of a BNG. signals are terminated and processed by the CP of a BNG.
When the CP and UP of a BNG are separated, there needs to be a way to 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> relay these signals between the CP and the UP.</t>
<t>
<t> The Si is used to establish tunnels between the
The Service Interface (Si) is used to establish tunnels between the CP and UP. The tunnels are responsible for relaying the PPPoE-, IPoE-,
CP and UP. The tunnels are responsible for relaying the PPPoE, IPoE, and L2TP-related control packets that are received from a Residential
and L2TP related control packets that are received from a Residential Gateway (RG) over those tunnels. An appropriate tunnel type is
Gateway (RG) over those tunnels. An appropriate tunnel type is VXLAN Virtual eXtensible Local Area Network (VXLAN)
<xref target="RFC7348"/>.</t> <xref target="RFC7348" format="default"/>.</t>
<t>
<t>
The detailed definition of Si is out of scope for this document.</t> The detailed definition of Si is out of scope for this document.</t>
</section>
</section> <section anchor="sect-3.3.2" numbered="true" toc="default">
<name>Control Interface (Ci)</name>
<section title="Control Interface" anchor="sect-3.3.2"><t> <t>
The CP uses the Control Interface to deliver subscriber session The CP uses the Ci to deliver subscriber session
states, network routing entries, etc. to the UP (see <xref target="sect-6.2.7 states, network routing entries, etc., to the UP (see <xref target="sect-6.2.
"/>). 7" format="default"/>).
The UP uses this interface to report subscriber service statistics, The UP uses this interface to report subscriber service statistics,
subscriber detection results, etc. to the CP (see Sections 6.3 and subscriber detection results, etc., to the CP (see Sections <xref target="sec
6.4). A carrying protocol for this interface is specified in this t-6.3" format="counter"/> and
<xref target="sect-6.4" format="counter"/>). A carrying protocol for this int
erface is specified in this
document.</t> document.</t>
</section>
</section> <section anchor="sect-3.3.3" numbered="true" toc="default">
<name>Management Interface (Mi)</name>
<section title="Management Interface" anchor="sect-3.3.3"><t> <t>
NETCONF <xref target="RFC6241"/> is the protocol used on the Management Inter The Network Configuration Protocol (NETCONF) <xref target="RFC6241"
face format="default"/> is the protocol used on the Mi between a CP and UP. It
between a CP and UP. It is used to configure the parameters of the is used to configure the parameters of the Ci, Si, access interfaces,
Control Interface, Service Interface, the Access interfaces and and QoS/ACL Templates. It is expected that implementations will make use of
QoS/ACL Templates. It is expected that implementations will make use existing YANG models where possible but that new YANG models specific to
of existing YANG models where possible, but that new YANG models S-CUSP will need to be defined. The definitions of the parameters that can
specific to S-CUSP will need to be defined. The definitions of the be configured are out of scope for this document.</t>
parameters that can be configured are out of scope for this document.</t> </section>
</section>
</section> <section anchor="sect-3.4" numbered="true" toc="default">
<name>BNG CUPS Procedure Overview</name>
</section> <t>
The following numbered sequences (<xref target="fig3" format="default"/>) giv
<section title="BNG CUPS Procedure Overview" anchor="sect-3.4"><t> e a high-level view
The following numbered sequences <xref target="fig3"/> gives a high-level vie
w
of the main BNG CUPS procedures.</t> of the main BNG CUPS procedures.</t>
<figure title="BNG CUPS Procedures Overview" anchor="fig3"><artwork><![CD <figure anchor="fig3">
ATA[ <name>BNG CUPS Procedures Overview</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
RG UP CP AAA RG UP CP AAA
| | | |
| |Establish S-CUSP Channel| | | |Establish S-CUSP Channel| |
| 1|<---------------------->| | | 1|<---------------------->| |
| | | | | | | |
| | Report Board | | | | Report board interface | |
| | interface | |
| | information | | | | information | |
| 2|------to CP via Ci----->| | | 2|------to CP via Ci----->| |
| | | | | | | |
| | Update BAS function | | | | Update BAS function | |
| 3| request / response | | | 3| request/response | |
| |<-----on UP via Ci----->| | | |<-----on UP via Ci----->| |
| | | | | | | |
| | Update network routing | | | | Update network routing | |
| | request / response | | | | request/response | |
| 4|<------- via Ci-------->| | | 4|<------- via Ci-------->| |
| | | |
| Online Req | | | | Online Req | | |
5.1|-------------->| | | 5.1|-------------->| | |
| | Relay the Online Req | | | | Relay the Online Req | |
| 5.2|-----to CP via Si------>| Authentication| | 5.2|-----to CP via Si------>| Authentication|
| | | Req/Rep | | | | Req/Rep |
| | 5.3|<------------->| | | 5.3|<------------->|
| | Send the Online Rep | | | | Send the Online Rep | |
| 5.4|<----to UP via Si-------| | | 5.4|<----to UP via Si-------| |
| Online Rep | | | | | | |
5.5|<--------------| | |
| | Create subscriber | | | | Create subscriber | |
| | session on UP | | | | session on UP | |
| 5.6|<--------via Ci-------->| | | 5.5|<--------via Ci-------->| |
| Online Rep | | |
5.6|<--------------| | |
| | | CoA Request | | | | CoA Request |
| | 6.1|<--------------| | | 6.1|<--------------|
| | Update session on UP | | | | Update session on UP | |
| 6.2|<--------via Ci-------->| | | 6.2|<--------via Ci-------->| |
| | | CoA Response | | | | CoA Response |
| | 6.3|-------------->| | Offline Req | 6.3|-------------->|
| | | |
| Offline Req | | |
7.1|-------------->| | | 7.1|-------------->| | |
| | Relay the Offline Req | | | | Relay the Offline Req | |
| 7.2|------to CP via Si----->| | | 7.2|------to CP via Si----->| |
| | | | | | | |
| | Send the Offline Rep | | | | Send the Offline Rep | |
| 7.3|<-----to UP via Si------| | | 7.3|<-----to UP via Si------| |
| Offline Rep | | | | Offline Rep | | |
7.4|<--------------| | | 7.4|<--------------| | |
| | Delete session on UP | | | | Delete session on UP | |
| 7.5|<--------via Ci-------->| | | 7.5|<--------via Ci-------->| |
| | | | | | | |
| | Event report | | | | Event report | |
| 8|---------via Ci-------->| | | 8|---------via Ci-------->| |
| | | | | | | |
| | Data Synchronization | | | | Data synchronization | |
| 9|<--------via Ci-------->| | | 9|<--------via Ci-------->| |
| | | | | | | |
| | CGN Address Allocation | | | | CGN address allocation | |
| 10|<--------via Ci-------->| | | 10|<--------via Ci-------->| |
| | | | | | | |]]></artwork>
]]></artwork> </figure>
</figure>
<t><list style="format (%d)">
<t> S-CUSP session establishment: This is the first step of BNG <ol spacing="normal" type="(%d)">
CUPS procedures. Once the Control Interface parameters are <li> S-CUSP session establishment: This is the first step of the BNG
configured on a UP, it will start to setup S-CUSP sessions with the CUPS procedures. Once the Ci parameters are
configured on a UP, it will start to set up S-CUSP sessions with the
specified CPs. The detailed definition of S-CUSP session establishment specified CPs. The detailed definition of S-CUSP session establishment
can be found in <xref target="sect-4.1.1"/>. can be found in <xref target="sect-4.1.1" format="default"/>.
</t> </li>
<li> Board and interface report: Once the S-CUSP session is
<t> Board and interface report: Once the S-CUSP session is established established between the UP and a CP, the UP will report status
between the UP and a CP, the UP will report status information on the information on the boards and subscriber-facing interfaces of this
boards and subscriber-facing interfaces of this UP to the CP. A board UP to the CP. A board can also be called a Line/Service Process Unit
can also be called a Line/Service Process Unit (LPU/SPU) card. The (LPU/SPU) card. The subscriber-facing interfaces refer to the
subscriber-facing interfaces refer to the interfaces that connect the interfaces that connect the access network nodes (e.g., Optical Line
Access Network nodes (e.g., OLT: Optical Line Terminal, DSLAM: Digital Terminal (OLT), DSLAM, etc.). The CP can use this information to
Subscriber Line Access Multiplexer, etc.). The CP can use this enable the Broadband Access Server (BAS) function (e.g., IPoE,
information to enable the Broadband Access Service (BAS) function PPPoE, etc.) on the specified interfaces. See Sections <xref
(e.g., IPoE, PPPoE, etc.) on the specified interfaces. See Sections target="sect-4.2.1" format="counter"/> and <xref target="sect-7.10"
4.2.1 and 7.10 for more details on Resource reporting. format="counter"/> for more details on resource reporting.
</t> </li>
<li> BAS function enable: To enable the BAS
<t> BAS (Broadband Access Service) function enable: To enable the BAS
function on the specified interfaces of a UP. function on the specified interfaces of a UP.
</t> </li>
<li> Subscriber network route advertisement: The CP will allocate one
<t> Subscriber network route advertisement: The CP will allocate one
or more IP address blocks to a UP. Each address block contains a or more IP address blocks to a UP. Each address block contains a
series of IP addresses. Those IP addresses will be allocated to series of IP addresses. Those IP addresses will be allocated to
subscribers who are dialing up from the UP. To enable other nodes in 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 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 notify the UP to advertise to the network the routes that can reach
those IP addresses. those IP addresses.
</t> </li>
<li> 5.1-5.6 is a complete call flow of a subscriber dial-up (as
<t> 5.1-5.6 is a complete call flow of a subscriber dial-up (as defined in <xref target="sect-4.3.1" format="default"/>) process. When a
defined in <xref target="sect-2.1"/>) process. When a UP receives a UP receives a
dial-up request, it will relay the request packet to a CP through the dial-up request, it will relay the request packet to a CP through the
Service Interface. The CP will parse the request. If everything is OK, Si. The CP will parse the request. If everything is OK,
it will send an authentication request to the AAA server to it will send an authentication request to the AAA server to
authenticate the subscriber. Once the subscriber passes the authenticate the subscriber. Once the subscriber passes the
authentication, the AAA server will return a positive response to 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 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 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 same time, the CP will create a subscriber session on the UP,
enables the subscriber to access the network. For different access enabling the subscriber to access the network. For different access
types, the process may be a bit different. But the high-level process types, the process may be a bit different, but the high-level process
is similar. For each access type, the detail process can be found in is similar. For each access type, the detailed process can be found in
<xref target="sect-5"/>. <xref target="sect-5" format="default"/>.
</t> </li>
<li> 6.1-6.3 is the sequence when updating an existing subscriber
<t> 6.1-6.3 is the sequence when updating an existing subscriber
session. The AAA server initiates a Change of Authorization (CoA) and 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 sends the CoA to the CP. The CP will then update the session according
to the CoA. See <xref target="sect-4.3.2"/> for more detail on CP to the CoA. See <xref target="sect-4.3.2" format="default"/> for more de tail on CP
messages updating UP tables. messages updating UP tables.
</t> </li>
<li> 7.1-7.5 is the sequence for deleting an existing subscriber
<t> 7.1-7.5 is the sequence for deleting an existing subscriber session. When a UP receives an Offline Request, it will relay the
session. When a UP receives an offline request, it will relay the request to a CP through the Si. The CP will send back a
request to a CP through the Service Interface. The CP will send back a response to the UP through the Si. The UP will then
response to the UP through the Service Interface. The UP will then forward the Offline Response to the subscriber. Then the CP will
forward the offline response to the subscriber. Then the CP will delete the session on the UP through the Ci.
delete the session on the UP through the Control Interface. </li>
</t> <li>
<t> Event reports include the following two parts (more detail can
<t> Event reports include the following two parts (more detail can be be found in <xref target="sect-4.3.4" format="default"/>). Both
found in <xref target="sect-4.3.4"/>) Both are reported using the Event are reported using the Event message: </t>
message.
<vspace blankLines="1"/> <ul empty="true" spacing="normal">
<li>
8.1. Subscriber Traffic Statistics Report 8.1. Subscriber Traffic Statistics Report
<vspace blankLines="1"/> </li>
<li>
8.2. Subscriber Detection Result Report 8.2. Subscriber Detection Result Report
</t> </li>
</ul>
<t> Data synchronization: See Sections 4.2.5 for more detail on CP and </li>
UP Synchronization. <li> Data synchronization: See <xref target="sect-4.2.5" format="defau
</t> lt"/> for more detail on CP and
UP synchronization.
<t> CGN address allocation: See Sections 4.2.4 for more detail on CGN </li>
Address Allocation. <li> CGN address allocation: See <xref target="sect-4.2.4" format="def
</t> ault"/> for more detail on CGN
address allocation.
</list> </li>
</t> </ol>
</section>
</section> </section>
<section anchor="sect-4" numbered="true" toc="default">
</section> <name>S-CUSP Protocol Overview</name>
<section anchor="sect-4.1" numbered="true" toc="default">
<section title="S-CUSP Protocol Overview" anchor="sect-4"><section title= <name>Control Channel Procedures</name>
"Control Channel Related Procedures" anchor="sect-4.1"><section title="S-CUSP Se <section anchor="sect-4.1.1" numbered="true" toc="default">
ssion Establishment" anchor="sect-4.1.1"><t> <name>S-CUSP Session Establishment</name>
<t>
A UP is associated with a CP and is controlled by that CP. In the 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 case of a hot-standby or cold-standby, a UP is associated with two
CPs, one called the Master CP and the other called the Standby CP. CPs: the master CP and standby CP.
The association between a UP and its CPs is implemented by dynamic The association between a UP and its CPs is implemented by dynamic
configuration.</t> configuration.</t>
<t>
<t>
Once a UP knows its CPs, the UP starts to establish S-CUSP sessions Once a UP knows its CPs, the UP starts to establish S-CUSP sessions
with those CPs, as shown in <xref target="fig4"/>.</t> with those CPs, as shown in <xref target="fig4" format="default"/>.</t>
<figure anchor="fig4">
<figure title="S-CUSP Session Establishment" anchor="fig4"><artwork><![CD <name>S-CUSP Session Establishment</name>
ATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
UP CP UP CP
| |
| TCP Session Establishment | | TCP Session Establishment |
|<------------------------------->| |<------------------------------->|
| | | |
| HELLO (version, capability) | | Hello (version, capability) |
|-------------------------------->| |-------------------------------->|
| | | |
| HELLO (version, capability) | | Hello (version, capability) |
|<--------------------------------| |<--------------------------------|
| | | |]]></artwork>
]]></artwork> </figure>
</figure> <t>
<t>
The S-CUSP session establishment consists of two successive steps:</t> The S-CUSP session establishment consists of two successive steps:</t>
<ol spacing="normal" type="(%d)">
<t><list style="format (%d)"> <li> Establishment of a TCP connection (3-way handshake) <xref targe
t="RFC0793" format="default"/> between the CP and
<t> Establishment of a TCP [RFC793] connection (3-way handshake) between the UP using a configured port from the dynamic port range
the CP and the UP using a configured port from the dynamic port range (49152-65535).
(49152-65535). </li>
</t> <li> Establishment of an S-CUSP session over the TCP connection.</li
>
<t> Establishment of an S-CUSP session over the TCP connection.</t> </ol>
<t> Once the TCP connection is established, the CP and the UP initiali
</list> ze
</t> the S-CUSP session, during which the version and Keepalive timers are
<t> Once the TCP connection is established, the CP and the UP initialize
the S-CUSP session during which the version and Keepalive timers are
negotiated.</t> negotiated.</t>
<t>
<t> The version information (Hello TLV, see <xref target="sect-7.4" format="defau
The version information (Hello TLV, see <xref target="sect-7.4"/>) is carried lt"/>) is carried
within Hello messages (see <xref target="sect-6.2.1"/>). A CP can support mu within Hello messages (see <xref target="sect-6.2.1" format="default"/>). A
ltiple CP can support multiple
versions, but a UP can only support one version. So, the version versions, but a UP can only support one version; thus the version
negotiation is based on whether a version can be supported by both negotiation is based on whether a version can be supported by both
the CP and the UP. For a CP or UP, if a Hello message is received the CP and the UP.
that does not indicate a version supported by both, a subsequent If a CP or UP receives a Hello message that does not indicate
Hello message with an Error Information TLV will be sent to the peer a version supported by both, it responds with a Hello message
to notify the peer of the "Version-Mismatch" error and the session containing an Error Information TLV to notify the peer of the
establishment phase fails.</t> Version-Mismatch error, and the session establishment phase
fails.</t>
<t> <t>
Keepalive negotiation is performed by carrying a Keepalive TLV in the Keepalive negotiation is performed by carrying a Keepalive TLV in the
Hello message. The Keepalive TLV includes a Keepalive timer and Dead Hello message. The Keepalive TLV includes a Keepalive timer and
Timer field. The CP and UP have to agree on the Keepalive Timer and DeadTimer field. The CP and UP have to agree on the Keepalive Timer and
Dead Timer. Otherwise, a subsequent Hello message with an Error DeadTimer. Otherwise, a subsequent Hello message with an Error
Information TLV will be sent to its peer and the session Information TLV will be sent to its peer, and the session
establishment phase fails.</t> establishment phase fails.</t>
<t>
<t>
The S-CUSP session establishment phase fails if the CP or UP disagree 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 on the version and keepalive parameters or if one of the CP or UP
does not answer after the expiration of the Establishment timer. does not answer after the expiration of the Establishment timer.
When the S-CUSP session establishment fails, the TCP connection is When the S-CUSP session establishment fails, the TCP connection is
promptly closed. Successive retries are permitted, but an promptly closed. Successive retries are permitted, but an
implementation SHOULD make use of an exponential back-off session implementation <bcp14>SHOULD</bcp14> make use of an exponential backoff sessi on
establishment retry procedure.</t> establishment retry procedure.</t>
<t>
<t>
The S-CUSP session timer values that need to be configured are The S-CUSP session timer values that need to be configured are
summarized in the table below.</t> summarized in <xref target="tab-sess-timers"/>.</t>
<table anchor="tab-sess-timers">
<figure><artwork><![CDATA[ <name>S-CUSP Session Timers</name>
Timer Range in Default <thead>
Name seconds Value <tr>
Establishment Timer 1-32767 45 <th>Timer Name</th><th>Range in Seconds</th><th>Default Value</th>
Keepalive Timer 0-255 30 </tr>
DeadTimer 1-32767 4 * Keepalive </thead>
]]></artwork> <tbody>
</figure> <tr>
</section> <td>Establishment Timer</td><td>1-32767</td><td>45</td>
</tr>
<section title="Keepalive Timer and DeadTimer" anchor="sect-4.1.2"><t> <tr>
<td>Keepalive Timer</td><td>0-255</td><td>30</td>
</tr>
<tr>
<td>DeadTimer</td><td>1-32767</td><td>4 * Keepalive</td>
</tr>
</tbody>
</table>
</section>
<section anchor="sect-4.1.2" numbered="true" toc="default">
<name>Keepalive Timer and DeadTimer</name>
<t>
Once an S-CUSP session has been established, a UP or CP may want to 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> know that its S-CUSP peer is still connected.</t>
<t>
<t>
Each end of an S-CUSP session runs a Keepalive timer. It restarts 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 the timer every time it sends a message on the session. When the
timer expires, it sends a Keepalive message. Thus, a message is timer expires, it sends a Keepalive message. Thus, a message is
transmitted at least as often as the value the Keepalive timer is transmitted at least as often as the value to which the Keepalive timer is
reset to, unless, as explained below, that value is the special value reset, unless, as explained below, that value is the special value
zero.</t> zero.</t>
<t>
<t> Each end of an S-CUSP session also runs a DeadTimer and restarts that
Each end of a S-CUSP session also run a DeadTimer, and restarts that
DeadTimer whenever a message is received on the session. If the DeadTimer whenever a message is received on the session. If the
DeadTimer at an end of the session expires, that end declares the DeadTimer expires at an end of the session, that end declares the
session dead and the session will be closed, unless their DeadTimer session dead and the session will be closed, unless their DeadTimer
is set to the special value zero in which case the session will not is set to the special value zero, in which case the session will not
time out.</t> time out.</t>
<t>
<t>
The minimum value of the Keepalive timer is 1 second, and it is The minimum value of the Keepalive timer is 1 second, and it is
specified in units of 1 second. The RECOMMENDED default value is 30 specified in units of 1 second. The <bcp14>RECOMMENDED</bcp14> default value is 30
seconds. The recommended default for the DeadTimer is four times the seconds. The recommended default for the DeadTimer is four times the
value of the Keepalive timer used by the remote peer. As above, the value of the Keepalive timer used by the remote peer. As above, the
timers may be disabled by setting them to zero.</t> timers may be disabled by setting them to zero.</t>
<t>
<t>
The Keepalive timer and DeadTimer are negotiated through the The Keepalive timer and DeadTimer are negotiated through the
Keepalive TLV carried in the Hello Message.</t> Keepalive TLV carried in the Hello message.</t>
</section>
</section> </section>
<section anchor="sect-4.2" numbered="true" toc="default">
</section> <name>Node Procedures</name>
<section anchor="sect-4.2.1" numbered="true" toc="default">
<section title="Node Related Procedures" anchor="sect-4.2"><section title <name>UP Resource Report</name>
="UP Resource Report" anchor="sect-4.2.1"><t> <t>
Once an S-CUSP session has been established between a CP and an UP, the UP Once an S-CUSP session has been established between a CP and a UP, the UP
reports the state information of the Boards and access-facing interfaces on reports the state information of the boards and access-facing interfaces on
the UP to the CP, as shown in <xref target="fig5"/>. Report messages are the UP to the CP, as shown in <xref target="fig5" format="default"/>. Report
messages are
unacknowledged and are assumed to be delivered because the session runs unacknowledged and are assumed to be delivered because the session runs
over TCP.</t> over TCP.</t>
<t>
<t> The CP can use that information to activate/enable the
The CP can use that information to activate/enable the Broadband BAS functions (e.g., IPoE, PPPoE, etc.) on the
Access Service (BAS) functions (e.g., IPoE, PPPoE, etc.) on the
specified interfaces.</t> specified interfaces.</t>
<t>
<t>
In addition, the UP resource report may trigger a UP warm-standby 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 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 the CP to start a warm-standby process, by moving the online
subscriber sessions to a standby UP and then direct the affected subscriber sessions to a standby UP and then directing the affected
subscribers to access the Internet through the standby UP.</t> subscribers to access the Internet through the standby UP.</t>
<figure anchor="fig5">
<figure title="UP Board and Interface Report" anchor="fig5"><artwork><![C <name>UP Board and Interface Report</name>
DATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
UP CP UP CP
| |
| Report Board Status | | Report Board Status |
|------to CP via Ci----->| |------to CP via Ci----->|
| | | |
| Report Interface Status| | Report Interface Status|
|------to CP via Ci----->| |------to CP via Ci----->|
| | | |]]></artwork>
]]></artwork> </figure>
</figure> <t>
<t> Board status information is carried in the Board Status TLV (<xref target="se
Board status information is carried in the Board Status TLV (<xref ct-7.10.2" format="default"/>),
target="sect-7.10.2"/>) and Interface status information is carried in and interface status information is carried in the
Interface Status TLV (<xref target="sect-7.10.1"/>). Both Board and Interface Status TLV (<xref target="sect-7.10.1" format="default"/>). Both Bo
Interface Status TLVs are carried in the Report Message (<xref ard Status and
target="sect-6.4"/>).</t> Interface Status TLVs are carried in the Report message (<xref target="sect-6
.4" format="default"/>).</t>
</section> </section>
<section anchor="sect-4.2.2" numbered="true" toc="default">
<section title="Update BAS Function on Access Interface" <name>Update BAS Function on Access Interface</name>
anchor="sect-4.2.2"><t> Once the CP collects the interface status of a <t> Once the CP collects the interface status of a
UP, it will activate/de-activate/modify the BAS functions on specified UP, it will activate/deactivate/modify the BAS functions on specified
interfaces through the Update_Request and Update_Response message interfaces through the Update_Request and Update_Response message exchang
(<xref target="sect-6.2"/>) exchanges, carrying the BAS Function TLV es
(<xref target="sect-7.7"/>).</t> (<xref target="sect-6.2" format="default"/>), carrying the BAS Function T
LV
<figure title="Update BAS Function" anchor="fig6"><artwork><![CDATA[ (<xref target="sect-7.7" format="default"/>).</t>
<figure anchor="fig6">
<name>Update BAS Function</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
UP CP UP CP
| | | Update BAS Function |
| Update BAS function |
| Request | | Request |
|<-----on UP via Ci-------| |<-----on UP via Ci-------|
| | | |
| Update BAS function | | Update BAS Function |
| Response | | Response |
|------on UP via Ci------>| |------on UP via Ci------>|
| | | |]]></artwork>
]]></artwork> </figure>
</figure> </section>
</section> <section anchor="sect-4.2.3" numbered="true" toc="default">
<name>Update Network Routing</name>
<section title="Update Network Routing" anchor="sect-4.2.3"><t> <t>
The CP will allocate one or more address blocks to a UP. Each address 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 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 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 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 CP needs to install the routes on the UP and notify the UP to
advertise the routes to the network.</t> advertise the routes to the network.</t>
<figure anchor="fig7">
<figure title="Update Network Routing" anchor="fig7"><artwork><![CDATA[ <name>Update Network Routing</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
UP CP UP CP
| |
| Subscriber network route| | Subscriber network route|
| update request | | update request |
|<------- via Ci----------| |<------- via Ci----------|
| | | |
| Subscriber network route| | Subscriber network route|
| update response | | update response |
|-------- via Ci--------->| |-------- via Ci--------->|
| | | | ]]></artwork>
]]></artwork> </figure>
</figure> <t>
<t> The Update_Request and Update_Response message exchanges, carrying the
The Update Request and Response Message exchanges, carrying the IPv4/IPv6 Routing TLVs (<xref target="sect-7.8" format="default"/>), update t
IPv4/IPv6 Routing Information TLVs (<xref target="sect-7.8"/>), update the he
subscriber's network routing information.</t> subscriber's network routing information.</t>
</section>
</section> <section anchor="sect-4.2.4" numbered="true" toc="default">
<name>CGN Public IP Address Allocation</name>
<section title="CGN Public IP Address Allocation" anchor="sect-4.2.4"><t> <t>
The following sequences describe the CGN address management related The following sequences (<xref target="fig8" format="default"/>) describe the
procedures. Three independent procedures are defined, one each for procedures related to CGN address
CGN address allocation request/response, CGN address renewal management. Three independent procedures are defined: one each
for CGN address allocation request/response, CGN address renewal
request/response, and CGN address release request/response.</t> request/response, and CGN address release request/response.</t>
<t>
<t>
CGN address allocation/renew/release procedures are designed for the case 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 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 subscriber private IP addresses to public IP addresses, and such mapping
is performed by the UP locally when a subscriber dials-up. That means the is performed by the UP locally when a subscriber dials up. That means the
UP has to ask for public IPv4 address blocks for CGN subscribers from the UP has to ask for public IPv4 address blocks for CGN subscribers from the
CP.</t> CP.</t>
<t>
<t>
In addition, when a public IP address is allocated to a UP, there 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, 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 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 achieved by the exchange of the Addr_Renew_Req and Addr_Renew_Ack
messages.</t> messages.</t>
<t>
<t> If the public IP address will not be used anymore, the UP <bcp14>SHOULD</bcp1
If the public IP address will not be used anymore, the UP SHOULD 4>
release the address by sending an Addr_Release_Req message to the CP.</t> release the address by sending an Addr_Release_Req message to the CP.</t>
<t>
<t>
If the CP wishes to withdraw addresses that it has previously leased If the CP wishes to withdraw addresses that it has previously leased
to a UP, it uses the same procedures as above. The "Oper" code in to a UP, it uses the same procedures as above. The Oper code
the IPv4/IPv6 Routing TLV (see <xref target="sect-7.1"/>) determines whether (see <xref target="sect-7.1" format="default"/>) in the IPv4/IPv6 Routing TLV
the (see <xref target="sect-7.8" format="default"/>) determines whether the
request is an update or withdraw.</t> request is an update or withdraw.</t>
<t>
<t> The relevant messages are defined in <xref target="sect-6.5" format="default"
The relevant messages are defined in Section 6.5.</t> />.</t>
<figure anchor="fig8">
<figure title="CGN Public IP Address Allocation" anchor="fig8"><artwork>< <name>CGN Public IP Address Allocation</name>
![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
UP CP UP CP
| |
| CGN Address Allocation | | CGN Address Allocation |
| Request | | Request |
1.1|-------- via Ci--------->| 1.1|-------- via Ci--------->|
| CGN Address Allocation | | CGN Address Allocation |
| Response | | Response |
1.2|<------- via Ci----------| 1.2|<------- via Ci----------|
| | | |
| CGN Address Renew | | CGN Address Renew |
| Request | | Request |
2.1|-------- via Ci--------->| 2.1|-------- via Ci--------->|
| CGN Address Renew | | CGN Address Renew |
| Response | | Response |
2.2|<------- via Ci----------| 2.2|<------- via Ci----------|
| | | |
| CGN Address Release | | CGN Address Release |
| Request | | Request |
3.1|-------- via Ci--------->| 3.1|-------- via Ci--------->|
| CGN Address Release | | CGN Address Release |
| Response | | Response |
3.3|<------- via Ci----------| 3.3|<------- via Ci----------|
| | | |]]></artwork>
]]></artwork> </figure>
</figure> </section>
</section> <section anchor="sect-4.2.5" numbered="true" toc="default">
<name>Data Synchronization between the CP and UP</name>
<section title="Data Synchronization between the CP and UP" anchor="sect- <t>
4.2.5"><t> For a CU-separated BNG, the UP will continue to function using the
For a 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 state that has been installed in it even if the CP fails or the
session between the UP and CP fails.</t> session between the UP and CP fails.</t>
<t>
<t>
Under some circumstances, it is necessary to synchronize state Under some circumstances, it is necessary to synchronize state
between the CP and UP, for example if a CP fails and the UP is between the CP and UP, for example, if a CP fails and the UP is
switched to a different CP.</t> switched to a different CP.</t>
<t>
<t>
Synchronization includes two directions. One direction is from UP to Synchronization includes two directions. One direction is from UP to
CP; in that case, the synchronization information is mainly about the CP; in that case, the synchronization information is mainly about the
board/interface status of the UP. The other direction is from CP to board/interface status of the UP. The other direction is from CP to
UP; in that case, the subscriber sessions, subscriber network routes, UP; in that case, the subscriber sessions, subscriber network routes,
L2TP tunnels, etc. will be synchronized to the UP.</t> L2TP tunnels, etc., will be synchronized to the UP.</t>
<t>
<t>
The synchronization is triggered by a Sync_Request message, to which The synchronization is triggered by a Sync_Request message, to which
the receiver will (1) reply with a Sync_Begin message to notify the the receiver will (1) reply with a Sync_Begin message to notify the
requester that synchronization will begin, and (2) then start the requester that synchronization will begin and (2) then start the
synchronization using the Sync_Data message. When synchronization synchronization using the Sync_Data message. When synchronization
finished, a Sync_End message will be sent.</t> finishes, a Sync_End message will be sent.</t>
<t>
<t> <xref target="fig9" format="default"/> shows the process of data synchronizat
The following figure shows the process of data synchronization ion
between a UP and a CP.</t> between a UP and a CP.</t>
<figure anchor="fig9">
<figure title="Data Synchronization" anchor="fig9"><artwork><![CDATA[ <name>Data Synchronization</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
UP CP UP CP
| |
| Synchronization Request | | Synchronization Request |
|<------- via Ci----------| |<------- via Ci----------|
| | | |
| Synchronization Begin | | Synchronization Begin |
|-------- via Ci--------->| |-------- via Ci--------->|
| | | |
| Board/Interface Report | | Board/Interface Report |
|-------- via Ci--------->| |-------- via Ci--------->|
| | | |
| Synchronization End | | Synchronization End |
|-------- via Ci--------->| |-------- via Ci--------->|
| | | |
1) Synchronization from UP to CP 1) Synchronization from UP to CP
UP CP UP CP
| |
| Synchronization Request | | Synchronization Request |
|-------- via Ci--------->| |-------- via Ci--------->|
| | | |
| Synchronization Begin | | Synchronization Begin |
|<-------- via Ci---------| |<-------- via Ci---------|
| | | |
| Synchronizes | | Synchronizes |
|Subscriber Session States| |Subscriber Session States|
| Network Route Entries | | Network Route Entries |
|<------- via Ci----------| |<------- via Ci----------|
| | | |
| Synchronization End | | Synchronization End |
|<-------- via Ci---------| |<-------- via Ci---------|
| | | |
2) Synchronization from CP to UP 2) Synchronization from CP to UP ]]></artwork>
]]></artwork> </figure>
</figure> </section>
</section> </section>
<section anchor="sect-4.3" numbered="true" toc="default">
</section> <name>Subscriber Session Procedures</name>
<t>
<section title="Subscriber Session Related Procedures" anchor="sect-4.3"> A subscriber session consists of a set of forwarding states, policies, and
<t> security rules that are applied to the subscriber. It is used for
A subscriber session consists of a set of forwarding states, forwarding subscriber traffic in a UP. To initialize a session on a UP, a
policies, and security rules that are applied to the subscriber. It collection of hardware resources (e.g., NP, TCAM, etc.) has to be allocated t
is used for forwarding subscriber traffic in a UP. To initialize a o
session on a UP, A collection of hardware resources (e.g., NP, TCAM a session on a UP as part of its initiation.</t>
etc.) have to be allocated to a session on a UP as part of its <t>
initiation.</t> Procedures related to subscriber sessions include subscriber session creation
,
<t> update, deletion, and statistics reporting. The following subsections give a
Subscriber session related procedures include subscriber session create,
update, delete, and statistics report. The following sub-sections give a
high-level view of the procedures.</t> high-level view of the procedures.</t>
<section anchor="sect-4.3.1" numbered="true" toc="default">
<section title="Create Subscriber Session" anchor="sect-4.3.1"><t> <name>Create Subscriber Session</name>
The below sequence describes the DHCP IPv4 dial-up process. It is an <t>
The sequence below (<xref target="fig10" format="default"/>) describes the DH
CP IPv4 dial-up process. It is an
example that shows how a subscriber session is created. (An example example that shows how a subscriber session is created. (An example
for IPv6 appears in <xref target="sect-5.1.2"/>.)</t> for IPv6 appears in <xref target="sect-5.1.2" format="default"/>.)</t>
<figure title="Subscriber Session Create" anchor="fig10"><artwork><![CDAT <figure anchor="fig10">
A[ <name>Creating a Subscriber Session</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
RG UP CP AAA RG UP CP AAA
| | | |
| Online Request| | | | Online Request| | |
1|-------------->| | | 1|-------------->| | |
| |Relay the Online Request| | | |Relay the Online Request| |
| 2|-----to CP via Si------>| Authentication| | 2|-----to CP via Si------>| Authentication|
| | | Req/Rep | | | | Req/Rep |
| | 3|<------------->| | | 3|<------------->|
| | Create subscriber | | | | Create Subscriber | |
| | session Request | | | | Session Request | |
| 4|<--------via Ci---------| | | 4|<--------via Ci---------| |
| | | | | | | |
| | Create subscriber | | | | Create Subscriber | |
| | session Response | | | | Session Response | |
| 5|---------via Ci-------->| | | 5|---------via Ci-------->| |
| | | |
| | | Accounting | | | | Accounting |
| | 6|<------------->| | | 6|<------------->|
| | | |
| | Send Online Response | | | | Send Online Response | |
| 7|<----to UP via Si-------| | | 7|<----to UP via Si-------| |
| | | | | | | |
|Online Response| | | |Online Response| | |
12|<--------------| | | 8|<--------------| | |
| | | | | | | |]]></artwork>
]]></artwork> </figure>
</figure> <t>
<t>
The request starts from an Online Request message (step 1) from the The request starts from an Online Request message (step 1) from the
RG (for example, a DHCP Discovery packet). When the UP receives 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 Online Request from the RG, it will tunnel the Online Request to the
CP through the Service Interface (Step 2). A tunneling technology CP through the Si (step 2). A tunneling technology
implements the Service Interface.</t> implements the Si.</t>
<t>
<t>
When the CP receives the Online Request from the UP, it will send an When the CP receives the Online Request from the UP, it will send an
authentication request to the AAA server to authenticate and authentication request to the AAA server to authenticate and
authorize the subscriber (step 3). When a positive reply is received authorize the subscriber (step 3). When a positive reply is received
from the AAA server, the CP starts to create a subscriber session for from the AAA server, the CP starts to create a subscriber session for
the request. Relevant resources (e.g., IP address, bandwidth, etc.) the request. Relevant resources (e.g., IP address, bandwidth, etc.)
will be allocated to the subscriber. Policies and security rules will will be allocated to the subscriber. Policies and security rules will
be generated for the subscriber. Then the CP sends a request to be generated for the subscriber. Then the CP sends a request to
create a session to the UP through the Control Interface (Ci) (step create a session to the UP through the Ci (step
4), and a response is expected from the UP to confirm the creation 4), and a response is expected from the UP to confirm the creation
(step 5).</t> (step 5).</t>
<t>
<t>
Finally, the CP will notify the AAA server to start accounting (step Finally, the CP will notify the AAA server to start accounting (step
6). At the same time, an Online Response message (for example, a 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 DHCP Ack packet) will be sent to the UP through the Si (step 7).
the UP will forward the Online Response to the RG (step 8).</t> The UP will then forward the Online Response to the RG (step 8).</t>
<t>
<t>
That completes the subscriber activation process.</t> That completes the subscriber activation process.</t>
</section>
</section> <section anchor="sect-4.3.2" numbered="true" toc="default">
<name>Update Subscriber Session</name>
<section title="Update Subscriber Session" anchor="sect-4.3.2"><t> <t>
The following numbered sequence shows the process of updating the The following numbered sequence (<xref target="fig11" format="default"/>) sho
ws the process of updating the
subscriber session.</t> subscriber session.</t>
<figure anchor="fig11">
<figure title="Subscriber Session Update" anchor="fig11"><artwork><![CDAT <name>Updating a Subscriber Session</name>
A[ <artwork name="" type="" align="left" alt=""><![CDATA[
UP CP AAA UP CP AAA
| | COA Request | | | CoA Request |
| 1|<--------------| | 1|<--------------|
| Session update Request | | | Session Update Request | |
2|<--------via Ci---------| | 2|<--------via Ci---------| |
| | | | | |
| Session update Response| | | Session Update Response| |
3|---------via Ci-------->| | 3|---------via Ci-------->| |
| | COA Response | | | CoA Response |
| 4|-------------->| | 4|-------------->|
| | | | | |]]></artwork>
]]></artwork> </figure>
</figure> <t>
<t>
When a subscriber session has been created on a UP, there may be When a subscriber session has been created on a UP, there may be
requirements to update the session with new parameters (e.g., requirements to update the session with new parameters (e.g.,
Bandwidth, QoS, policies, etc.).</t> bandwidth, QoS, policies, etc.).</t>
<t>
<t> This procedure is triggered by a Change of Authorization (CoA)
This procedure is triggered by a Change of Authorization (COA)
request message sent by the AAA server. The CP will update the request message sent by the AAA server. The CP will update the
session on the UP according to the new parameters through the Control session on the UP according to the new parameters through the Ci.</t>
Interface.</t> </section>
<section anchor="sect-4.3.3" numbered="true" toc="default">
</section> <name>Delete Subscriber Session</name>
<t>
<section title="Delete Subscriber Session" anchor="sect-4.3.3"><t> The call flow below shows how S-CUSP deals with a subscriber Offline
The below call flow shows how S-CUPS deals with a subscriber offline Request.</t>
request.</t> <figure anchor="fig12">
<name>Deleting a Subscriber Session</name>
<figure title="Subscriber Session Delete" anchor="fig12"><artwork><![CDAT <artwork name="" type="" align="left" alt=""><![CDATA[
A[
RG UP CP RG UP CP
| | |
|Offline Request | | |Offline Request | |
1|--------------->| | 1|--------------->| |
| | Relay the Offline | | | Relay the Offline |
| | Request | | | Request |
| 2|------to CP via Si----->| | 2|------to CP via Si----->|
| | | | | |
| | Send the Offline | | | Send the Offline |
| | Response | | | Response |
| 3|<-----to UP via Si------| | 3|<-----to UP via Si------|
|Offline Response| | |Offline Response| |
4|<---------------| | 4|<---------------| |
| | Session delete | | | Session Delete |
| | Request | | | Request |
| |<--------via Ci---------| | |<--------via Ci---------|
| | Session delete | | | Session Delete |
| | Response | | | Response |
| |---------via Ci-------->| | |---------via Ci-------->|
| | | | | |]]></artwork>
]]></artwork> </figure>
</figure> <t>
<t>
Similar to the session creation process, when a UP receives an Similar to the session creation process, when a UP receives an
offline request from an RG, it will tunnel the request to a CP Offline Request from an RG, it will tunnel the request to a CP
through the Si.</t> through the Si.</t>
<t>
<t> When the CP receives the Offline Request, it will withdraw/release
When the CP receives the offline request, it will withdraw/release
the resources (e.g., IP address, bandwidth) that have been allocated the resources (e.g., IP address, bandwidth) that have been allocated
to the subscriber. Then, it sends a reply to the UP through the to the subscriber. It then sends a reply to the UP through the
Service Interface and the UP will forward the reply to the RG. At 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 the same time, it will delete all the status of the session on the UP
through the Ci.</t> through the Ci.</t>
</section>
</section> <section anchor="sect-4.3.4" numbered="true" toc="default">
<name>Subscriber Session Events Report</name>
<section title="Subscriber Session Events Report" anchor="sect-4.3.4"><fi <figure anchor="fig13">
gure title="Events Report" anchor="fig13"><artwork><![CDATA[ <name>Events Report</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
UP CP UP CP
| | | Statistic/Detect Report|
| Statistic/Detect report|
|---------via Ci-------->| |---------via Ci-------->|
| | | |]]></artwork>
]]></artwork> </figure>
</figure> <t>
<t> When a session is created on a UP, the UP will periodically report statistics
When a session is created on a UP, the UP will periodically report information and subscriber detection results of the session to the CP. </t>
statistics information and detect results of the session to the CP.</t> </section>
</section>
</section> </section>
<section anchor="sect-5" numbered="true" toc="default">
</section> <name>S-CUSP Call Flows</name>
<t>
</section>
<section title="S-CUSP Call Flows" anchor="sect-5"><t>
The subsections below give an overview of various "dial-up" The subsections below give an overview of various "dial-up"
interactions over the Service Interface followed by an overview of interactions over the Si followed by an overview of
the setting of information in the UP by the CP using S-CUSP over the the setting of information in the UP by the CP using S-CUSP over the
Control Interface.</t> Ci.</t>
<t>
<t>
S-CUSP messages are described in this document using Routing Backus S-CUSP messages are described in this document using Routing Backus
Naur Form (RBNF) as defined in <xref target="RFC5511"/>.</t> Naur Form (RBNF) as defined in <xref target="RFC5511" format="default"/>.</t>
<section anchor="sect-5.1" numbered="true" toc="default">
<section title="IPoE" anchor="sect-5.1"><section title="DHCPv4 Access" <name>IPoE</name>
anchor="sect-5.1.1"> <section anchor="sect-5.1.1" numbered="true" toc="default">
<name>DHCPv4 Access</name>
<t>The following sequence shows detailed procedures for DHCPv4 access.</t> <t>The following sequence (<xref target="fig14" format="default"/>) sh
ows detailed procedures for DHCPv4 access.</t>
<figure title="DHCPv4 Access" anchor="fig14"><artwork><![CDATA[ <figure anchor="fig14">
<name>DHCPv4 Access</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
RG UP CP AAA RG UP CP AAA
| | | |
| DHCP Discovery| | | | DHCP Discovery| | |
1|-------------->| | | 1|-------------->| | |
| |Relay the DHCP Discovery| | | |Relay the DHCP Discovery| |
| 2|-----to CP via Si------>| AAA | | 2|-----to CP via Si------>| AAA |
| | | Req/Rep | | | | Req/Rep |
| | 3|<------------->| | | 3|<------------->|
| | | |
| | Send the DHCP Offer | | | | Send the DHCP Offer | |
| 4|<----to UP vis Si-------| | | 4|<----to UP via Si-------| |
| DHCP Offer | | | | DHCP Offer | | |
5|<--------------| | | 5|<--------------| | |
| DHCP Request | | | | DHCP Request | | |
6|-------------->| | | 6|-------------->| | |
| | Relay the DHCP Request| | | | Relay the DHCP Request | |
| 7|-----to CP via Si------>| | | 7|-----to CP via Si------>| |
| | | | | | | |
| | Create subscriber | | | | Create Subscriber | |
| | session Request | | | | Session Request | |
| 8|<--------via Ci---------| | | 8|<--------via Ci---------| |
| | Create subscriber | | | | Create Subscriber | |
| | session Response | | | | Session Response | |
| 9|---------via Ci-------->| | | 9|---------via Ci-------->| |
| | | Accounting | | | | Accounting |
| | 10|<------------->| | | 10|<------------->|
| | | |
| | Send DHCP ACK | | | | Send DHCP ACK | |
| 11|<----to UP via Si-------| | | 11|<----to UP via Si-------| |
| | | | | | | |
| DHCP ACK | | | | DHCP ACK | | |
12|<--------------| | | 12|<--------------| | |
| | | | | | | |]]></artwork>
]]></artwork> </figure>
</figure> <t>
<t> S-CUSP implements steps 8 and 9.</t>
The S-CUSP protocol implements steps 8 and 9.</t> <t>
<t>
After a subscriber is authenticated and authorized by the AAA server, After a subscriber is authenticated and authorized by the AAA server,
the CP creates a new subscriber session on the UP. This is achieved the CP creates a new subscriber session on the UP. This is achieved
by sending an Update_Request message to the UP.</t> by sending an Update_Request message to the UP.</t>
<t>
<t>
The format of the Update_Request message is shown as follows using The format of the Update_Request message is shown as follows using
RBNF:</t> RBNF:</t>
<sourcecode type="rbnf"><![CDATA[
<figure><artwork><![CDATA[
<Update_Request Message> ::= <Common Header> <Update_Request Message> ::= <Common Header>
<Basic Subscriber TLV> <Basic Subscriber TLV>
<IPv4 Subscriber TLV> <IPv4 Subscriber TLV>
<IPv4 Routing TLV> <IPv4 Routing TLV>
[<Subscriber Policy TLV>] [<Subscriber Policy TLV>]
]]></artwork> ]]></sourcecode>
</figure> <t>
<t> The UP will reply with an Update_Response message. The format of the
The UP will reply with an Update_Response message, the format of the
Update_Response message is as follows:</t> Update_Response message is as follows:</t>
<sourcecode type="rbnf"><![CDATA[
<figure><artwork><![CDATA[
<Update_Response Message> ::= <Common Header> <Update_Response Message> ::= <Common Header>
<Update Response TLV> <Update Response TLV>
[<Subscriber CGN Port Range TLV>] [<Subscriber CGN Port Range TLV>]
]]></artwork> ]]></sourcecode>
</figure> </section>
</section> <section anchor="sect-5.1.2" numbered="true" toc="default">
<name>DHCPv6 Access</name>
<section title="DHCPv6 Access" anchor="sect-5.1.2"> <t> The following sequence (<xref target="fig15" format="default"/>) s
hows detailed procedures for DHCPv6 access.
<t> The following sequence shows detailed procedures for DHCPv6 access. </t>
</t> <figure anchor="fig15">
<name>DHCPv6 Access</name>
<figure title="DHCPv6 Access" anchor="fig15"><artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
RG UP CP AAA RG UP CP AAA
| | | |
| Solicit | | | | Solicit | | |
1|-------------->| | | 1|-------------->| | |
| | Relay the Solicit | | | | Relay the Solicit | |
| 2|-----to CP via Si------>| AAA | | 2|-----to CP via Si------>| AAA |
| | | Req/Rep | | | | Req/Rep |
| | 3|<------------->| | | 3|<------------->|
| | | |
| | Send the Advertise | | | | Send the Advertise | |
| 4|<----to UP vis Si-------| | | 4|<----to UP via Si-------| |
| Advertise | | | | Advertise | | |
5|<--------------| | | 5|<--------------| | |
| | | | | | | |
| Request | | | | Request | | |
6|-------------->| | | 6|-------------->| | |
| | Relay the Request | | | | Relay the Request | |
| 7|-----to CP via Si------>| | | 7|-----to CP via Si------>| |
| | | | | | | |
| | | | | | Create Subscriber | |
| | Create subscriber | | | | Session Request | |
| | session Request | |
| 8|<--------via Ci-------->| | | 8|<--------via Ci-------->| |
| | | | | | | |
| | Create subscriber | | | | Create Subscriber | |
| | session Response | | | | Session Response | |
| 9|---------via Ci-------->| | | 9|---------via Ci-------->| |
| | | |
| | | Accounting | | | | Accounting |
| | 10|<------------->| | | 10|<------------->|
| | | |
| | Send Reply | | | | Send Reply | |
| 11|<----to UP via Si-------| | | 11|<----to UP via Si-------| |
| | | |
| Reply | | | | Reply | | |
12|<--------------| | | 12|<--------------| | |
| | | | | | | |]]></artwork>
]]></artwork> </figure>
</figure> <t>
<t>
Steps 1-7 are a standard DHCP IPv6 access process. The subscriber Steps 1-7 are a standard DHCP IPv6 access process. The subscriber
creation is triggered by a DHCP IPv6 request message. When this creation is triggered by a DHCP IPv6 request message. When this
message is received, it means that the subscriber has passed the AAA message is received, it means that the subscriber has passed the AAA
authentication and authorization. Then the CP will create a authentication and authorization. Then the CP will create a
subscriber session on the UP. This is achieved by sending an subscriber session on the UP. This is achieved by sending an
Update_Request message to the UP (Step 8).</t> Update_Request message to the UP (step 8).</t>
<t>
<t>
The format of the Update_Request message is as follows:</t> The format of the Update_Request message is as follows:</t>
<sourcecode type="rbnf"><![CDATA[
<figure><artwork><![CDATA[
<Update_Request Message> ::= <Common Header> <Update_Request Message> ::= <Common Header>
<Basic Subscriber TLV> <Basic Subscriber TLV>
<IPv6 Subscriber TLV> <IPv6 Subscriber TLV>
<IPv6 Routing TLV> <IPv6 Routing TLV>
[<Subscriber Policy TLV>] [<Subscriber Policy TLV>]
]]></artwork> ]]></sourcecode>
</figure> <t>
<t> The UP will reply with an Update_Response message (step 9). The
The UP will reply with an Update_Response message (Step 9). The
format of the Update_Response message is as follows:</t> format of the Update_Response message is as follows:</t>
<sourcecode type="rbnf"><![CDATA[
<figure><artwork><![CDATA[
<Update_Response Message> ::= <Common Header> <Update_Response Message> ::= <Common Header>
<Update Response TLV> <Update Response TLV>
]]></artwork> ]]></sourcecode>
</figure> </section>
</section> <section anchor="sect-5.1.3" numbered="true" toc="default">
<name>IPv6 Stateless Address Autoconfiguration (SLAAC) Access</name>
<section title="IPv6 SLAAC Access" anchor="sect-5.1.3"> <t>The following flow (<xref target="fig16" format="default"/>) shows
the IPv6 SLAAC access process.</t>
<t>The following flow shows the IPv6 SLAAC access process.</t> <figure anchor="fig16">
<name>IPv6 SLAAC Access</name>
<figure title="IPv6 SLAAC Access" anchor="fig16"><artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
RG UP CP AAA RG UP CP AAA
| | | |
| RS | | | | RS | | |
1|-------------->| | | 1|-------------->| | |
| | Relay the Router | | | | Relay the Router | |
| | Solicit (RS) | | | | Solicit (RS) | |
| 2|-----to CP via Si------>| AAA | | 2|-----to CP via Si------>| AAA |
| | | Req/Rep | | | | Req/Rep |
| | 3|<------------->| | | 3|<------------->|
| | | | | | Create Subscriber | |
| | Create subscriber | | | | Session Request | |
| | session Request | |
| 4|<--------via Ci---------| | | 4|<--------via Ci---------| |
| | | | | | | |
| | Create subscriber | | | | Create Subscriber | |
| | session Response | | | | Session Response | |
| 5|---------via Ci-------->| | | 5|---------via Ci-------->| |
| | | | | | | |
| | Send Router Advertise | | | | Send Router Advertise | |
| | (RA) | | | | (RA) | |
| 6|<----to UP vis Si-------| | | 6|<----to UP via Si-------| |
| RA | | | | RA | | |
7|<--------------| | | 7|<--------------| | |
| | | | | | | |
| NS | | | | NS | | |
8|-------------->| | | 8|-------------->| | |
| | Relay the Neighbor | | | | Relay the Neighbor | |
| | Solicit (NS) | | | | Solicit (NS) | |
| 9|-----to CP via Si------>| | | 9|-----to CP via Si------>| |
| | | |
| | | Accounting | | | | Accounting |
| | 10|<------------->| | | 10|<------------->|
| | | |
| | Send a Neighbor | | | | Send a Neighbor | |
| | Advertise (NA) | | | | Advertise (NA) | |
| 11|<----to UP via Si-------| | | 11|<----to UP via Si-------| |
| | | |
| NA | | | | NA | | |
12|<--------------| | | 12|<--------------| | |
| | | | | | | |]]></artwork>
]]></artwork> </figure>
</figure> <t>
<t>
It starts with a Router Solicit (RS) request from an RG that is 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 tunneled to the CP by the UP. After the AAA authentication and
authorization, the CP will create a subscriber session on the UP.</t> authorization, the CP will create a subscriber session on the UP.</t>
<t>
<t>
This is achieved by sending an Update_Request message to the UP (step This is achieved by sending an Update_Request message to the UP (step
4).</t> 4).</t>
<t>
<t>
The format of the Update_Request message is as follows:</t> The format of the Update_Request message is as follows:</t>
<sourcecode type="rbnf"><![CDATA[
<figure><artwork><![CDATA[
<Update_Request Message> ::= <Common Header> <Update_Request Message> ::= <Common Header>
<Basic Subscriber TLV> <Basic Subscriber TLV>
<IPv6 Subscriber TLV> <IPv6 Subscriber TLV>
<IPv6 Routing TLV> <IPv6 Routing TLV>
[<Subscriber Policy TLV>] [<Subscriber Policy TLV>]
]]></artwork> ]]></sourcecode>
</figure> <t>
<t> The UP will reply with an Update_Response message (step 5). The
The UP will reply with an Update_Response message (step 5), the
format of the Update_Response message is as follows:</t> format of the Update_Response message is as follows:</t>
<sourcecode type="rbnf"><![CDATA[
<figure><artwork><![CDATA[
<Update_Response Message> ::= <Common Header> <Update_Response Message> ::= <Common Header>
<Update Response TLV> <Update Response TLV>
]]></artwork> ]]></sourcecode>
</figure> </section>
</section> <section anchor="sect-5.1.4" numbered="true" toc="default">
<name>DHCPv6 and SLAAC Access</name>
<section title="DHCPv6 + SLAAC Access" anchor="sect-5.1.4"> <t> The following call flow (<xref target="fig17" format="default"/>)
shows the DHCP IPv6 and SLAAC access
<t> The following call flow shows the DHCP IPv6 and SLAAC access
process.</t> process.</t>
<figure anchor="fig17">
<figure title="DHCPv6 + SLAAC Access" anchor="fig17"><artwork><![CDATA[ <name>DHCPv6 and SLAAC Access</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
RG UP CP AAA RG UP CP AAA
| | | |
| RS | | | | RS | | |
1|-------------->| | | 1|-------------->| | |
| | Relay the Router | | | | Relay the RS | |
| | Solicit (RA) | |
| 2|-----to CP via Si------>| AAA | | 2|-----to CP via Si------>| AAA |
| | | Req/Rep | | | | Req/Rep |
| | 3|<------------->| | | 3|<------------->|
| | | | | | Create Subscriber | |
| | Create subscriber | | | | Session Request | |
| | session Request | |
| 4|<--------via Ci---------| | | 4|<--------via Ci---------| |
| | | | | | | |
| | Create subscriber | | | | Create Subscriber | |
| | session Response | | | | Session Response | |
| 5|---------via Ci-------->| | | 5|---------via Ci-------->| |
| | | | | | | |
| | Send Router Advertise | | | | Send RA | |
| | (RA) | | | 6|<----to UP via Si-------| |
| 6|<----to UP vis Si-------| |
| RA | | | | RA | | |
7|<--------------| | | 7|<--------------| | |
| | | | | | | |
|DHCPv6 Solicit | | | |DHCPv6 Solicit | | |
8|-------------->| | | 8|-------------->| | |
| | Relay DHCPv6 Solicit | | | | Relay DHCPv6 Solicit | |
| 9|-----to CP via Si------>| | | 9|-----to CP via Si------>| |
| | | | | | | |
| | Update subscriber | | | | Update Subscriber | |
| | session Request | | | | Session Request | |
| 10|<--------via Ci---------| | | 10|<--------via Ci---------| |
| | | | | | | |
| | Update subscriber | | | | Update Subscriber | |
| | session Response | | | | Session Response | |
| 11|---------via Ci-------->| | | 11|---------via Ci-------->| |
| | | |
| | | Accounting | | | | Accounting |
| | 12|<------------->| | | 12|<------------->|
| | | |
| | Send DHCPv6 Reply | | | | Send DHCPv6 Reply | |
| 13|<----to UP via Si-------| | | 13|<----to UP via Si-------| |
| | | | | | | |
| DHCPv6 Reply | | | | DHCPv6 Reply | | |
14|<--------------| | | 14|<--------------| | |
| | | | | | | |]]></artwork>
]]></artwork> </figure>
</figure> <t>
<t>
When a subscriber passes AAA authentication, the CP will create a When a subscriber passes AAA authentication, the CP will create a
subscriber session on the UP. This is achieved by sending an subscriber session on the UP. This is achieved by sending an
Update_Request message to the UP (step 4).</t> Update_Request message to the UP (step 4).</t>
<sourcecode type="rbnf"><![CDATA[
<figure><artwork><![CDATA[
<Update_Request Message> ::= <Common Header> <Update_Request Message> ::= <Common Header>
<Basic Subscriber TLV> <Basic Subscriber TLV>
<IPv6 Subscriber TLV> <IPv6 Subscriber TLV>
<IPv6 Routing TLV> <IPv6 Routing TLV>
[<Subscriber Policy TLV>] [<Subscriber Policy TLV>]
]]></artwork> ]]></sourcecode>
</figure> <t>
<t>
The UP will reply with an Update_Response message (step 5). The The UP will reply with an Update_Response message (step 5). The
format of the Update_Response is as follows:</t> format of the Update_Response is as follows:</t>
<sourcecode type="rbnf"><![CDATA[
<figure><artwork><![CDATA[
<Update_Response Message> ::= <Common Header> <Update_Response Message> ::= <Common Header>
<Update Response TLV> <Update Response TLV>
]]></artwork> ]]></sourcecode>
</figure> <t>
<t>
After receiving a DHCPv6 Solicit, the CP will update the subscriber After receiving a DHCPv6 Solicit, the CP will update the subscriber
session by sending an Update_Request message with new parameters to session by sending an Update_Request message with new parameters to
the UP (Step 10).</t> the UP (step 10).</t>
<t>
<t>
The format of the Update_Request message is as follows:</t> The format of the Update_Request message is as follows:</t>
<sourcecode type="rbnf"><![CDATA[
<figure><artwork><![CDATA[
<Update_Request Message> ::= <Common Header> <Update_Request Message> ::= <Common Header>
<Basic Subscriber TLV> <Basic Subscriber TLV>
<IPv6 Subscriber TLV> <IPv6 Subscriber TLV>
<IPv6 Routing TLV> <IPv6 Routing TLV>
[<Subscriber Policy TLV>] [<Subscriber Policy TLV>]
]]></artwork> ]]></sourcecode>
</figure> <t>
<t>
The UP will reply with an Update_Response message (step 11). The The UP will reply with an Update_Response message (step 11). The
format of the Update_Response is as follows:</t> format of the Update_Response is as follows:</t>
<sourcecode type="rbnf"><![CDATA[
<figure><artwork><![CDATA[
<Update_Response Message> ::= <Common Header> <Update_Response Message> ::= <Common Header>
<Update Response TLV> <Update Response TLV>
]]></artwork> ]]></sourcecode>
</figure> </section>
</section> <section anchor="sect-5.1.5" numbered="true" toc="default">
<name>DHCP Dual-Stack Access</name>
<section title="DHCP Dual Stack Access" anchor="sect-5.1.5"><t> <t>
The following sequence is a combination of DHCP IPv4 and DHCP IPv6 The following sequence (<xref target="fig18" format="default"/>) is a combina
tion of DHCP IPv4 and DHCP IPv6
access processes.</t> access processes.</t>
<figure anchor="fig18">
<figure title="DHCP Dual Stack Access" anchor="fig18"><artwork><![CDATA[ <name>DHCP Dual-Stack Access</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
RG UP CP AAA RG UP CP AAA
| | | |
| DHCP Discovery| | | | DHCP Discovery| | |
1|-------------->| | | 1|-------------->| | |
| |Relay the DHCP Discovery| | | |Relay the DHCP Discovery| |
| 2|-----to CP via Si------>| AAA | | 2|-----to CP via Si------>| AAA |
| | | Req/Resp | | | | Req/Resp |
| | 3|<------------->| | | 3|<------------->|
| | | |
| | Send the DHCP Offer | | | | Send the DHCP Offer | |
| 4|<----to UP vis Si-------| | | 4|<----to UP via Si-------| |
| DHCP Offer | | | | DHCP Offer | | |
5|<--------------| | | 5|<--------------| | |
| DHCP Request | | | | DHCP Request | | |
6|-------------->| | | 6|-------------->| | |
| | Relay the DHCP Request| | | | Relay the DHCP Request| |
| 7|-----to CP via Si------>| | | 7|-----to CP via Si------>| |
| | | | | | | |
| | Create subscriber | | | | Create Subscriber | |
| | session Request | | | | Session Request | |
| 8|<--------via Ci-------->| | | 8|<--------via Ci-------->| |
| | Create subscriber | | | | Create Subscriber | |
| | session Response | | | | Session Response | |
| 9|---------via Ci-------->| | | 9|---------via Ci-------->| |
| | | Accounting | | | | Accounting |
| | 10|<------------->| | | 10|<------------->|
| | Send DHCP ACK | | | | Send DHCP ACK | |
| 11|<----to UP via Si-------| | | 11|<----to UP via Si-------| |
| | | |
| DHCP ACK | | | | DHCP ACK | | |
12|<--------------| | | 12|<--------------| | |
| RS | | | | RS | | |
13|-------------->| | | 13|-------------->| | |
| | Relay the Router | | | | Relay the RS | |
| | Solicit (RA) | |
| 14|-----to CP via Si------>| AAA | | 14|-----to CP via Si------>| AAA |
| | | Req/Rep | | | | Req/Rep |
| | 15|<------------->| | | 15|<------------->|
| | | | | | Create Subscriber | |
| | Create subscriber | | | | Session Request | |
| | session Request | |
| 16|<--------via Ci---------| | | 16|<--------via Ci---------| |
| | Create subscriber | | | | Create Subscriber | |
| | session Response | | | | Session Response | |
| 17|---------via Ci-------->| | | 17|---------via Ci-------->| |
| | | | | | | |
| | Send Router Advertise | | | | Send the RA | |
| | (RA) | | | 18|<----to UP via Si-------| |
| 18|<----to UP vis Si-------| |
| RA | | | | RA | | |
19|<--------------| | | 19|<--------------| | |
| | | |
|DHCPv6 Solicit | | | |DHCPv6 Solicit | | |
20|-------------->| | | 20|-------------->| | |
| | Relay DHCPv6 Solicit | | | | Relay DHCPv6 Solicit | |
| 21|-----to CP via Si------>| | | 21|-----to CP via Si------>| |
| | | | | | | |
| | Update subscriber | | | | Update Subscriber | |
| | session Request | | | | Session Request | |
| 22|<--------via Ci---------| | | 22|<--------via Ci---------| |
| | Update subscriber | | | | Update Subscriber | |
| | session Response | | | | Session Response | |
| 23|---------via Ci-------->| | | 23|---------via Ci-------->| |
| | | Accounting | | | | Accounting |
| | 24|<------------->| | | 24|<------------->|
| | Send DHCPv6 Reply | | | | Send DHCPv6 Reply | |
| 25|<----to UP via Si-------| | | 25|<----to UP via Si-------| |
| DHCPv6 Reply | | | | DHCPv6 Reply | | |
26|<--------------| | | 26|<--------------| | |
| | | | | | | |]]></artwork>
]]></artwork> </figure>
</figure> <t>
<t> The DHCP dual-stack access includes three sets of
The DHCP dual stack access includes three sets of Update_Request / Update_Request/Update_Response exchanges to create/update a DHCPv4/v6
Update_Response exchanges to create/update DHCPv4/v6 subscriber subscriber session.</t>
session.</t> <ol spacing="normal" type="(%d)">
<li>
<t><list style="format (%d)"> <t>Create a DHCPv4 session (steps 8 and 9):
<t>Create a DHCPv4 session (step 8 and 9)
<figure><artwork><![CDATA[ </t>
<sourcecode type="rbnf"><![CDATA[
<Update_Request Message> ::= <Common Header> <Update_Request Message> ::= <Common Header>
<Basic Subscriber TLV> <Basic Subscriber TLV>
<IPv4 Subscriber TLV> <IPv4 Subscriber TLV>
<IPv4 Routing TLV> <IPv4 Routing TLV>
[<Subscriber Policy TLV>] [<Subscriber Policy TLV>]
<Update_Response Message> ::= <Common Header> <Update_Response Message> ::= <Common Header>
<Update Response TLV> <Update Response TLV>
[<Subscriber CGN Port Range TLV>] [<Subscriber CGN Port Range TLV>]
]]></artwork> ]]></sourcecode>
</figure></t> </li>
<li>
<t>Create a DHCPv6 session (step 16 and 17) <t>Create a DHCPv6 session (steps 16 and 17):
<figure><artwork><![CDATA[ </t>
<sourcecode type="rbnf"><![CDATA[
<Update_Request Message> ::= <Common Header> <Update_Request Message> ::= <Common Header>
<Basic Subscriber TLV> <Basic Subscriber TLV>
<IPv6 Subscriber TLV> <IPv6 Subscriber TLV>
<IPv6 Routing TLV> <IPv6 Routing TLV>
[<Subscriber Policy TLV>] [<Subscriber Policy TLV>]
<Update_Response Message> ::= <Common Header> <Update_Response Message> ::= <Common Header>
<Update Response TLV> <Update Response TLV>
]]></artwork> ]]></sourcecode>
</figure></t> </li>
<li>
<t>Update DHCPv6 session (step 22 and 23) <t>Update DHCPv6 session (steps 22 and 23):
<figure><artwork><![CDATA[ </t>
<sourcecode type="rbnf"><![CDATA[
<Update_Request Message> ::= <Common Header> <Update_Request Message> ::= <Common Header>
<Basic Subscriber TLV> <Basic Subscriber TLV>
<IPv6 Subscriber TLV> <IPv6 Subscriber TLV>
<IPv6 Routing TLV> <IPv6 Routing TLV>
[<Subscriber Policy TLV>] [<Subscriber Policy TLV>]
<Update_Response Message> ::= <Common Header> <Update_Response Message> ::= <Common Header>
<Update Response TLV> <Update Response TLV>
]]></artwork> ]]></sourcecode>
</figure></t> </li>
</ol>
</list> </section>
</t> <section anchor="sect-5.1.6" numbered="true" toc="default">
</section> <name>L2 Static Subscriber Access</name>
<t>L2 static subscriber access processes are as follows:</t>
<section title="L2 Static Subscriber Access" anchor="sect-5.1.6"> <figure anchor="fig19">
<name>L2 Static Subscriber Access</name>
<t>L2 static subscriber access processes are as follows:</t> <artwork name="" type="" align="left" alt=""><![CDATA[
<figure title="L2 Static Subscriber Access" anchor="fig19"><artwork><![CD
ATA[
RG UP CP AAA RG UP CP AAA
| | | |
| | Static Subscriber | | | | Static Subscriber | |
| | Detection Req. | | | | Detection Req. | |
| 1|<-----to UP via Ci------| | | 1|<-----to UP via Ci------| |
| | Static Subscriber | | | | Static Subscriber | |
| | Detection Rep. | | | | Detection Rep. | |
| 2|------to UP via Ci----->| | | 2|------to UP via Ci----->| |
| ARP/ND(REQ) | | | | ARP/ND(REQ) | | |
3.1|<--------------| | | 3.1|<--------------| | |
| ARP/ND(ACK) | | | | ARP/ND(ACK) | | |
3.2|-------------->| | | 3.2|-------------->| | |
| | Relay the ARP/ND | | | | Relay the ARP/ND | |
| 3.3|-----to CP via Si------>| AAA | | 3.3|-----to CP via Si------>| AAA |
| | | Req/Rep | | | | Req/Rep |
| | 3.4|<------------->| | | 3.4|<------------->|
| | Create subscriber | | | | Create Subscriber | |
| | session Request | | | | Session Request | |
| 3.5|<--------via Ci---------| | | 3.5|<--------via Ci---------| |
| | Create subscriber | | | | Create Subscriber | |
| | session Response | | | | Session Response | |
| 3.6|---------via Ci-------->| | | 3.6|---------via Ci-------->| |
| | | |
| ARP/ND(REQ) | | | | ARP/ND(REQ) | | |
4.1|-------------->| | | 4.1|-------------->| | |
| | Relay the ARP/ND | | | | Relay the ARP/ND | |
| 4.2|-----to CP via Si------>| AAA | | 4.2|-----to CP via Si------>| AAA |
| | | Req/Rep | | | | Req/Rep |
| | 4.3|<------------->| | | 4.3|<------------->|
| | Create subscriber | | | | Create Subscriber | |
| | session Request | | | | Session Request | |
| 4.4|<--------via Ci---------| | | 4.4|<--------via Ci---------| |
| | Create subscriber | | | | Create Subscriber | |
| | session Response | | | | Session Response | |
| 4.5|---------via Ci-------->| | | 4.5|---------via Ci-------->| |
| ARP/ND(ACK) | | | | ARP/ND(ACK) | | |
4.6|<--------------| | | 4.6|<--------------| | |
| | | |
| IP Traffic | | | | IP Traffic | | |
5.1|-------------->| | | 5.1|-------------->| | |
| | Relay the IP Traffic | | | | Relay the IP Traffic | |
| 5.2|-----to CP via Si------>| AAA | | 5.2|-----to CP via Si------>| AAA |
| | | Req/Rep | | | | Req/Rep |
| | 5.3|<------------->| | | 5.3|<------------->|
| | Create subscriber | | | | Create Subscriber | |
| | session Request | | | | Session Request | |
| 5.4|<--------via Ci-------->| | | 5.4|<--------via Ci-------->| |
| | Create subscriber | | | | Create Subscriber | |
| | session Response | | | | Session Response | |
| 5.5|---------via Ci-------->| | | 5.5|---------via Ci-------->| |
| | | |
| ARP/ND(REQ) | | | | ARP/ND(REQ) | | |
5.6|<--------------| | | 5.6|<--------------| | |
| ARP/ND(ACK) | | | | ARP/ND(ACK) | | |
5.7|-------------->| | | 5.7|-------------->| | |
| | | | | | | |]]></artwork>
]]></artwork> </figure>
</figure> <t>
<t>
For L2 static subscriber access, the process starts with a CP For L2 static subscriber access, the process starts with a CP
installing a static subscriber detection list on a UP. The list installing a static subscriber detection list on a UP. The list
determines which subscribers will be detected. That is implemented determines which subscribers will be detected. That is implemented
by exchanging Update_Request and Update_Response messages between CP by exchanging Update_Request and Update_Response messages between CP
and UP. The format of the messages are as follows:</t> and UP. The formats of the messages are as follows:</t>
<sourcecode type="rbnf"><![CDATA[
<figure><artwork><![CDATA[
<Update_Request Message> ::= <Common Header> <Update_Request Message> ::= <Common Header>
<IPv4 Static Subscriber Detect TLVs> <IPv4 Static Subscriber Detect TLVs>
<IPv6 Static Subscriber Detect TLVs> <IPv6 Static Subscriber Detect TLVs>
<Update_Response Message> ::= <Common Header> <Update_Response Message> ::= <Common Header>
<Update Response TLV> <Update Response TLV>
]]></artwork> ]]></sourcecode>
</figure> <t>
<t> For L2 static subscriber access, there are three ways to trigger the
For L2 Static subscriber access, there are three ways to trigger the
access process:</t> access process:</t>
<ol spacing="normal" type="(%d)">
<t><list style="format (%d)"> <li> Triggered by UP (steps 3.1-3.6): This assumes that the UP knows
the IP
<t> Triggered by UP (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
address, the access interface, and VLAN of the RG. The UP will
actively trigger the access flow by sending an ARP/ND packet to the RG. 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 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 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 authentication process. If the authentication result is positive,
The CP will create a corresponding subscriber session on the UP. the CP will create a corresponding subscriber session on the UP.
</t> </li>
<li> Triggered by RG ARP/ND (steps 4.1-4.6): Most of the process is
<t> Triggered by RG ARP/ND (4.1-4.6): Most of the process is same as the same as
option 1 (triggered by UP). The difference is that the RG will option 1 (triggered by UP). The difference is that the RG will
actively send the ARP/ND to trigger the process. actively send the ARP/ND to trigger the process.
</t> </li>
<li> Triggered by RG IP traffic (steps 5.1-5.7): This is for the cas
<t> Triggered by RG IP traffic (5.1-5.7): This is for the case where e where
the RG has the ARP/ND information, but the subscriber session on the the RG has the ARP/ND information, but the subscriber session on the
UP is lost (e.g., due to failure on the UP, or the UP restarted). UP is lost (e.g., due to failure on the UP or the UP restarting).
That means the RG may keep sending IP packets to the UP. The packets That means the RG may keep sending IP packets to the UP. The packets
will trigger the UP to start a new access process. will trigger the UP to start a new access process.
</t> </li>
</ol>
</list> <t>
</t>
<t>
From a subscriber session point of view, the procedures and the From a subscriber session point of view, the procedures and the
message formats for the above three cases are the same, as follows:</t> message formats for the three cases above are the same, as follows.</t>
<figure><artwork><![CDATA[ <t>IPv4 Case:</t>
IPv4 Case: <sourcecode type="rbnf"><![CDATA[
<Update_Request Message> ::= <Common Header> <Update_Request Message> ::= <Common Header>
<Basic Subscriber TLV> <Basic Subscriber TLV>
<IPv4 Subscriber TLV> <IPv4 Subscriber TLV>
<IPv4 Routing TLV> <IPv4 Routing TLV>
[<Subscriber Policy TLV>] [<Subscriber Policy TLV>]
<Update_Response Message> ::= <Common Header> <Update_Response Message> ::= <Common Header>
<Update Response TLV> <Update Response TLV>
[<Subscriber CGN Port Range TLV>] [<Subscriber CGN Port Range TLV>]
]]></sourcecode>
IPv6 Case: <t>IPv6 Case:</t>
<sourcecode type="rbnf"><![CDATA[
<Update_Request Message> ::= <Common Header> <Update_Request Message> ::= <Common Header>
<Basic Subscriber TLV> <Basic Subscriber TLV>
<IPv6 Subscriber TLV> <IPv6 Subscriber TLV>
<IPv6 Routing TLV> <IPv6 Routing TLV>
[<Subscriber Policy TLV>] [<Subscriber Policy TLV>]
<Update_Response Message> ::= <Common Header> <Update_Response Message> ::= <Common Header>
<Update Response TLV> <Update Response TLV>
]]></artwork> ]]></sourcecode>
</figure> </section>
</section> </section>
</section> <section anchor="sect-5.2" numbered="true" toc="default">
<section title="PPPoE" anchor="sect-5.2"><section title="IPv4 PPPoE Acces <name>PPPoE</name>
s" anchor="sect-5.2.1"> <section anchor="sect-5.2.1" numbered="true" toc="default">
<name>IPv4 PPPoE Access</name>
<t> The following figure shows the IPv4 PPPoE access call flow. <t><xref target="fig20" format="default"/> shows the IPv4 PPPoE access
</t> call flow.
</t>
<figure title="IPv4 PPPoE Access" anchor="fig20"><artwork><![CDATA[ <figure anchor="fig20">
<name>IPv4 PPPoE Access</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
RG UP CP AAA RG UP CP AAA
| | | |
| PPPoE Disc | PPPoE Disc | | | PPPoE Disc | PPPoE Disc | |
1|<------------->|<---------via Si------->| | 1|<------------->|<---------via Si------->| |
| | | | | | | |
| PPP LCP | PPP LCP | | | PPP LCP | PPP LCP | |
2|<------------->|<---------via Si------->| | 2|<------------->|<---------via Si------->| |
| | | AAA | | | | AAA |
| PPP PAP/CHAP | PPP PAP/CHAP | Req/Rep | | PPP PAP/CHAP | PPP PAP/CHAP | Req/Rep |
3|<------------->|<---------via Si------->|<------------->| 3|<------------->|<---------via Si------->|<------------->|
| | | | | | | |
| PPP IPCP | PPP IPCP | | | PPP IPCP | PPP IPCP | |
4|<------------->|<---------via Si------->| | 4|<------------->|<---------via Si------->| |
| | | | | | | |
| | Create subscriber | | | | Create Subscriber | |
| | session Request | | | | Session Request | |
| 5|<--------via Ci---------| | | 5|<--------via Ci---------| |
| | | | | | Create Subscriber | |
| | Create subscriber | | | | Session Response | |
| | session Response | |
| 6|---------via Ci-------->| | | 6|---------via Ci-------->| |
| | | |
| | | Accounting | | | | Accounting |
| | 7|<------------->| | | 7|<------------->|
| | | | | | | |]]></artwork>
]]></artwork> </figure>
</figure> <t>
<t> In the above sequence, steps 1-4 are the standard PPPoE call flow.
From the above sequence, step 1-4 are the standard PPPoE call flow.
The UP is responsible for redirecting the PPPoE control packets to The UP is responsible for redirecting the PPPoE control packets to
the CP or RG. The PPPoE control packets are transmitted between the the CP or RG. The PPPoE control packets are transmitted between the
CP and UP through the Si.</t> CP and UP through the Si.</t>
<t>
<t>
After the PPPoE call flow, if the subscriber passed the AAA After the PPPoE call flow, if the subscriber passed the AAA
authentication and authorization, the CP will create a corresponding authentication and authorization, the CP will create a corresponding
session on the UP through the Ci. The formats of the messages are as session on the UP through the Ci. The formats of the messages are as
follows:</t> follows:</t>
<sourcecode type="rbnf"><![CDATA[
<figure><artwork><![CDATA[
<Update_Request Message> ::= <Common Header> <Update_Request Message> ::= <Common Header>
<Basic Subscriber TLV> <Basic Subscriber TLV>
<PPP Subscriber TLV> <PPP Subscriber TLV>
<IPv4 Subscriber TLV> <IPv4 Subscriber TLV>
<IPv4 Routing TLV> <IPv4 Routing TLV>
[<Subscriber Policy TLV>] [<Subscriber Policy TLV>]
<Update_Response Message> ::= <Common Header> <Update_Response Message> ::= <Common Header>
<Update Response TLV> <Update Response TLV>
[<Subscriber CGN Port Range TLV>] [<Subscriber CGN Port Range TLV>]
]]></artwork> ]]></sourcecode>
</figure> </section>
</section> <section anchor="sect-5.2.2" numbered="true" toc="default">
<name>IPv6 PPPoE Access</name>
<section title="IPv6 PPPoE Access" anchor="sect-5.2.2"> <t><xref target="fig21" format="default"/> describes the IPv6 PPPoE ac
cess call flow.</t>
<t>The following figure describes the IPv6 PPPoE access call flow.</t> <figure anchor="fig21">
<name>IPv6 PPPoE Access</name>
<figure title="IPv6 PPPoE Access" anchor="fig21"><artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
RG UP CP AAA RG UP CP AAA
| | | |
| PPPoE Disc | PPPoE Disc | | | PPPoE Disc | PPPoE Disc | |
1|<------------->|<--------via Si-------->| | 1|<------------->|<--------via Si-------->| |
| | | | | | | |
| PPP LCP | PPP LCP | | | PPP LCP | PPP LCP | |
2|<------------->|<---------via Si------->| | 2|<------------->|<---------via Si------->| |
| | | AAA | | | | AAA |
| PPP PAP/CHAP | PPP PAP/CHAP | Req/Rep | | PPP PAP/CHAP | PPP PAP/CHAP | Req/Rep |
3|<------------->|<---------via Si------->|<------------->| 3|<------------->|<---------via Si------->|<------------->|
| | | | | | | |
| PPP IP6CP | PPP IP6CP | | | PPP IP6CP | PPP IP6CP | |
4|<------------->|<---------via Si------->| | 4|<------------->|<---------via Si------->| |
| | | | | | | |
| | Create subscriber | | | | Create Subscriber | |
| | session Request | | | | Session Request | |
| 5|<--------via Ci---------| | | 5|<--------via Ci---------| |
| | | | | | Create Subscriber | |
| | Create subscriber | | | | Session Response | |
| | session Response | |
| 6|---------via Ci-------->| | | 6|---------via Ci-------->| |
| | | | | | | |
| ND Negotiation| ND Negotiation | | | ND Negotiation| ND Negotiation | |
7|<------------->|<---------via Si------->| | 7|<------------->|<---------via Si------->| |
| | | | | | | |
| | Update subscriber | | | | Update Subscriber | |
| | session Request | | | | Session Request | |
| 8|<--------via Ci---------| | | 8|<--------via Ci---------| |
| | | | | | Update Subscriber | |
| | Update subscriber | | | | Session Response | |
| | session Response | |
| 9|---------via Ci-------->| | | 9|---------via Ci-------->| |
| | | |
| | | Accounting | | | | Accounting |
| | 10|<------------->| | | 10|<------------->|
| | | |
| DHCPv6 | DHCPv6 | | | DHCPv6 | DHCPv6 | |
| Negotiation | Negotiation | | | Negotiation | Negotiation | |
7'|<------------->|<---------via Si------->| | 7'|<------------->|<---------via Si------->| |
| | | | | | | |
| | Update subscriber | | | | Update Subscriber | |
| | session Request | | | | Session Request | |
| 8'|<---------via Ci--------| | | 8'|<---------via Ci--------| |
| | | | | | Update Subscriber | |
| | Update subscriber | | | | Session Response | |
| | session Response | |
| 9'|---------via Ci-------->| | | 9'|---------via Ci-------->| |
| | | |
| | | Accounting | | | | Accounting |
| | 10'|<------------->| | | 10'|<------------->|
| | | | | | | |]]></artwork>
]]></artwork> </figure>
</figure> <t>
<t>
From the above sequence, steps 1-4 are the standard PPPoE call flow. 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 UP is responsible for redirecting the PPPoE control packets to
the CP or RG. The PPPoE control packets are transmitted between the the CP or RG. The PPPoE control packets are transmitted between the
CP and UP through the Si.</t> CP and UP through the Si.</t>
<t>
<t>
After the PPPoE call flow, if the subscriber passed the AAA After the PPPoE call flow, if the subscriber passed the AAA
authentication and authorization, the CP will create a corresponding authentication and authorization, the CP will create a corresponding
session on the UP through the Ci. The formats of the messages are as session on the UP through the Ci. The formats of the messages are as
follows:</t> follows:</t>
<sourcecode type="rbnf"><![CDATA[
<figure><artwork><![CDATA[
<Update_Request Message> ::= <Common Header> <Update_Request Message> ::= <Common Header>
<Basic Subscriber TLV> <Basic Subscriber TLV>
<PPP Subscriber TLV> <PPP Subscriber TLV>
<IPv6 Subscriber TLV> <IPv6 Subscriber TLV>
<IPv6 Routing TLV> <IPv6 Routing TLV>
[<Subscriber Policy TLV>] [<Subscriber Policy TLV>]
<Update_Response Message> ::= <Common Header> <Update_Response Message> ::= <Common Header>
<Update Response TLV> <Update Response TLV>
]]></artwork> ]]></sourcecode>
</figure> <t>
<t>
Then, the RG will initialize an ND/DHCPv6 negotiation process with Then, the RG will initialize an ND/DHCPv6 negotiation process with
the CP (see step 7 and 7'), after that, it will trigger an update the CP (see steps 7 and 7'); after that, it will trigger an update
(8-9, 8'-9') to the subscriber session. The formats of the update (steps 8-9 and 8'-9') to the subscriber session. The formats of the update
messages are as follows:</t> messages are as follows:</t>
<sourcecode type="rbnf"><![CDATA[
<figure><artwork><![CDATA[
<Update_Request Message> ::= <Common Header> <Update_Request Message> ::= <Common Header>
<Basic Subscriber TLV> <Basic Subscriber TLV>
<PPP Subscriber TLV> <PPP Subscriber TLV>
<IPv6 Subscriber TLV> <IPv6 Subscriber TLV>
<IPv6 Routing TLV> <IPv6 Routing TLV>
[<Subscriber Policy TLV>] [<Subscriber Policy TLV>]
<Update_Response Message> ::= <Common Header> <Update_Response Message> ::= <Common Header>
<Update Response TLV> <Update Response TLV>
]]></artwork> ]]></sourcecode>
</figure> </section>
</section> <section anchor="sect-5.2.3" numbered="true" toc="default">
<name>PPPoE Dual-Stack Access</name>
<section title="PPPoE Dual Stack Access" anchor="sect-5.2.3"><t> <t>
The following figure shows a combination of IPv4 and IPv6 PPPoE <xref target="fig22" format="default"/> shows a combination of IPv4 and IPv6
access call flow.</t> PPPoE
access call flows.</t>
<figure title="PPPoE Dual Stack Access" anchor="fig22"><artwork><![CDATA[ <figure anchor="fig22">
<name>PPPoE Dual-Stack Access</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
RG UP CP AAA RG UP CP AAA
| | | |
|PPPoE Discovery| PPPoE Discovery | | |PPPoE Discovery| PPPoE Discovery | |
1|<------------->|<---------via Si------->| | 1|<------------->|<---------via Si------->| |
| | | | | | | |
| PPP LCP | PPP LCP | | | PPP LCP | PPP LCP | |
2|<------------->|<---------via Si------->| | 2|<------------->|<---------via Si------->| |
| | | AAA | | | | AAA |
| PPP PAP/CHAP | PPP PAP/CHAP | Req/Rep | | PPP PAP/CHAP | PPP PAP/CHAP | Req/Rep |
3|<------------->|<---------via Si------->|<------------->| 3|<------------->|<---------via Si------->|<------------->|
| | | | | | | |
| PPP IPCP | PPP IPCP | | | PPP IPCP | PPP IPCP | |
4|<------------->|<---------via Si------->| | 4|<------------->|<---------via Si------->| |
| | | | | | | |
| | Create v4 subscriber | | | | Create v4 Subscriber | |
| | session Request | | | | Session Request | |
| 5|<--------via Ci---------| | | 5|<--------via Ci---------| |
| | Create v4 subscriber | | | | Create v4 Subscriber | |
| | session Response | | | | Session Response | |
| 6|---------via Ci-------->| | | 6|---------via Ci-------->| |
| | | Accounting | | | | Accounting |
| | 7|<------------->| | | 7|<------------->|
| PPP IP6CP | PPP IP6CP | | | PPP IP6CP | PPP IP6CP | |
4'|<------------->|<---------via Si------->| | 4'|<------------->|<---------via Si------->| |
| | | | | | | |
| | Create V6 subscriber | | | | Create V6 Subscriber | |
| | session Request | | | | Session Request | |
| 5'|<--------via Ci---------| | | 5'|<--------via Ci---------| |
| | Create v6 subscriber | | | | Create v6 Subscriber | |
| | session Response | | | | Session Response | |
| 6'|---------via Ci-------->| | | 6'|---------via Ci-------->| |
| | | | | | | |
| ND Negotiation| ND Negotiation | | | ND Negotiation| ND Negotiation | |
8|<------------->|<---------via Si------->| | 8|<------------->|<---------via Si------->| |
| | | | | | | |
| | Update v6 subscriber | | | | Update v6 Subscriber | |
| | session Request | | | | Session Request | |
| 9|<---------via Ci--------| | | 9|<---------via Ci--------| |
| | Update v6 subscriber | | | | Update v6 Subscriber | |
| | session Response | | | | Session Response | |
| 10|---------via Ci-------->| | | 10|---------via Ci-------->| |
| | | Accounting | | | | Accounting |
| | 7'|<------------->| | | 7'|<------------->|
| DHCPv6 | DHCPv6 | | | DHCPv6 | DHCPv6 | |
| Negotiation | Negotiation | | | Negotiation | Negotiation | |
8'|<------------->|<---------via Si------->| | 8'|<------------->|<---------via Si------->| |
| | | | | | | |
| | Update v6 subscriber | | | | Update v6 Subscriber | |
| | session Request | | | | Session Request | |
| 9'|<--------via Ci---------| | | 9'|<--------via Ci---------| |
| | | | | | Update v6 Subscriber | |
| | Update v6 subscriber | | | | Session Response | |
| | session Response | |
| 10'|---------via Ci-------->| | | 10'|---------via Ci-------->| |
| | | |
| | | Accounting | | | | Accounting |
| | 7"|<------------->| | | 7"|<------------->|
| | | | | | | |]]></artwork>
]]></artwork> </figure>
</figure> <t>
<t>
PPPoE dual stack is a combination of IPv4 PPPoE and IPv6 PPPoE 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 access. The process is as above. The formats of the messages are as
follows:</t> follows:</t>
<ol spacing="normal" type="(%d)">
<li>
<t> Create an IPv4 PPPoE subscriber session (steps 5-6):
<t><list style="format (%d)"> </t>
<sourcecode type="rbnf"><![CDATA[
<t> Create an IPv4 PPPoE subscriber session (5-6)
<figure><artwork><![CDATA[
<Update_Request Message> ::= <Common Header> <Update_Request Message> ::= <Common Header>
<Basic Subscriber TLV> <Basic Subscriber TLV>
<PPP Subscriber TLV> <PPP Subscriber TLV>
<IPv4 Subscriber TLV> <IPv4 Subscriber TLV>
<IPv4 Routing TLV> <IPv4 Routing TLV>
[<Subscriber Policy TLV>] [<Subscriber Policy TLV>]
<Update_Response Message> ::= <Common Header> <Update_Response Message> ::= <Common Header>
<Update Response TLV> <Update Response TLV>
[<Subscriber CGN Port Range TLV>] [<Subscriber CGN Port Range TLV>]
]]></artwork> ]]></sourcecode>
</figure></t> </li>
<li>
<t> Create an IPv6 PPPoE subscriber session (5'-6') <t> Create an IPv6 PPPoE subscriber session (steps 5'-6'):
<figure><artwork><![CDATA[ </t>
<sourcecode type="rbnf"><![CDATA[
<Update_Request Message> ::= <Common Header> <Update_Request Message> ::= <Common Header>
<Basic Subscriber TLV> <Basic Subscriber TLV>
<PPP Subscriber TLV> <PPP Subscriber TLV>
<IPv6 Subscriber TLV> <IPv6 Subscriber TLV>
<IPv6 Routing TLV> <IPv6 Routing TLV>
[<Subscriber Policy TLV>] [<Subscriber Policy TLV>]
<Update_Response Message> ::= <Common Header> <Update_Response Message> ::= <Common Header>
<Update Response TLV> <Update Response TLV>
]]></artwork> ]]></sourcecode>
</figure></t> </li>
<li>
<t> Update the IPv6 PPPoE subscriber session (9-10, 9'-10') <t> Update the IPv6 PPPoE subscriber session (steps 9-10 and 9'-10
'):
<figure><artwork><![CDATA[ </t>
<sourcecode type="rbnf"><![CDATA[
<Update_Request Message> ::= <Common Header> <Update_Request Message> ::= <Common Header>
<Basic Subscriber TLV> <Basic Subscriber TLV>
<PPP Subscriber TLV> <PPP Subscriber TLV>
<IPv6 Subscriber TLV> <IPv6 Subscriber TLV>
<IPv6 Routing TLV> <IPv6 Routing TLV>
[<Subscriber Policy TLV>] [<Subscriber Policy TLV>]
<Update_Response Message> ::= <Common Header> <Update_Response Message> ::= <Common Header>
<Update Response TLV> <Update Response TLV>
]]></artwork> ]]></sourcecode>
</figure></t> </li>
</ol>
</list> </section>
</t>
</section> </section>
</section> <section anchor="sect-5.3" numbered="true" toc="default">
<name>WLAN Access</name>
<section title="WLAN Access" anchor="sect-5.3"> <t><xref target="fig23" format="default"/> shows the WLAN access call fl
ow.</t>
<t>The following figure shows the WLAN access call flow.</t> <figure anchor="fig23">
<name>WLAN Access</name>
<figure title="WLAN Access" anchor="fig23"><artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
RG UP CP AAA WEB Server RG UP CP AAA Web Server
| | | | |
| DHCP | | | | | DHCP | | | |
| Discovery | | | | | Discovery | | | |
1|------------>| | | | 1|------------>| | | |
| | DHCP | | | | | DHCP Discovery | | |
| | Discovery | | |
| 2|-----via Si---->| AAA | | | 2|-----via Si---->| AAA | |
| | DHCP Offer |<-------->| | | | DHCP Offer |<-------->| |
| 3|<----via Si-----| | | | 3|<----via Si-----| | |
| DHCP Offer | | | | | DHCP Offer | | | |
4|<------------| | | | 4|<------------| | | |
| DHCP | | | | | DHCP Request| | | |
| Request | | | |
5|------------>| | | | 5|------------>| | | |
| | DHCP Request | | | | | DHCP Request | | |
| 6|-----via Si---->| | | | 6|-----via Si---->| | |
| | | | | | | | | |
| | Create session | | | | | Create Session | | |
| | Request | | | | | Request | | |
| 7|<----via Ci-----| | | | 7|<----via Ci-----| | |
| | Create session | | | | | Create Session | | |
| | Response | | | | | Response | | |
| 8|----via Ci----->| | | | 8|----via Ci----->| | |
| | | | | | | | | |
| | DHCP ACK | | | | | DHCP ACK | | |
| 9|<----via Si-----| | | | 9|<----via Si-----| | |
| | | | |
| DHCP ACK | | | | | DHCP ACK | | | |
10|<------------| | | | 10|<------------| | | |
| | | | | | | | | |
| Subscriber | | | | | Subscriber | | | |
| HTTP Traffic| | | | | HTTP Traffic| | | |
11|------------>|--> | | | 11|------------>|--> | | |
| | | WEB URL | | | | | | Web URL | | |
| Traffic | | Redirect | | | | Traffic | | Redirect | | |
| Redirection | | | | | | Redirection | | | | |
12|<------------|<-+ | | | 12|<------------|<-+ | | |
| | | |
| | | |
13|-----------------Redirect to Web server------------->| 13|-----------------Redirect to Web Server------------->|
| | | |
14|<----------------Push HTTP log-in page---------------| 14|<----------------Push HTTP Log-in Page---------------|
| | | |
15|-----------------User Authentication---------------->| 15|-----------------User Authentication---------------->|
| | | |
| | | Portal Interchange | | | | Portal Interchange |
| | 16|<-------------------->| | | 16|<-------------------->|
| | | | | | | |
| | | AAA | | | | | AAA | |
| | | Req/Rep | | | | | Req/Rep | |
| | 17|<-------->| | | | 17|<-------->| |
| | | | | | | | | |
| | Update session | | | | | Update Session | | |
| | Request | | | | | Request | | |
| 18|<----via Ci-----| | | | 18|<----via Ci-----| | |
| | | | | | | Update Session | | |
| | Update session | | |
| | Response | | | | | Response | | |
| 19|-----via Ci---->| | | | 19|-----via Ci---->| | |
| | | | | | | | | |]]></artwork>
]]></artwork> </figure>
</figure> <t>
<t> WLAN access starts with the DHCP dial-up process (steps 1-6). After
WLAN access starts with the DHCP dial-up process (steps 1-6), after that, the CP will create a subscriber session on the UP (steps 7-8).
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> The formats of the session creation messages are as follows:</t>
<figure><artwork><![CDATA[ <t>IPv4 Case:</t>
IPv4 Case: <sourcecode type="rbnf"><![CDATA[
<Update_Request Message> ::= <Common Header> <Update_Request Message> ::= <Common Header>
<Basic Subscriber TLV> <Basic Subscriber TLV>
<IPv4 Subscriber TLV> <IPv4 Subscriber TLV>
<IPv4 Routing TLV> <IPv4 Routing TLV>
[<Subscriber Policy TLV>] [<Subscriber Policy TLV>]
<Update_Response Message> ::= <Common Header> <Update_Response Message> ::= <Common Header>
<Update Response TLV> <Update Response TLV>
[<Subscriber CGN Port Range TLV>] [<Subscriber CGN Port Range TLV>]
]]></sourcecode>
IPv6 Case: <t>IPv6 Case:</t>
<sourcecode type="rbnf"><![CDATA[
<Update_Request Message> ::= <Common Header> <Update_Request Message> ::= <Common Header>
<Basic Subscriber TLV> <Basic Subscriber TLV>
<IPv6 Subscriber TLV> <IPv6 Subscriber TLV>
<IPv6 Routing TLV> <IPv6 Routing TLV>
[<Subscriber Policy TLV>] [<Subscriber Policy TLV>]
<Update_Response Message> ::= <Common Header> <Update_Response Message> ::= <Common Header>
<Update Response TLV> <Update Response TLV>
]]></artwork> ]]></sourcecode>
</figure> <t>
<t> After step 10, the RG will be allocated an IP address, and its first
After step 10, the RG will be allocated an IP address and its first HTTP packet will be redirected to a web server for subscriber
HTTP packet will be redirected to a WEB server for subscriber authentication (steps 11-17). After the web authentication, if the
authentication (steps 11-17). After the WEB authentication, if the
result is positive, the CP will update the subscriber session by result is positive, the CP will update the subscriber session by
using the following message exchanges:</t> using the following message exchanges:</t>
<figure><artwork><![CDATA[ <t>IPv4 Case:</t>
IPv4 Case: <Update_Request Message> ::= <Common Header> <sourcecode type="rbnf"><![CDATA[
<Update_Request Message> ::= <Common Header>
<Basic Subscriber TLV> <Basic Subscriber TLV>
<IPv4 Subscriber TLV> <IPv4 Subscriber TLV>
<IPv4 Routing TLV> <IPv4 Routing TLV>
[<Subscriber Policy TLV>] [<Subscriber Policy TLV>]
<Update_Response Message> ::= <Common Header> <Update_Response Message> ::= <Common Header>
<Update Response TLV> <Update Response TLV>
[<Subscriber CGN Port Range TLV>] [<Subscriber CGN Port Range TLV>]
]]></sourcecode>
IPv6 Case: <Update_Request Message> ::= <Common Header> <t>IPv6 Case:</t>
<sourcecode type="rbnf"><![CDATA[
<Update_Request Message> ::= <Common Header>
<Basic Subscriber TLV> <Basic Subscriber TLV>
<IPv6 Subscriber TLV> <IPv6 Subscriber TLV>
<IPv6 Routing TLV> <IPv6 Routing TLV>
[<Subscriber Policy TLV>] [<Subscriber Policy TLV>]
<Update_Response Message> ::= <Common Header> <Update_Response Message> ::= <Common Header>
<Update Response TLV> <Update Response TLV>
]]></artwork> ]]></sourcecode>
</figure> </section>
</section> <section anchor="sect-5.4" numbered="true" toc="default">
<name>L2TP</name>
<section title="L2TP" anchor="sect-5.4"><section title="L2TP LAC Access" <section anchor="sect-5.4.1" numbered="true" toc="default">
anchor="sect-5.4.1"><figure title="L2TP-LAC Access" anchor="fig24"><artwork><![C <name>L2TP LAC Access</name>
DATA[ <figure anchor="fig24">
<name>L2TP LAC Access</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
RG UP(LAC) CP(LAC) AAA LNS RG UP(LAC) CP(LAC) AAA LNS
| | | | |
| PPPoE | PPPoE | | | | PPPoE | PPPoE | | |
| Discovery | Discovery | | | | Discovery | Discovery | | |
1|<---------->|<---via Si--->| | | 1|<---------->|<---via Si--->| | |
| | | | | | | | | |
| PPP LCP | PPP LCP | | | | PPP LCP | PPP LCP | | |
2|<---------->|<---via Si--->| | | 2|<---------->|<---via Si--->| | |
| | | AAA | | | | | AAA | |
|PPP PAP/CHAP| PPP PAP/CHAP | Req/Rep| | |PPP PAP/CHAP| PPP PAP/CHAP | Req/Rep| |
3|<---------->|<---via Si--->|<------>| | 3|<---------->|<---via Si--->|<------>| |
| | | | | | | | | |
| PPP IPCP | PPP IPCP | | | | PPP IPCP | PPP IPCP | | |
4|<---------->|<---via Si--->| | | 4|<---------->|<---via Si--->| | |
| | | | | | | | | |
| | L2TP tunnel | | | | | L2TP Tunnel | | |
| | negotiation | | | | | Negotiation | | |
| | SCCRQ/ | | | | | SCCRQ/ | | |
| | SCCRP/ | | | | | SCCRP/ | | |
| | SCCCN | | | | | SCCCN | | |
| 5|<---via Si--->| | | | 5|<---via Si--->| | |
| | /\ | | | /\ |
| | || forward | | | || Forward |
| | \/ | | | \/ |
| |<-----------via routing---------->| | |<-----------via Routing---------->|
| | | | | |
| | L2TP session | | | | | L2TP Session | | |
| | negotiation | | | | | Negotiation | | |
| | ICRQ/ | | | | | ICRQ/ | | |
| | ICRP/ | | | | | ICRP/ | | |
| | ICCN | | | | | ICCN | | |
| 6|<---via Si--->| | | | 6|<---via Si--->| | |
| | /\ | | | /\ |
| | || forward | | | || Forward |
| | \/ | | | \/ |
| |<-----------via routing---------->| | |<-----------via Routing---------->|
| | | | | |
| | Create | | | | | Create | | |
| | subscriber | | | | | Subscriber | | |
| | session | | | | | Session Req | | |
| | Request | | |
| 7|<---via Ci----| | | | 7|<---via Ci----| | |
| | | | |
| | Create | | | | | Create | | |
| | subscriber | | | | | Subscriber | | |
| | session | | | | | Session Rep | | |
| | Response | | |
| 8|----via Ci--->| | | | 8|----via Ci--->| | |
| | | | | | | | | |
| | | |
| PAP/CHAP (Triggered by LNS) | | PAP/CHAP (Triggered by LNS) |
9|<-----------------via routing?---------------->| 9|<-----------------via Routing----------------->|
| | | |]]></artwork>
]]></artwork> </figure>
</figure> <t>
<t>
Steps 1-4 are a standard PPPoE access process. After that, the LAC-CP 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 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 negotiation, the CP will create an L2TP LAC subscriber session on the UP
through the following messages:</t> through the following messages:</t>
<sourcecode type="rbnf"><![CDATA[
<figure><artwork><![CDATA[
<Update_Request Message> ::= <Common Header> <Update_Request Message> ::= <Common Header>
<Basic Subscriber TLV> <Basic Subscriber TLV>
<L2TP-LAC Subscriber TLV> <L2TP-LAC Subscriber TLV>
<L2TP-LAC Tunnel TLV> <L2TP-LAC Tunnel TLV>
<Update_Response Message> ::= <Common Header> <Update_Response Message> ::= <Common Header>
<Update Response TLV> <Update Response TLV>
]]></artwork> ]]></sourcecode>
</figure> </section>
</section> <section anchor="sect-5.4.2" numbered="true" toc="default">
<name>L2TP LNS IPv4 Access</name>
<section title="L2TP LNS IPv4 Access" anchor="sect-5.4.2"><figure title=" <figure anchor="fig25">
IPv4 L2TP-LNS Access" anchor="fig25"><artwork><![CDATA[ <name>L2TP LNS IPv4 Access</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
RG LAC UP(LNS) AAA CP(LNS) RG LAC UP(LNS) AAA CP(LNS)
| | | | |
| PPPoE | | | | | PPPoE | | | |
| Discovery | | | | | Discovery | | | |
1|<---------->| | | | 1|<---------->| | | |
| | | | | | | | | |
| PPP LCP | | | | | PPP LCP | | | |
2|<---------->| | | 2|<---------->| | |
| | AAA | | | | AAA | |
|PPP PAP/CHAP| Req/Rep | | |PPP PAP/CHAP| Req/Rep | |
3|<---------->|<--------------------->| | 3|<---------->|<--------------------->| |
| | | | | |
| | | | | L2TP Tunnel | L2TP Tunnel |
| | L2TP tunnel | L2TP tunnel | | | Negotiation | Negotiation |
| | negotiation | negotiation |
| | SCCRQ/ | SCCRQ/ | | | SCCRQ/ | SCCRQ/ |
| | SCCRP/ | SCCRP/ | | | SCCRP/ | SCCRP/ |
| | SCCCN | SCCCN | | | SCCCN | SCCCN |
| 4|<------------>|<------via Si----->| | 4|<------------>|<------via Si----->|
| | | | | | | |
| | L2TP session | L2TP session | | | L2TP Session | L2TP Session |
| | negotiation | negotiation | | | Negotiation | Negotiation |
| | ICRQ/ | ICRQ/ | | | ICRQ/ | ICRQ/ |
| | ICRP/ | ICRP/ | | | ICRP/ | ICRP/ |
| | ICCN | ICCN | | | ICCN | ICCN |
| 5|<------------>|<------via Si----->| | 5|<------------>|<------via Si----->|
| | | | | | | |
| | | Create | | | | Create Subscriber |
| | | subscriber | | | | Session Request |
| | | session |
| | | Request |
| | 6|<-----via Ci-------| | | 6|<-----via Ci-------|
| | | Create | | | | Create Subscriber |
| | | subscriber | | | | Session Response |
| | | session |
| | | Response |
| | 7|------via Ci------>| | | 7|------via Ci------>|
| | | |
| PAP/CHAP (Triggered by LNS) | | PAP/CHAP (Triggered by LNS) |
8|<--------------------------------------------->| 8|<--------------------------------------------->|
| | | |
| | | | AAA | | | | | AAA |
| | | | Req/Rep | | | | | Req/Rep |
| | | 9|<-------->| | | | 9|<-------->|
| | | | | | | |
| | | |
| PPP IPCP | | PPP IPCP |
10|<--------------------------------------------->| 10|<--------------------------------------------->|
| | | |
| | | Update | | | | Update Subscriber |
| | | subscriber | | | | Session Request |
| | | session |
| | | Request |
| | 11|<-----via Ci-------| | | 11|<-----via Ci-------|
| | | Update | | | | Update Subscriber |
| | | subscriber | | | | Session Response |
| | | session |
| | | Response |
| | 12|------via Ci------>| | | 12|------via Ci------>|
| | | | | | | |]]></artwork>
]]></artwork> </figure>
</figure> <t>
<t>
In this case, the BNG is running as an LNS and separated into LNS-CP 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 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 the L2TP session and tunnel negotiations are finished, the LNS-CP
will create an L2TP LNS subscriber session on the LNS-UP. The format will create an L2TP LNS subscriber session on the LNS-UP. The format
of the messages is as follows:</t> of the messages is as follows:</t>
<sourcecode type="rbnf"><![CDATA[
<figure><artwork><![CDATA[
<Update_Request Message> ::= <Common Header> <Update_Request Message> ::= <Common Header>
<L2TP-LNS Subscriber TLV> <L2TP-LNS Subscriber TLV>
<Basic Subscriber TLV> <Basic Subscriber TLV>
<PPP Subscriber TLV> <PPP Subscriber TLV>
<IPv4 Subscriber TLV> <IPv4 Subscriber TLV>
<IPv4 Routing TLV> <IPv4 Routing TLV>
<L2TP-LNS Tunnel TLV> <L2TP-LNS Tunnel TLV>
[<Subscriber Policy TLV>] [<Subscriber Policy TLV>]
<Update_Response Message> ::= <Common Header> <Update_Response Message> ::= <Common Header>
<Update Response TLV> <Update Response TLV>
[<Subscriber CGN Port Range TLV>] [<Subscriber CGN Port Range TLV>]
]]></artwork> ]]></sourcecode>
</figure> <t>
<t> After that, the LNS-CP will trigger a AAA authentication. If the
After that, the LNS-CP will trigger an AAA authentication. If the authentication result is positive, a PPP IP Control Protocol (IPCP) process
authentication result is positive, a PPP IPCP process will follow, will follow, and
then the CP will update the session with the following message then the CP will update the session with the following message
exchanges:</t> exchanges:</t>
<sourcecode type="rbnf"><![CDATA[
<figure><artwork><![CDATA[
<Update_Request Message> ::= <Common Header> <Update_Request Message> ::= <Common Header>
<L2TP-LNS Subscriber TLV> <L2TP-LNS Subscriber TLV>
<Basic Subscriber TLV> <Basic Subscriber TLV>
<PPP Subscriber TLV> <PPP Subscriber TLV>
<IPv4 Subscriber TLV> <IPv4 Subscriber TLV>
<IPv4 Routing TLV> <IPv4 Routing TLV>
<L2TP-LNS Tunnel TLV> <L2TP-LNS Tunnel TLV>
[<Subscriber Policy TLV>] [<Subscriber Policy TLV>]
<Update_Response Message> ::= <Common Header> <Update_Response Message> ::= <Common Header>
<Update Response TLV> <Update Response TLV>
[<Subscriber CGN Port Range TLV>] [<Subscriber CGN Port Range TLV>]
]]></artwork> ]]></sourcecode>
</figure> </section>
</section> <section anchor="sect-5.4.3" numbered="true" toc="default">
<name>L2TP LNS IPv6 Access</name>
<section title="L2TP LNS IPv6 Access" anchor="sect-5.4.3"><figure title=" <figure anchor="fig26">
L2TP-LNS IPv6 Access" anchor="fig26"><artwork><![CDATA[ <name>L2TP LNS IPv6 Access</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
RG LAC UP(LNS) AAA CP(LNS) RG LAC UP(LNS) AAA CP(LNS)
| | | | |
| PPPoE | | | | | PPPoE | | | |
| Discovery | | | | | Discovery | | | |
1|<---------->| | | | 1|<---------->| | | |
| | | | | | | | | |
| PPP LCP | | | | | PPP LCP | | | |
2|<---------->| | | 2|<---------->| | |
| | AAA | | | | AAA | |
|PPP PAP/CHAP| Req/Rep | | |PPP PAP/CHAP| Req/Rep | |
3|<---------->|<--------------------->| | 3|<---------->|<--------------------->| |
| | | | | |
| | | | | L2TP Tunnel | L2TP Tunnel |
| | L2TP tunnel | L2TP tunnel | | | Negotiation | Negotiation |
| | negotiation | negotiation |
| | SCCRQ/ | SCCRQ/ | | | SCCRQ/ | SCCRQ/ |
| | SCCRP/ | SCCRP/ | | | SCCRP/ | SCCRP/ |
| | SCCCN | SCCCN | | | SCCCN | SCCCN |
| 4|<------------>|<------via Si----->| | 4|<------------>|<------via Si----->|
| | | | | | | |
| | L2TP session | L2TP session | | | L2TP Session | L2TP Session |
| | negotiation | negotiation | | | Negotiation | Negotiation |
| | ICRQ/ | ICRQ/ | | | ICRQ/ | ICRQ/ |
| | ICRP/ | ICRP/ | | | ICRP/ | ICRP/ |
| | ICCN | ICCN | | | ICCN | ICCN |
| 5|<------------>|<------via Si----->| | 5|<------------>|<------via Si----->|
| | | | | | | |
| | | Create | | | | Create Subscriber |
| | | subscriber | | | | Session Request |
| | | session |
| | | Request |
| | 6|<-----via Ci-------| | | 6|<-----via Ci-------|
| | | Create | | | | Create Subscriber |
| | | subscriber | | | | Session Response |
| | | session |
| | | Response |
| | 7|------via Ci------>| | | 7|------via Ci------>|
| | | |
| PAP/CHAP (Triggered by LNS) | | PAP/CHAP (Triggered by LNS) |
8|<--------------------------------------------->| 8|<--------------------------------------------->|
| | | |
| | | | AAA | | | | | AAA |
| | | | Req/Rep | | | | | Req/Rep |
| | | 9|<-------->| | | | 9|<-------->|
| | | | | | | | | |
| | | |
| PPP IP6CP | | PPP IP6CP |
10|<--------------------------------------------->| 10|<--------------------------------------------->|
| | | |
| | | Update | | | | Update Subscriber |
| | | subscriber | | | | Session Request |
| | | session |
| | | Request |
| | 11|<-----via Ci-------| | | 11|<-----via Ci-------|
| | | Update | | | | Update Subscriber |
| | | subscriber | | | | Session Response |
| | | session |
| | | Response |
| | 12|------via Ci------>| | | 12|------via Ci------>|
| | | |
| | | | | |
| ND negotiation | ND negotiation | | ND Negotiation | ND Negotiation |
13|<------------------------->|<-----via Si------>| 13|<------------------------->|<-----via Si------>|
| | | | | |
| | | Update | | | | Update Subscriber |
| | | subscriber | | | | Session Request |
| | | session |
| | | Request |
| | 14|<-----via Ci-------| | | 14|<-----via Ci-------|
| | | Update | | | | Update Subscriber |
| | | subscriber | | | | Session Response |
| | | session |
| | | Response |
| | 15|------via Ci------>| | | 15|------via Ci------>|
| | | | | | | |]]></artwork>
]]></artwork> </figure>
</figure>
<t> <t>
Steps 1-12 are the same as L2TP and LNS IPv4 Access. Steps 1-5 Steps 1-12 are the same as L2TP LNS IPv4 access. Steps 1-5
finish the normal L2TP dial-up process. When the L2TP session and finish the normal L2TP dial-up process. When the L2TP session and
tunnel negotiations are finished, the LNS-CP will create an L2TP LNS 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 subscriber session on the LNS-UP. The format of the messages is as
follows:</t> follows:</t>
<sourcecode type="rbnf"><![CDATA[
<figure><artwork><![CDATA[
<Update_Request Message> ::= <Common Header> <Update_Request Message> ::= <Common Header>
<L2TP-LNS Subscriber TLV> <L2TP-LNS Subscriber TLV>
<Basic Subscriber TLV> <Basic Subscriber TLV>
<PPP Subscriber TLV> <PPP Subscriber TLV>
<IPv6 Subscriber TLV> <IPv6 Subscriber TLV>
<IPv6 Routing TLV> <IPv6 Routing TLV>
<L2TP-LNS Tunnel TLV> <L2TP-LNS Tunnel TLV>
[<Subscriber Policy TLV>] [<Subscriber Policy TLV>]
<Update_Response Message> ::= <Common Header> <Update_Response Message> ::= <Common Header>
<Update Response TLV> <Update Response TLV>
]]></artwork> ]]></sourcecode>
</figure> <t>
<t>
After that, the LNS-CP will trigger a AAA authentication. If the After that, the LNS-CP will trigger a AAA authentication. If the
authentication result is positive, a PPP IP6CP process will follow, authentication result is positive, a PPP IP6CP process will follow, and
then the CP will update the session with the following message then the CP will update the session with the following message
exchanges:</t> exchanges:</t>
<sourcecode type="rbnf"><![CDATA[
<figure><artwork><![CDATA[
<Update_Request Message> ::= <Common Header> <Update_Request Message> ::= <Common Header>
<L2TP-LNS Subscriber TLV> <L2TP-LNS Subscriber TLV>
<Basic Subscriber TLV> <Basic Subscriber TLV>
<PPP Subscriber TLV> <PPP Subscriber TLV>
<IPv6 Subscriber TLV> <IPv6 Subscriber TLV>
<IPv6 Routing TLV> <IPv6 Routing TLV>
<L2TP-LNS Tunnel TLV> <L2TP-LNS Tunnel TLV>
[<Subscriber Policy TLV>] [<Subscriber Policy TLV>]
<Update_Response Message> ::= <Common Header> <Update_Response Message> ::= <Common Header>
<Update Response TLV> <Update Response TLV>
]]></artwork> ]]></sourcecode>
</figure> <t>
<t>
Then, an ND negotiation will be triggered by the RG. After the ND Then, an ND negotiation will be triggered by the RG. After the ND
negotiation, the CP will update the session with the following negotiation, the CP will update the session with the following
message exchanges:</t> message exchanges:</t>
<sourcecode type="rbnf"><![CDATA[
<figure><artwork><![CDATA[
<Update_Request Message> ::= <Common Header> <Update_Request Message> ::= <Common Header>
<L2TP-LAC Subscriber TLV> <L2TP-LAC Subscriber TLV>
<Basic Subscriber TLV> <Basic Subscriber TLV>
<PPP Subscriber TLV> <PPP Subscriber TLV>
<IPv6 Subscriber TLV> <IPv6 Subscriber TLV>
<IPv6 Routing TLV> <IPv6 Routing TLV>
<L2TP-LNS Tunnel TLV> <L2TP-LNS Tunnel TLV>
[<Subscriber Policy TLV>] [<Subscriber Policy TLV>]
<Update_Response Message> ::= <Common Header> <Update_Response Message> ::= <Common Header>
<Update Response TLV> <Update Response TLV>
]]></artwork> ]]></sourcecode>
</figure> </section>
</section> </section>
</section> <section anchor="sect-5.5" numbered="true" toc="default">
<name>CGN (Carrier Grade NAT)</name>
<section title="CGN (Carrier Grade NAT)" anchor="sect-5.5"><figure title= <figure anchor="fig27">
"CGN Access" anchor="fig27"><artwork><![CDATA[ <name>CGN Access</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
RG UP CP AAA RG UP CP AAA
| | | |
| | Public Address Block | | | | Public Address Block | |
| | Allocation Request | | | | Allocation Request | |
| 1|<--------via Ci-------->| | | 1|<--------via Ci-------->| |
| | Public Address Block | | | | Public Address Block | |
| | Allocation Reply | | | | Allocation Reply | |
| 2|---------via Ci-------->| | | 2|---------via Ci-------->| |
| | | |
| Subscriber | | | | Subscriber | | |
| access request| Subscriber | | | Access Request| Subscriber | |
3|-------------->| access request | | 3|-------------->| Access Request | |
| 4|----------via Si------->| | | 4|----------via Si------->| |
| | | AAA | | | | AAA |
| | Subscriber | Req/Rep | | | Subscriber | Req/Rep |
| Subscriber | access reply 5|<------------->| | Subscriber | Access Reply 5|<------------->|
| access reply 6|<---------via Si--------| | | Access Reply 6|<---------via Si--------| |
7|<--------------| | | 7|<--------------| | |
| | | | | | Create Subscriber | |
| | Create subscriber | | | | Session Request | |
| | session Request | |
| 8|<--------via Ci---------| | | 8|<--------via Ci---------| |
| | | | | | | |
| | Create subscriber | | | | Create Subscriber | |
| | session Response | | | | Session Response | |
| | (with NAT information) | | | | (with NAT information) | |
| 9|---------via Ci-------->| | | 9|---------via Ci-------->| |
| | | |
| | | Accounting | | | | Accounting |
| | | with source | | | | with source |
| | | information | | | | information |
| | 10|<------------->| | | 10|<------------->|
| | | Public IP + | | | | Public IP + |
| | | Port range | | | | Port Range |
| | | to Private IP| | | | to Private IP|
| | | mapping | | | | Mapping |
| | | | | | | |]]></artwork>
]]></artwork> </figure>
</figure> <t>
<t>
The first steps allocate one or more CGN address blocks to the UP The first steps allocate one or more CGN address blocks to the UP
(steps 1-2). This is achieved by the following message exchanges (steps 1-2). This is achieved by the following message exchanges
between CP and UP.</t> between CP and UP:</t>
<sourcecode type="rbnf"><![CDATA[
<figure><artwork><![CDATA[
<Addr_Allocation_Req Message> ::= <Common Header> <Addr_Allocation_Req Message> ::= <Common Header>
<Request Address Allocation TLV> <Address Allocation Request TLV>
<Addr_Allocation_Ack Message> ::= <Common Header> <Addr_Allocation_Ack Message> ::= <Common Header>
<Address Assignment Response TLV> <Address Allocation Response TLV>
]]></artwork> ]]></sourcecode>
</figure> <t>
<t>
Steps 3-9 show the general dial-up process in the case of CGN mode. 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 The specific processes (e.g., IPoE, PPPoE, L2TP, etc.) are defined in
above sections.</t> above sections.</t>
<t>
<t>
If a subscriber is a CGN subscriber, once the subscriber session is If a subscriber is a CGN subscriber, once the subscriber session is
created/updated, the UP will report the NAT information to the CP. created/updated, the UP will report the NAT information to the CP.
This is achieved by carrying the "Subscriber CGN Port Range TLV" in This is achieved by carrying the Subscriber CGN Port Range TLV in
the Update_Response message.</t> the Update_Response message.</t>
</section>
</section> <section anchor="sect-5.6" numbered="true" toc="default">
<name>L3 Leased Line Access</name>
<section title="L3 Leased Line Access" anchor="sect-5.6"> <section anchor="sect-5.6.1" numbered="true" toc="default">
<section title="Web Authentication" anchor="sect-5.6.1"> <name>Web Authentication</name>
<figure title="Web Authentication based L3 Leased Line Access" anchor="fig28"><a <figure anchor="fig28">
rtwork><![CDATA[ <name>Web Authentication-Based L3 Leased Line Access</name>
RG UP CP AAA WEB Server <artwork name="" type="" align="left" alt=""><![CDATA[
| | | | | RG UP CP AAA Web Server
| User | | | | | User traffic| | | |
| traffic | | | |
1|------------>| | | | 1|------------>| | | |
| | User | | | | | User traffic | | |
| | traffic | | |
| 2|-----via Si---->| AAA | | | 2|-----via Si---->| AAA | |
| | | Req/Rep | | | | | Req/Rep | |
| | 3|<-------->| | | | 3|<-------->| |
| | Create session | | | | | Create Session | | |
| | Request | | | | | Request | | |
| 4|<----via Ci-----| | | | 4|<----via Ci-----| | |
| | | | | | | Create Session | | |
| | Create session | | |
| | Response | | | | | Response | | |
| 5|----via Ci----->| | | | 5|----via Ci----->| | |
| HTTP | | | | | | | | |
| traffic | | | | | HTTP traffic| | | |
6|------------>| | | | 6|------------>| | | |
| | | | | | | | | |
| Redirect to | | | | | Redirect to | | | |
| Web URL | | | | | Web URL | | | |
7|<------------| | | | 7|<------------| | | |
| | | | | | | | | |
| | | |
8|-----------------Redirected to Web server----------->| 8|-----------------Redirected to Web Server----------->|
| | | |
9|<----------------Push HTTP Log-in page---------------| 9|<----------------Push HTTP Log-in Page---------------|
| | | |
10|-----------------User Authentication---------------->| 10|-----------------User Authentication---------------->|
| | | |
| | | Portal Interchange | | | | Portal Interchange |
| | 11|<-------------------->| | | 11|<-------------------->|
| | | | | | | |
| | | AAA | | | | | AAA | |
| | | Req/Rep | | | | | Req/Rep | |
| | 12|<-------->| | | | 12|<-------->| |
| | | | | | | | | |
| | | | | | | Update Session | | |
| | Update session | | |
| | Request | | | | | Request | | |
| 13|<----via Ci-----| | | | 13|<----via Ci-----| | |
| | | | | | | Update Session | | |
| | Update session | | |
| | Response | | | | | Response | | |
| 14|----via Ci----->| | | | 14|----via Ci----->| | |
| | | | | | | | | |]]></artwork>
]]></artwork> </figure>
</figure> <t>
<t>
In this case, IP traffic from the RG will trigger the CP to 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 authenticate the RG by checking the source IP and the exchanges with
the AAA server. Once the RG passed the authentication, the CP will the AAA server. Once the RG has passed the authentication, the CP will
create a corresponding subscriber session on the UP through the create a corresponding subscriber session on the UP through the
following message exchanges:</t> following message exchanges:</t>
<figure><artwork><![CDATA[ <t>IPv4 Case:</t>
IPv4 Case: <sourcecode type="rbnf"><![CDATA[
<Update_Request Message> ::= <Common Header> <Update_Request Message> ::= <Common Header>
<Basic Subscriber TLV> <Basic Subscriber TLV>
<IPv4 Subscriber TLV> <IPv4 Subscriber TLV>
<IPv4 Routing TLV> <IPv4 Routing TLV>
[<Subscriber Policy TLV>] [<Subscriber Policy TLV>]
<Update_Response Message> ::= <Common Header> <Update_Response Message> ::= <Common Header>
<Update Response TLV> <Update Response TLV>
[<Subscriber CGN Port Range TLV>] [<Subscriber CGN Port Range TLV>]
]]></sourcecode>
IPv6 Case: <t>IPv6 Case:</t>
<sourcecode type="rbnf"><![CDATA[
<Update_Request Message> ::= <Common Header> <Update_Request Message> ::= <Common Header>
<Basic Subscriber TLV> <Basic Subscriber TLV>
<IPv6 Subscriber TLV> <IPv6 Subscriber TLV>
<IPv6 Routing TLV> <IPv6 Routing TLV>
[<Subscriber Policy TLV>] [<Subscriber Policy TLV>]
<Update_Response Message> ::= <Common Header> <Update_Response Message> ::= <Common Header>
<Update Response TLV> <Update Response TLV>
]]></artwork> ]]></sourcecode>
</figure> <t>
<t> Then, the HTTP traffic from the RG will be redirected to a web server
Then, the HTTP traffic from the RG will be redirected to a WEB server to finish the web authentication. Once the web authentication is
to finish the WEB authentication. Once the WEB authentication is
passed, the CP will trigger another AAA authentication. After the passed, the CP will trigger another AAA authentication. After the
AAA authentication, the CP will update the session with the following AAA authentication, the CP will update the session with the following
message exchanges:</t> message exchanges:</t>
<figure><artwork><![CDATA[ <t>IPv4 Case:</t>
IPv4 Case: <sourcecode type="rbnf"><![CDATA[
<Update_Request Message> ::= <Common Header> <Update_Request Message> ::= <Common Header>
<Basic Subscriber TLV> <Basic Subscriber TLV>
<IPv4 Subscriber TLV> <IPv4 Subscriber TLV>
<IPv4 Routing TLV> <IPv4 Routing TLV>
[<Subscriber Policy TLV>] [<Subscriber Policy TLV>]
<Update_Response Message> ::= <Common Header> <Update_Response Message> ::= <Common Header>
<Update Response TLV> <Update Response TLV>
[<Subscriber CGN Port Range TLV>] [<Subscriber CGN Port Range TLV>]
]]></sourcecode>
IPv6 Case: <t>IPv6 Case:</t>
<sourcecode type="rbnf"><![CDATA[
<Update_Request Message> ::= <Common Header> <Update_Request Message> ::= <Common Header>
<Basic Subscriber TLV> <Basic Subscriber TLV>
<IPv6 Subscriber TLV> <IPv6 Subscriber TLV>
<IPv6 Routing TLV> <IPv6 Routing TLV>
[<Subscriber Policy TLV>] [<Subscriber Policy TLV>]
<Update_Response Message> ::= <Common Header> <Update_Response Message> ::= <Common Header>
<Update Response TLV> <Update Response TLV>
]]></artwork> ]]></sourcecode>
</figure> </section>
</section> <section anchor="sect-5.6.2" numbered="true" toc="default">
<name>User Traffic Trigger</name>
<section title="User Traffic Trigger" anchor="sect-5.6.2"> <figure anchor="fig29">
<figure title="User Traffic Triggered L3 Leased Line Access" anchor="fig29"><art <name>User Traffic Triggered L3 Leased Line Access</name>
work><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
RG UP CP AAA RG UP CP AAA
| | | |
| | L3 access | | | | L3 access | |
| | control list | | | | control list | |
| 1|<----via Ci-----| | | 1|<----via Ci-----| |
| User | | | | User | | |
| traffic | | | | traffic | | |
2|------------>| | | 2|------------>| | |
| | User | | | | User traffic | |
| | traffic | |
| 3|-----via Si---->| | | 3|-----via Si---->| |
| | | AAA | | | | AAA |
| | | Req/Rep | | | | Req/Rep |
| | 4|<-------->| | | 4|<-------->|
| | | | | | | |
| | Create session | | | | Create Session | |
| | Request | | | | Request | |
| 5|<----via Ci-----| | | 5|<----via Ci-----| |
| | Create session | | | | Create Session | |
| | Response | | | | Response | |
| 6|----via Ci----->| | | 6|----via Ci----->| |
| | | | | | | |]]></artwork>
]]></artwork> </figure>
</figure> <t>
<t> In this case, the CP must install on the UP an access
In this user traffic triggered case, the CP must install an access control list, which is used by the UP to determine whether or not
control list on the UP, which is used by the UP to determine whether an RG is legal. If the traffic is from a legal RG, it will be
an RG is legal or not. If the traffic is from a legal RG, it will be
redirected to the CP though the Si. The CP will trigger a AAA 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 interchange with the AAA server. After that, the CP will create a
corresponding subscriber session on the UP with the following message corresponding subscriber session on the UP with the following message
exchanges:</t> exchanges:</t>
<figure><artwork><![CDATA[ <t>IPv4 Case:</t>
IPv4 Case: <sourcecode type="rbnf"><![CDATA[
<Update_Request Message> ::= <Common Header> <Update_Request Message> ::= <Common Header>
<Basic Subscriber TLV> <Basic Subscriber TLV>
<IPv4 Subscriber TLV> <IPv4 Subscriber TLV>
<IPv4 Routing TLV> <IPv4 Routing TLV>
[<Subscriber Policy TLV>] [<Subscriber Policy TLV>]
<Update_Response Message> ::= <Common Header> <Update_Response Message> ::= <Common Header>
<Update Response TLV> <Update Response TLV>
[<Subscriber CGN Port Range TLV>] [<Subscriber CGN Port Range TLV>]
]]></sourcecode>
IPv6 Case: <t>IPv6 Case:</t>
<sourcecode type="rbnf"><![CDATA[
<Update_Request Message> ::= <Common Header> <Update_Request Message> ::= <Common Header>
<Basic Subscriber TLV> <Basic Subscriber TLV>
<IPv6 Subscriber TLV> <IPv6 Subscriber TLV>
<IPv6 Routing TLV> <IPv6 Routing TLV>
[<Subscriber Policy TLV>] [<Subscriber Policy TLV>]
<Update_Response Message> ::= <Common Header> <Update_Response Message> ::= <Common Header>
<Update Response TLV> <Update Response TLV>
]]></artwork> ]]></sourcecode>
</figure> </section>
</section> </section>
</section> <section anchor="sect-5.7" numbered="true" toc="default">
<name>Multicast Service Access</name>
<section title="Multicast Service Access" anchor="sect-5.7"><figure title <figure anchor="fig30">
="Multicast Access" anchor="fig30"><artwork><![CDATA[ <name>Multicast Access</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
RG UP CP AAA RG UP CP AAA
| | | | | User Access | User Access | AAA |
| User access | User access | AAA | | Request | Request | Req/Rep |
| request | request | Req/Rep |
1|<----------->|<----via Si---->|<-------->| 1|<----------->|<----via Si---->|<-------->|
| | User | |
| | | | | | | |
| | | | | | Create Session | |
| | Create session | |
| | Request | | | | Request | |
| 2|<----via Ci---->| | | 2|<----via Ci---->| |
| | | | | | | |
| | Create session | | | | Create Session | |
| | Response | | | | Response | |
| 3|----via Ci----->| | | 3|----via Ci----->| |
| | | | | | | |
| Multicast | | | | Multicast | | |
| negotiation | | | | negotiation | | |
4|<----------->| | | 4|<----------->| | |
| | | | | | | |]]></artwork>
]]></artwork> </figure>
</figure> <t>
<t>
Multicast access starts with a user access request from the RG. The 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 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. interchange between the CP and the AAA server will be triggered.
After the authentication, the CP will create a multicast subscriber After the authentication, the CP will create a multicast subscriber
session on the UP through the following messages:</t> session on the UP through the following messages:</t>
<figure><artwork><![CDATA[ <t>IPv4 Case, there will be a Multicast-ProfileV4 sub-TLV present in
IPv4 Case: the Subscriber Policy TLV:</t>
<sourcecode type="rbnf"><![CDATA[
<Update_Request Message> ::= <Common Header> <Update_Request Message> ::= <Common Header>
<Multicast Group Information TLV>
<Basic Subscriber TLV> <Basic Subscriber TLV>
<IPv4 Subscriber TLV> <IPv4 Subscriber TLV>
<IPv4 Routing TLV> <IPv4 Routing TLV>
[<Subscriber Policy TLV>] <Subscriber Policy TLV>
<Update_Response Message> ::= <Common Header> <Update_Response Message> ::= <Common Header>
<Update Response TLV> <Update Response TLV>
[<Subscriber CGN Port Range TLV>] [<Subscriber CGN Port Range TLV>]
]]></sourcecode>
IPv6 Case: <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> <Update_Request Message> ::= <Common Header>
<Multicast Group Information TLV>
<Basic Subscriber TLV> <Basic Subscriber TLV>
<IPv6 Subscriber TLV> <IPv6 Subscriber TLV>
<IPv6 Routing TLV> <IPv6 Routing TLV>
[<Subscriber Policy TLV>] <Subscriber Policy TLV>
<Update_Response Message> ::= <Common Header> <Update_Response Message> ::= <Common Header>
<Update Response TLV> <Update Response TLV>
]]></artwork> ]]></sourcecode>
</figure> </section>
</section>
</section> <section anchor="sect-6" numbered="true" toc="default">
</section> <name>S-CUSP Message Formats</name>
<t>
<section title="S-CUSP Message Formats" anchor="sect-6"><t>
An S-CUSP message consists of a common header followed by a variable-length 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 body consisting entirely of TLVs. Receiving an S-CUSP message with an
unknown message type or missing mandatory TLV MUST trigger an Error message unknown message type or missing mandatory TLV <bcp14>MUST</bcp14> trigger an
(see <xref target="sect-6.7"/>) or a response message with an Error Informati Error message
on TLV (see (see <xref target="sect-6.7" format="default"/>) or a Response message with a
<xref target="sect-7.6"/>).</t> n Error Information TLV (see
<xref target="sect-7.6" format="default"/>).</t>
<t> <t>
Conversely, if a TLV is optional, the TLV may or may not be present. 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 Optional TLVs are indicated in the message formats shown in this document
by being enclosed in square brackets.</t> by being enclosed in square brackets.</t>
<t>
<t>
This section specifies the format of the common S-CUSP message header This section specifies the format of the common S-CUSP message header
and lists the defined messages.</t> and lists the defined messages.</t>
<t>
<t>
Network byte order is used for all multi-byte fields.</t> Network byte order is used for all multi-byte fields.</t>
<section anchor="sect-6.1" numbered="true" toc="default">
<section title="Common Message Header" anchor="sect-6.1"><figure title="S <name>Common Message Header</name>
-CUSP Message Common Header" anchor="fig31"><artwork><![CDATA[ <figure anchor="fig31">
S-CUSP Common Message Header: <name>S-CUSP Message Common Header</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 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 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 | | Ver | Resv | Message-Type | Message-Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Transaction-ID | | Reserved | Transaction-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> </figure>
<dl newline="false" spacing="normal" indent="3">
<t><list style="hanging" hangIndent="3"> <dt>Ver (4 bits):</dt>
<dd> The major version of the protocol. This
<t hangText="Ver (4 bits):"> The major version of the protocol. This
document specifies version 1. Different major versions of the protocol document specifies version 1. Different major versions of the protocol
may have significantly different message structure and format except may have significantly different message structures and formats except
that the Ver field will always be in the same place at the beginning of 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 each message. A successful S-CUSP session depends on the CP and the UP
both using the same major version of the protocol. both using the same major version of the protocol.
</t> </dd>
<dt>Resv (4 bits):</dt>
<t hangText="Resv (4 bits):"> Reserved. MUST be sent as zero and <dd> Reserved. <bcp14>MUST</bcp14> be sent as zero and
ignored on receipt. ignored on receipt.
</t> </dd>
<dt>Message-Type (8 bits):</dt>
<t hangText="Message-Type (8 bits):"> The set of message types <dd> The set of message types
specified in this document is listed in <xref target="sect-9.1"/>. specified in this document is listed in <xref target="sect-9.1" format="d
</t> efault"/>.
</dd>
<t hangText="Message-Length (16 bits):"> Total length of the S-CUSP <dt>Message-Length (16 bits):</dt>
<dd> Total length of the S-CUSP
message including the common header, expressed in number of bytes as message including the common header, expressed in number of bytes as
an unsigned integer. an unsigned integer.
</t> </dd>
<dt>Transaction-ID (16 bits):</dt>
<t hangText="Transaction ID (16 bits):"> This field is used to <dd> This field is used to
identify requests. It is echoed back in any corresponding identify requests. It is echoed back in any corresponding
ACK/Response/Error message. It is RECOMMENDED that a monotonically ACK/Response/Error message. It is <bcp14>RECOMMENDED</bcp14> that a monot
increasing value be used in successive message and that value wrap onically
back to zero after 0xFFFF. The contents of this field is an opaque increasing value be used in successive messages and that the value wraps
value that the receiver MUST NOT use for any purpose except to echo back to zero after 0xFFFF. The content of this field is an opaque
value that the receiver <bcp14>MUST NOT</bcp14> use for any purpose excep
t to echo
back in a corresponding response and, optionally, for logging. back in a corresponding response and, optionally, for logging.
</t> </dd>
</dl>
</list> </section>
</t> <section anchor="sect-6.2" numbered="true" toc="default">
</section> <name>Control Messages</name>
<t>
<section title="Control Messages" anchor="sect-6.2"><t>
This document defines the following control messages:</t> This document defines the following control messages:</t>
<figure><artwork><![CDATA[ <table>
Type Name Notes and TLVs that can be carried <name>Control Messages</name>
1 Hello Hello TLV, Keepalive TLV. <thead>
2 Keepalive A common header with the Keepalive message <tr>
type. <th>Type</th>
3 Sync_Request Synchronization request. <th>Name</th>
4 Sync_Begin Synchronization starts. <th>Notes and TLVs that can be carried</th>
5 Sync_Data Synchronization data: TLVs specified in </tr>
Section 5. </thead>
6 Sync_End End synchronization. <tbody>
7 Update_Request TLVs specified in Sections 7.6-7.9. <tr>
8 Update_Response TLVs specified in Sections 7.6-7.9. <td>1</td>
]]></artwork> <td>Hello</td>
</figure> <td>Hello TLV, Keepalive TLV</td>
</tr>
<section title="Hello Message" anchor="sect-6.2.1"><t> <tr>
Hello message is used for S-CUSP session establishment and version <td>2</td>
negotiation. The detail of S-CUSP session establishment and version <td>Keepalive</td>
negotiation can be found in <xref target="sect-4.1.1"/>.</t> <td>A common header with the Keepalive message type</td>
</tr>
<t> <tr>
The format of Hello message is as follows:</t> <td>3</td>
<td>Sync_Request</td>
<figure><artwork><![CDATA[ <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 <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 <xref target="sect-7.6" format="co
unter"/>-<xref target="sect-7.9" format="counter"/></td>
</tr>
<tr>
<td>8</td>
<td>Update_Response</td>
<td>TLVs specified in Sections <xref target="sect-7.6" format="co
unter"/>-<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 details of S-CUSP session establishment and version
negotiation can be found in <xref target="sect-4.1.1" format="default"/>.</t>
<t>
The format of the Hello message is as follows:</t>
<sourcecode type="rbnf"><![CDATA[
<Hello Message> ::= <Common Header> <Hello Message> ::= <Common Header>
<Hello TLV> <Hello TLV>
<Keepalive TLV> <Keepalive TLV>
[<Error Information TLV>] [<Error Information TLV>]
]]></artwork> ]]></sourcecode>
</figure> <t>
<t>
The return code and negotiation result will be carried in the Error The return code and negotiation result will be carried in the Error
Information TLV. They are listed as follows:</t> Information TLV. They are listed as follows:</t>
<dl newline="false" spacing="normal" indent="3">
<t> <dt>0:</dt>
0: Success, version negotiation success.</t> <dd> Success. Version negotiation success.
</dd>
<t> <dt>1:</dt>
1: Failure, malformed message received.</t> <dd> Failure. Malformed message received.
</dd>
<t> <dt>2:</dt>
2: One or more of the TLVs was not understood.</t> <dd> TLV-Unknown. One or more of the TLVs was not understood.
</dd>
<t><list style="hanging" hangIndent="3"><t hangText="1001:"> The <dt>1001:</dt>
<dd> Version-Mismatch. The
version negotiation fails. The S-CUSP session establishment phase version negotiation fails. The S-CUSP session establishment phase
fails. fails.
</t> </dd>
<dt>1002:</dt>
<t hangText="1002:"> The keepalive negotiation fails. The S-CUSP <dd> Keepalive Error. The keepalive negotiation fails. The S-CUSP
session establishment phase fails. session establishment phase fails.
</t> </dd>
<dt>1003:</dt>
<t hangText="1003:"> The establishment timer expires. session <dd> Timer Expires. The establishment timer expired. Session
establishment phase fails. establishment phase fails.
</t> </dd>
</dl>
</list> </section>
</t> <section anchor="sect-6.2.2" numbered="true" toc="default">
<name>Keepalive Message</name>
</section> <t>
<section title="Keepalive Message" anchor="sect-6.2.2"><t>
Each end of an S-CUSP session periodically sends a Keepalive message. 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 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> Keepalive procedures are defined in <xref target="sect-4.1.2" format="default
"/>.</t>
<t> <t>
The format of the Keepalive message is as follows:</t> The format of the Keepalive message is as follows:</t>
<sourcecode type="rbnf"><![CDATA[
<figure><artwork><![CDATA[
<Keepalive Message> ::= <Common Header> <Keepalive Message> ::= <Common Header>
]]></artwork> ]]></sourcecode>
</figure> </section>
</section> <section anchor="sect-6.2.3" numbered="true" toc="default">
<name>Sync_Request Message</name>
<section title="Sync_Request Message" anchor="sect-6.2.3"><t> <t>
The Sync_Request message is used to request synchronization from an The Sync_Request message is used to request synchronization from an
S-CUSP peer. Both CP and UP can request their peer to synchronize S-CUSP peer. Both CP and UP can request their peer to synchronize
data.</t> data.</t>
<t>
<t>
The format of the Sync_Request message is as follows:</t> The format of the Sync_Request message is as follows:</t>
<sourcecode type="rbnf"><![CDATA[
<figure><artwork><![CDATA[
<Sync_Request Message> ::= <Common Header> <Sync_Request Message> ::= <Common Header>
]]></artwork> ]]></sourcecode>
</figure> <t>
<t>
A Sync_Request message may result in a Sync_Begin message from its 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> peer. The Sync_Begin message is defined in <xref target="sect-6.2.4" format=
"default"/>.</t>
</section> </section>
<section anchor="sect-6.2.4" numbered="true" toc="default">
<section title="Sync_Begin Message" anchor="sect-6.2.4"><t> <name>Sync_Begin Message</name>
<t>
The Sync_Begin message is a reply to a Sync_Request message. It is The Sync_Begin message is a reply to a Sync_Request message. It is
used to notify the synchronization requester whether the used to notify the synchronization requester whether the
synchronization can be started.</t> synchronization can be started.</t>
<t>
<t> The format of the Sync_Begin message is as follows:</t>
The format of Sync_Begin message is as follows:</t> <sourcecode type="rbnf"><![CDATA[
<figure><artwork><![CDATA[
<Sync_Begin Message> ::= <Common Header> <Sync_Begin Message> ::= <Common Header>
<Error Information TLV> <Error Information TLV>
]]></artwork> ]]></sourcecode>
</figure> <t>
<t>
The return codes are carried in the Error Information TLV. The codes The return codes are carried in the Error Information TLV. The codes
are listed below:</t> are listed below:</t>
<dl newline="false" spacing="normal" indent="3">
<t> <dt>
0: Success, be ready to synchronize.</t> 0:</dt><dd> Success. Be ready to synchronize.</dd>
<dt>
<t> 1:</dt><dd> Failure. Malformed message received.</dd>
1: Failure, malformed message received.</t> <dt>
2:</dt><dd> TLV-Unknown. One or more of the TLVs was not understood.</dd>
<t> <dt>
2: One or more of the TLVs was not understood.</t> 2001:</dt><dd> Synch-NoReady. The data to be synchronized is not ready.</dd>
<dt>
<t> 2002:</dt><dd> Synch-Unsupport. The data synchronization is not supported.</
2001: Synch-NoReady. The data to be synchronized is not ready.</t> dd>
</dl>
<t> </section>
2002: Synch-Unsupport. The data synchronization is not supported.</t> <section anchor="sect-6.2.5" numbered="true" toc="default">
<name>Sync_Data Message</name>
</section> <t>
<section title="Sync_Data Message" anchor="sect-6.2.5"><t>
The Sync_Data message is used to send data being synchronized between 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 the CP and UP. The Sync_Data message has the same function and
format as the Update_Request message. The difference is that there 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 is no ACK for a Sync_Data message. An error caused by the Sync_Data
message will result in a Sync_End message.</t> message will result in a Sync_End message.</t>
<t>
<t>
There are two scenarios: There are two scenarios:
<list> </t>
<t>Synchronization from UP to CP: Synchronize the resource data to CP. <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> <Sync_Data Message> ::= <Common Header>
[<Resource Reporting TLVs>] [<Interface Status TLV>]
]]></artwork> [<Board Status TLV>]
</figure> </t> ]]></sourcecode>
</li>
<t>Synchronization from CP to UP: Synchronize all subscriber <li>
sessions to UP. As for which TLVs should be carried, it depends on the <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 carri
ed, it depends on the
specific session data to be synchronized. The process is equivalent to the specific session data to be synchronized. The process is equivalent to the
creation of a particular session. Refer to <xref target="sect-5"/> to see creation of a particular session. Refer to <xref target="sect-5" format="def ault"/> to see
more details. more details.
<figure><artwork><![CDATA[ </t>
<sourcecode type="rbnf"><![CDATA[
<Sync_Data Message> ::= <Common Header> <Sync_Data Message> ::= <Common Header>
[<User Routing TLVs>] [<IPv4 Routing TLV>]
[<User Information TLVs>] [<IPv6 Routing TLV>]
[<L2TP Subscriber TLVs>] [<Subscriber TLVs>]
[<Subscriber CGN Port Range TLV>] ]]></sourcecode>
[<Subscriber Policy TLV>] </li>
]]></artwork> </ul>
</figure></t> </section>
<section anchor="sect-6.2.6" numbered="true" toc="default">
</list> <name>Sync_End Message</name>
</t> <t>
</section>
<section title="Sync_End Message" anchor="sect-6.2.6"><t>
The Sync_End message is used to indicate the end of a synchronization 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> process. The format of a Sync_End message is as follows:</t>
<sourcecode type="rbnf"><![CDATA[
<figure><artwork><![CDATA[
<Sync_End Message> ::= <Common Header> <Sync_End Message> ::= <Common Header>
<Error Information TLV> <Error Information TLV>
]]></artwork> ]]></sourcecode>
</figure> <t>The return/error codes are listed as follows:
<t>The return/error codes are listed as follows:
<list>
<t>0: Success, synchronization finished.</t>
<t>1: Failure, malformed message received.</t>
<t>2: One or more of the TLVs was not understood.</t>
</list>
</t> </t>
</section> <dl newline="false" spacing="normal" indent="3">
<section title="Update_Request Message" anchor="sect-6.2.7"><t> <dt>0:</dt><dd> Success. Synchronization finished.</dd>
The Update_Request message is a multi-purpose message, it can be used <dt>1:</dt><dd> Failure. Malformed message received.</dd>
<dt>2:</dt><dd> TLV-Unknown. One or more of the TLVs was not underst
ood.</dd>
</dl>
</section>
<section anchor="sect-6.2.7" numbered="true" toc="default">
<name>Update_Request Message</name>
<t>
The Update_Request message is a multipurpose message; it can be used
to create, update, and delete subscriber sessions on a UP.</t> to create, update, and delete subscriber sessions on a UP.</t>
<t>
<t>
For session operations, the specific operation is controlled by the For session operations, the specific operation is controlled by the
"Oper" field of the carried TLVs. As defined in <xref target="sect-7.1"/>, t Oper field of the carried TLVs. As defined in <xref target="sect-7.1" format
he ="default"/>, the
"Oper" can be set to either "Update" or "Delete" when a TLV is Oper field can be set to either Update or Delete when a TLV is
carried in an Update_Request message.</t> carried in an Update_Request message.</t>
<t>
<t> When the Oper field is set to Update, it means to create or update a
When the "Oper" set to Update, it means to create or update a subscriber session. If the Oper field is set to Delete, it is a request to
subscriber session. If the "Oper" set to Delete, it is a request to
delete a corresponding session.</t> delete a corresponding session.</t>
<t>
<t> The format of the Update_Request message is as follows:</t>
The format of Update_Request message is as follows:</t> <sourcecode type="rbnf"><![CDATA[
<figure><artwork><![CDATA[
<Update_Request Message> ::= <Common Header> <Update_Request Message> ::= <Common Header>
[<User Routing TLVs>] [<IPv4 Routing TLV>]
[<User Information TLVs>] [<IPv6 Routing TLV>]
[<L2TP Subscriber TLVs>] [<Subscriber TLVs>]
[<Subscriber CGN Port Range TLV>] ]]></sourcecode>
[<Subscriber Policy TLV>] <t>
]]></artwork> Where the Subscriber TLVs are those appearing in
</figure> <xref target="sect-7.9" format="default"/>.
<t> Each Update_Request message will result in an Update_Response message,
Each Update_Request message will result in an Update_Response message which is defined in <xref target="sect-6.2.8" format="default"/>.</t>
that is defined in <xref target="sect-6.2.8"/>.</t> </section>
<section anchor="sect-6.2.8" numbered="true" toc="default">
</section> <name>Update_Response Message</name>
<t>
<section title="Update_Response Message" anchor="sect-6.2.8"><t>
The Update_Response message is a response to an Update_Request The Update_Response message is a response to an Update_Request
message. It is used to confirm the update request (or reject it in 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 the case of an error). The format of an Update_Response message is
as follows:</t> as follows:</t>
<sourcecode type="rbnf"><![CDATA[
<figure><artwork><![CDATA[
<Update_Response Message> ::= <Common Header> <Update_Response Message> ::= <Common Header>
[<Subscriber CGN Port Range TLV>] [<Subscriber CGN Port Range TLV>]
<Error Information TLV> <Error Information TLV>
]]></artwork> ]]></sourcecode>
</figure> <t>
<t>
The return/error codes are carried in the Error Information TLV. The return/error codes are carried in the Error Information TLV.
They are listed as follows:</t> They are listed as follows:</t>
<dl newline="false" spacing="normal" indent="3">
<t><list style="hanging" hangIndent="3"> <dt>0:</dt>
<dd> Success.</dd>
<t hangText="0:"> Success.</t> <dt>1:</dt>
<dd> Failure. Malformed message received.</dd>
<t hangText="1:"> Failure, malformed message received.</t> <dt>2:</dt>
<dd> TLV-Unknown. One or more of the TLVs was not understood.</dd>
<t hangText="2:"> One or more of the TLVs was not understood.</t> <dt>3001:</dt>
<dd> Pool-Mismatch. The corresponding address pool
<t hangText="3001(Pool-Mismatch):"> The corresponding address pool cannot be found.</dd>
cannot be found.</t> <dt>3002:</dt>
<dd> Pool-Full. The address pool is fully allocated,
<t hangText="3002 (Pool-Full):"> The address pool is fully allocated and no address segment is available.</dd>
and no address segment is available.</t> <dt>3003:</dt>
<dd> Subnet-Mismatch. The address pool subnet cannot
<t hangText="3003 (Subnet-Mismatch):"> The address pool subnet cannot be found.</dd>
be found.</t> <dt>3004:</dt>
<dd> Subnet-Conflict. Subnets in the address pool
<t hangText="3004 (Subnet-Conflict):"> Subnets in the address pool have been classified into other clients.</dd>
have been classified into other clients.</t> <dt>4001:</dt>
<dd> Update-Fail-No-Res. The forwarding table fails
<t hangText="4001 (Update-Fail-No-Res):"> The forwarding table fails to be delivered because the forwarding resources are insufficient.</dd>
to be delivered because the forwarding resources are insufficient.</t> <dt>4002:</dt>
<dd> QoS-Update-Success. The QoS policy takes effect.</dd>
<t hangText="4002 (QoS-Update-Success):"> The QoS policy takes effect.</t <dt>4003:</dt>
> <dd> QoS-Update-Sq-Fail. Failed to process the queue
in the QoS policy.</dd>
<t hangText="4003 (QoS-Update-Sq-Fail):"> Failed to process the queue <dt>4004:</dt>
in the QoS policy.</t> <dd> QoS-Update-CAR-Fail. Processing of the CAR in
the QoS policy fails.</dd>
<t hangText="4004 (QoS-Update-CAR-Fail):"> Processing of the CAR in <dt>4005:</dt>
the QoS policy fails.</t> <dd> Statistic-Fail-No-Res. Statistics processing
failed due to insufficient statistics resources.</dd>
<t hangText="4005 (Statistic-Fail-No-Res):"> Statistics processing </dl>
failed due to insufficient statistics resources.</t> </section>
</section>
</list> <section anchor="sect-6.3" numbered="true" toc="default">
</t> <name>Event Message</name>
<t>
</section>
</section>
<section title="Event Message" anchor="sect-6.3"><t>
The Event message is used to report subscriber session traffic The Event message is used to report subscriber session traffic
statistics and detection information. The format of Event message is statistics and detection information. The format of the Event message is
as follows:</t> as follows:</t>
<sourcecode type="rbnf"><![CDATA[
<figure><artwork><![CDATA[
<Event Message> ::= <Common Header> <Event Message> ::= <Common Header>
[<User Traffic Statistics Report TLV>] [<Subscriber Traffic Statistics Report TLV>]
[<User Detection Result Report TLV>] [<Subscriber Detection Result Report TLV>]
]]></artwork> ]]></sourcecode>
</figure> </section>
</section> <section anchor="sect-6.4" numbered="true" toc="default">
<name>Report Message</name>
<section title="Report Message" anchor="sect-6.4"><t> <t>
The Report message is used to report board and interface status on a The Report message is used to report board and interface status on a
UP. The format of Report message is as follows:</t> UP. The format of the Report message is as follows:</t>
<sourcecode type="rbnf"><![CDATA[
<figure><artwork><![CDATA[
<Report Message> ::= <Common Header> <Report Message> ::= <Common Header>
[<Board Status TLVs>] [<Board Status TLVs>]
[<Interface Status TLVs>] [<Interface Status TLVs>]
]]></artwork> ]]></sourcecode>
</figure> </section>
</section> <section anchor="sect-6.5" numbered="true" toc="default">
<name>CGN Messages</name>
<section title="CGN Messages" anchor="sect-6.5"><t> <t>
This document defines the following resource allocation messages:</t> This document defines the following resource allocation messages:</t>
<table>
<figure><artwork><![CDATA[ <name>Resource Allocation Messages</name>
Type Message Name TLV that is carried <thead>
200 Addr_Allocation_Req Address Allocation Request <tr>
201 Addr_Allocation_Ack Address Allocation Response <th>Type</th><th>Message Name</th><th>TLV that is carried</th>
202 Addr_Renew_Req Address Renewal Request </tr>
203 Addr_Renew_Ack Address Renewal Response </thead>
204 Addr_Release_Req Address Release Request <tbody>
205 Addr_Release_Ack Address Release Response <tr>
]]></artwork> <td>200</td><td>Addr_Allocation_Req</td><td>Address Allocation Request</td
</figure> >
<section title="Addr_Allocation_Req Message" anchor="sect-6.5.1"><t> </tr>
<tr>
<td>201</td><td>Addr_Allocation_Ack</td><td>Address Allocation Response</t
d>
</tr>
<tr>
<td>202</td><td>Addr_Renew_Req</td><td>Address Renewal Request</td>
</tr>
<tr>
<td>203</td><td>Addr_Renew_Ack</td><td>Address Renewal Response</td>
</tr>
<tr>
<td>204</td><td>Addr_Release_Req</td><td>Address Release Request</td>
</tr>
<tr>
<td>205</td><td>Addr_Release_Ack</td><td>Address Release 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 The Addr_Allocation_Req message is used to request CGN address
allocation. The format of Addr_Allocation_Req message is as follows:</t> allocation. The format of the Addr_Allocation_Req message is as follows:</t>
<sourcecode type="rbnf"><![CDATA[
<figure><artwork><![CDATA[
<Addr_Allocation_Req Message> ::= <Common Header> <Addr_Allocation_Req Message> ::= <Common Header>
<Address Allocation Request TLV> <Address Allocation Request TLV>
]]></artwork> ]]></sourcecode>
</figure> </section>
</section> <section anchor="sect-6.5.2" numbered="true" toc="default">
<name>Addr_Allocation_Ack Message</name>
<section title="Addr_Allocation_Ack Message" anchor="sect-6.5.2"><t> <t>
The Addr_Allocation_Ack message is a response to an The Addr_Allocation_Ack message is a response to an
Addr_Allocation_Req message. The format of Addr_Allocation_Ack Addr_Allocation_Req message. The format of the Addr_Allocation_Ack
message is as follows:</t> message is as follows:</t>
<sourcecode type="rbnf"><![CDATA[
<figure><artwork><![CDATA[
<Addr_Allocation_Ack Message> ::= <Common Header> <Addr_Allocation_Ack Message> ::= <Common Header>
<Address Allocation Response TLV> <Address Allocation Response TLV>
]]></artwork> ]]></sourcecode>
</figure> </section>
</section> <section anchor="sect-6.5.3" numbered="true" toc="default">
<name>Addr_Renew_Req Message</name>
<section title="Addr_Renew_Req Message" anchor="sect-6.5.3"><t> <t>
The Addr_Renew_Req message is used to request address renewal. The The Addr_Renew_Req message is used to request address renewal. The
format of Addr_Renew_Req message is as follows:</t> format of the Addr_Renew_Req message is as follows:</t>
<sourcecode type="rbnf"><![CDATA[
<figure><artwork><![CDATA[
<Addr_Renew_Req Message> ::= <Common Header> <Addr_Renew_Req Message> ::= <Common Header>
<Address Renewal Request TLV> <Address Renewal Request TLV>
]]></artwork> ]]></sourcecode>
</figure> </section>
</section> <section anchor="sect-6.5.4" numbered="true" toc="default">
<name>Addr_Renew_Ack Message</name>
<section title="Addr_Renew_Ack Message" anchor="sect-6.5.4"><t> <t>
The Addr_Renew_Ack message is a response to an Addr_Renew_Req The Addr_Renew_Ack message is a response to an Addr_Renew_Req
message. The format of Addr_Renew_Req message is as follows:</t> message. The format of the Addr_Renew_Req message is as follows:</t>
<sourcecode type="rbnf"><![CDATA[
<figure><artwork><![CDATA[
<Addr_Renew_Ack Message> ::= <Common Header> <Addr_Renew_Ack Message> ::= <Common Header>
<Address Renewal Response TLV> <Address Renewal Response TLV>
]]></artwork> ]]></sourcecode>
</figure> </section>
</section> <section anchor="sect-6.5.5" numbered="true" toc="default">
<name>Addr_Release_Req Message</name>
<section title="Addr_Release_Req Message" anchor="sect-6.5.5"><t> <t>
The Addr_Release_Req message is used to request address release. The The Addr_Release_Req message is used to request address release. The
format of Addr_Release_Req message is as follows:</t> format of the Addr_Release_Req message is as follows:</t>
<sourcecode type="rbnf"><![CDATA[
<figure><artwork><![CDATA[
<Addr_Release_Req Message> ::= <Common Header> <Addr_Release_Req Message> ::= <Common Header>
<Address Release Request TLV> <Address Release Request TLV>
]]></artwork> ]]></sourcecode>
</figure> </section>
</section> <section anchor="sect-6.5.6" numbered="true" toc="default">
<name>Addr_Release_Ack Message</name>
<section title="Addr_Release_Ack Message" anchor="sect-6.5.6"><t> <t>
The Addr_Release_Ack message is a response to an Addr_Release_Req The Addr_Release_Ack message is a response to an Addr_Release_Req
message. The format of Addr_Release_Ack message is as follows:</t> message. The format of the Addr_Release_Ack message is as follows:</t>
<sourcecode type="rbnf"><![CDATA[
<figure><artwork><![CDATA[
<Addr_Release_Ack Message> ::= <Common Header> <Addr_Release_Ack Message> ::= <Common Header>
<Address Release Response TLV> <Address Release Response TLV>
]]></artwork> ]]></sourcecode>
</figure> </section>
</section> </section>
<section anchor="sect-6.6" numbered="true" toc="default">
</section> <name>Vendor Message</name>
<t>
<section title="Vendor Message" anchor="sect-6.6"><t> The Vendor message, in conjunction with the Vendor TLV and Vendor
The Vendor message, in conjunction with the vendor TLV and vendor sub-TLV, can be used by vendors to extend S-CUSP. The
sub-TLV, can be used by vendors to extend the S-CUSP protocol. The Message-Type is 11. If the receiver does not recognize the message,
message type is 11. If the receiver does not recognize the message,
an Error message will be returned to the sender.</t> an Error message will be returned to the sender.</t>
<t>
<t>
The format of the Vendor message is as follows:</t> The format of the Vendor message is as follows:</t>
<sourcecode type="rbnf"><![CDATA[
<figure><artwork><![CDATA[
<Vendor Message> ::= <Common Header> <Vendor Message> ::= <Common Header>
<Vendor TLV> <Vendor TLV>
[<any other TLVs as specified by the vendor>] [<any other TLVs as specified by the vendor>]
]]></artwork> ]]></sourcecode>
</figure> </section>
</section> <section anchor="sect-6.7" numbered="true" toc="default">
<name>Error Message</name>
<section title="Error Message" anchor="sect-6.7"><t> <t>
The Error message is defined to return some critical error The Error message is defined to return some critical error
information to the sender. If a receiver does not support the type information to the sender. If a receiver does not support the type
of the received message, it MUST return an Error message to the of the received message, it <bcp14>MUST</bcp14> return an Error message to th e
sender.</t> sender.</t>
<t>
<t>
The format of the Error message is as below:</t> The format of the Error message is as below:</t>
<sourcecode type="rbnf"><![CDATA[
<figure><artwork><![CDATA[
<Error Message> ::= <Common Header> <Error Message> ::= <Common Header>
<Error Information TLV> <Error Information TLV>
]]></artwork> ]]></sourcecode>
</figure> </section>
</section> </section>
</section>
<section title="S-CUSP TLVs and Sub-TLVs" anchor="sect-7"><t> <section anchor="sect-7" numbered="true" toc="default">
<name>S-CUSP TLVs and Sub-TLVs</name>
<t>
This section specifies the following:</t> This section specifies the following:</t>
<ul spacing="normal">
<t><list style="symbols"><t>the format of the TLVs that appear in S-CUSP <li>The format of the TLVs that appear in S-CUSP messages,</li>
messages,</t> <li>The format of the sub-TLVs that appear within the values of some
TLVs, and</li>
<t>the format of the sub-TLVs that appear within the values of some <li>The format of some basic data fields that appear within TLVs or
TLVs, and</t> sub-TLVs.</li>
</ul>
<t>the format of some basic data fields that appear within TLVs or <t>
sub-TLVs.</t> See <xref target="sect-9" format="default"/> for a list of all defined TLVs a
nd sub-TLVs.</t>
</list> <section anchor="sect-7.1" numbered="true" toc="default">
</t> <name>Common TLV Header</name>
<t>
<t> S-CUSP messages consist of the common header specified in <xref target="sect-
See <xref target="sect-9"/> for a list of all defined TLVs and sub-TLVs.</t> 6.1" format="default"/>
<section title="Common TLV Header" anchor="sect-7.1"><t>
S-CUSP messages consist of the common header specified in <xref target="sect-
6.1"/>
followed by TLVs formatted as specified in this section.</t> followed by TLVs formatted as specified in this section.</t>
<figure anchor="fig32">
<figure title="Common TLV Header" anchor="fig32"><artwork><![CDATA[ <name>Common TLV Header</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 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 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 | | Oper | TLV-Type | TLV-Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Value ~ ~ Value ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> </figure>
<t><list style="hanging" hangIndent="3"> <dl newline="false" spacing="normal" indent="3">
<dt>Oper (4 bits):</dt>
<t hangText="Oper (4 bits):"> For Message-Types that specify an <dd> For Message-Types that specify an
operation on a data set, the Oper field is interpreted as Update, operation on a data set, the Oper field is interpreted as Update,
Delete, or Reserved as specified in <xref target="sect-9.3"/>. For all Delete, or Reserved as specified in <xref target="sect-9.3" format="defa
other Message-Types, the Oper field MUST be sent as zero and ignored ult"/>. For all
on receipt.</t> other Message-Types, the Oper field <bcp14>MUST</bcp14> be sent as zero
and ignored
<t hangText="TLV-Type (12 bits):"> The Type of a TLV. TLV-Type on receipt.</dd>
<dt>TLV-Type (12 bits):</dt>
<dd> The type of a TLV. TLV-Type
specifies the interpretation and format of the Value field of the TLV. specifies the interpretation and format of the Value field of the TLV.
See <xref target="sect-9.2"/>.</t> See <xref target="sect-9.2" format="default"/>.</dd>
<dt>TLV-Length (2 bytes):</dt>
<t hangText="TLV-Length (2 bytes):"> The length of the Value portion <dd> The length of the Value portion
of the TLV in bytes as an unsigned integer. of the TLV in bytes as an unsigned integer.
</t> </dd>
<dt>Value (variable length):</dt>
<t hangText="Value (variable length):"> This is the value portion of <dd> This is the portion of
the TLV whose size is given by TLV-Length. The value portion consists the TLV whose size is given by TLV-Length. It consists
of fields, frequently using one of the basic data field types (see of fields, frequently using one of the basic data field types (see
<xref target="sect-7.2"/>) and sub-TLVs (see <xref <xref target="sect-7.2" format="default"/>) and sub-TLVs (see <xref targe
target="sect-7.3"/>). t="sect-7.3" format="default"/>).
</t> </dd>
</dl>
</list> </section>
</t> <section anchor="sect-7.2" numbered="true" toc="default">
<name>Basic Data Fields</name>
</section> <t>
<section title="Basic Data Fields" anchor="sect-7.2"><t>
This section specifies the binary format of several standard basic This section specifies the binary format of several standard basic
data fields that are used within other data structures in this data fields that are used within other data structures in this
specification.</t> specification.</t>
<dl newline="false" spacing="normal" indent="3">
<t><list style="hanging" hangIndent="3"> <dt>STRING:</dt>
<dd> 0 to 255 octets. Will be encoded as a sub-TLV
<t hangText="STRING:"> 0 to 255 octets. Will be encoded as a sub-TLV (see <xref target="sect-7.3" format="default"/>) to provide the length.
(see Section 7.3) to provide the length. The use of this data type in The use of this data type in
S-CUSP is to provide convenient labels for use by network operators in S-CUSP is to provide convenient labels for use by network operators in
configuring and debugging their networks and interpreting S-CUSP configuring and debugging their networks and interpreting S-CUSP
messages. Subscribers will not normally see these labels. They are messages. Subscribers will not normally see these labels. They are
normally interpreted as ASCII [RFC20]. </t> normally interpreted as ASCII <xref target="RFC0020" format="default"/>.
</dd>
<t hangText="MAC-Addr:"> 6 octets. Ethernet MAC Address <xref target="RFC <dt>MAC-Addr:</dt>
7042"/>.</t> <dd> 6 octets. Ethernet MAC address <xref target="RFC7042" format="def
ault"/>.</dd>
<t hangText="IPv4-Address:"> 8 octets. 4 octets of the IPv4 address <dt>IPv4-Address:</dt>
value followed by a 4 octet address mask in the format <dd> 8 octets. 4 octets of the IPv4 address
XXX.XXX.XXX.XXX.</t> value followed by a 4-octet address mask in the format
XXX.XXX.XXX.XXX.</dd>
<t hangText="IPv6-Address:"> 20 octets. 16 octets of IPv6 address <dt>IPv6-Address:</dt>
followed by a 4 octet integer n in the range of 0 to 128 which gives <dd> 20 octets. 16 octets of the IPv6 address
followed by a 4-octet integer n in the range of 0 to 128, which gives
the address mask as the one's complement of 2**(128-n) - 1. the address mask as the one's complement of 2**(128-n) - 1.
</t> </dd>
<dt>VLAN ID:</dt>
<t hangText="VLAN ID:"> 2 octets. As follows [802.1Q]:</t> <dd> <t>2 octets. As follows <xref target="IEEE-802.1Q" format="defaul
t"/>:</t>
</list> <artwork name="" type="" align="left" alt=""><![CDATA[
</t>
<figure><artwork><![CDATA[
0 1 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PRI |D| VLAN-ID | | PRI |D| VLAN-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> <dl newline="false" spacing="normal" indent="3">
<dt>PRI:</dt>
<t><list style="hanging" hangIndent="3"> <dd> Priority. Default value 7.</dd>
<dt>D:</dt>
<t hangText="PRI:"> Priority. Default value 7.</t> <dd> Drop Eligibility Indicator (DEI). Default value 0.</dd>
<dt>VLAN-ID:</dt>
<t hangText="D:"> Drop Eligibility Indicator (DEI). Default value 0.</t> <dd> Unsigned integer in the range 1-4094. (0 and
4095 are not valid VLAN IDs <xref target="IEEE-802.1Q" format="default"/>.
<t hangText="VLAN-ID:"> Unsigned integer in the range 1-4094. (0 and )</dd>
4095 are not valid VLAN IDs <xref target="IEEE-802.1Q"/>.)</t> </dl></dd>
</dl>
</list> </section>
</t> <section anchor="sect-7.3" numbered="true" toc="default">
<name>Sub-TLV Format and Sub-TLVs</name>
</section> <t>
In some cases, the Value portion of a TLV, as specified in <xref target="sect
<section title="Sub-TLV Format and Sub-TLVs" anchor="sect-7.3"><t> -7.1" format="default"/>, can
In some cases, the Value portion of a TLV, as specified above, can contain one or more sub-TLVs formatted as follows:</t>
contain one or more Sub-TLVs formatted as follows:</t> <figure anchor="fig33">
<name>Sub-TLV Header</name>
<figure title="Sub-TLV Header" anchor="fig33"><artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 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 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 | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value | | Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
]]></artwork> ]]></artwork>
</figure> </figure>
<dl newline="false" spacing="normal" indent="3">
<t><list style="hanging" hangIndent="3"> <dt>Type (2 bytes):</dt>
<dd> The type of a sub-TLV. The Type field
<t hangText="Type (2 bytes):"> The Type of a Sub-TLV. The Type field specifies the interpretation and format of the Value field of the TLV.
specified the interpretation and format of the Value field of the TLV. Sub-TLV type values have the same meaning regardless of the TLV type of
Sub-TLV Type values have the same meaning regardless of the TLV Type of the TLV within which the sub-TLV occurs. See <xref target="sect-9.4" for
the TLV within which the sub-TLV occurs. See <xref target="sect-9.4"/>.< mat="default"/>.</dd>
/t> <dt>Length (2 bytes):</dt>
<dd> The length of the Value portion of
<t hangText="Length (2 bytes):"> The length of the Value portion of the sub-TLV in bytes as an unsigned integer.</dd>
the sub-TLV in bytes as an unsigned integer.</t> <dt>Value (variable length):</dt>
<dd> This is the Value portion of
<t hangText="Value (variable length):"> This is the value portion of the sub-TLV whose size is given by Length.</dd>
the sub-TLV whose size is given by Length.</t> </dl>
<t>
</list>
</t>
<t>
The sub-TLVs currently specified are defined in the following The sub-TLVs currently specified are defined in the following
subsections.</t> subsections.</t>
<section anchor="sect-7.3.1" numbered="true" toc="default">
<section title="Name sub-TLVs" anchor="sect-7.3.1"><t> <name>Name Sub-TLVs</name>
<t>
This document defines the following name sub-TLVs that are used to This document defines the following name sub-TLVs that are used to
carry the name of the corresponding object. The length of each of 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 these sub-TLVs is variable from 1 to 255 octets. The value is of
type STRING padded with zeros octets to 4-octet alignment.</t> type STRING padded with zero octets to a length in octets that is
an integer multiple of 4.</t>
<figure><artwork><![CDATA[ <table>
Type Sub-TLV Name Meaning <name>Name Sub-TLVs</name>
1 VRF-Name The name of a VRF <thead>
2 Ingress-QoS-Profile The name of an ingress QoS profile <tr>
3 Egress-QoS-Profile The name of an egress QoS profile <th>Type</th><th>Sub-TLV Name</th><th>Meaning</th>
4 User-ACL-Policy The name of an ACL policy </tr>
5 Multicast-ProfileV4 The name of an IPv4 multicast profile </thead>
6 Multicast-ProfileV6 The name of an IPv6 multicast profile <tbody>
7 NAT-Instance The name of a NAT instance <tr>
8 Pool-Name The name of an address pool <td>1</td><td>VRF-Name</td><td>The name of a VRF</td>
]]></artwork> </tr>
</figure> <tr>
</section> <td>2</td><td>Ingress-QoS-Profile</td><td>The name of an ingress QoS prof
ile</td>
</tr>
<tr>
<td>3</td><td>Egress-QoS-Profile</td><td>The name of an egress QoS profil
e</td>
</tr>
<tr>
<td>4</td><td>User-ACL-Policy</td><td>The name of an ACL policy</td>
</tr>
<tr>
<td>5</td><td>Multicast-ProfileV4</td><td>The name of an IPv4 multicast p
rofile</td>
</tr>
<tr>
<td>6</td><td>Multicast-ProfileV6</td><td>The name of an IPv6 multicast p
rofile</td>
</tr>
<tr>
<td>9</td><td>NAT-Instance</td><td>The name of a NAT instance</td>
</tr>
<tr>
<td>10</td><td>Pool-Name</td><td>The name of an address pool</td>
</tr>
</tbody>
</table>
</section>
<section title="Ingress-CAR sub-TLV" anchor="sect-7.3.2"><t> <section 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 The Ingress-CAR sub-TLV indicates the authorized upstream Committed
Access Rate (CAR) parameters. The sub-TLV type of the Ingress-CAR Access Rate (CAR) parameters. The sub-TLV type of the Ingress-CAR
sub-TLV is 9. The sub-TLV length is 16. The format is as shown in sub-TLV is 7. The sub-TLV length is 16. The format is as shown in
Figure 34.</t> <xref target="fig34" format="default"/>.</t>
<figure anchor="fig34">
<figure title="Ingress-CAR sub-TLV" anchor="fig34"><artwork><![CDATA[ <name>Ingress-CAR Sub-TLV</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 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 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) | | CIR (Committed Information Rate) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PIR (Peak Information Rate) | | PIR (Peak Information Rate) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CBS (Committed Burst Size) | | CBS (Committed Burst Size) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PBS (Peak Burst Size) | | PBS (Peak Burst Size) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> </figure>
<t> Where:
<list>
<t> CIR (4 bytes): Guaranteed rate in bits/second.</t>
<t> PIR (4 bytes): Burst rate in bits/second.</t>
<t> CBS (4 bytes): The token bucket in bytes.</t>
<t> PBS (4 bytes): Burst token bucket in bytes.</t>
</list> <t> Where:
</t> </t>
<t> <ul empty="true"><li>
<dl newline="false" spacing="normal">
<dt>CIR (4 bytes):</dt><dd>Guaranteed rate in bits/second.</dd>
<dt>PIR (4 bytes):</dt><dd>Burst rate in bits/second.</dd>
<dt>CBS (4 bytes):</dt><dd>The token bucket in bytes.</dd>
<dt>PBS (4 bytes):</dt><dd>Burst token bucket in bytes.</dd>
</dl>
</li></ul>
<t>
These fields are unsigned integers. More details about CIR, PIR, CBS, These fields are unsigned integers. More details about CIR, PIR, CBS,
and PBS can be found in <xref target="RFC2698"/>.</t> and PBS can be found in <xref target="RFC2698" format="default"/>.</t>
</section>
</section> <section anchor="sect-7.3.3" numbered="true" toc="default">
<name>Egress-CAR Sub-TLV</name>
<section title="Egress-CAR sub-TLV" anchor="sect-7.3.3"><t> <t>
The Egress-CAR sub-TLV indicates the authorized downstream Committed Access 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 Rate (CAR) parameters. The sub-TLV type of the Egress-CAR sub-TLV is
10. Its sub-TLV length is 16 octets. The format of the value part is as 8. Its sub-TLV length is 16 octets. The format of the value part is as
defined below.</t> defined below.</t>
<figure anchor="fig35">
<figure title="Egress-CAR sub-TLV" anchor="fig35"><artwork><![CDATA[ <name>Egress-CAR Sub-TLV</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 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 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) | | CIR (Committed Information Rate) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PIR (Peak Information Rate) | | PIR (Peak Information Rate) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CBS (Committed Burst Size) | | CBS (Committed Burst Size) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PBS (Peak Burst Size) | | PBS (Peak Burst Size) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> </figure>
<t>Where:
<t>Where: </t>
<list>
<t>CIR (4 bytes): Guaranteed rate in bits/second.</t>
<t>PIR (4 bytes): Burst rate in bits/second.</t>
<t>CBS (4 bytes): The token bucket in bytes.</t>
<t>PBS (4 bytes): Burst token bucket in bytes.</t> <ul empty="true"><li>
<dl newline="false" spacing="normal">
<dt>CIR (4 bytes):</dt><dd>Guaranteed rate in bits/second.</dd>
<dt>PIR (4 bytes):</dt><dd>Burst rate in bits/second.</dd>
<dt>CBS (4 bytes):</dt><dd>The token bucket in bytes.</dd>
<dt>PBS (4 bytes):</dt><dd>Burst token bucket in bytes.</dd>
</dl>
</list> </li></ul>
</t>
<t> <t>
These fields are unsigned integers. More details about CIR, PIR, CBS, These fields are unsigned integers. More details about CIR, PIR, CBS,
and PBS can be found in <xref target="RFC2698"/>.</t> and PBS can be found in <xref target="RFC2698" format="default"/>.</t>
</section>
</section> <section anchor="sect-7.3.4" numbered="true" toc="default">
<name>If-Desc Sub-TLV</name>
<section title="If-Desc sub-TLV" anchor="sect-7.3.4"><t> <t>
The If-Desc sub-TLV is defined to designate an interface. It is an 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" optional sub-TLV that may be carried in those TLVs that have an If-Index
or "out-if-index" field. The If-Desc sub-TLV is used as a locally unique or Out-If-Index field. The If-Desc sub-TLV is used as a locally unique
identifier within a BNG.</t> identifier within a BNG.</t>
<t>
<t>
The sub-TLV type is 11. The sub-TLV length is 12 octets. The format The sub-TLV type is 11. The sub-TLV length is 12 octets. The format
depends on the If-Type. The format of the value part is as follows:</t> depends on the 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[ <figure anchor="fig36">
<name>If-Desc Sub-TLV Formats</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 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 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 | | If-Type (1-5)| Chassis | Slot |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-Slot | Port Number | | Sub-Slot | Port Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-Port Number | | Sub-Port Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
If-Desc sub-TLV (Physical Port) If-Desc Sub-TLV (Physical Port)
0 1 2 3 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 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 | | If-Type (6-7) | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Logic-ID | | Logic-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-Port Number | | Sub-Port Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
If-Desc sub-TLV (Virtual Port) If-Desc Sub-TLV (Virtual Port)
]]></artwork> ]]></artwork>
</figure> </figure>
<t>Where:
<list> <t>Where:
</t>
<t>If-Type: 8 bits in length. The value of this field indicates the <ul empty="true"><li>
<dl newline="false" spacing="normal">
<dt>If-Type:</dt><dd>8 bits in length. The value of this field indic
ates the
type of an interface. The If-Type values defined in this document type of an interface. The If-Type values defined in this document
are listed in <xref target="sect-9.6"/>.</t> are listed in <xref target="sect-9.6" format="default"/>.</dd>
<dt>Chassis (8 bits):</dt><dd>Identifies the chassis that the interf
<t>Chassis (8 bits): Identifies the chassis that the interface ace
belongs to.</t> belongs to.</dd>
<dt>Slot (16 bits):</dt><dd>Identifies the slot that the interface b
<t>Slot (16 bits): Identifies the slot that the interface belongs to.</t> elongs to.</dd>
<dt>Sub-Slot (16 bits):</dt><dd>Identifies the sub-slot the interfac
<t>Sub-slot (16 bits): Identifies the sub-slot the interface belongs to.</ e belongs to.</dd>
t> <dt>Port Number (16 bits):</dt><dd>An identifier of a physical port/
interface
<t>Port Number (16 bits): An identifier of a physical port/interface
(e.g., If-Type: 1-5). It is locally significant within the (e.g., If-Type: 1-5). It is locally significant within the
slot/sub-slot.</t> slot/sub-slot.</dd>
<dt>Sub-Port Number (32 bits):</dt><dd>An identifier of the sub-port
<t>Sub-port Number (32 bits): An identifier of the sub-port. Locally . Locally
significant within its "parent" port (physical or virtual).</t> significant within its "parent" port (physical or virtual).</dd>
<dt>Logic-ID (32 bits):</dt><dd>An identifier of a virtual interface
<t>Logic-ID (32 bits): An identifier of a virtual interface (e.g., (e.g.,
If-Type: 6-7)</t> If-Type: 6-7).</dd>
</list>
</t>
</section> </dl>
</li></ul>
<section title="IPv6 Address List sub-TLV" anchor="sect-7.3.5"><t> </section>
<section anchor="sect-7.3.5" numbered="true" toc="default">
<name>IPv6 Address List Sub-TLV</name>
<t>
The IPv6 Address List sub-TLV is used to convey one or more IPv6 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 addresses. It is carried in the IPv6 Subscriber TLV. The sub-TLV
type is 12. The sub-TLV length is variable.</t> type is 12. The sub-TLV length is variable.</t>
<t>The format of the value part of the IPv6 Address List sub-TLV is as
<t>The format of IPv6 Addresses sub-TLV is as follows:</t> follows:</t>
<figure anchor="fig37">
<figure title="IPv6 Address List sub-TLV" anchor="fig37"><artwork><![CDAT <name>IPv6 Address List Sub-TLV</name>
A[ <artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 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 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 ~ ~ IPv6 Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ... ~ ~ ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ IPv6 Address ~ ~ IPv6 Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> </figure>
<t>Where:
<t>Where: </t>
<ul empty="true"><li>
<list> <dl newline="false" spacing="normal">
<t>IP Address (IPv6-Address): Each IP Address is an IP-Address type,
carries an IPv6 address.</t>
</list> <dt>IPv6 Address (IPv6-Address):</dt><dd>Each IP Address is of
</t> type IP-Address and carries an IPv6 address and length.</dd>
</section> </dl>
</li></ul>
<section title="Vendor sub-TLV" anchor="sect-7.3.6"><t> </section>
The Vendor sub-TLV is intended to be used inside the value portion of <section anchor="sect-7.3.6" numbered="true" toc="default">
the Vendor TLV (<xref target="sect-7.13"/>). It provides a Sub-Type that <name>Vendor Sub-TLV</name>
<t>
The Vendor sub-TLV is intended to be used inside the Value portion of
the Vendor TLV (<xref target="sect-7.13" format="default"/>). It provides a S
ub-Type that
effectively extends the sub-TLV type in the sub-TLV header and effectively extends the sub-TLV type in the sub-TLV header and
provides for versioning of vendor sub-TLVs.</t> provides for versioning of Vendor sub-TLVs.</t>
<t>The value part of the Vendor sub-TLV is formatted as follows:</t>
<t>The value part of the Vendor sub-TLV is formatted as follows:</t> <figure anchor="fig38">
<name>Vendor Sub-TLV</name>
<figure title="Vendor sub-TLV" anchor="fig38"><artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 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 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-Type | Sub-Type-Version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ value (other as specified by vendor) ~ ~ Value (other as specified by vendor) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> </figure>
<t>Where:
<t>Where: </t>
<list>
<t>The sub-TLV type: 13.</t>
<t>The sub-TLV length: variable.</t>
<t>Vendor-ID (4 bytes): Vendor ID as defined in RADIUS <xref
target="RFC2865"/>.</t>
<t>Sub-Type (2 bytes): Used by the Vendor to distinguish multiple
different sub-TLVs.</t>
<t>Sub-Type-Version (2 bytes): Used by the Vendor to distinguish
different versions of a Vendor-Defined sub-TLV sub-Type.</t>
<t>value: as specified by the vendor.</t> <ul empty="true"><li>
<dl newline="false" spacing="normal">
</list> <dt>Sub-TLV type:</dt><dd>13.</dd>
</t> <dt>Sub-TLV length:</dt><dd>Variable.</dd>
<dt>Vendor-ID (4 bytes):</dt><dd>Vendor ID as defined in RADIUS <xre
f target="RFC2865" format="default"/>.</dd>
<dt>Sub-Type (2 bytes):</dt><dd>Used by the vendor to distinguish mu
ltiple
different sub-TLVs.</dd>
<dt>Sub-Type-Version (2 bytes):</dt><dd>Used by the vendor to distin
guish
different versions of a vendor-defined sub-TLV Sub-Type.</dd>
<dt>Value:</dt><dd>As specified by the vendor.</dd>
</dl>
</li></ul>
<t> <t>
Since Vendor code will be handling the sub-TLV after the Vendor ID Since vendor code will be handling the sub-TLV after the Vendor-ID
field is recognized, the remainder of the sub-TLV can be organized 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 however the vendor wants. But it desirable for a vendor to be able to
define multiple different vendor sub-TLVs and to keep track of define multiple different Vendor sub-TLVs and to keep track of
different versions of its vendor-defined sub-TLVs. Thus, it is different versions of its vendor-defined sub-TLVs. Thus, it is
RECOMMENDED that the vendor assign a Sub-Type value for each of that <bcp14>RECOMMENDED</bcp14> that the vendor assign a Sub-Type value for each o f that
vendor's sub-TLVs that is different from other Sub-Type values 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 vendor has used. Also, when modifying a vendor-defined sub-TLV in a
way potentially incompatible with a previous definition, the vendor way potentially incompatible with a previous definition, the vendor
SHOULD increase the value it is using in the Sub-Type-Version field.</t> <bcp14>SHOULD</bcp14> increase the value it is using in the Sub-Type-Version
field.</t>
</section>
</section> </section>
</section>
<section title="The Hello TLV" anchor="sect-7.4"><t> <section 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 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 negotiation. It indicates the S-CUSP sub-version and
capabilities supported. The format of Hello TLV is as follows:</t> capabilities supported. The format of the value part of the Hello TLV is as
follows:</t>
<figure title="Hello TLV" anchor="fig39"><artwork><![CDATA[ <figure anchor="fig39">
<name>Hello TLV</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 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 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 | | VerSupported |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor ID | | Vendor-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Capabilities | | Capabilities |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> </figure>
<t>Where:
<t>Where: </t>
<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 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 be non-zero. 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 bytes in length. Vendor ID, as defined in RADIUS
<xref target="RFC2865"/>.</t>
<t>Capabilities: 32 bits in length. Flags that indicate the support of <ul empty="true"><li>
particular capabilities by the sender of the Hello. No Capabilities <dl newline="false" spacing="normal">
are defined in this document, so implementations of the version <dt>TLV type:</dt><dd>100.</dd>
specified herein will set this field to zero. The Capabilities field <dt>TLV length:</dt><dd>12 octets.</dd>
of the Hello TLV MUST be checked before any other TLVs in the Hello <dt>VerSupported:</dt><dd>32 bits in length. It is a bit map of the
because capabilities defined in the future might extend existing TLVs Sub-Versions of S-CUSP that the sender supports. This document
or permit new TLVs.</t> specifies Sub-Version zero of Major Version 1, that is, Version
</list> 1.0. The VerSupported field <bcp14>MUST</bcp14> be nonzero. The
</t> VerSupported bits are numbered from 0 as the most significant
</list> bit. Bit 0 indicates support of Sub-Version zero, bit 1
</t> indicates support of Sub-Version one, etc.</dd>
<dt>Vendor-ID:</dt><dd>4 bytes in length. Vendor ID, as defined in RAD
IUS
<xref 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 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 <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.</dd>
</dl>
</li></ul>
<t> <t>
After the exchange of Hello messages, the CP and UP each perform a 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 logical AND of the Sub-Version supported by the CP and the UP and
separately perform a logical AND of the Capabilities bits fields for separately perform a logical AND of the Capabilities field for
the CP and the UP.</t> the CP and the UP.</t>
<t>
<t>
If the result of the AND of the Sub-Versions supported is zero, then If the result of the AND of the Sub-Versions supported is zero, then
no session can be established and the connection is torn down. If the no session can be established, and the connection is torn down. If the
result of the AND of the Sub-Versions supported is non-zero, then the result of the AND of the Sub-Versions supported is nonzero, then the
session uses the highest Sub-Version supported by both the CP and UP.</t> session uses the highest Sub-Version supported by both the CP and UP.</t>
<t>
<t>
For example, if one side supports Sub-Versions 1, 3, 4, and 5 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 = 0x5C000000) and the other side supports 2, 3, and 4
(VerSupported = 0x38000000), then 3 and 4 are the Sub-Versions in (VerSupported = 0x38000000), then 3 and 4 are the Sub-Versions in
common and 4 is the highest Sub-Version supported by both sides. So 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> Sub-Version 4 is used for the session that has been negotiated.</t>
<t>
<t>
The result of the logical AND of the Capabilities bits will show what The result of the logical AND of the Capabilities bits will show what
additional capabilities both sides support. If this result is zero, additional capabilities both sides support. If this result is zero,
there are no such capabilities so none can be used during the there are no such capabilities, so none can be used during the
session. If this result is non-zero, it shows the additional session. If this result is nonzero, it shows the additional
capabilities that can be used during the session. The CP and the UP capabilities that can be used during the session. The CP and the UP
MUST NOT use a capability unless both advertise support.</t> <bcp14>MUST NOT</bcp14> use a capability unless both advertise support.</t>
</section>
</section> <section anchor="sect-7.5" numbered="true" toc="default">
<name>Keepalive TLV</name>
<section title="The Keepalive TLV" anchor="sect-7.5"><t> <t>
The Keepalive TLV is carried in the Hello message. It provides The Keepalive TLV is carried in the Hello message. It provides
timing information for this feature. The format of Hello TLV is as timing information for this feature. The format of the value part of
follows:</t> the Keepalive TLV is as follows:</t>
<figure anchor="fig40">
<figure title="Keepalive TLV" anchor="fig40"><artwork><![CDATA[ <name>Keepalive TLV</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 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 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 | | Keepalive | DeadTimer | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> </figure>
<t>Where:
<t>Where: </t>
<list>
<t>The TLV type: 102.</t> <ul empty="true"><li>
<dl newline="false" spacing="normal">
<t>The value of the Length field is 4 octets.</t> <dt>TLV type:</dt><dd>102.</dd>
<dt>TLV length:</dt><dd>4 octets.</dd>
<t>Keepalive (8 bits): Indicates the maximum interval (in seconds) <dt>Keepalive (8 bits):</dt><dd>Indicates the maximum interval (in seconds)
between two consecutive S-CUSP messages sent by the sender of the between two consecutive S-CUSP messages sent by the sender of the message
message containing this TLV as an unsigned integer. The minimum value containing this TLV as an unsigned integer. The minimum value for the
for the Keepalive field is 1 second. When set to 0, once the session Keepalive field is 1 second. When set to 0, once the session is established,
is established, no further Keepalive messages are sent to the remote no further Keepalive messages are sent to the remote peer. A
peer. A RECOMMENDED value for the Keepalive frequency is 30 seconds.</t> <bcp14>RECOMMENDED</bcp14> value for the Keepalive frequency is 30
seconds.</dd>
<t>DeadTimer (8 bits in length): Specifies the amount of time as an <dt>DeadTimer (8 bits in length):</dt><dd>Specifies the amount
unsigned integer number of seconds after the expiration of which the of time as an unsigned integer number of seconds, after the expiration of
S-CUSP peer can declare the session with the sender of the Hello 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 message to be down if no S-CUSP message has been received. The DeadTimer
DeadTimer SHOULD be set to 0 and MUST be ignored if the Keepalive is <bcp14>SHOULD</bcp14> be set to 0 and <bcp14>MUST</bcp14> be ignored if the
set to 0. A RECOMMENDED value for the DeadTimer is 4 times the value Keepalive is set to 0. A <bcp14>RECOMMENDED</bcp14> value for the DeadTimer is
of the Keepalive.</t> 4 times the value of the Keepalive.</dd>
<t>The Reserved bits MUST be sent as zero and ignored on receipt.</t> <dt>Reserved:</dt><dd>The Reserved bits <bcp14>MUST</bcp14> be sent as
zero and
ignored on receipt.</dd>
</list> </dl>
</t> </li></ul>
</section> </section>
<section title="The Error Information TLV" anchor="sect-7.6"><t> <section anchor="sect-7.6" numbered="true" toc="default">
<name>Error Information TLV</name>
<t>
The Error Information TLV is a common TLV that can be used in many The Error Information TLV is a common TLV that can be used in many
Response (e.g., Update_Response message) and ACK messages (e.g., responses (e.g., Update_Response message) and ACK messages (e.g.,
Addr_Allocation_Ack message, etc.). It is used to convey the Addr_Allocation_Ack message). It is used to convey the
information about an error in the received S-CUSP message. The information about an error in the received S-CUSP message. The
format of the Error Information TLV is as follows:</t> format of the value part of the Error Information TLV is as follows:</t>
<figure anchor="fig41">
<figure title="Error Information TLV" anchor="fig41"><artwork><![CDATA[ <name>Error Information TLV</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 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 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 | | Message-Type | Reserved | TLV-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Code | | Error Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> </figure>
<t>Where:
<t>Where: </t>
<list>
<t>The TLV type: 101.</t>
<t>The value of the Length field is 8 octets.</t>
<t>Message-Type(1 byte): This parameter is the message type of the
message containing an error.</t>
<t>Reserved (1 byte): MUST be sent as zero and ignored on receipt.</t>
<t>TLV-Type (2 bytes): Indicates which TLV caused the error.</t>
<t>Error Code: 4 bytes in length. Indicate the specific Error Code <ul empty="true"><li>
(see <xref target="sect-9.5"/>).</t> <dl newline="false" spacing="normal">
</list> <dt>TLV type:</dt><dd>101.</dd>
</t> <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.</dd>
<dt>Reserved (1 byte):</dt><dd><bcp14>MUST</bcp14> be sent as zero and
ignored on receipt.</dd>
<dt>TLV-Type (2 bytes):</dt><dd>Indicates which TLV caused the error.<
/dd>
<dt>Error Code:</dt><dd>4 bytes in length. Indicate the specific Erro
r Code
(see <xref target="sect-9.5" format="default"/>).</dd>
</section> </dl>
</li></ul>
<section title="BAS Function TLV" anchor="sect-7.7"><t> </section>
<section anchor="sect-7.7" numbered="true" toc="default">
<name>BAS Function TLV</name>
<t>
The BAS Function TLV is used by a CP to control the access mode, The BAS Function TLV is used by a CP to control the access mode,
authentication methods, and other related functions of an interface authentication methods, and other related functions of an interface
on a UP.</t> on a UP.</t>
<t>The format of the BAS Function TLV value part is as follows:</t>
<t>The format of the BAS Function TLV value part is as follows:</t> <figure anchor="fig42">
<name>BAS Function TLV</name>
<figure title="BAS Function TLV" anchor="fig42"><artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 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 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 | | If-Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access-Mode | Auth-Method4 | Auth-Method6 | Reserved | | Access-Mode | Auth-Method4 | Auth-Method6 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-TLVs (optional) | | Sub-TLVs (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> </figure>
<t>Where: <t>Where:
</t>
<list> <ul empty="true"><li>
<t>The TLV type: 1.</t> <dl newline="false" spacing="normal">
<t>The value of the Length field is variable.</t> <dt>TLV type:</dt><dd>1.</dd>
<t>If-Index: 4 bytes in length, a unique identifier of an interface of <dt>TLV length:</dt><dd>Variable.</dd>
a BNG.</t>
<t>Access-Mode: 1 byte in length. It indicates the access mode of the <dt>If-Index:</dt><dd>4 bytes in length, a unique identifier of an int
interface. The defined values are listed in <xref erface of
target="sect-9.7"/>.</t> a BNG.</dd>
<t>Auth-Method4: 1 byte in length. It indicates the authentication on <dt>Access-Mode:</dt><dd>1 byte in length. It indicates the access mod
e of the
interface. The defined values are listed in <xref target="sect-9.7"
format="default"/>.</dd>
<dt>Auth-Method4:</dt><dd>1 byte in length. It indicates the authentic
ation on
this interface for the IPv4 scenario. This field is defined as a this interface for the IPv4 scenario. This field is defined as a
bitmap. The bits defined in this document are listed in <xref bitmap. The bits defined in this document are listed in <xref target="se
target="sect-9.8"/>. Other bits are reserved and MUST be sent as zero ct-9.8" format="default"/>. Other bits are reserved and <bcp14>MUST</bcp14> be s
and ignored on receipt.</t> ent as zero
and ignored on receipt.</dd>
<t>Auth-Method6: 1 byte in length. It indicates the authentication on <dt>Auth-Method6:</dt><dd>1 byte in length. It indicates the authentic ation on
this interface for the IPv6 scenario. This field is defined as a this interface for the IPv6 scenario. This field is defined as a
bitmap. The bits defined in this document are listed in <xref bitmap. The bits defined in this document are listed in <xref target="se
target="sect-9.8"/>. Other bits are reserved and MUST be sent as zero ct-9.8" format="default"/>. Other bits are reserved and <bcp14>MUST</bcp14> be s
and ignored on receipt.</t> ent as zero
and ignored on receipt.</dd>
<t>sub-TLVs: <dt>Sub-TLVs:</dt><dd><t>The IF-Desc sub-TLV can be carried.</t>
<list>
<t>The IF-Desc sub-TLV can be carried.</t>
<t> If-Desc sub-TLV: carries the interface information.</t>
</list>
</t>
<t>The flags field is defined as follows:</t> <dl newline="false" spacing="normal">
<dt>If-Desc sub-TLV:</dt><dd>Carries the interface information.</dd>
</dl>
</dd>
</list> <dt>Flags:</dt><dd>The Flags field is defined as follows:</dd>
</t>
<figure title="Interface Flags" anchor="fig43"><artwork><![CDATA[ </dl>
</li></ul>
<figure anchor="fig43">
<name>Interface Flags</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 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 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| | MBZ |Y|X|P|I|N|A|S|F|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> </figure>
<t>Where: <t>Where:
<list> </t>
<t>F (IPv4 Trigger) bit: Indicates whether IPv4 packets can trigger a
subscriber to go online. 1: enabled, 0: disabled.</t>
<t>S (IPv6 Trigger) bit: Indicates whether IPv6 packets can trigger a <ul empty="true">
subscriber to go online. 1: enabled, 0: disabled.</t> <li>
<dl newline="false" spacing="normal">
<t>A (ARP Trigger) bit: Indicates whether ARP packets can trigger <dt>F (IPv4 Trigger) bit:</dt>
a subscriber to go online. 1: enabled, 0: disabled.</t> <dd>
<t>Indicates whether IPv4 packets can trigger a
subscriber to go online.</t>
<dl newline= "false" spacing="normal">
<dt>1:</dt><dd>Enabled.</dd>
<dt>0:</dt><dd>Disabled.</dd>
</dl>
</dd>
<t>N (ND Trigger) bit: Indicates whether ND packets can trigger a <dt>S (IPv6 Trigger) bit:</dt><dd><t>Indicates whether IPv6 packets can tr
subscriber to go online. 1: enabled, 0: disabled.</t> igger a
subscriber to go online.</t>
<t>I (IPoE-Flow-Check): Used for UP detection. IPoE 1: Enable traffic <dl newline= "false" spacing="normal">
detection. 0: Disable traffic detection.</t> <dt>1:</dt><dd>Enabled.</dd>
<dt>0:</dt><dd>Disabled.</dd>
</dl>
<t>P (PPP-Flow-Check) bit: Used for UP detection. PPP 1: Enable </dd>
traffic detection. 0: Disable traffic detection.</t>
<t>X (ARP-Proxy) bit: 1: The interface is enabled with ARP proxy and <dt>A (ARP Trigger) bit:</dt><dd><t>Indicates whether ARP packets can trigg
can process ARP requests across different Port+VLANs. 0: The ARP proxy er
is not enabled on the interface and only the ARP requests of the same a subscriber to go online.</t>
Port+VLAN are processed.</t>
<t>Y (ND-Proxy) bit: 1: The interface is enabled with ND proxy and can <dl newline= "false" spacing="normal">
process ND requests across different Port+VLANs. 0: The ND proxy is <dt>1:</dt><dd>Enabled.</dd>
not enabled on the interface and only the ND requests of the same <dt>0:</dt><dd>Disabled.</dd>
Port+VLAN are processed.</t> </dl>
<t>MBZ: Reserved bits that MUST be sent as zero and ignored on receipt. </dd>
</t>
</list> <dt>N (ND Trigger) bit:</dt><dd><t>Indicates whether ND packets can trigge
</t> r a
subscriber to go online.</t>
</section> <dl newline= "false" spacing="normal">
<dt>1:</dt><dd>Enabled.</dd>
<dt>0:</dt><dd>Disabled.</dd>
</dl>
<section title="Routing TLVs" anchor="sect-7.8"><t> </dd>
<dt>I (IPoE-Flow-Check):</dt><dd><t>Used for UP detection.</t>
<dl newline= "false" spacing="normal">
<dt>1:</dt><dd>Enable traffic detection.</dd>
<dt>0:</dt><dd>Disable traffic detection.</dd>
</dl>
</dd>
<dt>P (PPP-Flow-Check) bit:</dt><dd><t>Used for UP detection.</t>
<dl newline= "false" spacing="normal">
<dt>1:</dt><dd>Enable traffic detection.</dd>
<dt>0:</dt><dd>Disable traffic detection.</dd>
</dl>
</dd>
<dt>X (ARP-Proxy) 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 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 network port and VLAN are processe
d.</dd>
</dl>
</dd>
<dt>Y (ND-Proxy) 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 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 network port and VLAN are processed
.</dd>
</dl>
</dd>
<dt>MBZ:</dt><dd>Reserved bits that <bcp14>MUST</bcp14> be sent as
zero and ignored on receipt.</dd>
</dl>
</li>
</ul>
</section>
<section 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 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 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 UP. Those IP addresses will be allocated to subscribers who will
dial-up (as defined in <xref target="sect-2.1"/>) to the UP. To make sure th at dial-up (as defined in <xref target="sect-4.3.1" format="default"/>) to the U P. To make sure that
other nodes within the network learn how to reach those IP addresses, 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 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 addresses on the UP and notify the UP to advertise the routes to the
network.</t> network.</t>
<t>
<t>
The Routing TLVs are used by a CP to notify a UP of the updates to 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 network routing information. They can be carried in the
Update_Request message and Sync_Data message.</t> Update_Request message and Sync_Data message.</t>
<section anchor="sect-7.8.1" numbered="true" toc="default">
<section title="IPv4 Routing TLV" anchor="sect-7.8.1"><t> <name>IPv4 Routing TLV</name>
<t>
The IPv4 Routing TLV is used to carry information related to IPv4 The IPv4 Routing TLV is used to carry information related to IPv4
network routing.</t> network routing.</t>
<t>The format of the TLV value part is as below:</t>
<t>The format of the TLV value part is as below:</t> <figure anchor="fig44">
<name>IPv4 Routing TLV</name>
<figure title="IPv4 Routing TLV" anchor="fig44"><artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 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 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 | | Dest-Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next-Hop | | Next-Hop |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Out-If-Index | | Out-If-Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cost | | Cost |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag | | Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Route Type | Reserved |A| | Route-Type | Reserved |A|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ sub-TLVs (optional) ~ ~ Sub-TLVs (optional) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> </figure>
<t>Where:
<t>Where: </t>
<list>
<t>The TLV Type: 7</t>
<t>The TLV Length: Variable</t>
<t>User-ID: 4 bytes in length. This field carries the user <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 identifier. It is filled with all Fs when a non-user route is
delivered to the UP.</t> delivered to the UP.</dd>
<dt>Dest-Address (IPv4-Address type):</dt><dd>Identifies the destina
<t>Dest-Address (IPv4-Address type): Identifies the destination tion
address.</t> address.</dd>
<dt>Next-Hop (IPv4-Address type):</dt><dd>Identifies the next-hop ad
<t>Next-Hop: (IPv4-Address type): Identifies the next hop address.</t> dress.</dd>
<dt>Out-If-Index (4 bytes):</dt><dd>Indicates the interface index.</
<t>Out-If-Index (4 bytes): Indicates the interface index.</t> dd>
<dt>Cost (4 bytes):</dt><dd>The cost value of the route.</dd>
<t>Cost (4 bytes): The cost value of the route.</t> <dt>Tag (4 bytes):</dt><dd>The tag value of the route.</dd>
<dt>Route-Type (2 bytes):</dt><dd>The value of this field
<t>Tag (4 bytes): The tag value of the route.</t> indicates the route type. The values defined in this document are
listed in <xref target="sect-9.9" format="default"/>.</dd>
<t>Route-Type (2 bytes): The value of this field indicates the route <dt>Advertise-Flag:</dt><dd><t>1 bit shown as "A" in the figure abov
type. The values defined in this document are listed in <xref e
target="sect-9.9"/>.</t> (<xref target="fig44" format="default"/>). Indicates whether the
UP should advertise the route. The following flag values are
<t>Advertise-Flag: 1 bit shown as &quot;A&quot; is the figure above. defined:</t>
Indicates whether the IP 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 VRF-Name and/or If-Desc sub-TLVs can be carried.
<list>
<t>VRF-Name sub-TLV: indicates which VRF the route belongs to.</t>
<t> If-Desc sub-TLV: carries the interface information.</t>
</list>
</t>
<t> The Reserved field MUST be sent as zero and ignored on receipt.</t> <dl newline="false" spacing="normal">
<dt>0:</dt><dd>Not advertised.</dd>
<dt>1:</dt><dd>Advertised.</dd>
</dl>
</dd>
</list> <dt>Sub-TLVs:</dt><dd><t>The VRF-Name and/or If-Desc sub-TLVs
</t> can be carried.</t>
</section> <dl newline="false" spacing="normal">
<dt>VRF-Name sub-TLV:</dt><dd>Indicates which VRF the route
belongs to.</dd>
<dt>If-Desc sub-TLV:</dt><dd>Carries the interface information.<
/dd>
</dl>
</dd>
<dt>Reserved:</dt><dd>The Reserved field <bcp14>MUST</bcp14> be
sent as zero and ignored on receipt.</dd>
<section title="IPv6 Routing TLV" anchor="sect-7.8.2"><t> </dl>
</li></ul>
</section>
<section anchor="sect-7.8.2" numbered="true" toc="default">
<name>IPv6 Routing TLV</name>
<t>
The IPv6 Routing TLV is used to carry IPv6 network routing The IPv6 Routing TLV is used to carry IPv6 network routing
information.</t> information.</t>
<t>The format of the value part of this TLV is as follows:</t>
<t>The format of this TLV is as follows:</t> <figure anchor="fig45">
<name>IPv6 Routing TLV</name>
<figure title="IPv6 Routing TLV" anchor="fig45"><artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 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 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 Dest-Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ IPv6 Next-Hop ~ ~ IPv6 Next-Hop ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Out-If-Index | | Out-If-Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cost | | Cost |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag | | Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Route Type | Reserved |A| | Route-Type | Reserved |A|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ sub-TLVs (optional) ~ ~ Sub-TLVs (optional) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> </figure>
<t>Where:
<t>Where: </t>
<list>
<t>The TLV Type: 7</t>
<t>The TLV Length is Variable.</t> <ul empty="true"><li>
<dl newline="false" spacing="normal">
<t>User-ID: 4 bytes in length. This field carries the user identifier. <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 This field is filled with all Fs when a non-user route is delivered to
the UP.</t> the UP.</dd>
<dt>IPv6 Dest-Address (IPv6-Address type):</dt><dd>Identifies the de
<t>IPv6 Dest-Address (IPv6-Address type): Identifies the destination stination
address.</t> address.</dd>
<dt>IPv6 Next-Hop (IPv6-Address type):</dt><dd>Identifies the next-h
<t>IPv6 Next-Hop: (IPv6-Address type): Identifies the next hop op
address.</t> address.</dd>
<dt>Out-If-Index (4 bytes):</dt><dd>Indicates the interface index.</
<t>Out-If-Index (4 bytes): Indicates the interface index.</t> dd>
<dt>Cost (4 bytes):</dt><dd>This is the cost value of the route.</dd
<t>Cost (4 bytes): This is the cost value of the route.</t> >
<dt>Tag (4 bytes):</dt><dd>The tag value of the route.</dd>
<t>Tag (4 bytes): The tag value of the route.</t> <dt>Route-Type (2 bytes):</dt><dd>The value of this field
indicates the route type. The values defined in this document are
<t>Route-Type: (2 bytes): The value of this field indicates the route listed in <xref target="sect-9.9" format="default"/>.</dd>
type. The values defined in this document are listed in <xref
target="sect-9.9"/>.</t>
<t>Advertise-Flag: 1 bit shown as &quot;A&quot; is the figure above.
Indicates whether UP should advertise the route. Following flags are
defined:
<list> <dt>Advertise-Flag:</dt><dd><t>1 bit shown as "A" in the figure
<t>0: Not advertised,</t> above (<xref target="fig45" format="default"/>). Indicates
<t>1: Advertised.</t> whether the UP should advertise the route. The following flags
</list> are defined:</t>
</t>
<t>sub-TLVs: If-Desc and VRF-Name sub-TLVs can be carried. <dl newline="false" spacing="normal">
<dt>0:</dt><dd>Not advertised.</dd>
<dt>1:</dt><dd>Advertised.</dd>
</dl>
</dd>
<list> <dt>Sub-TLVs:</dt><dd><t>The If-Desc and VRF-Name sub-TLVs can be ca
<t>VRF-Name sub-TLV: Indicates the VRF to which the subscriber rried.</t>
belongs.</t>
<t> If-Desc sub TLV: carries the interface information.</t>
</list>
</t>
<t> The Reserved field MUST be sent as zero and ignored on receipt.</t> <dl newline="false" spacing="normal">
<dt>VRF-Name sub-TLV:</dt><dd>Indicates the VRF to which the sub
scriber
belongs.</dd>
<dt>If-Desc sub-TLV:</dt><dd>Carries the interface information.<
/dd>
</dl>
</dd>
</list> <dt>Reserved:</dt><dd>The Reserved field <bcp14>MUST</bcp14> be sent
</t> as zero and ignored on receipt.</dd>
</section>
</section> </dl>
</li></ul>
<section title="Subscriber TLVs" anchor="sect-7.9"><t> </section>
</section>
<section 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 The Subscriber TLVs are defined for a CP to send the basic
information about a user to a UP.</t> information about a user to a UP.</t>
<section anchor="sect-7.9.1" numbered="true" toc="default">
<section title="Basic Subscriber TLV" anchor="sect-7.9.1"><t> <name>Basic Subscriber TLV</name>
The Basic Subscriber TLV is used to carry the basic common <t>
The Basic Subscriber TLV is used to carry the common
information for all kinds of access subscribers. It is carried in an information for all kinds of access subscribers. It is carried in an
Update_Request message.</t> Update_Request message.</t>
<t>The format of the Basic Subscriber TLV value part is as follows:</t
<t>The format of the Basic Subscriber TLV value part is as follows:</t> >
<figure anchor="fig46">
<figure title="Basic Subscriber TLV" anchor="fig46"><artwork><![CDATA[ <name>Basic Subscriber TLV</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 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 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 | Oper ID | Reserved | | User-MAC (cont.) | Oper-ID | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access Type |Sub-access Type| Account Type | Address Family| | Access-Type |Sub-Access-Type| Account-Type | Address Family|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| C-VID | P-VID | | C-VID | P-VID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Detect Times | Detect Interval | | Detect-Times | Detect-Interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| If-Index | | If-Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ sub-TLVs (optional) ~ ~ Sub-TLVs (optional) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> </figure>
<t>Where:
<t>Where: </t>
<list>
<t>The TLV Type: 2.</t>
<t>The TLV is variable in length.</t>
<t>User-ID (4 bytes): The identifier of a subscriber.</t>
<t>Session-ID (4 bytes): Session ID of a PPPoE subscriber. The value
zero identifies a non-PPPoE subscriber.</t>
<t>User-Mac (MAC-Addr type): The MAC Address of a subscriber.</t>
<t>Oper-ID (1 byte): Indicates the ID of an operation performed by a
user. This field is carried in the response from the UP.</t>
<t>Reserved (1 byte): MUST be sent as zero and ignored on receipt.</t>
<t>Access-Type (1 byte): Indicates the type of subscriber access. Values
defined in this document are listed in <xref target="sect-9.10"/>.</t>
<t>Sub-Access-Type (1 byte): Indicates whether PPP termination or PPP
relay is used.
<list>
<t>0: Reserved</t>
<t>1: PPP Relay (for LAC)</t>
<t>2: PPP termination (for LNS)</t>
</list>
</t>
<t>Account-Type (1 byte): <ul empty="true">
<list> <li>
<t>0: Collects statistics on IPv4 and IPv6 traffic of terminals <dl newline="false" spacing="normal">
independently.</t> <dt>TLV type:</dt><dd>2.</dd>
<t>1: Collects statistics on IPv4 and IPv6 traffic of terminals.</t> <dt>TLV length:</dt><dd>Variable.</dd>
<dt>User-ID (4 bytes):</dt><dd>The identifier of a subscriber.</dd>
<dt>Session-ID (4 bytes):</dt><dd>Session ID of a PPPoE subscriber.
The value zero identifies a non-PPPoE subscriber.</dd>
<dt>User-MAC (MAC-Addr type):</dt><dd>The MAC address of a subscriber.</dd
>
<dt>Oper-ID (1 byte):</dt><dd>Indicates the ID of an operation performed b
y a
user. This field is carried in the response from the UP.</dd>
<dt>Reserved (1 byte):</dt><dd><bcp14>MUST</bcp14> be sent as zero
and ignored on receipt.</dd>
<dt>Access-Type (1 byte):</dt><dd>Indicates the type of subscriber
access. Values defined in this document are listed in <xref
target="sect-9.10" format="default"/>.</dd>
<dt>Sub-Access-Type (1 byte):</dt>
<dd>
<t>Indicates whether PPP termination or PPP relay is used.</t>
<dl newline="false" spacing="normal">
<dt>0:</dt><dd>Reserved.</dd>
<dt>1:</dt><dd>PPP Relay (for LAC).</dd>
<dt>2:</dt><dd>PPP termination (for LNS).</dd>
</dl>
</dd>
</list> <dt>Account-Type (1 byte):</dt>
</t> <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.</dd>
<dt>1:</dt><dd>Collects statistics on IPv4 and IPv6
traffic of terminals.</dd>
</dl>
</dd>
<t>Address Family (1 byte) <dt>Address Family (1 byte):</dt>
<list> <dd>
<t>1: IPv4</t> <t>The type of IP address.</t>
<t>2: IPv6</t> <dl newline="false" spacing="normal">
<t>3: dual stack</t> <dt>1:</dt><dd>IPv4.</dd>
</list> <dt>2:</dt><dd>IPv6.</dd>
</t> <dt>3:</dt><dd>Dual stack.</dd>
</dl>
</dd>
<t>C-VID (VLAN-ID): Indicates the inner VLAN ID. The value 0 <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, indicates that the VLAN ID is invalid. The default value of PRI is 7,
the value of DEI is 0, and the value of VID is 1~4094. The PRI value the value of DEI is 0, and the value of VID is 1-4094. The PRI value
can also be obtained by parsing terminal packets.</t> can also be obtained by parsing terminal packets.</dd>
<t>P-VID (VLAN-ID): Indicates the outer VLAN ID. The value 0 <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 indicates that the VLAN ID is invalid. The format is the same as that
for C-VID.</t> for C-VID.</dd>
<t>Detect-Times (2 bytes): Number of detection timeout times. The
value 0 indicates that no detection is performed.</t>
<t>Detect-Interval (2 bytes): Detection interval in seconds.</t>
<t>If-Index (4 bytes): Interface index.</t>
<t> Sub-TLVs: VRF-Name sub-TLV and If-Desc sub-TLV can be carried.</t>
<t>VRF-Name sub-TLV: Indicates the VRF to which the subscriber <dt>Detect-Times (2 bytes):</dt><dd>Number of detection timeout times. Th
belongs.</t> e
value 0 indicates that no detection is performed.</dd>
<t>If-Desc sub-TLV: carries the interface information.</t> <dt>Detect-Interval (2 bytes):</dt><dd>Detection interval in
seconds.</dd>
<t>The Reserved field MUST be sent as zero and ignored on receipt.</t> <dt>If-Index (4 bytes):</dt><dd>Interface index.</dd>
</list> <dt>Sub-TLVs:</dt>
</t> <dd>
<t>The VRF-Name sub-TLV and If-Desc sub-TLV can
be carried.</t>
<dl newline="false" spacing="normal">
<dt>VRF-Name sub-TLV:</dt><dd>Indicates the VRF to which the
subscriber belongs.</dd>
<dt>If-Desc sub-TLV:</dt><dd>Carries the interface information.
</dd>
</dl>
</dd>
</section> <dt>Reserved:</dt><dd>The Reserved field <bcp14>MUST</bcp14> be sent as
zero and ignored on receipt.</dd>
</dl>
</li>
</ul>
<section title="PPP Subscriber TLV" anchor="sect-7.9.2"><t> </section>
The PPP Subscriber TLV is defined to carry PPP information of a User <section anchor="sect-7.9.2" numbered="true" toc="default">
<name>PPP Subscriber TLV</name>
<t>
The PPP Subscriber TLV is defined to carry PPP information of a user
from a CP to a UP. It will be carried in an Update_Request message from a CP to a UP. It will be carried in an Update_Request message
when PPPoE or L2TP access is used.</t> when PPPoE or L2TP access is used.</t>
<t>The format of the TLV value part is as follows:</t>
<t>The format of the TLV value part is as follows:</t> <figure anchor="fig47">
<name>PPP Subscriber TLV</name>
<figure title="PPP Subscriber TLV" anchor="fig47"><artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 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 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 | Reserved |M| | MSS-Value | Reserved |M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MRU | Reserved | | MRU | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Magic Number | | Magic-Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer Magic Number | | Peer-Magic-Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> </figure>
<t>Where: <t>Where:
</t>
<list>
<t>The TLV type: 3.</t>
<t>The TLV length is 12 octets.</t>
<t>User-ID (4 bytes): The identifier of a subscriber.</t>
<t>MSS-Value (2 bytes): Indicates the MSS value (in bytes).</t>
<t>MSS-Enable (M) (1 bit): Indicates whether the MSS is enabled.
<list>
<t>0: Disabled.</t>
<t>1: Enabled.</t>
</list>
</t>
<t>MRU (2 bytes): PPPoE local MRU (in bytes).</t> <ul empty="true"><li>
<dl newline="false" spacing="normal">
<t>Magic-Number (4 bytes): Local magic number in PPP negotiation <dt>TLV type:</dt><dd>3.</dd>
packets.</t> <dt>TLV length:</dt><dd>12 octets.</dd>
<dt>User-ID (4 bytes):</dt><dd>The identifier of a subscriber.</dd>
<dt>MSS-Value (2 bytes):</dt><dd>Indicates the MSS value (in
bytes).</dd>
<t>Peer-Magic-Number (4 bytes): Remote peer magic number.</t> <dt>MSS-Enable (M) (1 bit):</dt><dd><t>Indicates whether the MSS
is enabled.</t>
<t>The Reserved fields MUST be sent as zero and ignored on <dl newline="false" spacing="normal">
receipt.</t> <dt>0:</dt><dd>Disabled.</dd>
<dt>1:</dt><dd>Enabled.</dd>
</dl>
</dd>
</list> <dt>MRU (2 bytes):</dt><dd>PPPoE local MRU (in bytes).</dd>
</t> <dt>Magic-Number (4 bytes):</dt><dd>Local magic number in PPP negoti
ation
packets.</dd>
<dt>Peer-Magic-Number (4 bytes):</dt><dd>Remote peer magic number.</
dd>
<dt>Reserved:</dt><dd>The Reserved fields <bcp14>MUST</bcp14> be
sent as zero and ignored on receipt.</dd>
</section> </dl>
</li></ul>
<section title="IPv4 Subscriber TLV" anchor="sect-7.9.3"><t> </section>
The IPv4 Subscriber TLV is defined to carry IPv4 related information <section anchor="sect-7.9.3" numbered="true" toc="default">
<name>IPv4 Subscriber TLV</name>
<t>
The IPv4 Subscriber TLV is defined to carry IPv4-related information
for a BNG user. It will be carried in an Update_Request message when for a BNG user. It will be carried in an Update_Request message when
IPv4 IPoE or PPPoE access is used.</t> IPv4 IPoE or PPPoE access is used.</t>
<t>The format of the TLV value part is as follows:</t>
<t>The format of the TLV value part is as follows:</t> <figure anchor="fig48">
<name>IPv4 Subscriber TLV</name>
<figure title="IPv4 Subscriber TLV" anchor="fig48"><artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 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 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| | MTU | Reserved |U|E|W|P|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ VRF-Name sub-TLV ~ ~ VRF-Name Sub-TLV ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> </figure>
<t>Where: <t>Where:
</t>
<list> <ul empty="true"><li>
<t>The TLV type: 4.</t> <dl newline="false" spacing="normal">
<dt>TLV type:</dt><dd>4.</dd>
<dt>TLV length:</dt><dd>Variable.</dd>
<dt>User-ID (4 bytes):</dt><dd>The identifier of a subscriber.</dd>
<dt>User-IPv4 (IPv4-Address):</dt><dd>The IPv4 address of the subscr
iber.</dd>
<dt>Gateway-IPv4 (IPv4-Address):</dt><dd>The gateway address of the
subscriber.</dd>
<t>The TLV length is variable.</t> <dt>Portal-Force (P) (1 bit):</dt><dd><t>Push advertisement.</t>
<t>User-ID (4 bytes): The identifier of a subscriber.</t> <dl newline= "false" spacing="normal">
<dt>0:</dt><dd>Off.</dd>
<dt>1:</dt><dd>On.</dd>
</dl>
<t>User-IPv4 (IPv4-Address): The IPv4 address of the subscriber.</t> </dd>
<t>Gateway-IPv4 (IPv4-Address): The gateway address of the <dt>Web-Force (W) (1 bit):</dt><dd><t>Push IPv4 Web.</t>
subscriber.</t>
<t>Portal Force (P) (1 bit ): Push advertisement, 0: off, 1: on.</t> <dl newline= "false" spacing="normal">
<dt>0:</dt><dd>Off.</dd>
<dt>1:</dt><dd>On.</dd>
</dl>
<t>Web-Force (W) (1 bit): Push IPv4 Web. 0: off, 1: on. </t> </dd>
<t>Echo-Enable (E) (1 bit): UP returns ARP Req or PPP Echo. 0: off, <dt>Echo-Enable (E) (1 bit):</dt><dd><t>UP returns ARP Req or PPP Ec
1: on.</t> ho.</t>
<t>IPv4-URPF (U) (1 bit): User Unicast Reverse Path Forwarding (URPF) <dl newline= "false" spacing="normal">
flag. 0: off, 1: on.</t> <dt>0:</dt><dd>Off.</dd>
<dt>1:</dt><dd>On.</dd>
</dl>
<t>MTU 2 bytes MTU value. The default value is 1500.</t> </dd>
<t>VRF-Name Sub-TLV: Indicates the subscriber belongs to which VRF.</t> <dt>IPv4-URPF (U) (1 bit):</dt><dd><t>User Unicast Reverse Path Forw
arding (URPF)
flag.</t>
<t>The Reserved field MUST be sent as zero and ignored on receipt.</t> <dl newline= "false" spacing="normal">
<dt>0:</dt><dd>Off.</dd>
<dt>1:</dt><dd>On.</dd>
</dl>
</list> </dd>
</t>
</section> <dt>MTU (2 bytes):</dt><dd>MTU value. The default value is 1500.</d
d>
<dt>VRF-Name Sub-TLV:</dt><dd>Indicates the subscriber belongs to wh
ich VRF.</dd>
<dt>Reserved:</dt><dd>The Reserved field <bcp14>MUST</bcp14> be sent
as zero and ignored on receipt.</dd>
<section title="IPv6 Subscriber TLV" anchor="sect-7.9.4"><t> </dl>
The IPv6 Subscriber TLV is defined to carry IPv6 related information </li></ul>
</section>
<section anchor="sect-7.9.4" numbered="true" toc="default">
<name>IPv6 Subscriber TLV</name>
<t>
The IPv6 Subscriber TLV is defined to carry IPv6-related information
for a BNG user. It will be carried in an Update_Request message when for a BNG user. It will be carried in an Update_Request message when
IPv6 IPoE or PPPoE access is used.</t> IPv6 IPoE or PPPoE access is used.</t>
<t>The format of the TLV value part is as follows:</t>
<t>The format of the TLV value part is as follows:</t> <figure anchor="fig49">
<name>IPv6 Subscriber TLV</name>
<figure title="IPv6 Subscriber TLV" anchor="fig49"><artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 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 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 PD-Address (IPv6 Address List sub-TLV) ~ ~ User PD-Address (IPv6 Address List Sub-TLV) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Gateway ND-Address (IPv6 Address List sub-TLV) ~ ~ Gateway ND-Address (IPv6 Address List Sub-TLV) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| User Link-Local-Address | | User Link-Local-Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Interface ID | | IPv6 Interface ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Interface ID (cont.) | | IPv6 Interface ID (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MTU | Reserved |U|E|W|P| | MTU | Reserved |U|E|W|P|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ VRF Name sub-TLV (optional) ~ ~ VRF Name Sub-TLV (optional) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> </figure>
<t>Where:
<t>Where: </t>
<list> <ul empty="true"><li>
<t>The TLV type: 5.</t> <dl newline="false" spacing="normal">
<t>The TLV length is variable.</t> <dt>TLV type:</dt><dd>5.</dd>
<dt>TLV length:</dt><dd>Variable.</dd>
<dt>User-ID (4 bytes):</dt><dd>The identifier of a subscriber.</dd>
<dt>User PD-Addresses (IPv6 Address List):</dt><dd>Carries a list of
Prefix
Delegation (PD) addresses of the subscriber.</dd>
<dt>User ND-Addresses (IPv6 Address List):</dt><dd>Carries a list of
Neighbor
Discovery (ND) addresses of the subscriber.</dd>
<dt>User Link-Local-Address (IPv6-Address):</dt><dd>The link-local a
ddress of
the subscriber.</dd>
<dt>IPv6 Interface ID (8 bytes):</dt><dd>The identifier of an IPv6
interface.</dd>
<t>User-ID (4 bytes): The identifier of a subscriber.</t> <dt>Portal-Force 1 bit (P):</dt><dd><t>Push advertisement.</t>
<t>User PD-Addresses (IPv6 Address List): Carries a list of Prefix <dl newline= "false" spacing="normal">
Delegation (PD) addresses of the subscriber.</t> <dt>0:</dt><dd>Off.</dd>
<dt>1:</dt><dd>On.</dd>
</dl>
<t>User ND-Addresses (IPv6 Address List): Carries a list of Neighbor </dd>
Discovery (ND) addresses of the subscriber.</t>
<t>User Link-Local-Address (IPv6-Address): The link-local address of <dt>Web-Force 1 bit (W):</dt><dd><t>Push IPv6 Web.</t>
the subscriber.</t>
<t>IPv6 Interface ID (8 bytes): The identifier of an IPv6 <dl newline= "false" spacing="normal">
interface.</t> <dt>0:</dt><dd>Off.</dd>
<dt>1:</dt><dd>On.</dd>
</dl>
<t>Portal Force 1 bit (P): Push advertisement, 0: off, 1: on.</t> </dd>
<t>Web-Force 1 bit (W): Push IPv6 Web, 0: off, 1: on.</t> <dt>Echo-Enable 1 bit (E):</dt><dd><t>The UP returns ARP Req or
PPP Echo.</t>
<t>Echo-Enable 1 bit (E): The UP returns ARP Req or PPP Echo. 0: off; <dl newline= "false" spacing="normal">
1: on.</t> <dt>0:</dt><dd>Off.</dd>
<dt>1:</dt><dd>On.</dd>
</dl>
<t>IPv6-URPF 1 bit (U): User Reverse Path Forwarding (URPF) flag, 0: </dd>
off; 1: on.</t>
<t>MTU (2 bytes): The MTU value. The default value is 1500.</t> <dt>IPv6-URPF 1 bit (U):</dt><dd><t>User Reverse Path Forwarding
(URPF) flag.</t>
<t>VRF-Name Sub-TLV: Indicates the VRF to which the subscriber <dl newline= "false" spacing="normal">
belongs.</t> <dt>0:</dt><dd>Off.</dd>
<dt>1:</dt><dd>On.</dd>
</dl>
<t> The Reserved field MUST be sent as zero and ignored on </dd>
receipt.</t>
</list> <dt>MTU (2 bytes):</dt><dd>The MTU value. The default value is 1500.
</t> </dd>
<dt>VRF-Name Sub-TLV:</dt><dd>Indicates the VRF to which the subscri
ber
belongs.</dd>
<dt>Reserved:</dt><dd>The Reserved field <bcp14>MUST</bcp14> be sent
as zero and ignored on
receipt.</dd>
</section> </dl>
</li></ul>
<section title="IPv4 Static Subscriber Detect TLV" anchor="sect-7.9.5"><t </section>
> <section anchor="sect-7.9.5" numbered="true" toc="default">
The IPv4 Static Subscriber Detect TLV is defined to carry IPv4 <name>IPv4 Static Subscriber Detect TLV</name>
related information for a static access subscriber. It will be <t>
The IPv4 Static Subscriber Detect TLV is defined to carry IPv4-related
information for a static access subscriber. It will be
carried in an Update_Request message when IPv4 static access on a UP carried in an Update_Request message when IPv4 static access on a UP
needs to be enabled.</t> needs to be enabled.</t>
<t>The format of the TLV value part is as follows:</t>
<t>The format of the TLV value part is as follows:</t> <figure anchor="fig50">
<name>IPv4 Static Subscriber TLV</name>
<figure title="IPv4 Static Subscriber TLV" anchor="fig50"><artwork><![CDA <artwork name="" type="" align="left" alt=""><![CDATA[
TA[
0 1 2 3 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 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 | | If-Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| C-VID | P-VID | | C-VID | P-VID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| User Address | | User Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Gateway Address | | Gateway Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| User MAC | | User-MAC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| User MAC (cont.) | Reserved | | User-MAC (cont.) | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ sub-TLVs (optional) ~ ~ Sub-TLVs (optional) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> </figure>
<t>Where:
<t>Where: </t>
<list>
<t>The TLV type: 6.</t>
<t>The TLV length is variable.</t>
<t>If-Index (4 bytes): The interface index of the interface from which
the subscriber will dial-up.</t>
<t>C-VID (VLAN-ID): Indicates the inner VLAN ID. The value 0 <ul empty="true"><li>
indicates that the VLAN ID is invalid. A valid value is 1~4094.</t> <dl newline="false" spacing="normal">
<t>P-VID (VLAN-ID): Indicates the outer VLAN ID. The value 0 <dt>TLV type:</dt><dd>9.</dd>
<dt>TLV length:</dt><dd>Variable.</dd>
<dt>If-Index (4 bytes):</dt><dd>The interface index of the interface
from which
the subscriber will 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.</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 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 of the C-VID. A valid value is 1-4094. </dd>
this parameter to PeVid.</t> <dt>User Address (IPv4-Addr):</dt><dd>The user's IPv4 address.</dd>
<dt>Gateway Address (IPv4-Addr):</dt><dd>The gateway's IPv4 address.
<t>User Address (IPv4-Addr): The user's IPv4 address.</t> </dd>
<dt>User-MAC (MAC-Addr type):</dt><dd>The MAC address of the subscri
<t>Gateway Address (IPv4-Addr): The gateway's IPv4 Address.</t> ber.</dd>
<t>User-MAC (MAC-Addr type): The MAC address of the subscriber.</t>
<t>Sub-TLVs: VRF-Name and If-Desc sub-TLVs may be carried.</t>
<t>VRF-Name sub-TLV: Indicates the VEF to which the subscriber
belongs.</t>
<t>If-Desc sub-TLV: Carries the interface information.</t> <dt>Sub-TLVs:</dt><dd><t>The VRF-Name and If-Desc sub-TLVs may be
carried.</t>
<t> The Reserved field MUST be sent as zero and ignored on <dl newline="false" spacing="normal">
receipt.</t> <dt>VRF-Name sub-TLV:</dt><dd>Indicates the VRF to which the sub
scriber
belongs.</dd>
<dt>If-Desc sub-TLV:</dt><dd>Carries the interface information.<
/dd>
</dl>
</dd>
</list> <dt>Reserved:</dt><dd>The Reserved field <bcp14>MUST</bcp14> be
</t> sent as zero and ignored on receipt.</dd>
</section> </dl>
</li></ul>
<section title="IPv6 Static Subscriber Detect TLV" anchor="sect-7.9.6"><t </section>
> <section anchor="sect-7.9.6" numbered="true" toc="default">
The IPv6 Static Subscriber Detect TLV is defined to carry IPv6 <name>IPv6 Static Subscriber Detect TLV</name>
related information for a static access subscriber. It will be <t>
The IPv6 Static Subscriber Detect TLV is defined to carry IPv6-related
information for a static access subscriber. It will be
carried in an Update_Request message when needed to enable IPv6 carried in an Update_Request message when needed to enable IPv6
static subscriber detection on a UP.</t> static subscriber detection on a UP.</t>
<t>The format of the TLV value part is as follows:</t>
<t>The format of the TLV value part is as follows:</t> <figure anchor="fig51">
<name>IPv6 Static Subscriber Detect TLV</name>
<figure title="IPv6 Static Subscriber Detect TLV" anchor="fig51"><artwork <artwork name="" type="" align="left" alt=""><![CDATA[
><![CDATA[
0 1 2 3 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 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 | | If-Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| C-VID | P-VID | | C-VID | P-VID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ User Address ~ ~ User Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Gateway Address ~ ~ Gateway Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| User MAC | | User-MAC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| User MAC (cont.) | Reserved | | User-MAC (cont.) | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ sub-TLVs (optional) ~ ~ Sub-TLVs (optional) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> </figure>
<t>Where:
<t>Where: </t>
<list>
<t>The TLV type: 6.</t>
<t>The TLV length is variable.</t>
<t>If-Index (4 bytes): The interface index of the interface from which
the subscriber will dial-up.</t>
<t>C-VID (VLAN-ID): 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 the outer VLAN ID. The value 0 <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):</dt><dd>The interface index of the interface
from which
the subscriber will 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.</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 indicates that the VLAN ID is invalid. The format is the same as that
the of C-VID. A valid value is 1~4094. For a single-layer VLAN, set the of C-VID. A valid value is 1-4094. For a single-layer VLAN, set
this parameter to PeVid.</t> this parameter to PeVid.</dd>
<dt>User Address (IPv6-Address type):</dt><dd>The subscriber's IPv6
<t>User Address (IPv6-Address type): The subscriber's IPv6 address.</t> address.</dd>
<dt>Gateway Address (IPv6-Address type):</dt><dd>The gateway's
<t>Gateway Address (IPv6-Address type): The gateway's IPv6 Address.</t> IPv6 Address.</dd>
<dt>User-MAC (MAC-Addr type):</dt><dd>The MAC
<t>User-MAC (MAC-Addr type): The MAC address of the subscriber.</t> address of the subscriber.</dd>
<t>sub-TLVs: VRF-Name and If-Desc sub-TLVs may be carried
<list>
<t>VRF-Name Sub-TLV: Indicates the VRF to which the subscriber belongs.</
t>
<t>If-Desc sub-TLV: Carries the interface information.</t> <dt>Sub-TLVs:</dt><dd><t>VRF-Name and If-Desc sub-TLVs may be carrie d</t>
</list> <dl newline="false" spacing="normal">
</t> <dt>VRF-Name sub-TLV:</dt><dd>Indicates the VRF to which the
subscriber belongs.</dd>
<dt>If-Desc sub-TLV:</dt><dd>Carries the interface information.<
/dd>
</dl>
<t> The Reserved field MUST be sent as zero and ignored on receipt.</t> </dd>
</list> <dt>Reserved:</dt><dd>The Reserved field <bcp14>MUST</bcp14> be
</t> sent as zero and ignored on receipt.</dd>
</section> </dl>
</li></ul>
<section title="L2TP-LAC Subscriber TLV" anchor="sect-7.9.7"><t> </section>
<section anchor="sect-7.9.7" numbered="true" toc="default">
<name>L2TP-LAC Subscriber TLV</name>
<t>
The L2TP-LAC Subscriber TLV is defined to carry the related The L2TP-LAC Subscriber TLV is defined to carry the related
information for an L2TP LAC access subscriber. It will be carried in information for an L2TP LAC access subscriber. It will be carried in
an Update_Request message when L2TP LAC access is used.</t> an Update_Request message when L2TP LAC access is used.</t>
<t>The format of the TLV value part is as follows:</t>
<t>The format of the TLV value part is as follows:</t> <figure anchor="fig52">
<name>L2TP-LAC Subscriber TLV</name>
<figure title="L2TP-LAC Subscriber TLV" anchor="fig52"><artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 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 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 Session ID | | Local-Tunnel-ID | Local-Session-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote Tunnel ID | Remote Session ID | | Remote-Tunnel-ID | Remote-Session-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> </figure>
<t>Where:
<t>Where: </t>
<list>
<t>The TLV type: 11.</t>
<t>The TLV is 12 octets long.</t>
<t>User-ID (4 bytes): The identifier of a user/subscriber.</t>
<t>Local-Tunnel-ID (2 bytes): The local ID of the L2TP tunnel.</t>
<t>Local-Session-ID (2 bytes): The local session ID with the L2TP
tunnel.</t>
<t>Remote-Tunnel-ID (2 bytes): The identifier of the L2TP tunnel at
the remote end-point.</t>
<t>Remote-Session-ID (2 bytes): The session ID of the L2TP tunnel at <ul empty="true"><li>
the remote end-point.</t>
</list> <dl newline="false" spacing="normal">
</t>
</section> <dt>TLV type:</dt><dd>11.</dd>
<dt>TLV length:</dt><dd>12 octets.</dd>
<dt>User-ID (4 bytes):</dt><dd>The identifier of a user/subscriber.<
/dd>
<dt>Local-Tunnel-ID (2 bytes):</dt><dd>The local ID of the L2TP tunn
el.</dd>
<dt>Local-Session-ID (2 bytes):</dt><dd>The local session ID with th
e L2TP
tunnel.</dd>
<dt>Remote-Tunnel-ID (2 bytes):</dt><dd>The identifier of the L2TP t
unnel at
the remote endpoint.</dd>
<dt>Remote-Session-ID (2 bytes):</dt><dd>The session ID of the L2TP
tunnel at
the remote endpoint.</dd>
</dl>
</li></ul>
<section title="L2TP-LNS Subscriber TLV" anchor="sect-7.9.8"><t> </section>
<section anchor="sect-7.9.8" numbered="true" toc="default">
<name>L2TP-LNS Subscriber TLV</name>
<t>
The L2TP-LNS Subscriber TLV is defined to carry the related The L2TP-LNS Subscriber TLV is defined to carry the related
information for a L2TP LNS access subscriber. It will be carried in information for a L2TP LNS access subscriber. It will be carried in
an Update_Request message when L2TP LNS access is used.</t> an Update_Request message when L2TP LNS access is used.</t>
<t>The format of the TLV value part is as follows:</t>
<t>The format of the TLV value part is as follows:</t> <figure anchor="fig53">
<name>L2TP-LNS Subscriber TLV</name>
<figure title="L2TP-LNS Subscriber TLV" anchor="fig53"><artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 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 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 Session ID | | Local-Tunnel-ID | Local-Session-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote Tunnel ID | Remote Session ID | | Remote-Tunnel-ID | Remote-Session-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> </figure>
<t>Where:
<t>Where: </t>
<list>
<t>The TLV type: 12.</t>
<t>The TLV length is 12 octets.</t>
<t>User-ID (4 bytes): The identifier of a user/subscriber.</t>
<t>Local-Tunnel-ID (2 bytes): The local ID of the L2TP tunnel.</t>
<t>Local-Session-ID (2 bytes): The local session ID with the L2TP tunnel.
</t>
<t>Remote-Tunnel-ID (2 bytes): The identifier of the L2TP tunnel at <ul empty="true"><li>
the remote end-point.</t>
<t>Remote-Session-ID (2 bytes): The session ID of the L2TP tunnel at <dl newline="false" spacing="normal">
the remote end-point.</t> <dt>TLV type:</dt><dd>12.</dd>
<dt>TLV length:</dt><dd>12 octets.</dd>
<dt>User-ID (4 bytes):</dt><dd>The identifier of a user/subscriber.<
/dd>
<dt>Local-Tunnel-ID (2 bytes):</dt><dd>The local ID of the L2TP tunn
el.</dd>
<dt>Local-Session-ID (2 bytes):</dt><dd>The local session ID with th
e L2TP tunnel.</dd>
<dt>Remote-Tunnel-ID (2 bytes):</dt><dd>The identifier of the L2TP t
unnel at
the remote endpoint.</dd>
<dt>Remote-Session-ID (2 bytes):</dt><dd>The session ID of the L2TP
tunnel at
the remote endpoint.</dd>
</list> </dl>
</t>
</section> </li></ul>
<section title="L2TP-LAC Tunnel TLV" anchor="sect-7.9.9"><t> </section>
The L2TP-LAC Tunnel TLV is defined to carry the L2TP LAC tunnel <section anchor="sect-7.9.9" numbered="true" toc="default">
related information. It will be carried in the Update_Request <name>L2TP-LAC Tunnel TLV</name>
<t>
The L2TP-LAC Tunnel TLV is defined to carry information related to the L2TP L
AC tunnel.
It will be carried in the Update_Request
message when L2TP LAC access is used.</t> message when L2TP LAC access is used.</t>
<t>The format of the TLV value part is as follows:</t>
<t>The format of the TLV value part is as follows:</t> <figure anchor="fig54">
<name>L2TP-LAC Tunnel TLV</name>
<figure title="L2TP-LAC Tunnel TLV" anchor="fig54"><artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 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 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Tunnel ID | Remote Tunnel ID | | Local-Tunnel-ID | Remote-Tunnel-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Destination Port | | Source-Port | Dest-Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Tunnel Source Address ~ ~ Source-IP ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Tunnel Destination Address ~ ~ Dest-IP ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ VRF Name sub-TLV ~ ~ VRF-Name Sub-TLV ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> </figure>
<t>Where:
<t>Where: </t>
<list>
<t>The TLV type: 13.</t>
<t>The TLV length is variable.</t>
<t>Local-Tunnel-ID (2 bytes): The local ID of the L2TP tunnel.</t>
<t>Remote-Tunnel-ID (2 bytes): The remote ID of the L2TP tunnel.</t>
<t>Source-Port (2 bytes): The source UDP port number of an L2TP subscribe
r.</t>
<t>Dest-Port (2 bytes): The destination UDP port number of an L2TP
subscriber.</t>
<t>Source-IP (IPv4/v6): The source IP address of the tunnel.</t> <ul empty="true"><li>
<t>Dest-IP (IPv4/v6): The destination IP address of the tunnel.</t> <dl newline= "false" spacing="normal">
<t>VRF-Name Sub-TLV: The VRF name to which the L2TP subscriber tunnel <dt>TLV type:</dt><dd>13.</dd>
belongs.</t> <dt>TLV length:</dt><dd>Variable.</dd>
<dt>Local-Tunnel-ID (2 bytes):</dt><dd>The local ID of the L2TP tunn
el.</dd>
<dt>Remote-Tunnel-ID (2 bytes):</dt><dd>The remote ID of the L2TP tu
nnel.</dd>
<dt>Source-Port (2 bytes):</dt><dd>The source UDP port number of an
L2TP subscriber.</dd>
<dt>Dest-Port (2 bytes):</dt><dd>The destination UDP port number of
an L2TP
subscriber.</dd>
<dt>Source-IP (IPv4/v6):</dt><dd>The source IP address of the tunnel
.</dd>
<dt>Dest-IP (IPv4/v6):</dt><dd>The destination IP address of the tun
nel.</dd>
<dt>VRF-Name Sub-TLV:</dt><dd>The VRF name to which the L2TP subscri
ber tunnel
belongs.</dd>
</list> </dl>
</t>
</section> </li></ul>
<section title="L2TP-LNS Tunnel TLV" anchor="sect-7.9.10"><t> </section>
The L2TP-LNS Tunnel TLV is defined to carry the L2TP LNS tunnel <section anchor="sect-7.9.10" numbered="true" toc="default">
related information. It will be carried in the Update_Request <name>L2TP-LNS Tunnel TLV</name>
<t>
The L2TP-LNS Tunnel TLV is defined to carry information related to the L2TP L
NS tunnel.
It will be carried in the Update_Request
message when L2TP LNS access is used.</t> message when L2TP LNS access is used.</t>
<t>The format of the TLV value part is as follows:</t>
<t>The format of the TLV value part is as follows:</t> <figure anchor="fig55">
<name>L2TP-LNS Tunnel TLV</name>
<figure title="L2TP-LNS Tunnel TLV" anchor="fig55"><artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 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 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Tunnel ID | Remote Tunnel ID | | Local-Tunnel-ID | Remote-Tunnel-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Destination Port | | Source-Port | Dest-Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Tunnel Source Address ~ ~ Source-IP ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Tunnel Destination Address ~ ~ Dest-IP ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ VRF Name sub-TLV ~ ~ VRF-Name Sub-TLV ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> </figure>
<t>Where:
<t>Where: </t>
<list>
<t>The TLV type: 14.</t>
<t>The TLV length is variable.</t>
<t>Local-Tunnel-ID (2 bytes): The local ID of the L2TP tunnel.</t>
<t>Remote-Tunnel-ID (2 bytes): The remote ID of the L2TP tunnel.</t>
<t>Source-Port (2 bytes): The source UDP port number of an L2TP subscribe
r.</t>
<t>Dest-Port (2 bytes): The destination UDP port number of an L2TP subscr
iber.</t>
<t>Source-IP (IPv4/v6): The source IP address of the tunnel.</t> <ul empty="true"><li>
<t>Dest-IP (IPv4/v6): The destination IP address of the tunnel.</t> <dl newline= "false" spacing="normal">
<t>VRF-Name Sub-TLV: The VRF name to which the L2TP subscriber tunnel <dt>TLV type:</dt><dd>14.</dd>
belongs.</t> <dt>TLV length:</dt><dd>Variable.</dd>
<dt>Local-Tunnel-ID (2 bytes):</dt><dd>The local ID of the L2TP tunn
el.</dd>
<dt>Remote-Tunnel-ID (2 bytes):</dt><dd>The remote ID of the L2TP tu
nnel.</dd>
<dt>Source-Port (2 bytes):</dt><dd>The source UDP port number of an
L2TP subscriber.</dd>
<dt>Dest-Port (2 bytes):</dt><dd>The destination UDP port number of
an L2TP subscriber.</dd>
<dt>Source-IP (IPv4/v6):</dt><dd>The source IP address of the tunnel
.</dd>
<dt>Dest-IP (IPv4/v6):</dt><dd>The destination IP address of the tun
nel.</dd>
<dt>VRF-Name Sub-TLV:</dt><dd>The VRF name to which the L2TP subscri
ber tunnel
belongs.</dd>
</list> </dl>
</t>
</section> </li></ul>
<section title="Update Response TLV" anchor="sect-7.9.11"><t> </section>
<section anchor="sect-7.9.11" numbered="true" toc="default">
<name>Update Response TLV</name>
<t>
The Update Response TLV is used to return the operation result of an 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 update request. It is carried in the Update_Response message as a
response to the Update_Request message.</t> response to the Update_Request message.</t>
<t>The format of the value part of the Update Response TLV
<t>The format of Update Response TLV is as follows:</t> is as follows:</t>
<figure anchor="fig56">
<figure title="Update Response TLV" anchor="fig56"><artwork><![CDATA[ <name>Update Response TLV</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 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 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-Trans-ID | Oper-Code | Oper-Result | Reserved | | User-Trans-ID | Oper-Code | Oper-Result | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error-Code | | Error-Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> </figure>
<t>Where:
<t>Where: </t>
<list>
<t>The TLV type: 302.</t>
<t>The TLV length is 12.</t> <ul empty="true"><li>
<t>User-ID (4 bytes): A unique identifier of a user/subscriber.</t> <dl newline= "false" spacing="normal">
<t>User-Trans-ID (1 byte): In the case of dual-stack access or when <dt>TLV type:</dt><dd>302.</dd>
<dt>TLV length:</dt><dd>12.</dd>
<dt>User-ID (4 bytes):</dt><dd>A unique identifier of a user/subscri
ber.</dd>
<dt>User-Trans-ID (1 byte):</dt><dd>In the case of dual-stack access
or when
modifying a session, User-Trans-ID is used to identify a user 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 operation transaction. It is used by the CP to correlate a response to
a specific request.</t> a specific request.</dd>
<t>Oper-Code (1 byte): Operation code. 1: update, 2: delete.</t> <dt>Oper-Code (1 byte):</dt><dd><t>Operation code.</t>
<t>Oper-Result (1 byte): Operation Result. 0: Success, Others: Failure.</ <dl newline= "false" spacing="normal">
t> <dt>1:</dt><dd>Update.</dd>
<dt>2:</dt><dd>Delete.</dd>
</dl>
<t>Error-Code (4 bytes): Operation failure cause code. for details, </dd>
see <xref target="sect-9.5"/>.</t>
<t>The Reserved field MUST be sent as zero and ignored on receipt.</t> <dt>Oper-Result (1 byte):</dt><dd><t>Operation Result.</t>
</list> <dl newline= "false" spacing="normal">
</t> <dt>0:</dt><dd>Success.</dd>
<dt>Others:</dt><dd>Failure.</dd>
</dl>
</section> </dd>
<section title="Subscriber Policy TLV" anchor="sect-7.9.12"><t> <dt>Error-Code (4 bytes):</dt><dd>Operation failure cause code. For
details,
see <xref target="sect-9.5" format="default"/>.</dd>
<dt>Reserved:</dt><dd>The Reserved field <bcp14>MUST</bcp14> be sent
as zero and ignored on receipt.</dd>
</dl>
</li></ul>
</section>
<section anchor="sect-7.9.12" numbered="true" toc="default">
<name>Subscriber Policy TLV</name>
<t>
The Subscriber Policy TLV is used to carry the policies that will be The Subscriber Policy TLV is used to carry the policies that will be
applied to a subscriber. It is carried in the Update_Request applied to a subscriber. It is carried in the Update_Request
message.</t> message.</t>
<t>The format of the TLV value part is as follows:</t>
<t>The format of the TLV value part is as follows:</t> <figure anchor="fig57">
<name>Subscriber Policy TLV</name>
<figure title="User QoS Policy Information TLV" anchor="fig57"><artwork>< <artwork name="" type="" align="left" alt=""><![CDATA[
![CDATA[
0 1 2 3 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 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 | | I-Priority | E-Priority | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ sub-TLVs ~ ~ Sub-TLVs ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> </figure>
<t>Where:
<t>Where: </t>
<list>
<t>The TLV type: 6.</t>
<t>The TLV length is variable.</t>
<t>User-ID (4 bytes): The identifier of a user/subscriber.</t>
<t>Ingress-Priority (1 byte): Indicates the upstream priority. The
value range is 0~7.</t>
<t>Egress-Priority (1 byte): Indicates the downstream priority. The
value range is 0~7.</t>
<t>sub-TLVs: 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 the name of the QoS-Profile
that is the profile in the upstream direction.</t>
<t>Egress-QoS-Profile Sub-TLV: Indicates the name of the QoS-Profile <ul empty="true"><li>
that is the profile in the downstream direction.</t>
<t>User-ACL-Policy Sub-TLV: All ACL user policies, including v4ACLIN, <dl newline= "false" spacing="normal">
v4ACLOUT, v6ACLIN, v6ACLOUT, v4WEBACL, v6WEBACL, v4SpecialACL, and
v6SpecialACL.</t>
<t>Multicast-Profile4 Sub-TLV: IPv4 multicast policy name.</t> <dt>TLV type:</dt><dd>6.</dd>
<dt>TLV length:</dt><dd>Variable.</dd>
<dt>User-ID (4 bytes):</dt><dd>The identifier of a user/subscriber.<
/dd>
<dt>Ingress-Priority (1 byte):</dt><dd>Indicates the upstream priori
ty. The
value range is 0~7.</dd>
<dt>Egress-Priority (1 byte):</dt><dd>Indicates the downstream prior
ity. The
value range is 0~7.</dd>
<dt>Sub-TLVs:</dt><dd><t>The sub-TLVs that are present can occur
in any order.</t>
<t>Multicast-Profile6 Sub-TLV: IPv6 multicast policy name.</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.</dd>
<dt>Egress-QoS-Profile sub-TLV:</dt><dd>Indicates the name of
the QoS-Profile that is the profile in the downstream
direction.</dd>
<dt>User-ACL-Policy sub-TLV:</dt><dd>All ACL user policies,
including v4ACLIN, v4ACLOUT, v6ACLIN, v6ACLOUT, v4WEBACL,
v6WEBACL, v4SpecialACL, and v6SpecialACL.</dd>
<dt>Multicast-Profile4 sub-TLV:</dt><dd>IPv4 multicast policy na
me.</dd>
<dt>Multicast-Profile6 sub-TLV:</dt><dd>IPv6 multicast policy na
me.</dd>
<dt>NAT-Instance sub-TLV:</dt><dd>Indicates the instance ID of
a NAT user. </dd>
<t>NAT-Instance Sub-TLV: Indicates the instance ID of a NAT user. </t> </dl>
</list> </dd>
</t>
<t> The Reserved field MUST be sent as zero and ignored on <dt>Reserved:</dt><dd>The Reserved field <bcp14>MUST</bcp14> be sent
receipt.</t> as
zero and ignored on receipt.</dd>
</list> </dl>
</t>
</section> </li></ul>
<section title="Subscriber CGN Port Range TLV" anchor="sect-7.9.13"><t> </section>
<section anchor="sect-7.9.13" numbered="true" toc="default">
<name>Subscriber CGN Port Range TLV</name>
<t>
The Subscriber CGN Port Range TLV is used to carry the NAT public 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 address and port range. It will be carried in the Update_Response
message when CGN is used.</t> message when CGN is used.</t>
<t>The format of the value part of this TLV is as follows:</t>
<t>The format of this TLV is as follows:</t> <figure anchor="fig58">
<name>Subscriber CGN Port Range TLV</name>
<figure title="Subscriber CGN Port Range TLV" anchor="fig58"><artwork><![ <artwork name="" type="" align="left" alt=""><![CDATA[
CDATA[
0 1 2 3 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 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-Port-Start | NAT-Port-End |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NAT-Address | | NAT-Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> </figure>
<t>Where:
<t>Where: </t>
<list>
<t>The TLV type: 15.</t>
<t>The TLV length is 12 octets.</t>
<t>User-ID (4 bytes): The identifier of a user/subscriber.</t>
<t>NAT-Port-Start (2 bytes): The start port number.</t>
<t>NAT-Port-End (2 bytes): The end port number.</t> <ul empty="true"><li>
<t>NAT-Address (4 bytes): The NAT public network address.</t> <dl newline= "false" spacing="normal">
</list> <dt>TLV type:</dt><dd>15.</dd>
</t> <dt>TLV length:</dt><dd>12 octets.</dd>
<dt>User-ID (4 bytes):</dt><dd>The identifier of a user/subscriber.<
/dd>
<dt>NAT-Port-Start (2 bytes):</dt><dd>The start port number.</dd>
<dt>NAT-Port-End (2 bytes):</dt><dd>The end port number.</dd>
<dt>NAT-Address (4 bytes):</dt><dd>The NAT public network address.</
dd>
</section> </dl>
</section> </li></ul>
<section title="Device Status TLVs" anchor="sect-7.10"><t> </section>
The TLVs in this section are for reporting Interface and Board level </section>
<section anchor="sect-7.10" numbered="true" toc="default">
<name>Device Status TLVs</name>
<t>
The TLVs in this section are for reporting interface and board-level
information from the UP to the CP.</t> information from the UP to the CP.</t>
<section anchor="sect-7.10.1" numbered="true" toc="default">
<section title="Interface Status TLV" anchor="sect-7.10.1"><t> <name>Interface Status TLV</name>
<t>
The Interface Status TLV is used to carry the status information of 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> 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>
<t>The format of the value part of this TLV is as follows:</t> <figure anchor="fig59">
<name>Interface Status TLV</name>
<figure title="Interface Status TLV" anchor="fig59"><artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 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 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 | | If-Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC Address (upper part) | | MAC-Address (upper part) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC Address (lower part) | Phy-State | Reserved | | MAC-Address (lower part) | Phy-State | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MTU | | MTU |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-TLVs (optional) | | Sub-TLVs (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> </figure>
<t>Where:
<t>Where: </t>
<list>
<t>The TLV type: 200.</t>
<t>The TLV length is variable.</t> <ul empty="true"><li>
<t>If-Index (4 bytes): Indicates the interface index.</t> <dl newline= "false" spacing="normal">
<t>MAC-Address (MAC-Addr type): Interface MAC address.</t> <dt>TLV type:</dt><dd>200.</dd>
<dt>TLV length:</dt><dd>Variable.</dd>
<dt>If-Index (4 bytes):</dt><dd>Indicates the interface index.</dd>
<dt>MAC-Address (MAC-Addr type):</dt><dd>Interface MAC address.</dd>
<t>Phy-State (1 byte): Physical status of the interface. 0: down, 1: <dt>Phy-State (1 byte):</dt><dd><t>Physical status of the
Up</t> interface.</t>
<t>MTU (4 bytes): Interface MTU value.</t> <dl newline= "false" spacing="normal">
<dt>0:</dt><dd>Down.</dd>
<dt>1:</dt><dd>Up.</dd>
</dl>
<t>sub-TLVs: The If-Desc and VRF-Name sub-TLVs can be carried.</t> </dd>
<t>The Reserved field MUST be sent as zero and ignored on receipt.</t> <dt>MTU (4 bytes):</dt><dd>Interface MTU value.</dd>
<dt>Sub-TLVs:</dt><dd>The If-Desc and VRF-Name sub-TLVs can be carri
ed.</dd>
<dt>Reserved:</dt><dd>The Reserved field <bcp14>MUST</bcp14> be
sent as zero and ignored on receipt.</dd>
</list> </dl>
</t>
</section> </li></ul>
<section title="Board Status TLV" anchor="sect-7.10.2"><t> </section>
<section anchor="sect-7.10.2" numbered="true" toc="default">
<name>Board Status TLV</name>
<t>
The Board Status TLV is used to carry the status information of a 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> 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>
<t>The format of Board Status TLV is as follows:</t> <figure anchor="fig60">
<name>Board Status TLV</name>
<figure title="Interface Resource TLV" anchor="fig60"><artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 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 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 | | Board-Type | Board-State | Reserved | Chassis |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Slot | Reserved | | Slot | Sub-Slot |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> </figure>
<t>Where:
<t>Where: </t>
<list>
<t>The TLV type: 201.</t>
<t>The TLV length is 8 octets.</t>
<t>Chassis (1 byte): The chassis number of the Board.</t>
<t>Slot (1 byte): The slot number of the Board.</t>
<t>Sub-Slot (1 byte): The sub-slot number of the Board.</t>
<t>Board-Type (1 byte):
<list> <ul empty="true"><li>
<t>1: CGN Service Process Unit (SPU) board.</t>
<t>2: Line Process Unit (LPU) Board.</t>
</list>
</t>
<t>Board-State (1 byte): <dl newline= "false" spacing="normal">
<list> <dt>TLV type:</dt><dd>201.</dd>
<t>0: Normal.</t> <dt>TLV length:</dt><dd>8 octets.</dd>
<t>1: Abnormal.</t> <dt>Chassis (1 byte):</dt><dd>The chassis number of the board.</dd>
</list> <dt>Slot (16 bits):</dt><dd>The slot number of the board.</dd>
</t> <dt>Sub-Slot (16 bits):</dt><dd>The sub-slot number of the board.</d
d>
<dt>Board-Type (1 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.</dd>
<dt>2:</dt><dd>Line Process Unit (LPU) board.</dd>
</dl>
</dd>
<t>The reserved field MUST be sent as zero and ignored on receipt.</t> <dt>Board-State (1 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>
</list> <dt>Reserved:</dt><dd>The Reserved field <bcp14>MUST</bcp14> be sent
</t> as zero and ignored on receipt.</dd>
</section> </dl>
</section> </li></ul>
<section title="CGN TLVs" anchor="sect-7.11"><section title="Address Allo </section>
cation Request TLV" anchor="sect-7.11.1"><t> </section>
<section 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</name>
<t>
The Address Allocation Request TLV is used to request address The Address Allocation Request TLV is used to request address
allocation from CP. An address Pool-Name sub-TLV is carried to allocation from the CP. A Pool-Name sub-TLV is carried to
indicate from which address pool to allocate addresses. The Address indicate from which address pool to allocate addresses. The Address
Allocation Request TLV is carried in the Addr_Allocation_Req message.</t> 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>
<t>The format of the value part of this TLV is as follows:</t> <figure anchor="fig61">
<name>Address Allocation Request TLV</name>
<figure title="Address Allocation Request TLV" anchor="fig61"><artwork><! <artwork name="" type="" align="left" alt=""><![CDATA[
[CDATA[
0 1 2 3 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 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 ~ ~ Pool-Name Sub-TLV ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> </figure>
<t>Where:
<t>Where: </t>
<list> <ul empty="true"><li>
<t>The TLV type: 400.</t>
<t>The TLV length is variable.</t> <dl newline= "false" spacing="normal">
<t>Pool-Name sub-TLV: Indicates from which Address pool to allocate <dt>TLV type:</dt><dd>400.</dd>
address.</t> <dt>TLV length:</dt><dd>Variable.</dd>
<dt>Pool-Name sub-TLV:</dt><dd>Indicates from which address pool
to allocate address.</dd>
</list> </dl>
</t>
</section> </li></ul>
<section title="Address Allocation Response TLV" anchor="sect-7.11.2"><t> </section>
<section anchor="sect-7.11.2" numbered="true" toc="default">
<name>Address Allocation Response TLV</name>
<t>
The Address Allocation Response TLV is used to return the address The Address Allocation Response TLV is used to return the address
allocation result, it is carried the Addr_Allocation_Ack message.</t> allocation result; it is carried in the Addr_Allocation_Ack message.</t>
<t>
<t>
The value part of the Address Allocation Response TLV is formatted as The value part of the Address Allocation Response TLV is formatted as
follows:</t> follows:</t>
<figure anchor="fig62">
<figure title="Address Assignment Response TLV" anchor="fig62"><artwork>< <name>Address Allocation Response TLV</name>
![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 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 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 | | Lease Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Addr and Mask | | Client-IP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Addr and Mask continued | | Client-IP (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error-Code | | Error-Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Pool-Name sub-TLV ~ ~ Pool-Name Sub-TLV ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> </figure>
<t>Where:
<t>Where: </t>
<list>
<t>The TLV type: 401.</t>
<t>The TLV length is variable.</t>
<t>Lease Time (4 bytes): Duration of address lease in seconds.</t>
<t>IPv4 Addr and Mask (IPv4-Address type): The allocated IPv4
address.</t>
<t>Error-Code (4 bytes): Indicates success or an error. <ul empty="true"><li>
<list> <dl newline= "false" spacing="normal">
<t>0: Success.</t>
<t>1: Failure.</t> <dt>TLV type:</dt><dd>401.</dd>
<dt>TLV length:</dt><dd>Variable.</dd>
<t>3001 (Pool-Mismatch): The corresponding address pool cannot be <dt>Lease Time (4 bytes):</dt><dd>Duration of address lease in secon
found.</t> ds.</dd>
<dt>Client-IP (IPv4-Address type):</dt><dd>The allocated
IPv4 address and mask.</dd>
<dt>Error-Code (4 bytes):</dt><dd><t>Indicates success or an error.<
/t>
<t>3002 (Pool-Full): The address pool is fully allocated and no <dl newline= "false" spacing="normal">
address segment is available.</t> <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.</dd>
<dt>3002:</dt><dd>Pool-Full. The address pool is fully allocated
, and no
address segment is available.</dd>
</list> </dl>
</t> </dd>
<t>Pool-Name sub-TLV: A Pool-Name sub-TLV to indicate from which <dt>Pool-Name sub-TLV:</dt><dd>Indicates from which
Address pool the address is allocated.</t> address pool the address is allocated.</dd>
</list> </dl>
</t>
</section> </li></ul>
<section title="Address Renewal Request TLV" anchor="sect-7.11.3"><t> </section>
<section anchor="sect-7.11.3" numbered="true" toc="default">
<name>Address Renewal Request TLV</name>
<t>
The Address Renewal Request TLV is used to request address renewal The Address Renewal Request TLV is used to request address renewal
from the CP. It is carried the Addr_Renew_Req message.</t> from the CP. It is carried in the Addr_Renew_Req message.</t>
<t>The format of this TLV value is as follows:</t>
<t>The format of this TLV value is as follows:</t> <figure anchor="fig63">
<name>Address Renewal Request TLV</name>
<figure title="Address Renewal Request TLV" anchor="fig63"><artwork><![CD <artwork name="" type="" align="left" alt=""><![CDATA[
ATA[
0 1 2 3 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 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 ~ ~ Pool-Name Sub-TLV ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> </figure>
<t>Where:
<t>Where: </t>
<list>
<t>The TLV type: 402.</t>
<t>The TLV length is variable.</t> <ul empty="true"><li>
<t>IPv4 Addr and Mask (IPv4-Addr): The IPv4 address to be renewed.</t> <dl newline= "false" spacing="normal">
<t>Pool Name sub-TLV: A Pool-Name sub-TLV to indicate from which <dt>TLV type:</dt><dd>402.</dd>
Address pool to renew the address.</t> <dt>TLV length:</dt><dd>Variable.</dd>
<dt>Client-IP (IPv4-Address type):</dt><dd>The IPv4 address and mask
to be
renewed.</dd>
<dt>Pool-Name sub-TLV:</dt><dd>Indicates from which
address pool to renew the address.</dd>
</list> </dl>
</t>
</section> </li></ul>
<section title="The Address Renewal Response TLV" anchor="sect-7.11.4"><t </section>
> <section anchor="sect-7.11.4" numbered="true" toc="default">
<name>Address Renewal Response TLV</name>
<t>
The Address Renewal Response TLV is used to return the address The Address Renewal Response TLV is used to return the address
renewal result. It is carried in the Addr_Renew_Ack message.</t> renewal result. It is carried in the Addr_Renew_Ack message.</t>
<t>The format of this TLV value is as follows:</t>
<t>The format of this TLV value is as follows:</t> <figure anchor="fig64">
<name>Address Renewal Response TLV</name>
<figure title="Address Renewal Response TLV" anchor="fig64"><artwork><![C <artwork name="" type="" align="left" alt=""><![CDATA[
DATA[
0 1 2 3 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 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 | | Error-Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Pool-Name sub-TLV ~ ~ Pool-Name Sub-TLV ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> </figure>
<t>Where:
<t>Where: </t>
<list>
<t>The TLV type: 403.</t>
<t>The TLV length is variable.</t>
<t>Client-IP (IPv4-Address type): The renewed IPv4 address.</t>
<t>Error Code (4 bytes): Indicates success or an error:
<list>
<t>0: Renew succeeded.</t>
<t>1: Renew failed.</t>
<t>3001 (Pool-Mismatch): The corresponding address pool cannot be <ul empty="true"><li>
found.</t>
<t>3002 (Pool-Full): The address pool is fully allocated and no <dl newline= "false" spacing="normal">
address segment is available.</t>
<t>3003 (Subnet-Mismatch): The address pool subnet cannot be found.</t <dt>TLV type:</dt><dd>403.</dd>
> <dt>TLV length:</dt><dd>Variable.</dd>
<dt>Client-IP (IPv4-Address type):</dt><dd>The renewed IPv4 address
and mask.</dd>
<dt>Error-Code (4 bytes):</dt><dd><t>Indicates success or an error:<
/t>
<t>3004 (Subnet-Conflict): Subnets in the address pool have been <dl newline= "false" spacing="normal">
assigned to other clients.</t> <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.</dd>
<dt>3002:</dt><dd>Pool-Full. The address pool is fully allocated
, and no
address segment is available.</dd>
<dt>3003:</dt><dd>Subnet-Mismatch. The address pool subnet
cannot be found.</dd>
<dt>3004:</dt><dd>Subnet-Conflict. Subnets in the address pool h
ave been
assigned to other clients.</dd>
</list> </dl>
</t> </dd>
<t>Pool Name sub-TLV: A Pool-Name Sub-TLV to indicate from which <dt>Pool-Name sub-TLV:</dt><dd>Indicates from which
Address pool to renew the address.</t> address pool to renew the address.</dd>
</list> </dl>
</t>
</section> </li></ul>
<section title="Address Release Request TLV" anchor="sect-7.11.5"><t> </section>
<section anchor="sect-7.11.5" numbered="true" toc="default">
<name>Address Release Request TLV</name>
<t>
The Address Release Request TLV is used to release an IPv4 address. The Address Release Request TLV is used to release an IPv4 address.
It is carried in the Addr_Release_Req message.</t> It is carried in the Addr_Release_Req message.</t>
<t>The value part of this TLV is formatted as follows:</t>
<t>The value part of this TLV is formatted as follows:</t> <figure anchor="fig65">
<name>Address Release Request TLV</name>
<figure title="Address Release Request TLV" anchor="fig65"><artwork><![CD <artwork name="" type="" align="left" alt=""><![CDATA[
ATA[
0 1 2 3 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 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 ~ ~ Pool-Name sub-TLV ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> </figure>
<t>Where:
<t>Where: </t>
<list>
<t>The TLV type: 404.</t>
<t>The TLV length is variable.</t> <ul empty="true"><li>
<t>IPv4 Address and Mask (IPv4-Address type): The IPv4 address be release d.</t> <dl newline= "false" spacing="normal">
<t>Pool-Name sub-TLV: A Pool-Name Sub-TLV to indicate from which <dt>TLV type:</dt><dd>404.</dd>
Address pool to release the address.</t> <dt>TLV length:</dt><dd>Variable.</dd>
<dt>Client-IP (IPv4-Address type):</dt><dd>The IPv4
address and mask to be released.</dd>
<dt>Pool-Name sub-TLV:</dt><dd>Indicates from which
address pool to release the address.</dd>
</list> </dl>
</t>
</section> </li></ul>
<section title="The Address Release Response TLV" anchor="sect-7.11.6"><t </section>
> <section anchor="sect-7.11.6" numbered="true" toc="default">
<name>Address Release Response TLV</name>
<t>
The Address Release Response TLV is used to return the address The Address Release Response TLV is used to return the address
release result. It is carried in the Addr_Release_Ack message.</t> 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>
<t>The format of this TLV is as follows:</t> <figure anchor="fig66">
<name>Address Release Response TLV</name>
<figure title="Address Renewal Response TLV" anchor="fig66"><artwork><![C <artwork name="" type="" align="left" alt=""><![CDATA[
DATA[
0 1 2 3 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 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 | | Error-Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Pool-Name sub-TLV ~ ~ Pool-Name sub-TLV ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> </figure>
<t>Where:
<t>Where: </t>
<list>
<t>The TLV type: 405.</t>
<t>The TLV length is variable.</t>
<t>Client-IP (IPv4-Address type): The released IPv4 address.</t>
<t>Error-Code (4 bytes): Indicates success or an error.
<list>
<t>0: Address release success.</t>
<t>1: Address release failed.</t> <ul empty="true"><li>
<t>3001 (Pool-Mismatch): The corresponding address pool cannot be f ound.</t> <dl newline= "false" spacing="normal">
<t>3003 (Subnet-Mismatch): The address cannot be found.</t> <dt>TLV type:</dt><dd>405.</dd>
<dt>TLV length:</dt><dd>Variable.</dd>
<dt>Client-IP (IPv4-Address type):</dt><dd>The released IPv4 address
and mask.</dd>
<dt>Error-Code (4 bytes):</dt><dd><t>Indicates success or an error.<
/t>
<t>3004 (Subnet-Conflict): The address has been allocated to <dl newline= "false" spacing="normal">
another subscriber.</t> <dt>0:</dt><dd>Success. Address release success.</dd>
<dt>1:</dt><dd>Failure. Address release failed.</dd>
<dt>3001:</dt><dd>Pool-Mismatch. The corresponding address
pool cannot be found.</dd>
</list> <dt>3003:</dt><dd>Subnet-Mismatch. The address cannot be found.<
</t> /dd>
<t>Pool-Name sub-TLV: A Pool-Name Sub-TLV to indicate from which <dt>3004:</dt><dd>Subnet-Conflict. The address has been
address pool to release the address.</t> allocated to another subscriber.</dd>
</dl>
</dd>
</list> <dt>Pool-Name sub-TLV:</dt><dd>Indicates from which
</t> address pool to release the address.</dd>
</section> </dl>
</section> </li></ul>
<section title="Event TLVs" anchor="sect-7.12"><section title="Subscriber </section>
Traffic Statistics TLV" anchor="sect-7.12.1"><t> </section>
<section 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</name>
<t>
The Subscriber Traffic Statistics TLV is used to return the traffic The Subscriber Traffic Statistics TLV is used to return the traffic
statistics of a user/subscriber. The format of this TLV is as statistics of a user/subscriber. The format of the value part of this TLV is as
follows:</t> follows:</t>
<figure anchor="fig67">
<figure title="Subscriber Traffic Statistics TLV" anchor="fig67"><artwork <name>Subscriber Traffic Statistics TLV</name>
><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 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 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Statistics Type | | Statistics-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ingress Packets (upper part) | | Ingress Packets (upper part) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ingress Packets (lower part) | | Ingress Packets (lower part) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ingress Bytes (upper part) | | Ingress Bytes (upper part) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ingress Bytes (lower part) | | Ingress Bytes (lower part) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ingress Loss Packets (upper part) | | Ingress Loss Packets (upper part) |
skipping to change at line 5415 skipping to change at line 5344
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Egress Loss Packets (upper part) | | Egress Loss Packets (upper part) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Egress Loss Packets (lower part) | | Egress Loss Packets (lower part) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Egress Loss Bytes (upper part) | | Egress Loss Bytes (upper part) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Egress Loss Bytes (lower part) | | Egress Loss Bytes (lower part) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> </figure>
<t>Where:
<t>Where: </t>
<list>
<t>The TLV type: 300.</t>
<t>The TLV length is 72 octets.</t>
<t>User-ID (4 bytes): The subscriber identifier.</t>
<t>Statistics-Type (4 bytes): 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 Packets (8 bytes): The number of the packets in upstream
direction.</t>
<t>Ingress Bytes (8 bytes): The bytes of the upstream traffic.</t>
<t>Ingress Loss Packets (8 bytes): The number of the lost packets in
upstream direction.</t>
<t>Ingress Loss Bytes (8 bytes): The bytes of the lost upstream packets.< /t> <ul empty="true"><li>
<t>Egress Packets (8 bytes): The number of the packets in downstream <dl newline= "false" spacing="normal">
direction.</t>
<t>Egress Bytes (8 bytes): The bytes of the downstream traffic.</t> <dt>TLV type:</dt><dd>300.</dd>
<dt>TLV length:</dt><dd>72 octets.</dd>
<dt>User-ID (4 bytes):</dt><dd>The subscriber identifier.</dd>
<dt>Statistics-Type (4 bytes):</dt><dd><t>Traffic type. It can be o
ne of the
following options:</t>
<t>Egress Loss Packets (8 bytes): The number of the lost packets in <dl newline= "false" spacing="normal">
downstream direction.</t> <dt>0:</dt><dd>IPv4 traffic.</dd>
<dt>1:</dt><dd>IPv6 traffic.</dd>
<dt>2:</dt><dd>Dual-stack traffic.</dd>
</dl>
</dd>
<t>Egress Loss Bytes (8 bytes): The bytes of the lost downstream <dt>Ingress Packets (8 bytes):</dt><dd>The number of the packets
packets.</t> in the upstream direction.</dd>
<dt>Ingress Bytes (8 bytes):</dt><dd>The bytes of the upstream traff
ic.</dd>
<dt>Ingress Loss Packets (8 bytes):</dt><dd>The number of the lost
packets in the upstream direction.</dd>
<dt>Ingress Loss Bytes (8 bytes):</dt><dd>The bytes of the lost
upstream packets.</dd>
<dt>Egress Packets (8 bytes):</dt><dd>The number of the packets in
the downstream direction.</dd>
<dt>Egress Bytes (8 bytes):</dt><dd>The bytes of the downstream traf
fic.</dd>
<dt>Egress Loss Packets (8 bytes):</dt><dd>The number of the lost
packets in the downstream direction.</dd>
<dt>Egress Loss Bytes (8 bytes):</dt><dd>The bytes of the lost downs
tream
packets.</dd>
</list> </dl>
</t>
</section> </li></ul>
<section title="Subscriber Detection Result TLV" anchor="sect-7.12.2"><t> </section>
<section anchor="sect-7.12.2" numbered="true" toc="default">
<name>Subscriber Detection Result TLV</name>
<t>
The Subscriber Detection Result TLV is used to return the detection The Subscriber Detection Result TLV is used to return the detection
result of a subscriber. Subscriber detection is a function to detect result of a subscriber. Subscriber detection is a function to detect
whether a subscriber is online or not. The result can be used by the whether or not a subscriber is online. The result can be used by the
CP to determine how to deal with the subscriber session. (e.g., CP to determine how to deal with the subscriber session (e.g.,
delete the session if detection failed).</t> delete the session if detection failed).</t>
<t>The format of this TLV value part is as follows:</t>
<t>The format of this TLV value part is as follows:</t> <figure anchor="fig68">
<name>Subscriber Detection Result TLV</name>
<figure title="Subscriber Detection Result TLV" anchor="fig68"><artwork>< <artwork name="" type="" align="left" alt=""><![CDATA[
![CDATA[
0 1 2 3 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 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Detect Type | Detect Result | Reserved | | Detect-Type | Detect-Result | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> </figure>
<t>Where:
<t>Where: </t>
<list>
<t>The TLV type: 301.</t>
<t>The TLV length is 8 octets.</t>
<t>User-ID (4 bytes): The subscriber identifier.</t>
<t>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 (1 byte): <ul empty="true"><li>
<list> <dl newline= "false" spacing="normal">
<t>0: Indicates that the detection is successful.</t>
<t>1: Detection failure. The UP needs report only when the <dt>TLV type:</dt><dd>301.</dd>
detection fails.</t> <dt>TLV length:</dt><dd>8 octets.</dd>
</list> <dt>User-ID (4 bytes):</dt><dd>The subscriber identifier.</dd>
</t> <dt>Detect-Type (1 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>
<t>The Reserved field MUST be sent as zero and ignored on receipt.</t> <dt>Detect-Result (1 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.</dd
>
<dt>1:</dt><dd>Detection failure. The UP needs to report only
when the detection fails.</dd>
</dl>
</dd>
</list> <dt>Reserved:</dt><dd>The Reserved field <bcp14>MUST</bcp14> be sent
</t> as zero and ignored on receipt.</dd>
</section> </dl>
</section> </li></ul>
<section title="Vendor TLV" anchor="sect-7.13"><t> </section>
The Vendor ID TLV occurs as the first TLV in the Vendor message </section>
(<xref target="sect-6.6"/>). It provides a Sub-Type that effectively extends <section anchor="sect-7.13" numbered="true" toc="default">
the <name>Vendor TLV</name>
<t>
The Vendor TLV occurs as the first TLV in the Vendor message
(<xref target="sect-6.6" format="default"/>). It provides a Sub-Type that eff
ectively extends the
message type in the message header, provides for versioning of vendor message type in the message header, provides for versioning of vendor
TLVs, and can accommodate sub-TLVs.</t> TLVs, and can accommodate sub-TLVs.</t>
<t>The value part of the Vendor TLV is formatted as follows:</t>
<t>The value part of the Vendor TLV is formatted as follows:</t> <figure anchor="fig69">
<name>Vendor TLV</name>
<figure title="Vendor TLV" anchor="fig69"><artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 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 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-Type | Sub-Type-Version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ sub-TLVs (optional) ~ ~ Sub-TLVs (optional) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> </figure>
<t>Where:
<t>Where: </t>
<list>
<t>The TLV type: 1024.</t>
<t>The TLV length is variable.</t>
<t>Vendor-ID (4 bytes): Vendor ID ass defined in RADIUS <xref
target="RFC2865"/>.</t>
<t>Sub-Type (2 bytes): Used by the Vendor to distinguish multiple <ul empty="true"><li>
different vendor messages.</t>
<t>Sub-Type-Version (2 bytes): Used by the Vendor to distinguish <dl newline="false" spacing="normal" indent="3">
different versions of a Vendor-Defined message sub-type.</t>
<t>Sub-TLVs (variable): Sub-TLVs as specified by the vendor.</t> <dt>TLV type:</dt><dd>1024.</dd>
<dt>TLV length:</dt><dd>Variable.</dd>
<dt>Vendor-ID (4 bytes):</dt><dd>Vendor ID as defined in RADIUS
<xref target="RFC2865" format="default"/>.</dd>
<dt>Sub-Type (2 bytes):</dt><dd>Used by the vendor to distinguish mult
iple
different vendor messages.</dd>
<dt>Sub-Type-Version (2 bytes):</dt><dd>Used by the vendor to distingu
ish
different versions of a vendor-defined message Sub-Type.</dd>
<dt>Sub-TLVs (variable):</dt><dd>Sub-TLVs as specified by the vendor.<
/dd>
</dl>
</list> </li></ul>
</t>
<t> <t>
Since Vendor code will be handling the TLV after the Vendor ID field Since vendor code will be handling the TLV after the Vendor-ID field
is recognized, the remainder of the TLV value can be organized is recognized, the remainder of the TLV values can be organized
however the vendor wants. But it is desirable for a vendor to be able 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 to define multiple different vendor messages and to keep track of
different versions of its vendor-defined messages. Thus, it is different versions of its vendor-defined messages. Thus, it is
RECOMMENDED that the vendor assign a Sub-Type value for each vendor <bcp14>RECOMMENDED</bcp14> that the vendor assign a Sub-Type value for each v endor
message that it defines different from other Sub-Type values that message that it defines different from other Sub-Type values that
vendor has used. Also, when modifying a vendor-defined message in a vendor has used. Also, when modifying a vendor-defined message in a
way potentially incompatible with a previous definition, the vendor way potentially incompatible with a previous definition, the vendor
SHOULD increase the value it is using in the Sub-Type-Version field.</t> <bcp14>SHOULD</bcp14> increase the value it is using in the Sub-Type-Version
field.</t>
</section> </section>
</section> </section>
<section title="Implementation Status" anchor="sect-8"><t>
RFC Editor: Please remove this section before publication.</t>
<t>
This section discusses the status of implementations that have provided
information and the testing of this protocol at the time of posting of this
Internet-Draft, and is based on the proposal in <xref target="RFC7942"/>
("Improving Awareness of Running Code: The Implementation Status
Section"). The description of implementations in this section is intended
to assist in processing drafts to RFCs.</t>
<t>
Please note that the listing of any individual implementation or test
results here does not imply endorsement by the RFC Series Editor
(RSE), the Independent Submissions Editor (ISE), or the IETF.
Furthermore, no effort has been spent to verify the information
presented here that was supplied by contributors. This is not
intended as, and must not be construed to be, a catalog of available
implementations or their testing or features. Readers are advised to
note that other implementations may exist.</t>
<t>
According to <xref target="RFC7942"/>, "this will allow reviewers ... to
assign due consideration to documents that have the benefit of running
code, which may serve as evidence of valuable experimentation and feedback
that have made the implemented protocols more mature.".</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 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-hack
athon-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 anchor="sect-9" numbered="true" toc="default">
<name>Tables of S-CUSP Codepoints</name>
<section title="Tables of S-CUSP Codepoints" anchor="sect-9"><t> <t>
This section provides tables of the S-CUSP codepoints, particularly This section provides tables of the S-CUSP codepoints, particularly
message types, TLV types, TLV operation codes, sub-TLV types, and message types, TLV types, TLV operation codes, sub-TLV types, and
error codes. In most cases, references are provided to relevant error codes. In most cases, references are provided to relevant
sections elsewhere in this document.</t> sections elsewhere in 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 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>
<section title="Message Types" anchor="sect-9.1"><figure><artwork><![CDAT <table>
A[ <name>TLV Types</name>
Type Name Section of this document <thead>
------- ---------------- ------------------------ <tr>
0 reserved <th>Type</th><th>Name</th><th>Usage Description</th>
1 Hello 6.2.1. </tr>
2 Keepalive 6.2.2. </thead>
3 Sync_Request 6.2.3. <tbody>
4 Sync_Begin 6.2.4. <tr>
5 Sync_Data 6.2.5. <td>0</td><td>Reserved</td><td>-</td>
6 Sync_End 6.2.6. </tr>
7 Update_Request 6.2.7. <tr>
8 Update_Response 6.2.8. <td>1</td><td>BAS Function</td><td>Carries the BNG access functions to be
9 Report 6.4. enabled or disabled on specified interfaces.</td>
10 Event 6.3. </tr>
11 Vendor 6.6. <tr>
12 Error 6.7. <td>2</td><td>Basic Subscriber</td><td>Carries the basic information about
13-199 unassigned a BNG subscriber.</td>
200 Addr_Allocation_Req 6.5.1. </tr>
201 Addr_Allocation_Ack 6.5.2. <tr>
202 Addr_Renew_Req 6.5.3. <td>3</td><td>PPP Subscriber</td><td>Carries the PPP information about a B
203 Addr_Renew_Ack 6.5.4. NG subscriber.</td>
204 Addr_Release_Req 6.5.5. </tr>
205 Addr_Release_Ack 6.5.6. <tr>
206-254 unassigned <td>4</td><td>IPv4 Subscriber</td><td>Carries the IPv4 address of a BNG su
255 reserved bscriber.</td>
]]></artwork> </tr>
</figure> <tr>
</section> <td>5</td><td>IPv6 Subscriber</td><td>Carries the IPv6 address of a BNG su
bscriber.</td>
<section title="TLV Types" anchor="sect-9.2"><figure><artwork><![CDATA[ </tr>
Type Name Usage Description <tr>
0 reserved - <td>6</td><td>Subscriber Policy</td><td>Carries the policy information app
1 BAS Function Carries the BNG access lied to a BNG subscriber.</td>
functions to be enabled or </tr>
disabled on specified <tr>
interfaces. <td>7</td><td>IPv4 Routing</td><td>Carries the IPv4 network routing inform
2 Basic Subscriber Carries the basic information ation.</td>
about a BNG subscriber. </tr>
3 PPP Subscriber Carries the PPP information <tr>
about a BNG subscriber. <td>8</td><td>IPv6 Routing</td><td>Carries the IPv6 network routing inform
4 IPv4 Subscriber Carries the IPv4 address of a ation.</td>
BNG subscriber. </tr>
5 IPv6 Subscriber Carries the IPv6 address of a <tr>
BNG subscriber. <td>9</td><td>IPv4 Static Subscriber Detect</td><td>Carries the IPv4 stati
6 Subscriber Policy Carries the policy information c subscriber detect information.</td>
applied to a BNG subscriber. </tr>
7 IPv4 Routing Carries the IPv4 network <tr>
routing information. <td>10</td><td>IPv6 Static Subscriber Detect</td><td>Carries the IPv6 stati
8 IPv6 Routing Carries the IPv6 network c subscriber detect information.</td>
routing information. </tr>
9 IPv4 Static Subscriber Detect Carries the IPv4 static <tr>
subscriber detect information. <td>11</td><td>L2TP-LAC Subscriber</td><td>Carries the L2TP LAC subscriber
10 IPv6 Static Subscriber Detect Carries the IPv6 static information.</td>
subscriber detect information. </tr>
11 L2TP-LAC Subscriber Carries the L2TP LAC <tr>
subscriber information. <td>12</td><td>L2TP-LNS Subscriber</td><td>Carries the L2TP LNS subscriber
12 L2TP-LNS Subscriber Carries the L2TP LNS information.</td>
subscriber information. </tr>
13 L2TP-LAC-Tunnel Carries the L2TP LAC tunnel <tr>
subscriber information. <td>13</td><td>L2TP-LAC Tunnel</td><td>Carries the L2TP LAC tunnel subscrib
14 L2TP-LNS-Tunnel Carries the L2TP LNS tunnel er information.</td>
subscriber information. </tr>
15 Subscriber CGN Port Range Carries the public IPv4 <tr>
address and related port range <td>14</td><td>L2TP-LNS Tunnel</td><td>Carries the L2TP LNS tunnel subscrib
of a BNG subscriber. er information.</td>
16-99 unassigned - </tr>
100 Hello Used for version and Keepalive <tr>
timers negotiation. <td>15</td><td>Subscriber CGN Port Range</td><td>Carries the public IPv4 ad
101 Error Information Carried in the Ack of the dress and related port range of a BNG subscriber.</td>
control message. Carries the </tr>
processing result, success, or <tr>
error. <td>16-99</td><td>Unassigned</td><td>-</td>
102 Keepalive Carried in the Hello message </tr>
for Keepalive timers <tr>
negotiation. <td>100</td><td>Hello</td><td>Used for version and Keepalive timers negotia
103-199 unassigned - tion.</td>
200 Interface Status Interfaces status reported by </tr>
the UP including physical <tr>
interfaces, sub-interfaces, <td>101</td><td>Error Information</td><td>Carried in the Ack of the control
trunk interfaces, and tunnel message. Carries the processing result, success, or error.</td>
interfaces. </tr>
201 Board Status Board information reported by <tr>
the UP including the board <td>102</td><td>Keepalive</td><td>Carried in the Hello message for Keepaliv
type and in-position status. e timers negotiation.</td>
202-299 unassigned - </tr>
300 Subscriber Traffic Statistics User traffic statistics. <tr>
301 Subscriber Detection Results User detection information. <td>103-199</td><td>Unassigned</td><td> -</td>
302 Update Response The processing result of a </tr>
subscriber session update. <tr>
303-299 unassigned - <td>200</td><td>Interface Status</td><td>Interfaces status reported by the U
400 Address Allocation Request Request address allocation. P including physical interfaces, sub-interfaces, trunk interfaces, and tunnel in
401 Address Allocation Response Address allocation response. terfaces.</td>
402 Address Renewal Request Request for address lease </tr>
renewal. <tr>
403 Address Renewal Response Response to a request for <td>201</td><td>Board Status</td><td>Board information reported by the UP in
extending an IP address lease. cluding the board type and in-position status.</td>
404 Address Release Request Request to release the </tr>
address. <tr>
405 Address Release Response Ack of a message releasing an <td>202-299</td><td>Unassigned</td><td>-</td>
IP address. </tr>
406-1023 unassigned - <tr>
1024 Vendor As implemented by vendor. <td>300</td><td>Subscriber Traffic Statistics</td><td>User traffic statistic
1039-4095 unassigned - s.</td>
]]></artwork> </tr>
</figure> <tr>
</section> <td>301</td><td>Subscriber Detection Result</td><td>User detection informati
on.</td>
<section title="TLV Operation Codes" anchor="sect-9.3"><t> </tr>
<tr>
<td>302</td><td>Update Response</td><td>The processing result of a subscribe
r session update.</td>
</tr>
<tr>
<td>303-299</td><td>Unassigned</td><td> -</td>
</tr>
<tr>
<td>400</td><td>Address Allocation Request</td><td>Request address allocatio
n.</td>
</tr>
<tr>
<td>401</td><td>Address Allocation Response</td><td>Address allocation respo
nse.</td>
</tr>
<tr>
<td>402</td><td>Address Renewal Request</td><td>Request for address lease re
newal.</td>
</tr>
<tr>
<td>403</td><td>Address Renewal Response</td><td>Response to a request for e
xtending an IP address lease.</td>
</tr>
<tr>
<td>404</td><td>Address Release Request</td><td>Request to release the addre
ss.</td>
</tr>
<tr>
<td>405</td><td>Address Release Response</td><td>Ack of a message releasing
an IP 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 the vendor.</td>
</tr>
<tr>
<td>1039-4095</td><td>Unassigned</td><td> -</td>
</tr>
</tbody>
</table>
</section>
<section anchor="sect-9.3" numbered="true" toc="default">
<name>TLV Operation Codes</name>
<t>
TLV operation codes appear in the Oper field in the header of some TLV operation codes appear in the Oper field in the header of some
TLVs. See <xref target="sect-7.1"/>.</t> TLVs. See <xref target="sect-7.1" format="default"/>.</t>
<figure><artwork><![CDATA[
Code Operation
---- ----------
0 reserved
1 Update
2 Delete
3-15 unassigned
]]></artwork>
</figure>
</section>
<section title="Sub-TLV Types" anchor="sect-9.4">
<t>See Section 7.3.</t>
<figure><artwork><![CDATA[
Type Name 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 or more of the TLVs was not
understood.
3 TLV-Length The TLV length is abnormal.
4-999 unassigned Unassigned basic error codes.
1000 reserved
1001 Version-Mismatch The version negotiation fails. Terminate.
The subsequent service processes
corresponding to the UP are suspended.
1002 Keepalive Error The keepalive negotiation fails.
1003 Timer Expires The establishment timer expired.
1004-1999 unassigned Unassigned error codes for version
negotiation.
2000 reserved
2001 Synch-NoReady The data to be smoothed is not ready.
2002 Synch-Unsupport The request for smooth data is not
supported.
2003-2999 unassigned Unassigned data synchronization error
codes.
3000 reserved
3001 Pool-Mismatch The corresponding address pool cannot be
found.
3002 Pool-Full The address pool is fully allocated and no
address segment is available.
3003 Subnet-Mismatch The address pool subnet cannot be found.
3004 Subnet-Conflict Subnets in the address pool have been
classified into other clients.
3005-3999 unassigned Unassigned error codes for address
allocation.
4000 reserved
4001 Update-Fail-No-Res The forwarding table fails to be
delivered because the forwarding resources
are insufficient.
4002 QoS-Update-Success The QoS policy takes effect.
4003 QoS-Update-Sq-Fail Failed to process the queue in the QoS
policy.
4004 QoS-Update-CAR-Fail Processing of the CAR in the QoS
policy fails.
4005 Statistic-Fail-No-Res Statistics processing failed due to
insufficient statistics resources.
4006-4999 unassigned forwarding table delivery error codes.
5000-4294967295 reserved
]]></artwork>
</figure>
</section> <table>
<name>TLV Operation 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 <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</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">
<section title="If-Type Values" anchor="sect-9.6"><t> <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 n
ot understood.</td>
</tr>
<tr>
<td>3</td><td>TLV-Length</td><td>The TLV length is abnormal.</t
d>
</tr>
<tr>
<td>4-999</td><td>Unassigned</td><td>Unassigned basic error cod
es.</td>
</tr>
<tr>
<td>1000</td><td>Reserved</td><td></td>
</tr>
<tr>
<td>1001</td><td>Version-Mismatch</td><td>The version negotiati
on fails. Terminate. The subsequent service processes corresponding to the UP a
re suspended.</td>
</tr>
<tr>
<td>1002</td><td>Keepalive Error</td><td>The keepalive negotiat
ion fails.</td>
</tr>
<tr>
<td>1003</td><td>Timer Expires</td><td>The establishment timer
expired.</td>
</tr>
<tr>
<td>1004-1999</td><td>Unassigned</td><td>Unassigned error codes
for version 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.</td>
</tr>
<tr>
<td>2002</td><td>Synch-Unsupport</td><td>The request for smooth
data is not supported.</td>
</tr>
<tr>
<td>2003-2999</td><td>Unassigned</td><td>Unassigned data synchr
onization error codes.</td>
</tr>
<tr>
<td>3000</td><td>Reserved</td><td></td>
</tr>
<tr>
<td>3001</td><td>Pool-Mismatch</td><td>The corresponding addres
s pool cannot be found.</td>
</tr>
<tr>
<td>3002</td><td>Pool-Full</td><td>The address pool is fully al
located, and no address segment is available.</td>
</tr>
<tr>
<td>3003</td><td>Subnet-Mismatch</td><td>The address pool subne
t cannot be found.</td></tr>
<tr>
<td>3004</td><td>Subnet-Conflict</td><td>Subnets in the address
pool have been classified into other clients.</td>
</tr>
<tr>
<td>3005-3999</td><td>Unassigned</td><td>Unassigned error codes
for address 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 tabl
e fails to be delivered because the forwarding resources are insufficient.</td>
</tr>
<tr>
<td>4002</td><td>QoS-Update-Success</td><td>The QoS policy take
s effect.</td>
</tr>
<tr>
<td>4003</td><td>QoS-Update-Sq-Fail</td><td>Failed to process t
he queue in the QoS policy.</td>
</tr>
<tr>
<td>4004</td><td>QoS-Update-CAR-Fail</td><td>Processing of the
CAR in the QoS policy fails.</td>
</tr>
<tr>
<td>4005</td><td>Statistic-Fail-No-Res</td><td>Statistics proce
ssing failed due to insufficient statistics resources.</td>
</tr>
<tr>
<td>4006-4999</td><td>Unassigned </td><td>Unassigned forwarding
table delivery error codes.</td>
</tr>
<tr>
<td>5000-4294967295</td><td>Reserved</td><td></td>
</tr>
</tbody>
</table>
</section>
<section 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 Defined values of the If-Type field in the If-Desc sub-TLV (see
<xref target="sect-7.3.4"/>) are as follows:</t> <xref target="sect-7.3.4" format="default"/>) are as follows:</t>
<figure><artwork><![CDATA[
Value Meaning
----- ------------
0 reserved
1 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> <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)</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 Defined values of the Access-Mode field in the BAS Function TLV (see
<xref target="sect-7.7"/>) are as follows:</t> <xref target="sect-7.7" format="default"/>) are as follows:</t>
<table>
<figure><artwork><![CDATA[ <name>Access-Mode Values</name>
Value Meaning <thead>
----- ---------- <tr>
0 Layer 2 subscriber <th>Value</th> <th>Meaning</th>
1 Layer 3 subscriber </tr>
2 Layer 2 leased line </thead>
3 Layer 3 leased line <tbody>
4-254 unassigned <tr>
255 reserved. <td>0</td><td>Layer 2 subscriber</td>
]]></artwork> </tr>
</figure> <tr>
</section> <td>1</td><td>Layer 3 subscriber</td>
</tr>
<section title="Access Method Bits" anchor="sect-9.8"><t> <tr>
<td>2</td><td>Layer 2 leased line</td>
</tr>
<tr>
<td>3</td><td>Layer 3 leased 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</name>
<t>
Defined values of the Auth-Method4 and Auth-Method6 fields in the BAS Defined values of the Auth-Method4 and Auth-Method6 fields in the BAS
Function TLV (see <xref target="sect-7.7"/>) are defined as bit fields as fol Function TLV (see <xref target="sect-7.7" format="default"/>) are defined as
lows:</t> bit fields as follows:</t>
<table>
<figure><artwork><![CDATA[ <name>Auth-Method4 Values</name>
Auth-Method4 <thead>
Bit Meaning <tr>
---- --------- <th>Bit</th>
0x01 PPPoE authentication <th>Meaning</th>
0x02 DOT1X authentication </tr>
0x04 Web authentication </thead>
0x08 Web fast authentication <tbody>
0x10 Binding authentication <tr>
0x20 reserved <td>0x01</td><td>PPPoE authentication</td>
0x40 reserved </tr>
0x80 reserved <tr>
<td>0x02</td><td>DOT1X authentication</td>
Auth-Method6 </tr>
Bit Meaning <tr>
---- --------- <td>0x04</td><td>Web authentication</td>
0x01 PPPoE authentication </tr>
0x02 DOT1X authentication <tr>
0x04 Web authentication <td>0x08</td><td>Web fast authentication</td>
0x08 Web fast authentication </tr>
0x10 Binding authentication <tr>
0x20 reserved <td>0x10</td><td>Binding authentication</td>
0x40 reserved </tr>
0x80 reserved <tr>
]]></artwork> <td>0x20</td><td>Reserved</td>
</figure> </tr>
</section> <tr>
<td>0x40</td><td>Reserved</td>
<section title="Route-Type Values" anchor="sect-9.9"><t> </tr>
Values of the Route-Type field in the IPv4 and IPv6 Routing TLVs (see <tr>
<xref target="sect-7.8.1"/> and 7.8.2) defined in this document are as follow <td>0x80</td><td>Reserved</td>
s:</t> </tr>
</tbody>
<figure><artwork><![CDATA[ </table>
Value Meaning
------- ---------
0 User host route
1 Radius authorization FrameRoute
2 Network segment route
3 Gateway route
4 Radius authorized IP route
5 L2TP LNS side user route
6-65534 unassigned
65535 reserved
]]></artwork>
</figure>
</section>
<section title="Access-Type Values" anchor="sect-9.10"><t> <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</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 Section
s
<xref target="sect-7.8.1" format="counter"/> and <xref target="sect-7.8.2" fo
rmat="counter"/>) defined in this document are as follows:</t>
<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</td>
</tr>
<tr>
<td>1</td><td>Radius authorization FrameRoute</td>
</tr>
<tr>
<td>2</td><td>Network segment route</td>
</tr>
<tr>
<td>3</td><td>Gateway route</td>
</tr>
<tr>
<td>4</td><td>Radius authorized IP route</td>
</tr>
<tr>
<td>5</td><td>L2TP LNS side user 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 Values of the Access-Type field in the Basic Subscriber TLV (see
<xref target="sect-7.9.1"/>) defined in this document are as follows:</t> <xref target="sect-7.9.1" format="default"/>) defined in this document are as
follows:</t>
<figure><artwork><![CDATA[ <table>
Access-Type <name>Access-Type Values</name>
Value Meaning <thead>
------ ---------- <tr>
0 reserved <th>Value</th><th>Meaning</th>
1 PPP access (PPP [RFC1661]) </tr>
2 PPP over Ethernet over ATM access (PPPoEoA) </thead>
3 PPP over ATM access (PPPoA [RFC3336]) <tbody>
4 PPP over Ethernet access (PPPoE [RFC2516]) <tr>
5 PPPoE over VLAN access (PPPoEoVLAN [RFC2516]) <td>0</td><td>Reserved</td>
6 PPP over LNS access (PPPoLNS) </tr>
7 IP over Ethernet DHCP access (IPoE_DHCP) <tr>
8 IP over Ethernet EAP authentication access (IPoE_EAP) <td>1</td><td>PPP access (PPP <xref target="RFC1661" format="default"/>)<
9 IP over Ethernet Layer 3 access (IPoE_L3) /td>
10 IP over Ethernet Layer 2 Static access (IPoE_L2_STATIC) </tr>
11 Layer 2 Leased Line access (L2_Leased_Line) <tr>
12 Layer 2 VPN Leased Line access (L2VPN_Leased_Line) <td>2</td><td>PPP over Ethernet over ATM access (PPPoEoA)</td>
13 Layer 3 Leased Line access (L3_Leased_Line) </tr>
14 Layer 2 Leased line Sub-User access <tr>
(L2_Leased_Line_SUB_USER) <td>3</td><td>PPP over ATM access (PPPoA <xref target="RFC3336" format="d
15 L2TP LAC tunnel access (L2TP_LAC) efault"/>)</td>
16 L2TP LNS tunnel access (L2TP_LNS) </tr>
17-254 unassigned <tr>
255 reserved <td>4</td><td>PPP over Ethernet access (PPPoE <xref target="RFC2516" form
]]></artwork> at="default"/>)</td>
</figure> </tr>
</section> <tr>
<td>5</td><td>PPPoE over VLAN access (PPPoEoVLAN <xref target="RFC2516" f
</section> ormat="default"/>)</td>
</tr>
<section title="IANA Considerations" anchor="sect-10"><t> <tr>
This document requires no IANA actions.</t> <td>6</td><td>PPP over LNS access (PPPoLNS)</td>
</tr>
</section> <tr>
<td>7</td><td>IP over Ethernet DHCP access (IPoE_DHCP)</td>
<section title="Security Considerations" anchor="sect-11"><t> </tr>
<tr>
<td>8</td><td>IP over Ethernet EAP authentication access (IPoE_EAP)</td>
</tr>
<tr>
<td>9</td><td>IP over Ethernet Layer 3 access (IPoE_L3)</td>
</tr>
<tr>
<td>10</td><td>IP over Ethernet Layer 2 Static access (IPoE_L2_STATIC)</t
d>
</tr>
<tr>
<td>11</td><td>Layer 2 Leased Line access (L2_Leased_Line)</td>
</tr>
<tr>
<td>12</td><td>Layer 2 VPN Leased Line access (L2VPN_Leased_Line)</td>
</tr>
<tr>
<td>13</td><td>Layer 3 Leased Line access (L3_Leased_Line)</td>
</tr>
<tr>
<td>14</td><td>Layer 2 Leased line Sub-User access
(L2_Leased_Line_SUB_USER)</td>
</tr>
<tr>
<td>15</td><td>L2TP LAC tunnel access (L2TP_LAC)</td>
</tr>
<tr>
<td>16</td><td>L2TP LNS tunnel access (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 anchor="sect-10" numbered="true" toc="default">
<name>IANA Considerations</name>
<t>
This document has no IANA actions.</t>
</section>
<section anchor="sect-11" numbered="true" toc="default">
<name>Security Considerations</name>
<t>
The Service, Control, and Management Interfaces between the CP and UP The Service, Control, and Management Interfaces between the CP and UP
might be across the general Internet or other hostile environment. might be across the general Internet or other hostile environment.
The ability of an adversary to block or corrupt messages or introduce The ability of an adversary to block or corrupt messages or introduce
spurious messages on any one or more of these interfaces would give spurious messages on any one or more of these interfaces would give
the adversary the ability to stop subscribers from accessing network the adversary the ability to stop subscribers from accessing network
services, disrupt existing subscriber sessions, divert traffic, mess services, disrupt existing subscriber sessions, divert traffic, mess
up accounting statistics, and generally cause havoc. Damage would not up accounting statistics, and generally cause havoc. Damage would not
necessarily be limited to one or a few subscribers but could disrupt 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 routing or deny service to one or more instances of the CP or
otherwise cause extensive interference. If the adversary knows the otherwise cause extensive interference. If the adversary knows the
details of the UP equipment and its forwarding rule capabilities, 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 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 sent to an address of the adversary's choosing, thus enabling
eavesdropping.</t> eavesdropping.</t>
<t>
<t> Thus, appropriate protections <bcp14>MUST</bcp14> be implemented to provide
Thus, appropriate protections MUST be implemented to provide
integrity, authenticity, and secrecy of traffic over those integrity, authenticity, and secrecy of traffic over those
interfaces. Whether such protection is used is a network operator interfaces. Whether such protection is used is the decision of the network op
decision. See <xref target="RFC6241"/> for Management Interface / NETCONF se erator.
curity. See <xref target="RFC6241" format="default"/> for Mi/NETCONF security.
Security on the Service Interface is dependent on the tunneling Security on the Si is dependent on the tunneling
protocol used which is out of scope for this document. Security for protocol used, which is out of scope for this document. Security for
the Control Interface, over which the S-CUSP protocol flows, is the Ci, over which S-CUSP flows, is
further discussed below.</t> further discussed below.</t>
<t>
<t>
S-CUSP messages do not provide security. Thus, if these messages are S-CUSP messages do not provide security. Thus, if these messages are
exchanged in an environment where security is a concern, that exchanged in an environment where security is a concern, that
security MUST be provided by another protocol such as TLS 1.3 security <bcp14>MUST</bcp14> be provided by another protocol such as TLS 1.3
<xref target="RFC8446"/> or IPSEC. TLS 1.3 is the mandatory to implement prot <xref target="RFC8446" format="default"/> or IPsec. TLS 1.3 is the mandatory-
ocol to-implement protocol
for interoperability. The use of a particular security protocol on for interoperability. The use of a particular security protocol on
the Control Interface is determined by configuration. Such security the Ci is determined by configuration. Such security
protocols need not always be used and lesser security precautions protocols need not always be used, and lesser security precautions
might be appropriate because, in some cases, the communication might be appropriate because, in some cases, the communication
between the CP and UP is in a benign environment.</t> between the CP and UP is in a benign environment.</t>
</section>
</middle>
<back>
</section> <displayreference target="RFC0020" to="RFC20"/>
<displayreference target="RFC0793" to="RFC793"/>
</middle> <displayreference target="IEEE-802.1Q" to="802.1Q"/>
<back>
<references title="Normative References">
&RFC0020;
&RFC0793;
&RFC2119;
&RFC2661;
&RFC2865;
&RFC6241;
&RFC8174;
</references>
<references title="Informative References">
<reference anchor="IEEE-802.1Q"><front>
<title>IEEE Standard for Local and metropolitan area networks / Bridges a
nd Bridged Networks</title>
<author>
<organization>IEEE</organization>
</author>
<date month="3" year="November 2013"/>
</front>
<seriesInfo name="IEEE" value="Std 802.1Q-2014"/> <references>
</reference> <name>References</name>
&RFC1661; <references>
&RFC2131; <name>Normative References</name>
&RFC2516; <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
&RFC2698; ence.RFC.0020.xml"/>
&RFC3022; <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
&RFC3336; ence.RFC.0793.xml"/>
&RFC5511; <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
&RFC7042; ence.RFC.2119.xml"/>
&RFC7348; <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
&RFC7942; ence.RFC.2661.xml"/>
&RFC8446; <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
<reference anchor="TR-384"><front> ence.RFC.2865.xml"/>
<title>Cloud Central Office Reference Architectural Framework</title> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
<author> ence.RFC.6241.xml"/>
<organization>Broadband Forum</organization> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
</author> ence.RFC.8174.xml"/>
</references>
<references>
<date year="2018"/> <name>Informative References</name>
</front>
<seriesInfo name="BBF" value="TR-384"/> <reference anchor="IEEE-802.1Q" >
</reference> <front>
<reference anchor="WT-459"><front> <title>IEEE Standard for Local and metropolitan area networks--Bridges and B
<title>Control and User Plane Separation for a Disaggregated BNG</title> ridged Networks</title>
<author> <author>
<organization>Broadband Forum</organization> <organization>IEEE</organization>
</author> </author>
<date month="July" year="2018" />
</front>
<seriesInfo name="IEEE" value="802.1Q-2018"/>
<seriesInfo name="DOI" value="10.1109/IEEESTD.2018.8403927"/>
</reference>
<date year="2019"/> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
</front> ence.RFC.1661.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.2131.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.2516.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.2698.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.3022.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.3336.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.5511.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.7042.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.7348.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8446.xml"/>
<seriesInfo name="BBF" value="WT-459"/> <reference anchor="TR-384">
</reference> <front>
</references> <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>
</reference>
<section title="Acknowledgements" numbered="no" anchor="acknowledgements" <reference anchor="WT-459">
><t> <front>
The helpful comments and suggestions of the following are hereby <title>Control and User Plane Separation for a Disaggregated BNG</ti
tle>
<seriesInfo name="BBF" value="WT-459"/>
<author>
<organization>Broadband Forum</organization>
</author>
<date year="2019"/>
</front>
</reference>
</references>
</references>
<section numbered="false" anchor="acknowledgements" toc="default">
<name>Acknowledgements</name>
<t>
The helpful comments and suggestions from the following individuals are hereb
y
acknowledged: acknowledged:
<list> </t>
<t>Loa Andersson</t> <ul spacing="normal">
<t>Greg Mirsky</t> <li><t><contact fullname="Loa Andersson"/></t></li>
</list> <li><t><contact fullname="Greg Mirsky"/></t></li>
</t> </ul>
</section>
</section>
<section title="Contributors" numbered="no" anchor="contributors"><figure
><artwork><![CDATA[
Zhenqiang Li
China Mobile
32 Xuanwumen West Ave, Xicheng District
Beijing, Beijing 100053
China
Email: lizhenqiang@chinamobile.com
Mach (Guoyi) Chen
Huawei Technologies
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 <section numbered="false" anchor="contributors" toc="default">
<name>Contributors</name>
Jun Song <contact fullname="Zhenqiang Li" >
Huawei Technologies <organization>China Mobile</organization>
<address>
<postal>
<street>32 Xuanwumen West 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>
Email: song.jun@huawei.com <contact fullname="Mach(Guoyi) Chen" >
<organization>Huawei Technologies</organization>
<address>
<postal>
<street>Huawei Bldg., No. 156 Beiqing Road</street>
<city>Beijing</city>
<region></region><code>100095</code>
<country>China</country>
</postal>
<email>mach.chen@huawei.com</email>
</address>
</contact>
Dan Meng <contact fullname="Zhouyi Yu" >
H3C Technologies <organization>Huawei Technologies</organization>
No.1 Lixing Center <address>
No.8 guangxun south street, Chaoyang District, <postal>
Beijing, 100102 <street></street>
China <city></city>
<region></region><code></code>
<country></country>
</postal>
<email>yuzhouyi@huawei.com</email>
</address>
</contact>
Email: mengdan@h3c.com <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>
Hanlei Liu <contact fullname="Zitao Wang" >
H3C Technologies <organization>Huawei Technologies</organization>
No.1 Lixing Center <address>
No.8 guangxun south street, Chaoyang District, <postal>
Beijing, 100102 <street></street>
China <city></city>
<region></region><code></code>
<country></country>
</postal>
<email>wangzitao@huawei.com</email>
</address>
</contact>
Email: hanlei_liu@h3c.com <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>
Victor Lopez <contact fullname="Dan Meng" >
Telefonica <organization>H3C Technologies</organization>
Spain <address>
<postal>
<extaddr>No. 1 Lixing 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>
Email: victor.lopezalvarez@telefonica.com <contact fullname="Hanlei Liu" >
]]></artwork> <organization>H3C Technologies</organization>
</figure> <address>
</section> <postal>
<extaddr>No. 1 Lixing 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>
</back> <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>
</rfc> </section>
</back>
</rfc>
 End of changes. 1007 change blocks. 
3946 lines changed or deleted 4462 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/