wdiff rfc8157.original rfc8157.txt

Independent Submission N. Leymann
Internet Draft
Request for Comments: 8157 C. Heidemann
Intended
Category: Informational Deutsche Telekom AG
ISSN: 2070-1721 M. Zhang
B. Sarikaya
Huawei
M. Cullen
Painless Security
Expires: June 24,
May 2017 December 21, 2016

Huawei's GRE Tunnel Bonding Protocol
draft-zhang-gre-tunnel-bonding-05.txt

Abstract

There is an emerging demand for solutions that provide redundancy and
load-sharing across wired and cellular links from a single service
provider, Service
Provider, so that a single subscriber is provided with bonded access
to heterogeneous connections at the same time.

In this document, GRE (Generic Routing Encapsulation) Tunnel Bonding
is specified as an enabling approach for bonded access to a wired and
a wireless network in customer premises, e.g. e.g., homes. In GRE Tunnel
Bonding, two GRE tunnels, one per network connection, are set up and
bonded together to form a single GRE tunnel for a subscriber.
Compared with each composing connection, subconnection, the bonded connections promise
increased access capacity and improved reliability. The solution
described in this document is currently implemented by Huawei and
deployed by Deutsche Telekom AG. Publication of this This document is to will enable other
developers to build interoperable implementations.

Status of this This Memo

This Internet-Draft document is not an Internet Standards Track specification; it is
published for informational purposes.

This is submitted a contribution to IETF in full conformance with the
provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents RFC Series, independently of the Internet Engineering
Task Force (IETF), any other
RFC stream. The RFC Editor has chosen to publish this document at
its areas, discretion and makes no statement about its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.

Internet-Drafts are draft documents valid value for a maximum of six months
and may be updated, replaced,
implementation or obsoleted deployment. Documents approved for publication by other documents at
the RFC Editor are not a candidate for any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

The list level of Internet
Standard; see Section 2 of RFC 7841.

Information about the current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html

The list status of Internet-Draft Shadow Directories can this document, any errata,
and how to provide feedback on it may be accessed obtained at
http://www.ietf.org/shadow.html
http://www.rfc-editor.org/info/rfc8157.

This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 ....................................................3
2. Acronyms and Terminology . . . . . . . . . . . . . . . . . . . 4 ........................................4
3. Use Case . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 ........................................................6
4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 ........................................................7
4.1. Control Plane . . . . . . . . . . . . . . . . . . . . . . . 7 ..............................................7
4.2. Data Plane . . . . . . . . . . . . . . . . . . . . . . . . 7 .................................................7
4.3. Traffic Classification and Distribution . . . . . . . . . . 7 ....................8
4.4. Traffic Recombination . . . . . . . . . . . . . . . . . . . 8 ......................................8
4.5. Bypass . . . . . . . . . . . . . . . . . . . . . . . . . . 8 .....................................................9
4.6. Measurement . . . . . . . . . . . . . . . . . . . . . . . . 9 ................................................9
4.7. Policy Control Considerations . . . . . . . . . . . . . . . 9 ..............................9
5. Control Protocol Specification (Control Plane) . . . . . . . . 9 .................10
5.1. GRE Tunnel Setup Request . . . . . . . . . . . . . . . . . 11 ..................................12
5.1.1. Client Identification Name . . . . . . . . . . . . . . 12 .........................12
5.1.2. Session ID . . . . . . . . . . . . . . . . . . . . . . 12 .........................................13
5.1.3. DSL Synchronization Rate . . . . . . . . . . . . . . . 13 ...........................14
5.2. GRE Tunnel Setup Accept . . . . . . . . . . . . . . . . . . 13 ...................................14
5.2.1. H IPv4 Address . . . . . . . . . . . . . . . . . . . . 14 .....................................15
5.2.2. H IPv6 Address . . . . . . . . . . . . . . . . . . . . 14 .....................................15
5.2.3. Session ID . . . . . . . . . . . . . . . . . . . . . . 15 .........................................16
5.2.4. RTT Difference Threshold . . . . . . . . . . . . . . . 15 ...........................16
5.2.5. Bypass Bandwidth Check Interval . . . . . . . . . . . . 16 ....................17
5.2.6. Active Hello Interval . . . . . . . . . . . . . . . . . 16 ..............................17
5.2.7. Hello Retry Times . . . . . . . . . . . . . . . . . . . 17 ..................................18
5.2.8. Idle Timeout . . . . . . . . . . . . . . . . . . . . . 17 .......................................18
5.2.9. Bonding Key Value . . . . . . . . . . . . . . . . . . . 18 ..................................19
5.2.10. Configured DSL Upstream Bandwidth . . . . . . . . . . 19 .................20
5.2.11. Configured DSL Downstream Bandwidth . . . . . . . . . 19 ...............21
5.2.12. RTT Difference Threshold Violation . . . . . . . . . . 20 ................21
5.2.13. RTT Difference Threshold Compliance . . . . . . . . . 20 ...............22
5.2.14. Idle Hello Interval . . . . . . . . . . . . . . . . . 21 ...............................23
5.2.15. No Traffic Monitored Interval . . . . . . . . . . . . 22 .....................23
5.3. GRE Tunnel Setup Deny . . . . . . . . . . . . . . . . . . . 22 .....................................24
5.3.1. Error Code . . . . . . . . . . . . . . . . . . . . . . 22 .........................................24
5.4. GRE Tunnel Hello . . . . . . . . . . . . . . . . . . . . . 23 ..........................................25
5.4.1. Timestamp . . . . . . . . . . . . . . . . . . . . . . . 23 ..........................................25
5.4.2. IPv6 Prefix Assigned by HAAP . . . . . . . . . . . . . 24 .......................26
5.5. GRE Tunnel Tear Down . . . . . . . . . . . . . . . . . . . 25 ......................................26
5.6. GRE Tunnel Notify . . . . . . . . . . . . . . . . . . . . . 25 .........................................27
5.6.1. Bypass Traffic Rate . . . . . . . . . . . . . . . . . . 25 ................................27
5.6.2. Filter List Package . . . . . . . . . . . . . . . . . . 26 ................................28
5.6.3. Switching to DSL Tunnel . . . . . . . . . . . . . . . . 29 ............................31
5.6.4. Overflowing to LTE Tunnel . . . . . . . . . . . . . . . 29 ..........................31
5.6.5. DSL Link Failure . . . . . . . . . . . . . . . . . . . 30 ...................................32
5.6.6. LTE Link Failure . . . . . . . . . . . . . . . . . . . 30 ...................................32
5.6.7. IPv6 Prefix Assigned to Host . . . . . . . . . . . . . 30 .......................33
5.6.8. Diagnostic Start: Bonding Tunnel . . . . . . . . . . . 31 ...................33
5.6.9. Diagnostic Start: DSL Tunnel . . . . . . . . . . . . . 31 .......................34
5.6.10. Diagnostic Start: LTE Tunnel . . . . . . . . . . . . . 32 ......................34
5.6.11. Diagnostic End . . . . . . . . . . . . . . . . . . . . 32 ....................................35
5.6.12. Filter List Package ACK . . . . . . . . . . . . . . . 33 ...........................35
5.6.13. Switching to Active Hello State . . . . . . . . . . . 33 ...................36
5.6.14. Switching to Idle Hello State . . . . . . . . . . . . 34 .....................37
5.6.15. Tunnel Verification . . . . . . . . . . . . . . . . . 34 ...............................37
6. Tunnel Protocol Operation (Data Plane) . . . . . . . . . . . . 35 .........................38
6.1. The GRE Header . . . . . . . . . . . . . . . . . . . . . . 36 ............................................38
6.2. Automatic Setup of GRE Tunnels . . . . . . . . . . . . . . 36 ............................39
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 38 ........................................41
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 38 ............................................41
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 38
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 39
10.1. .....................................................41
9.1. Normative References . . . . . . . . . . . . . . . . . . . 39
10.2. ......................................41
9.2. Informative References . . . . . . . . . . . . . . . . . . 40
Author's ....................................42
Contributors ......................................................43
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41 ................................................44

1. Introduction

Service providers Providers used to provide subscribers with separate access to
their fixed networks and mobile networks. It has become desirable to
bond these heterogeneous networks together to offer access service to
subscribers that offer
subscribers; this service will provide increased access capacity and
improved reliability.

This document focuses on the use case that where a DSL (Digital Subscriber
Line) connection and an LTE (Long Term Evolution) connection are
bonded together. When the traffic volume exceeds the bandwidth of
the DSL connection, the excess amount can be offloaded to the LTE
connection. A Home Gateway (HG) is a Customer Premises Equipment
(CPE) device initiating the DSL and LTE connections. A Hybrid Access
Aggregation Point (HAAP) is the network function that resides in the
provider's networks to terminate these bonded connections. Note that
if there were more than two connections that need to be bonded, the
GRE Tunnel Bonding mechanism could support that scenario as well.
However, support for more than two connections is out the scope of scope for
this document. Also, the protocol specified in this document is
limited to the single-
operator single-operator scenario only, i.e., the two peering boxes,
boxes -- the HG and HAAP, the HAAP -- are operated by a single provider.
The adaptation of the GRE Tunnel Bonding protocol Protocol to the
multi-provider scenario is left as for future work.

This document bases the solution on GRE (Generic Routing
Encapsulation [RFC2874] [RFC2890]) [RFC2784] [RFC2890]), since GRE is widely supported in
both fixed and mobile networks. Approaches specified in this
document might as well also be used by other tunneling technologies to
achieve tunnel bonding. However, such kind of variants are out the scope of scope for
this document.

For each heterogeneous connection (DSL and LTE) between the HG and
the HAAP, one GRE tunnel is set up. The HG and HAAP respectively the HAAP,
respectively, serve as the common termination point of the two
tunnels at both end. ends. Those GRE tunnels are further bonded together
to form a logical GRE tunnel for the subscriber. The HG conceals the composing
GRE tunnels from the end nodes, and end nodes simply treat the
logical GRE tunnel as a single IP link. This provides an overlay:
the users' IP packets (inner IP) are encapsulated in GRE GRE, which is in
turn carried over IP (outer IP).

The GRE Tunnel Bonding Protocol is developed by Huawei and has been
deployed in networks operated by Deutsche Telekom AG. Publication of
this This document is to make it open
makes this protocol available to the public and enable public, thereby enabling other
developers to build interoperable implementations.

2. Acronyms and Terminology

GRE: Generic Routing Encapsulation [RFC2874] [RFC2890] [RFC2784] [RFC2890].

DSL: Digital Subscriber Line is a Line. A family of technologies that are used to
transmit digital data over telephone lines lines.

LTE: Long Term Evolution. A standard for wireless communication of
high-speed data for mobile phones and data terminals. Commonly
marketed as 4G LTE.

HG: Home Gateway. A CPE device that is enhanced to support the
simultaneous use of both fixed broadband and 3GPP access
connections.

HAAP: Hybrid Access Aggregation Point. A logical function in
Operator's an
operator's network, terminating bonded connections while offering
high speed
high-speed Internet.

CIR: Committed Information Rate [RFC2698] [RFC2697].

RTT: Round Trip Time Round-Trip Time.

AAA: Authentication, Authorization Authorization, and Accounting [RFC6733] [RFC6733].

SOAP: Simple Object Access Protocol. It is a A protocol specification for
exchanging structured information in the implementation of web
services in computer networks.

FQDN: A Fully Qualified Domain Name (FQDN) is Name. Generally, a domain host name that
includes all higher level domains relevant to with at
least one domain label under the entity named.
[RFC1594] top-level domain. For example,
"dhcp.example.org" is an FQDN [RFC7031].

DSCP: The six-bit 6-bit codepoint (DSCP) of the Differentiated Services
Field field
(DS Field) field) in the IPv4 and IPv6 Headers headers [RFC2724].

BRAS: Broadband Remote Access Server. It routes Routes traffic to and from
broadband remote access devices such as Digital Subscriber Line
Access Multiplexers (DSLAM) (DSLAMs) on an Internet service provider's (ISP) Service Provider's
(ISP's) network.

PGW: Packet Data Network Gateway. In the Long Term Evolution (LTE)
architecture for the Evolved Packet Core (EPC), the PGW acts as an anchor
for user plane user-plane mobility.

PDP: Packet Data Protocol. A packet transfer protocol used in
wireless GPRS (General Packet Radio Service)/HSDPA (High Speed Service) / HSDPA (High-Speed
Downlink Packet Access) networks.

PPPoE: Point-to-Point Protocol over Ethernet is a Ethernet. A network protocol for
encapsulating PPP frames inside Ethernet frames.

DNS: Domain Name System is a System. A hierarchical distributed naming system
for computers, services, or any resource connected to the Internet
or a private network.

DHCP: Dynamic Host Configuration Protocol. A standardized network
protocol used on Internet Protocol (IP) networks for dynamically
distributing network configuration parameters, such as IP
addresses for interfaces and services.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].

3. Use Case

Bonding Connection
+-+ ****************************
| | *+-+ +-+*
| | *|E+-- LTE Connection --+ |*
subscriber |C| *+-+ |H|* Internet
| | *+-+ | |*
| | *|D+-- DSL Connection --+ |*
| | *+-+ +-+*
+-+ ****************************
\______/ \__/
HCPE
HG HAAP

C: The service endpoint of the bonding service at the HG.
E: The endpoint of the LTE connection resides in the HG.
D: The endpoint of the DSL connection resides in HG the HG.
H: The endpoint for each heterogeneous connection at the HAAP.

Figure 3.1: 1: Offloading from DSL to LTE, increased access capacity Increased Access Capacity

If a Service Provider runs heterogeneous networks, such as fixed and
mobile, subscribers might be eager to use those networks
simultaneously for increased access capacity rather than just using a
single network. As shown by the reference model in Figure 3.1, 1, the
subscriber expects a significantly higher access bandwidth from the
bonding connection than from the DSL connection. In other words,
when the traffic volume exceeds the bandwidth of the DSL connection,
the excess amount may be offloaded to the LTE connection.

Compared to per-flow load balancing mechanisms load-balancing mechanisms, which are widely used
nowadays, the use case described in this document requires a per-
packet
per-packet offloading approach. For per-flow load-balancing, load balancing, the
maximum bandwidth that may be used by a traffic flow is the bandwidth
of an individual connection. While connection, while for per-packet offloading, a
single flow may use the added-up combined bandwidth of the two connections.

4. Overview

In this document, the widely supported GRE is chosen as the tunneling
technique. With the newly defined control protocol, GRE tunnels are
setup
set up on top of the DSL and LTE connections connections, which are ended at
D and H or at E and H, as shown in Figure 3.1. 1. These tunnels are
bonded together to form a single logical bonding connection between
the HG and the HAAP. Subscribers use this logical connection without
knowing the
composing GRE tunnels.

4.1. Control Plane

A clean-slate control protocol is designed to manage the GRE tunnels
that are setup set up per heterogeneous connection between the HG and the
HAAP. The goal is to design a compact control plane for bonding
access instead of reusing existing control planes.

In order to measure the performance of connections, control packets
need to co-route the same path with data packets. Therefore, a
GRE Channel is opened for the purpose of data plane data-plane forwarding of control
plane
control-plane packets. As shown in Figure 5.1, 2 (see Section 5), the GRE
header ([RFC2784]) [RFC2784] with the Key extension specified by [RFC2890] is
being used. The GRE Protocol Type (0xB7EA) is used to identify this
GRE Channel. A family of control messages are is encapsulated with a GRE
header and carried over this channel. Attributes, formatted in
Type-Length-Value (TLV) style, are further defined and included in
each control message.

With the newly defined control plane, the GRE tunnels between the HG
and the HAAP can be established, managed managed, and released without the
involvement of operators.

4.2. Data Plane

Using the control plane defined in Section 4.1, GRE tunnels can be
automatically setup set up per heterogeneous connection between the HG and
the HAAP. For the use case described in Section 3, one GRE tunnel is
ended at the DSL WAN interfaces, e.g., the DSL GRE tunnel, and
another GRE tunnel is ended at the LTE WAN interfaces, e.g., the LTE
GRE tunnel. Each tunnel may carry a user's IP packets as payload,
which forms a typical IP-over-IP overlay. These tunnels are bonded
together to offer a single access point to subscribers.

As shown in Figure 6.1, 3 (see Section 6.1), the GRE header ([RFC2784]) [RFC2784] with
the Key and Sequence Number extensions specified by [RFC2890] is used
to encapsulate data packets. The Protocol Type is either 0x0800
[RFC2784]
(listed as "0x800" in [RFC2784]) or 0x86DD [RFC7676], which indicates
that the inner packet is either an IPv4 packet or an IPv6 packet. packet,
respectively. The GRE Key field is set to a unique value for the
entire bonding connection. The GRE Sequence Number field is used to
maintain the sequence of packets transported in all GRE tunnels as a
single flow between the HG and the HAAP.

4.3. Traffic Classification and Distribution

For the offloading use case, the coloring mechanism specified in
[RFC2697] is being used to classify subscriber's subscribers' IP packets, both
upstream and downstream, into the DSL GRE tunnel or the LTE GRE
tunnel. Packets colored as green or yellow will be distributed into
the DSL GRE tunnel tunnel, and packets colored as red will be distributed
into the LTE GRE tunnel. For the scenario that requires more than
two GRE tunnels, multiple levels of token buckets might be realized.
However, that scenario is out of the scope for this document.

The Committed Information Rate (CIR) of the coloring mechanism is set
to the total DSL WAN bandwidth minus the bypass DSL bandwidth (See (see
Section 4.4.). 4.5). The total DSL WAN bandwidth MAY be configured, MAY be
obtained from the management system (AAA server, SOAP server, etc.),
or MAY be detected in real-time real time using ANCP the Access Node Control
Protocol (ANCP) [RFC6320].

4.4. Traffic Recombination

For the offloading use case, the recombination function at the
receiver provides in-order delivery of subscribers' traffic. The
receiver maintains a small reordering buffer and orders the data
packets in this buffer by via the Sequence Number field [RFC2890] of the
GRE header. All packets carried on GRE tunnels which that belong to the
same bonding connection go into a single reordering buffer.

Operators may configure the maximum allowed size (See (see
MAX_PERFLOW_BUFFER in [RFC2890]) of the buffer for reordering. They
may also configure the maximum time (See (see OUTOFORDER_TIMER in
[RFC2890]) that a packet can stay in the buffer for reordering. The
OUTOFORDER_TIMER must be configured carefully. Values larger than
the difference of the normal Round-Trip Time (RTT) (e.g., 100 ms) of
the two connections are not recommended. Implementation and
deployment experiences exhibits have demonstrated that there is usually a
large margin for the value of MAX_PERFLOW_BUFFER. Values larger than
the multiply multiplication of the sum of the line rate of the two connections
and the value of OUTOFORDER_TIMER should be used.

4.5. Bypass

Service Providers provide some services that should not be delivered
over the bonding connection. For example, Service Providers may not
expect real-time IPTV to be carried by the LTE GRE tunnel. It is
required that IPTV traffic bypasses bypass the GRE Tunnel Bonding and uses use the
raw DSL bandwidth. Bypass traffic is not subject to the traffic
classification and distribution specified above. The raw connection
used for bypass traffic is not controlled by the HAAP. It may or may
not go through a device that in which the HAAP resides in. resides.

The HAAP may announce the service types that need to bypass the
bonded GRE tunnels by using the Filter List Package attribute as
specified in Section 5.6.2. The HG and the HAAP need to set aside
the DSL bandwidth for bypassing. The available DSL bandwidth for GRE
Tunnel Bonding is equal to the total DSL bandwidth minus the bypass
bandwidth.

4.6. Measurement

Since control packets are routed using the same paths as the data
packets, the real performance of the data paths (e.g., the GRE
tunnels) can be measured. The GRE Tunnel Hello messages specified in
Section 5.3 5.4 are used to carry the timestamp information information, and the Round
Trip Time (RTT) RTT
value can therefore be calculated based on the timestamp.

Besides the end-to-end delay of the GRE tunnels, the HG and the HAAP
need to measure the capacity of the tunnels as well. For example,
the HG is REQUIRED to measure the downstream bypassing bandwidth and
report it to the HAAP in real time (See (see Section 5.6.1.). 5.6.1).

4.7. Policy Control Considerations

Operators and users may input policies into the GRE Tunnel Bonding.
These policies will be interpreted "interpreted" into parameters or actions that
impact the traffic classification, distribution, combination,
measurement
measurement, and bypass.

Operators and users may offer the service types that need to bypass
the bonded GRE tunnels. Service types defined by operators (see
Section 5.6.2) will be delivered from the HAAP to the HG through the
control plane (See (see Section 5.6.12.), 4.1), and the HG will use the raw
connection to transmit traffic for these service types. Users may as well
also define bypass service types on the HG. Bypass service types
defined by users need not to be delivered to the HAAP.

Operators may specify the interval for sending Hello messages and the
retry times for the HG or the HAAP to send out Hello messages before
the failure of a connection.

Since the GRE tunnels are setup set up on top of heterogeneous DSL and LTE
connections, if the difference of the transmission delays of these
connections exceeds a given threshold for a certain period, the HG
and the HAAP should be able to stop the offloading behavior and
fallback
fall back to a traditional transmission mode, where the LTE GRE
tunnel is disused while all traffic is transmitted over the DSL GRE
tunnel. Operators are allowed to define this threshold and period.

5. Control Protocol Specification (Control Plane)

Control messages are used to establish, maintain, measure measure, and
tear down GRE tunnels between the HG and the HAAP. Also, the control
plane undertakes the responsibility to convey traffic policies over
the GRE tunnels.

For the purpose of measurement, control messages need to be delivered
as GRE encapsulated packets and co-routed with data plane data-plane packets.
The new GRE Protocol Type (0xB7EA) is allocated for this purpose purpose, and
the standard GRE header as per [RFC2874] [RFC2784] with the Key extension
specified by [RFC2890] is used. The Checksum Present bit is set
to
zero. 0. The Key Present bit is set to 1. The Sequence Number Present
bit is set to 0. So So, the format of the GRE header for control
messages of the GRE Tunnel Bonding protocol Protocol is as follows:

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| |1|0| Reserved0 | Ver | Protocol Type 0xB7EA |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Key
The
For security purposes, the Key field is used to carry a random number for the purpose of
security.
number. The random number is generated by the HAAP HAAP, and informed
to the HG. (See HG is
informed of it (see Section 5.2.9.) 5.2.9).

The general format of the entire control message is as follows:

Figure 5.1: The format 2: Format of control messages Control Messages of GRE Tunnel Bonding

MsgType (4 bits)
Message Type. The control message family contains the following 6
six types of control messages: messages (not including "Reserved"):

Control Message Family Type
========================== =========
GRE Tunnel Setup Request 1
GRE Tunnel Setup Accept 2
GRE Tunnel Setup Deny 3
GRE Tunnel Hello 4
GRE Tunnel Tear Down 5
GRE Tunnel Notify 6
Reserved 0,7-15 0, 7-15

T-Type (4 bits)
Tunnel Type. Set to 0001 if the control message is sent via the
primary GRE tunnel (normally the DSL GRE tunnel). Set to 0010 if
the control message is sent via the secondary GRE tunnel (normally
the LTE GRE tunnel). Values 0000 and values from 0011 through
1111 are reserved for future use and MUST be ignored on receipt.

Attributes
The Attributes field includes the attributes that need to be
carried in the control message. Each Attribute has the following
format.
format:

Attribute Type (1 octet)
The Attribute Type specifies the type of the attribute.

Attribute Length (2 octets)
Attribute Length indicates the length of the Attribute Value
in
octets. bytes.

Attribute Value (variable)
The Attribute Value includes the value of the attribute.

All control messages are sent in network byte order (high order
octets (high-order bytes
first). The Protocol Type carried in the GRE header for the control
message is 0xB7EA. Based on this number, the receiver will
determine decide to
consume the GRE packet locally rather than further
forwarding. forward it further.

5.1. GRE Tunnel Setup Request

The HG uses the GRE Tunnel Setup Request message to request that the
HAAP establish the GRE tunnels. It is sent out from the HG's LTE and
DSL WAN interfaces separately. Attributes that need to be included
in this message are defined in the following subsections.

5.1.1. Client Identification Name

Operator

An operator uses the Client Identification Name (CIN) to identify the
HG. The HG sends the CIN to the HAAP for authentication and
authorization as specified in [TS23.401]. It is REQUIRED that the
GRE Tunnel Setup Request message sent out from the LTE WAN interface
contains
contain the CIN attribute while the GRE Tunnel Setup Request message
sent out from the DSL WAN interface does not contain this attribute.

The CIN attribute has the following format:

Attribute Type
CIN, set to 3.

Attribute Length
Set to 40.

Client Identification Name
This is a 40-byte string value encoded in UTF-8 and set by the
operator. It is used as the identification of the HG in the
operator's network.

5.1.2. Session ID

This Session ID is generated by the HAAP when the LTE GRE Tunnel
Setup Request message is received. The HAAP announces the Session ID
to the HG in the LTE GRE Tunnel Setup Accept message. For those WAN
interfaces that need to be bonded together, the HG MUST use the same
Session ID. The HG MUST carry the Session ID attribute in each DSL
GRE Tunnel Setup Request message. For the first time that the LTE
GRE Tunnel Setup Request message is sent to the HAAP, the Session ID
attribute need not be included. However, if the LTE GRE Tunnel tunnel fails
and the HG tries to revive it, the LTE GRE Tunnel Setup Request
message MUST include the Session ID attribute.

The Session ID attribute has the following format:

Attribute Length
Set to 4.

Session ID
An unsigned integer generated by the HAAP. It is used as the
identification of bonded GRE Tunnels. tunnels.

5.1.3. DSL Synchronization Rate

The HG uses the DSL Synchronization Rate to notify the HAAP about the
downstream bandwidth of the DSL link. The DSL GRE Tunnel Setup
Request message MUST include the DSL Synchronization Rate attribute.
The LTE GRE Tunnel Setup Request message SHOULD NOT include this
attribute.

Attribute Type
DSL Synchronization Rate, set to 7.

Attribute Length
Set to 4.

DSL Synchronization Rate
An unsigned integer measured in kbps.

5.2. GRE Tunnel Setup Accept

The HAAP uses the GRE Tunnel Setup Accept message as the response to
the GRE Tunnel Setup Request message. This message indicates
acceptance of the tunnel establishment and carries parameters of the
GRE tunnels. Attributes that need be to be included in this message are
defined below.

5.2.1. H IPv4 Address

The HAAP uses the H IPv4 Address attribute to inform the HG of the
H IPv4 address. The HG uses the H IPv4 address as the destination
endpoint IPv4 address of the GRE tunnels (the source endpoint IPv4
addresses of the GRE tunnels are respectively DSL/LTE the DSL WAN interface IP address (D)
and the LTE WAN interface IP address (D/E)). (E), respectively, as shown in
Figure 1). The LTE GRE Tunnel Setup Accept message MUST include the
H IPv4 Address attribute.

Attribute Type
H IPv4 Address, set to 1.

Attribute Length
Set to 4.

H IPv4 Address
Set to the pre-configured IPv4 address (e.g. (e.g., an IP address of a
Line Card in the HAAP) HAAP), which is used as the endpoint IP address
of GRE tunnels by the HAAP.

5.2.2. H IPv6 Address

The HAAP uses the H IPv6 Address attribute to inform the HG of the
H IPv6 address. The HG uses the H IPv6 address as the destination
endpoint IPv6 address of the GRE tunnels (the source endpoint IPv4 IPv6
addresses of the GRE tunnels are respectively DSL/LTE the DSL WAN interface IP address (D)
and the LTE WAN interface IP address
(D/E)). (E), respectively, as shown in
Figure 1).

The LTE GRE Tunnel Setup Accept message MUST include the H IPv6
Address attribute.

Attribute Length
Set to 16.

H IPv6 Address
Set to the pre-configured IPv6 address (e.g. (e.g., an IP address of a
Line Card in the HAAP) HAAP), which is used as the endpoint IP address
of GRE tunnels by the HAAP.

5.2.3. Session ID

The LTE GRE Tunnel Setup Accept message MUST include the Session ID
attribute as defined in Section 5.1.2.

5.2.4. RTT Difference Threshold

The HAAP uses the RTT Difference Threshold attribute to inform the HG
of the acceptable threshold of the RTT difference between the DSL
link and the LTE link. If the measured RTT difference exceeds this
threshold, the HG SHOULD stop offloading traffic to the LTE GRE
tunnel. The LTE GRE Tunnel Setup Accept message MUST include the RTT
Difference Threshold attribute.

Attribute Type
RTT Difference Threshold, set to 9.

Attribute Length
Set to 4.

RTT Difference Threshold
An unsigned integer measured in milliseconds. This value can be
chosen in the range 0 through 1000.

5.2.5. Bypass Bandwidth Check Interval

The HAAP uses the Bypass Bandwidth Check Interval attribute to inform
the HG of how frequently the bypass bandwidth should be checked. The
HG should check the bypass bandwidth of the DSL WAN interface in each
time period indicated by this interval. The LTE GRE Tunnel Setup
Accept message MUST include the Bypass Bandwidth Check Interval
attribute.

Attribute Type
Bypass Bandwidth Check Interval, set to 10.

Attribute Length
Set to 4.

Bypass Bandwidth Check Interval
An unsigned integer measured in seconds. This value can be chosen
in the range 10 through 300.

5.2.6. Active Hello Interval

The HAAP uses the Active Hello Interval attribute to inform the HG of
the pre-configured interval for sending out GRE Tunnel Hellos. The
HG should send out GRE Tunnel Hellos via both the DSL and LTE WAN
interfaces in each time period as indicated by this interval. The
LTE GRE Tunnel Setup Accept message MUST include the Active Hello
Interval attribute.

Attribute Length
Set to 4.

Active Hello Interval
An unsigned integer measured in seconds. This value can be chosen
in the range 1 through 100.

5.2.7. Hello Retry Times

The HAAP uses the Hello Retry Times attribute to inform the HG of the
retry times for sending GRE Tunnel Hellos. If the HG does not
receive any acknowledgement from the HAAP for the number of GRE
Tunnel Hello attempts specified in this attribute, the HG will
declare a failure of the GRE Tunnel. tunnel. The LTE GRE Tunnel Setup Accept
message MUST include the Hello Retry Times attribute.

Attribute Type
Hello Retry Times, set to 15.

Attribute Length
Set to 4.

Hello Retry Times
An unsigned integer, which integer that takes values in the range 3 through 10.

5.2.8. Idle Timeout

The HAAP uses the Idle Timeout attribute to inform the HG of the pre-
configured
pre-configured timeout value to terminate the DSL GRE tunnel. When
an LTE GRE Tunnel tunnel failure is detected, all traffic will be sent over
the DSL GRE tunnel. If the failure of the LTE GRE tunnel lasts
longer than the Idle Timeout, subsequent traffic will be sent over
raw DSL rather than over a tunnel, and the DSL GRE tunnel SHOULD be
terminated. The LTE GRE Tunnel Setup Accept message MUST include the
Idle Timeout attribute.

Attribute Type
Idle Timeout, set to 16.

Attribute Length
Set to 4.

Idle Timeout
An unsigned integer measured in seconds. It takes values in the
range 0 through 172,800 with the a granularity of 60. The default
value is 1,440 86,400 (24 hours). The value 0 indicates that the idle
timer never expires.

5.2.9. Bonding Key Value

The HAAP uses the Bonding Key Value attribute to inform the HG of the
number which that is to be carried as the Key of the GRE header for
subsequent control messages. The Bonding Key Value is generated by
the HAAP and used for the purpose of security. security purposes.

The method used to generate this number is left up to
implementations. The
Pseudo Random Number Generator pseudorandom number generator defined in
ANSI X9.31 X9.31, Appendix A.2.4 [ANSI-X9.31-1998] is RECOMMENDED. Note
that Random Number Generation collision is random number generation "collisions" are allowed in the GRE
Tunnel Bonding protocol. Protocol.

Attribute Length
Set to 4.

Bonding Key Value
A 32-bit random number generated by the HAAP.

5.2.10. Configured DSL Upstream Bandwidth

The HAAP obtains the upstream bandwidth of the DSL link from the
management system and uses the Configured DSL Upstream Bandwidth
attribute to inform the HG. The HG uses the received upstream
bandwidth as the Committed Information Rate CIR [RFC2697] for the DSL link
[RFC2697]. link. The DSL GRE Tunnel
Setup Accept message MUST include the Configured DSL Upstream
Bandwidth attribute.

Attribute Type
Configured DSL Upstream Bandwidth, set to 22.

Attribute Length
Set to 4.

Configured DSL Upstream Bandwidth
An unsigned integer measured in kbps.

5.2.11. Configured DSL Downstream Bandwidth

The HAAP obtains the downstream bandwidth of the DSL link from the
management system and uses the Configured DSL Downstream Bandwidth
attribute to inform the HG. The HG uses the received downstream
bandwidth as the base in calculating the bypassing bandwidth. The
DSL GRE Tunnel Setup Accept message MUST include the Configured DSL
Downstream Bandwidth attribute.

Attribute Type
Configured DSL Downstream Bandwidth, set to 23.

Attribute Length
Set to 4.

Configured DSL Downstream Bandwidth
An unsigned integer measured in kbps.

5.2.12. RTT Difference Threshold Violation

The HAAP uses the RTT Difference Threshold Violation attribute to
inform the HG of the number of times in a row that the RTT Difference
Threshold (See (see Section 5.2.4.) 5.2.4) may be violated before the HG MUST stop
using the LTE GRE Tunnel. tunnel. If the RTT Difference Threshold is
continuously violated for more than the indicated number of
measurements, the HG MUST stop using the LTE GRE tunnel. The LTE GRE
Tunnel Setup Accept message MUST include the RTT Difference Threshold
Violation attribute.

+-+-+-+-+-+-+-+-+
|Attribute Type | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Length | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+
| RTT Diff Threshold Violation (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+
Attribute Type
RTT Difference Threshold Violation, set to 24.

Attribute Length
Set to 4.

RTT Difference Threshold Violation
An unsigned integer which that takes values in the range 1 through 25.
A typical value is 3.

5.2.13. RTT Difference Threshold Compliance

The HAAP uses the RTT Difference Threshold Compliance attribute to
inform the HG of the number of times in a row that the RTT Difference
Threshold (See (see Section 5.2.4.) 5.2.4) must be compliant before use of the LTE
GRE tunnel can be resumed. If the RTT Difference Threshold is
continuously detected to be compliant across more than this number of
measurments,
measurements, the HG MAY resume using the LTE GRE tunnel. The LTE
GRE Tunnel Setup Accept message MUST include the RTT Difference
Threshold Compliance attribute.

Attribute Type
RTT Diff Difference Threshold Compliance, set to 25.

Attribute Length
Set to 4.

RTT Diff Difference Threshold Compliance
An unsigned integer which that takes values in the range 1 through 25.
A typical value is 3.

5.2.14. Idle Hello Interval

The HAAP uses the Idle Hello Interval attribute to inform the HG of
the pre-configured interval for sending out GRE Tunnel Hellos when
the subscriber is detected to be idle. The HG SHOULD begin to send
out GRE Tunnel Hellos via both the DSL and LTE WAN interfaces in each
time period as indicated by this interval, if the bonded tunnels have
seen no traffic for a period longer than the "No Traffic Monitored
Interval" (See (see Section 5.2.15.). 5.2.15). The LTE GRE Tunnel Setup Accept
message MUST include the Idle Hello Interval attribute.

Attribute Type
Idle Hello Interval, set to 31.

Attribute Length
Set to 4.

Idle Hello Interval
An unsigned integer measured in seconds. This value can be chosen
from
in the range 100 through 86,400 (24 hours) with the a granularity of
100. The default value is 1800 (30 minutes).

5.2.15. No Traffic Monitored Interval

The HAAP uses the No Traffic Monitored Interval attribute to inform
the HG of the pre-configured interval for switching the GRE Tunnel
Hello mode. If traffic is detected on the bonded GRE tunnels before
this informed interval expires, the HG SHOULD switch to the Active Hello
Interval. The LTE GRE Tunnel Setup Accept message MUST include the
No Traffic Monitored Interval attribute.

+-+-+-+-+-+-+-+-+
|Attribute Type | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Length | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+
| No Traffic Monitored Interval (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+
Attribute Type
No Traffic Monitored Interval, set to 32.

Attribute Length
Set to 4.

No Traffic Monitored Interval
An unsigned integer measured in seconds. This value is in the
range 30 through 86,400 (24 hours). The default value is 60.

5.3. GRE Tunnel Setup Deny

The HAAP MUST sends send the GRE Tunnel Setup Deny message to the HG if the
GRE
tunnel setup request Tunnel Setup Request from this HG is denied. The HG MUST
terminate the GRE tunnel setup process as soon as it receives the GRE
Tunnel Setup Deny message.

5.3.1. Error Code

The HAAP uses the Error Code attribute to inform the HG of the error
code. The error code depicts the reason why the GRE tunnel setup
request Tunnel Setup Request is
denied. Both the LTE GRE Tunnel Setup Deny message and the DSL GRE
Tunnel Setup Deny message MUST include the Error Code attribute.

Attribute Type
Error Code, set to 17.

Attribute Length
Set to 4.

Error Code
An unsigned integer. The list of the codes are listed is as follows. follows:

1: The HAAP was not reachable over LTE during the GRE tunnel setup
request. Tunnel
Setup Request.

2: The HAAP was not reachable via DSL during the GRE tunnel setup
request. Tunnel Setup
Request.

3: The LTE GRE tunnel to the HAAP failed.

4: The DSL GRE tunnel to the HAAP failed.

5: The given DSL User ID is not allowed to use the GRE Tunnel
Bonding service.

6: The given User Alias (TOID)/User / User ID (GUID) (Globally Unique Identifier
(GUID)) is not allowed to use the GRE Tunnel Bonding service.

7: The LTE and DSL User IDs do not match.

8: The HAAP denied the GRE tunnel setup request Tunnel Setup Request because a bonding
session with the same User ID already exists.

9: The HAAP denied the GRE tunnel setup request Tunnel Setup Request because the
user's CIN is not permitted.

10: The HAAP terminated a GRE Tunnel Bonding session for
maintenance reasons.

11: There was a communication error between the HAAP and the
management system during the LTE tunnel setup request. GRE Tunnel Setup Request.

12: There was a communication error between the HAAP and the
management system during the DSL tunnel setup request. GRE Tunnel Setup Request.

5.4. GRE Tunnel Hello

After the DSL/LTE GRE tunnel is established, the HG begins to
periodically send out GRE Tunnel Hello messages via the tunnel, which tunnel; the
HAAP acknowledges the HG's messages by returning GRE Tunnel Hello
messages back to the HG. This continues until the tunnel is terminated.

5.4.1. Timestamp

The HAAP uses the Timestamp attribute to inform the HG of the
timestamp value that is used for RTT calculation. Both the LTE GRE
Tunnel Hello message and the DSL GRE Tunnel Hello message MUST
include the Timestamp attribute.

Attribute Length
Set to 8.

Timestamp
The time since the system restarts. restarted. The high-order 4 octets bytes
indicate an unsigned integer in units of one 1 second; the low-order
4 octets bytes indicate an unsigned integer in unit units of one 1 millisecond.

5.4.2. IPv6 Prefix Assigned by HAAP

The HAAP uses the IPv6 Prefix Assigned by the HAAP attribute to inform
the HG of the assigned IPv6 prefix. This IPv6 prefix is to be
captured by the Lawful Interception. via lawful intercept. Both the LTE GRE Tunnel Hello message
and the DSL GRE Tunnel Hello message MUST include the IPv6 Prefix
Assigned by HAAP attribute.

Attribute Type
IPv6 Prefix Assigned by HAAP, set to 13.

Attribute Length
Set to 17.

IPv6 Prefix Assigned by HAAP
The highest-order 16 octets bytes encode an IPv6 address. The lowest-
order one octet
lowest-order 1 byte encodes the prefix length. These two values
are put together to represent an IPv6 prefix.

5.5. GRE Tunnel Tear Down

The HAAP can terminate a DSL/LTE GRE tunnel by sending the GRE Tunnel
Tear Down message to the HG via the tunnel. The Error Code attribute
as defined in Section 5.3.1 MUST be included in this message. After
receiving the GRE Tunnel Tear Down message, the HG removes the IP
address of H H, which is the destination IP addresses of the DSL and
LTE GRE tunnels.

5.6. GRE Tunnel Notify

The HG and the HAAP use the GRE Tunnel Notify message message, which is
transmitted either through either the DSL GRE tunnel or the LTE GRE tunnel tunnel,
to notify each other about their status regarding the DSL/LTE GRE
tunnels, the information for the bonded tunnels, the actions that
need to be taken, etc.

Usually, the receiver just sends the received attributes back as the
acknowledgement for each GRE Tunnel Notify message. There However, there
is an exception for the Filter List Package. Since Package: since the size of the
Filter List Package attribute can be very large, a special attribute
-- the Filter List Package ACK attribute -- is
specified in Section 5.6.12 used as the acknowledgement.
acknowledgement (see Section 5.6.12).

Attributes that need be to be included in the GRE Tunnel Notify message
are defined below.

5.6.1. Bypass Traffic Rate

There are a few types of traffic that need to be transmitted over the
raw DSL WAN interface rather than the bonded GRE tunnels. The HG has
to set aside bypass bandwidth on the DSL WAN interface for these
traffic types. Therefore, the available bandwidth of the DSL GRE
tunnel is the entire DSL WAN interface bandwidth minus the occupied
bypass bandwidth.

The HG uses the Bypass Traffic Rate attribute to inform the HAAP of
the downstream bypass bandwidth for the DSL WAN interface. The
Bypass Traffic Rate attribute will be included in the DSL GRE Tunnel
Notify message. The HAAP calculates the available downstream
bandwidth for the DSL GRE tunnel as the Configured DSL Downstream
Bandwidth minus
this informed the bypass bandwidth. bandwidth provided by the HG. The
available DSL bandwidth will be used as the Committed Information Rate (CIR) CIR of the coloring
system [RFC2697].

Attribute Length
Set to 4.

Bypass Traffic Rate
An unsigned integer measured in kbps.

5.6.2. Filter List Package

The HAAP uses the Filter List Package attribute to inform the HG of
the service types that need to bypass the bonded GRE tunnels. The
full list of all filter items Filter Items may be given by a series of Filter List
Package attributes with each specifying a partial list. At the HG, a
full list of filter items Filter Items is maintained. Also, the HG needs to
maintain an exception list of filter items. Filter Items. For example, the packets
carrying the control messages defined in this document should be
excluded from the filter list.

Incoming packets that match a filter item Filter Item in the filter list while
not matching any item in the exception list MUST be transmitted over
the
raw DSL rather than the bonded GRE tunnels. Both the LTE GRE Tunnel
Notify message and the DSL GRE Tunnel Notify message MAY include the
Filter List Package attribute. The DSL GRE Tunnel Notify message is
preferred.

Attribute Type
Filter List Package, set to 8.

Attribute Length
The total length of the Filter List TLV. The maximum allowed
length is 969 bytes.

Filter List TLV
The Filter List TLV occurs one time in a Filter List Package
attribute. It has the following format. format:

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Commit_Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Packet_Sum | Packet_ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Filter Item (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ...... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Filter Item (n) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

where each filter item Filter Item is of the following format format:

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Enable | Description Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Description Value ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Value ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Commit_Count
An unsigned integer which that identifies the version of the filter
item Filter
Item list. The version is shared by all Filter List Packages
and monotonic increasing increases monotonically by one for each new filter item Filter Item
list. The HG MUST refresh its filter item Filter Item list when a new
Commit_Count is received.

Packet_Sum
If a single Filter List Package attribute might make the
control message larger than the MTU, fragmentation is used.
The Packet_Sum indicates the total number of fragments.

Packet_ID
The fragmentation index for this Filter List Package attribute.
Each fragment is numbered starting at 1 and increasing by one
up to Packet_Sum.

Type
The Type of the Filter Item. Currently, the following types
are
supported. supported:

Filter Items Item Type
=========================
=========================== ============
FQDN [RFC1594] [RFC7031] 1
DSCP [RFC2724] 2
Destination Port 3
Destination IP 4
Destination IP&Port IP & Port 5
Source Port 6
Source IP 7
Source IP&Port IP & Port 8
Source Mac MAC 9
Protocol 10
Source IP Range 11
Destination IP Range 12
Source IP Range&Port Range & Port 13
Destination IP Range&Port Range & Port 14

Other values are reserved for future use and MUST be ignored on
receipt.

Length
The length of the Filter Item in octets. bytes. Type and Length are
excluded.

Enable
Whether
An integer that indicates whether or not the filter item Filter Item is
enabled. One A value of 1 means enabled "enabled", and zero a value of 0 means disabled.
"disabled". Other possible values are reserved and MUST be
ignored on receipt.

Description Length
The length of the Description Value in octets. bytes.

Description Value
A variable variable-length string value encoded in UTF-8 that describes
the Filter List TLV (e.g., "FQDN").

Value
A variable variable-length string encoded in UTF-8 that specifies the
value of the Filter Item (e.g. (e.g., "www.yahoo.com"). As an
example, Type = 1 and Value = "www.yahoo.com" means mean that packets
whose FQDN field equals "www.yahoo.com" match the filter item. Values for "Mac" Filter Item.
"Source MAC" (source Media Access Control address) values are
specified using hexadecimal numbers. Port number numbers are decimals
as assigned by IANA in [Port-NO]. For the "Protocol" type, the
value could either be either a decimal or a keyword specified by IANA
in [Pro-NO]. The formats for "IP" IP addresses and "IP
Range" IP address
ranges are defined in [RFC4632] and [RFC4291] for IPv4 and IPv6
IPv6, respectively. When the filter item A Filter Item of Type 5, 8, 13, or 14 is a
combination of two
parameters (Type 5, 8 and 13), parameters; values for the two parameters
are separated by a colon (":").

5.6.3. Switching to DSL Tunnel

If the RTT difference is continuously detected to violate be in violation of
the RTT Difference Threshold (See (see Section 5.2.4.) 5.2.4) more than the number
of times specified in the RTT Difference Threshold Violation (See
attribute (see Section
5.2.12.), 5.2.12), the HG uses the Switching to DSL
Tunnel attribute to inform the HAAP to use the DSL GRE tunnel only.
When the HAAP receives this attribute, it MUST begin to transmit
downstream traffic to this HG solely over the DSL GRE tunnel. The
DSL GRE Tunnel Notify message MAY include the Switching to DSL Tunnel
attribute.

+-+-+-+-+-+-+-+-+
|Attribute Type | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Length | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Attribute Type
Switching to DSL Tunnel, set to 11.

Attribute Length
Set to 0.

5.6.4. Overflowing to LTE Tunnel

If the RTT difference is continuously detected to not violated be in violation
of the RTT Difference Threshold attribute (See (see Section 5.2.4.) 5.2.4) more than the
number of times specified in the RTT Difference Threshold Compliance
attribute
(See (see Section 5.2.13), the HG uses the Overflowing to LTE
Tunnel attribute to inform the HAAP that the LTE GRE tunnel can be
used again. The DSL GRE Tunnel Notify message MAY include the
Overflowing to LTE Tunnel attribute.

+-+-+-+-+-+-+-+-+
|Attribute Type | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Length | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Attribute Type
Overflowing to LTE Tunnel, set to 12.

Attribute Length
Set to 0.

5.6.5. DSL Link Failure

When the HG detects that the DSL WAN interface status is down, "down", it
MUST tear down the DSL GRE tunnel. It informs the HAAP about the
failure by using the DSL Link Failure attribute. The HAAP MUST
tear down the DSL GRE tunnel upon receipt of the DSL Link Failure attribute is received.
attribute. The DSL Link Failure attribute SHOULD be carried in the
LTE GRE Tunnel Notify message.

+-+-+-+-+-+-+-+-+
|Attribute Type | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Length | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Attribute Type
DSL Link Failure, set to 18.

Attribute Length
Set to 0.

5.6.6. LTE Link Failure

When the HG detects that the LTE WAN interface status is down, "down", it
MUST tear down the LTE GRE tunnel. It informs the HAAP about the
failure by using the LTE Link Failure attribute. The HAAP MUST
tear down the LTE GRE tunnel upon receipt of the LTE Link Failure attribute is received.
attribute. The LTE Link Failure attribute SHOULD be carried in the
DSL GRE Tunnel Notify message.

+-+-+-+-+-+-+-+-+
|Attribute Type | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Length | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Attribute Type
LTE Link Failure, set to 19.

Attribute Length
Set to 0.

5.6.7. IPv6 Prefix Assigned to Host

If the HG changes the IPv6 prefix assigned to the host, it uses the
IPv6 Prefix Assigned to Host attribute to inform the HAAP. Both the
LTE GRE Tunnel Notify message and the DSL GRE Tunnel Notify message
MAY include the IPv6 Prefix Assigned to Host attribute.

Attribute Type
IPv6 Prefix Assigned to Host, set to 21.

Attribute Length
Set to 17.

IPv6 Prefix Assigned to Host
The highest-order 16 octets bytes encode an IPv6 address. The lowest-
order one octet
lowest-order 1 byte encodes the prefix length. These two values
are put together to represent an IPv6 prefix.

5.6.8. Diagnostic Start: Bonding Tunnel

The HG uses the Diagnostic Start: Bonding Tunnel attribute to inform
the HAAP to switch to diagnostic mode to test the performance of the
entire bonding tunnel. The Diagnostic Start: Bonding Tunnel
attribute SHOULD be carried in the DSL GRE Tunnel Notify message.

+-+-+-+-+-+-+-+-+
|Attribute Type | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Length | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Attribute Type
Diagnostic Start: Bonding Tunnel, set to 26.

Attribute Length
Set to 0.

5.6.9. Diagnostic Start: DSL Tunnel

The HG uses the Diagnostic Start: DSL Tunnel attribute to inform the
HAAP to switch to diagnostic mode to test the performance of the DSL
GRE tunnel. The Diagnostic Start: DSL Tunnel attribute SHOULD be
carried in the DSL GRE Tunnel Notify message.

+-+-+-+-+-+-+-+-+
|Attribute Type | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Length | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Attribute Type
Diagnostic Start: DSL Tunnel, set to 27.

Attribute Length
Set to 0.

5.6.10. Diagnostic Start: LTE Tunnel

The HG uses the Diagnostic Start: LTE Tunnel attribute to inform the
HAAP to switch to diagnostic mode to test the performance of the
entire bonding
LTE GRE tunnel. The Diagnostic Start: LTE Tunnel attribute SHOULD be
carried in the DSL GRE Tunnel Notify message.

+-+-+-+-+-+-+-+-+
|Attribute Type | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Length | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Attribute Type
Diagnostic Start: LTE Tunnel, set to 18. 28.

Attribute Length
Set to 0.

5.6.11. Diagnostic End

The HG uses the Diagnostic End attribute to inform th the HAAP to stop
operating in diagnostic mode. The Diagnostic End attribute SHOULD be
carried in the DSL GRE Tunnel Notify message.

+-+-+-+-+-+-+-+-+
|Attribute Type | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Length | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Attribute Type
Diagnostic End, set to 29.

Attribute Length
Set to 0.

5.6.12. Filter List Package ACK

The HG uses the Filter List Package ACK attribute to acknowledge the
Filter List Package sent by the HAAP. Both the LTE GRE Tunnel Notify
message and the DSL GRE Tunnel Notify message MAY include the Filter
List Package ACK attribute.

Attribute Type
Filter List Package ACK, set to 30.

Attribute Length
Set to 5.

Filter List Package ACK
The highest-order 4 octets bytes are the Commit_Count as defined in
Section 5.6.2. The lowest-order 1 octet byte encodes the following
error codes:

0: The Filter List Package is acknowledged.

1: The Filter List Package is not acknowledged. The HG is a new
subscriber and has not ever received a Filter List Package. In
this case, the HAAP SHOULD tear down the bonding tunnels and
force the HG to re-establish the GRE Tunnels. tunnels.

2: The Filter List Package is not acknowledged. The HG has
already
got gotten a valid Filter List Package. The filter list on
the HG will continue to be used used, while the HAAP need to not do nothing.
anything.

5.6.13. Switching to Active Hello State

If traffic is being sent/received over the bonding GRE tunnels before
the "No Traffic Monitored Interval" expires (See (see Section 5.2.15.), 5.2.15), the
HG sends to the HAAP a GRE Tunnel Notify message containing the
Switching to Active Hello State attribute.

The HAAP will switch to active hello state Active Hello State and send the HG a GRE
Tunnel Notify message carrying the Switching to Active Hello State
attribute as the ACK.

When the HG receives the ACK, it will switch to active hello state, Active Hello State,
start RTT detection detection, and start sending GRE Tunnel Hello messages with
the Active Hello Interval (See (see Section 5.2.6.). 5.2.6).

+-+-+-+-+-+-+-+-+
|Attribute Type | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Length | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Attribute Type
Switching to Active Hello State, set to 33.

Attribute Length
Set to 0.

5.6.14. Switching to Idle Hello State

The HG initiates switching to idle hello state Idle Hello State when the bonding of
GRE Tunnels tunnels is successfully established and the LTE GRE Tunnel Setup
Accept message carrying the Idle Hello Interval attribute (See (see
Section 5.2.14.) 5.2.14) is received. The HG sends the HAAP a GRE Tunnel
Notify message containing the Switching to Idle Hello State
attribute.

The HAAP will switch to idle hello state, Idle Hello State, clear RTT state state, and send
the HG a GRE Tunnel Notify message carrying the Switching to Idle
Hello State attribute as the ACK.

When the HG receives the ACK, it will (1) switch to idle hello state, Idle Hello State,
(2) stop RTT detection, detection and clear RTT state as well state, and (3) start sending GRE
Tunnel Hello messages with the Idle Hello Interval (See (see
Section 5.2.14).

+-+-+-+-+-+-+-+-+
|Attribute Type | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Length | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Attribute Type
Switching to Idle Hello State, set to 34.

Attribute Length
Set to 0.

5.6.15. Tunnel Verification

The HAAP uses the Tunnel Verification attribute to inform the HG to
verify whether an existing LTE GRE tunnel is still functioning. The
Tunnel Verification attribute SHOULD be carried in the LTE GRE Tunnel
Notify message. It provides a means to detect the tunnel faster than
the GRE Tunnel Hello, especially when the LTE GRE tunnel is in the
Idle Hello state State and it takes a much longer time to detect this
tunnel.

When the HAAP receives an LTE GRE Tunnel Setup Request and finds that
the requested tunnel is conflicting conflicts with an existing tunnel, the HAAP
initiates the Tunnel Verification. tunnel verification. The HAAP drops all conflicting LTE
GRE Tunnel Setup Request messages and sends GRE Tunnel Notify
messages carrying the Tunnel Verification attribute until the
verification ends. The HG MUST respond to the HAAP with the same
Tunnel Verification attribute as the ACK if the tunnel is still
functioning.

If the ACK of the Tunnel Verification attribute is received from the
HG, the HAAP judges determines that the existing tunnel is still
functioning. An LTE GRE Tunnel Deny message (with Error Code = 8)
will be sent to the HG. The HG SHOULD terminate the GRE tunnel setup request Tunnel Setup
Request process immediately.

If the HAAP does not receive a Tunnel Verification tunnel verification ACK message after
3
three attempts (1 (one initial attempt and 2 two retries), it will regard
the existing tunnel as failed failed, and the LTE GRE Tunnel Setup Request
will be accepted.

+-+-+-+-+-+-+-+-+
|Attribute Type | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Length | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Attribute Type
Tunnel Verification, set to 35.

Attribute Length
Set to 0.

6. Tunnel Protocol Operation (Data Plane)

GRE tunnels are set up over heterogeneous connections, such as LTE
and DSL, between the HG and the HAAP. Users' IP (inner) packets are
encapsulated in GRE packets which that are in turn are carried in IP (outer)
packets. The general structure of data packets of the GRE Tunnel
Bonding protocol Protocol is shown as below.

+--------------------------------+
| Media Header |
+--------------------------------+
| Outer IP Header |
+--------------------------------+
| GRE Header |
+--------------------------------+
| Inner IP Packet |
+--------------------------------+

6.1. The GRE Header

The GRE header is was first standardized in [RFC2784]. [RFC2890] adds added
the optional Key and Sequence Number fields.

The Checksum and the Reserved1 fields are not used in the GRE Tunnel
Bonding, therefore
Bonding; therefore, the C bit is set to zero. 0.

The Key bit is set to one 1 so that the Key field is present. The Key
field is used as a 32-bit random number. It is generated by the HAAP
per bonding connection connection, and notified to the HG (See is notified (see Section 5.2.9).

The S bit is set to one, 1, and the Sequence Number field is present and
used for in-order delivery as per [RFC2890].

The Protocol Type field in the GRE header MUST be set to 0x0800 for
IPv4 or 0x86DD for IPv6. So So, the GRE header used by data packets of
the GRE Tunnel Bonding protocol have Protocol has the following format. format:

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| |1|1| Reserved0 | Ver | Protocol Type 0x0800/86DD |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 6.1 The 3: GRE header Header for data packets Data Packets of GRE Tunnel Bonding

6.2. Automatic Setup of GRE Tunnels

The HG gets the DSL WAN interface IP address (D) from the Broadband
Remote Access Server (BRAS) via the Point-to-Point Protocol over
Ethernet
(PPPoE), (PPPoE) and gets the LTE WAN interface IP address (E)
through the Packet Data Protocol (PDP) from the Packet Data Network
Gateway (PGW). The domain name of a HAAP group may be configured or
obtained via the DSL/LTE WAN interface based on gateway configuration
protocols such as [TR-069], where the HAAP group comprises of one or
multiple HAAPs. The Domain Name System (DNS) resolution of the HAAP
group's domain name is requested via the DSL/LTE WAN interface. The
DNS server will reply with an anycast HAAP IP address (G) (G), which MAY
be pre-configured by the operator.

After the interface IP addresses have been acquired, the HG starts
the following GRE Tunnel Bonding procedure. It is REQUIRED that the
HG first set up the LTE GRE tunnel and then set up the DSL GRE
tunnel.

The HG sends the GRE Tunnel Setup Request message to the HAAP via the
LTE WAN interface. The outer source IP address for this message is
the LTE WAN interface IP address (E) (E), while the outer destination IP
address is the anycast HAAP IP address (G). The HAAP with the
highest priority (e.g., the one that the HG has the least cost least-cost path
to reach) in the HAAP group, which receives the GRE Tunnel Setup
Request message, will initiate the Authentication procedure for authentication and Authorization
procedure,
authorization, as specified in [TS23.401], to check whether the HG is
trusted by the PGW.

If the Authentication authentication and Authorization authorization succeed, the HAAP sets the
LTE WAN interface IP address (E) (E), which is obtained from the GRE
Tunnel Setup Request message (i.e., its outer source IP address) address), as
the destination endpoint IP address of the GRE tunnel and replies to
the HG's LTE WAN interface with the GRE Tunnel Setup Accept message
in which an IP address (H) of the HAAP (e.g. (e.g., an IP address of a Line
Card in the HAAP) and a Session ID randomly generated by the HAAP are
carried as attributes. The outer source IP address for this message
is the IP address (H) or the anycast HAAP IP address (G) (G), while the
outer destination IP address is the LTE WAN interface IP address (E).
Otherwise, the HAAP MUST send to the HG's LTE WAN interface the GRE
Tunnel Setup Deny message message, and the HG MUST terminate the tunnel set up setup
process once it receives the GRE Tunnel Setup Deny message.

After the LTE GRE tunnel is successfully set up, the HG will obtain
the C address (see Figure 1) over the tunnel from the HAAP through
the Dynamic Host Configuration Protocol (DHCP). After that, the HG
starts to set up the DSL GRE tunnel. It sends a GRE Tunnel Setup
Request message via the DSL WAN interface, carrying the
aforementioned Session ID received from the HAAP. The outer source
IP address for this message is the DSL WAN interface IP address (D) (D),
while the outer destination IP address is the IP address (H) of the
HAAP. The HAAP, which receives the GRE Tunnel Setup Request message,
will initiate the
Authentication and Authorization procedure for authentication and authorization in
order to check whether the HG is trusted by the BRAS.

If the Authentication authentication and Authorization authorization succeed, the HAAP sets the
DSL WAN interface IP address (D) (D), which is obtained from the GRE
Tunnel Setup Request message (i.e., its outer source IP address) address), as
the destination endpoint IP address of the GRE tunnel and replies to
the HG's DSL WAN interface with the GRE Tunnel Setup Accept message.
The outer source IP address for this message is the IP address (H) of
the HAAP HAAP, while the outer destination IP address is the DSL WAN
interface IP address (D). In this way, the two tunnels with the same
Session ID can be used to carry traffic from the same user. That is
to say, the two tunnels are "bonded" together. Otherwise, if the
Authentication
authentication and Authorization authorization fail, the HAAP MUST send to the HG's
DSL WAN interface the GRE Tunnel Setup Deny message. Meanwhile, it
MUST send to the HG's LTE WAN interface the GRE Tunnel Tear Down
message. The HG MUST terminate the tunnel set up setup process once it
receives the GRE Tunnel Setup Deny message and MUST tear down the LTE
GRE tunnel that has been set up once it receives the GRE Tunnel
Tear Down Message. message.

7. Security Considerations

Malicious devices controlled by attackers may intercept the control
messages sent on the GRE tunnels. Later on, the rogue devices may
fake control messages to disrupt the GRE tunnels or attract traffic
of
from the target HG.

As a security feature, the Key field of the GRE header of the control
messages and the data packets is generated as a 32-bit clear-text cleartext
password, except for the first GRE Setup Request message per bonding
connection sent from the HG to the HAAP, whose Key field is filled
with all zeros. The HAAP and the HG validate the Key value and the
outer source IP
address address, and they discard any packets with any invalid combination.
combinations.

Moreover, GRE over IP Security (IPSec) (IPsec) could be used to enhance the
security.

8. IANA Considerations

IANA need not to assign anything for the GRE Tunnel Bonding Protocol.
The GRE Protocol Type Type, the Ethertype for the GRE Channel Channel, is set to 0xB7EA
0xB7EA, which is under the control of the IEEE Registration
Authority. However, IANA may
update has updated the "IEEE 802 Numbers" IANA web
page [802Type] [802Type], which is of primarily historic interest.

9. Contributors

Li Xue
Individual
EMail: xueli_jas@163.com

Zhongwen Jiang
Huawei Technologies

EMail: jiangzhongwen@huawei.com

10. References

10.1.

9.1. Normative References

[Port-NO] IANA, "Service Name and Transport Protocol Port Number
Registry", <http://www.iana.org/assignments/
service-names-port-numbers>.

[Pro-NO] IANA, "Assigned Internet Protocol Numbers",
<http://www.iana.org/assignments/protocol-numbers>.

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

[RFC2697] Heinanen, J. and R. Guerin, "A Single Rate Three Color
Marker", RFC 2697, DOI 10.17487/RFC2697, September 1999,
<http://www.rfc-editor.org/info/rfc2697>.

[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,
DOI 10.17487/RFC2784, March 2000, <http://www.rfc-
editor.org/info/rfc2784>.
<http://www.rfc-editor.org/info/rfc2784>.

[RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE",
RFC 2890, DOI 10.17487/RFC2890, September 2000,
<http://www.rfc-editor.org/info/rfc2890>.

[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, DOI 10.17487/RFC4291,
February 2006, <http://www.rfc-editor.org/info/rfc4291>.

[RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing
(CIDR): The Internet Address Assignment and Aggregation
Plan", BCP 122, RFC 4632, DOI 10.17487/RFC4632,
August 2006, <http://www.rfc-editor.org/info/rfc4632>.

[TR-069] Broadband Forum, "CPE WAN Management Protocol", Issue: 1
Amendment 5, Nov, November 2013, <https://www.broadband-
forum.org/technical/download/TR-069_Amendment-5.pdf>
<https://www.broadband-forum.org/technical/download/
TR-069_Amendment-5.pdf>.

[TS23.401] "3GPP 3GPP TS23.401, General "General Packet Radio Service (GPRS)
enhancements for Evolved Universal Terrestrial Radio
Access Network (E-UTRAN) access", v11.7.0, September 2013.

[Port-NO] IANA, "Service Name and Transport Protocol Port Number
Registry", <http://www.iana.org/assignments/service-names-
port-numbers>

[Pro-NO] IANA, "Assigned Internet Protocol Numbers",
<http://www.iana.org/assignments/protocol-numbers>

[RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing
(CIDR): The Internet Address Assignment and Aggregation
Plan", BCP 122, RFC 4632, DOI 10.17487/RFC4632, August
2006, <http://www.rfc-editor.org/info/rfc4632>.

[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, DOI 10.17487/RFC4291, February
2006, <http://www.rfc-editor.org/info/rfc4291>.

10.2.

9.2. Informative References

[RFC1594] Marine, A., Reynolds, J., and G. Malkin, "FYI on Questions
and Answers - Answers to Commonly asked "New Internet User"
Questions", RFC 1594, March 1994.

[802Type] IANA, "IEEE 802 Numbers",
<http://www.iana.org/assignments/ieee-802-numbers>.

[ANSI-X9.31-1998]
ANSI Standard X9.31-1998, "Digital Signatures Using
Reversible Public Key Cryptography for the Financial
Services Industry (rDSA)", 1998.

[RFC2724] Handelman, S., Stibler, S., Brownlee, N., and G. Ruth,
"RTFM: New Attributes for Traffic Flow Measurement",
RFC 2724, DOI 10.17487/RFC2724, October 1999, <http://www.rfc-
editor.org/info/rfc2724>.
<http://www.rfc-editor.org/info/rfc2724>.

[RFC6320] Wadhwa, S., Moisand, J., Haag, T., Voigt, N., and T.
Taylor, Ed., "Protocol for Access Node Control Mechanism
in Broadband Networks", RFC 6320, DOI 10.17487/RFC6320,
October 2011, <http://www.rfc-editor.org/info/rfc6320>.

[RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn,
Ed., "Diameter Base Protocol", RFC 6733,
DOI 10.17487/RFC6733, October 2012, <http://www.rfc-
editor.org/info/rfc6733>.
<http://www.rfc-editor.org/info/rfc6733>.

[RFC7031] Mrugalski, T. and K. Kinnear, "DHCPv6 Failover
Requirements", RFC 7031, DOI 10.17487/RFC7031,
September 2013, <http://www.rfc-editor.org/info/rfc7031>.

[RFC7676] Pignataro, C., Bonica, R., and S. Krishnan, "IPv6 Support
for Generic Routing Encapsulation (GRE)", RFC 7676,
DOI 10.17487/RFC7676, October 2015, <http://www.rfc-
editor.org/info/rfc7676>.

[802Type] IANA, "IEEE 802 Numbers",
<http://www.iana.org/assignments/ieee-802-numbers>.

Author's
<http://www.rfc-editor.org/info/rfc7676>.

Contributors

Li Xue
Individual
Email: xueli_jas@163.com

Zhongwen Jiang
Huawei Technologies
Email: jiangzhongwen@huawei.com

Authors' Addresses

Nicolai Leymann
Deutsche Telekom AG
Winterfeldtstrasse 21-27
Berlin 10781
Germany
Phone: +49-170-2275345
Email: n.leymann@telekom.de

Cornelius Heidemann
Deutsche Telekom AG
Heinrich-Hertz-Strasse 3-7
Darmstadt 64295
Germany
Phone: +4961515812721 +49-6151-5812721
Email: heidemannc@telekom.de

Mingui Zhang
Huawei Technologies
No.156
No. 156 Beiqing Rd.
Haidian District, District
Beijing 100095 P.R.
China

EMail:
Email: zhangmingui@huawei.com

Behcet Sarikaya
Huawei USA
5340 Legacy Dr. Building 3
Plano, TX 75024

EMail:
United States of America
Email: sarikaya@ieee.org

Margaret Cullen
Painless Security
14 Summer St. Suite 202
Malden, MA 02148 USA

EMail:
United States of America
Email: margaret@painless-security.com