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

Versions: 00 01 02 03 04 05 RFC 8157

Independent Submission                                        N. Leymann
Internet Draft                                              C. Heidemann
Intended Category: Informational                     Deutsche Telekom AG
                                                                M. Zhang
                                                             B. Sarikaya
                                                                  Huawei
                                                               M. Cullen
                                                       Painless Security
Expires: May 4, 2017                                    October 31, 2016

                  Huawei's GRE Tunnel Bonding Protocol
                 draft-zhang-gre-tunnel-bonding-04.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, 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. 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, 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.

Status of this Memo

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

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as
   Internet-Drafts.

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

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/1id-abstracts.html




Mingui Zhang, et al       Expires May 4, 2017                   [Page 1]


INTERNET-DRAFT             GRE Tunnel Bonding           October 31, 2016


   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html


Copyright and License Notice

   Copyright (c) 2016 IETF Trust and the persons identified as the
   document authors. All rights reserved.

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


Table of Contents

   1. Introduction  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2. Acronyms and Terminology  . . . . . . . . . . . . . . . . . . .  4
   3. Use Case  . . . . . . . . . . . . . . . . . . . . . . . . . . .  5
   4. Overview  . . . . . . . . . . . . . . . . . . . . . . . . . . .  6
     4.1. Control Plane . . . . . . . . . . . . . . . . . . . . . . .  6
     4.2. Data Plane  . . . . . . . . . . . . . . . . . . . . . . . .  7
     4.3. Traffic Classification and Distribution . . . . . . . . . .  7
     4.4. Traffic Recombination . . . . . . . . . . . . . . . . . . .  8
     4.5. Bypassing . . . . . . . . . . . . . . . . . . . . . . . . .  8
     4.6. Measurement . . . . . . . . . . . . . . . . . . . . . . . .  8
     4.7. Policy Control Considerations . . . . . . . . . . . . . . .  9
   5. Control Protocol Specification (Control Plane)  . . . . . . . .  9
     5.1. GRE Tunnel Setup Request  . . . . . . . . . . . . . . . . . 11
       5.1.1. Client Identification Name  . . . . . . . . . . . . . . 12
       5.1.2. Session ID  . . . . . . . . . . . . . . . . . . . . . . 12
       5.1.3. DSL Synchronization Rate  . . . . . . . . . . . . . . . 13
     5.2. GRE Tunnel Setup Accept . . . . . . . . . . . . . . . . . . 13
       5.2.1. H IPv4 Address  . . . . . . . . . . . . . . . . . . . . 14
       5.2.2. H IPv6 Address  . . . . . . . . . . . . . . . . . . . . 14
       5.2.3. Session ID  . . . . . . . . . . . . . . . . . . . . . . 15
       5.2.4. RTT Difference Threshold  . . . . . . . . . . . . . . . 15
       5.2.5. Bypass Bandwidth Check Interval . . . . . . . . . . . . 15
       5.2.6. Active Hello Interval . . . . . . . . . . . . . . . . . 16
       5.2.7. Hello Retry Times . . . . . . . . . . . . . . . . . . . 17
       5.2.8. Idle Timeout  . . . . . . . . . . . . . . . . . . . . . 17
       5.2.9. Bonding Key Value . . . . . . . . . . . . . . . . . . . 18



Mingui Zhang, et al       Expires May 4, 2017                   [Page 2]


INTERNET-DRAFT             GRE Tunnel Bonding           October 31, 2016


       5.2.10. Configured DSL Upstream Bandwidth  . . . . . . . . . . 18
       5.2.11. Configured DSL Downstream Bandwidth  . . . . . . . . . 19
       5.2.12. RTT Difference Threshold Violation . . . . . . . . . . 19
       5.2.13. RTT Difference Threshold Compliance  . . . . . . . . . 20
       5.2.14. Idle Hello Interval  . . . . . . . . . . . . . . . . . 21
       5.2.15. No Traffic Monitored Interval  . . . . . . . . . . . . 21
     5.3. GRE Tunnel Setup Deny . . . . . . . . . . . . . . . . . . . 22
       5.3.1. Error Code  . . . . . . . . . . . . . . . . . . . . . . 22
     5.4. GRE Tunnel Hello  . . . . . . . . . . . . . . . . . . . . . 23
       5.4.1. Timestamp . . . . . . . . . . . . . . . . . . . . . . . 23
       5.4.2. IPv6 Prefix Assigned by HAAP  . . . . . . . . . . . . . 24
     5.5. GRE Tunnel Tear Down  . . . . . . . . . . . . . . . . . . . 24
     5.6. GRE Tunnel Notify . . . . . . . . . . . . . . . . . . . . . 24
       5.6.1. Bypass Traffic Rate . . . . . . . . . . . . . . . . . . 25
       5.6.2. Filter List Package . . . . . . . . . . . . . . . . . . 26
       5.6.3. Switching to DSL Tunnel . . . . . . . . . . . . . . . . 28
       5.6.4. Overflowing to LTE Tunnel . . . . . . . . . . . . . . . 29
       5.6.5. DSL Link Failure  . . . . . . . . . . . . . . . . . . . 29
       5.6.6. LTE Link Failure  . . . . . . . . . . . . . . . . . . . 29
       5.6.7. IPv6 Prefix Assigned to Host  . . . . . . . . . . . . . 30
       5.6.8. Diagnostic Start: Bonding Tunnel  . . . . . . . . . . . 30
       5.6.9. Diagnostic Start: DSL Tunnel  . . . . . . . . . . . . . 31
       5.6.10. Diagnostic Start: LTE Tunnel . . . . . . . . . . . . . 31
       5.6.11. Diagnostic End . . . . . . . . . . . . . . . . . . . . 32
       5.6.12. Filter List Package ACK  . . . . . . . . . . . . . . . 32
       5.6.13. Switching to Active Hello State  . . . . . . . . . . . 33
       5.6.14. Switching to Idle Hello State  . . . . . . . . . . . . 33
       5.6.15. Tunnel Verification  . . . . . . . . . . . . . . . . . 34
   6. Tunnel Protocol Operation (Data Plane)  . . . . . . . . . . . . 35
     6.1. The GRE Header  . . . . . . . . . . . . . . . . . . . . . . 35
     6.2. Automatic Setup of GRE Tunnels  . . . . . . . . . . . . . . 36
   7. Security Considerations . . . . . . . . . . . . . . . . . . . . 38
   8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 38
   9. Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . 38
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 38
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 38
     10.2. Informative References . . . . . . . . . . . . . . . . . . 39
   Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . . 40

1. Introduction

   Service 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 increased access capacity and improved
   reliability.

   This document focuses on the use case that DSL (Digital Subscriber



Mingui Zhang, et al       Expires May 4, 2017                   [Page 3]


INTERNET-DRAFT             GRE Tunnel Bonding           October 31, 2016


   Line) connection and 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.
   Home Gateway (HG) is a Customer Premises Equipment (CPE) initiating
   the DSL and LTE connections. 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 this document.

   This document bases the solution on GRE (Generic Routing
   Encapsulation [RFC2890]) since GRE is widely supported in both fixed
   and mobile networks. One GRE tunnel is set up for each heterogeneous
   connection (DSL and LTE) between the HG and HAAP. Those GRE tunnels
   are further bonded together to form a logical GRE tunnel for the
   subscriber. 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 which is in turn carried over IP (outer IP).

2. Acronyms and Terminology

   GRE: Generic Routing Encapsulation [RFC2890]

   DSL: Digital Subscriber Line is a family of technologies that are
   used to transmit digital data over telephone 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 network, terminating bonded connections while offering
   high speed Internet.

   CIR: Committed Information Rate [RFC2698]

   RTT: Round Trip Time

   AAA: Authentication, Authorization and Accounting [RFC6733]

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



Mingui Zhang, et al       Expires May 4, 2017                   [Page 4]


INTERNET-DRAFT             GRE Tunnel Bonding           October 31, 2016


   FQDN: A Fully Qualified Domain Name (FQDN) is a domain name that
   includes all higher level domains relevant to the entity named.
   [RFC1594]

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

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

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

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

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

   DNS: Domain Name System is 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














Mingui Zhang, et al       Expires May 4, 2017                   [Page 5]


INTERNET-DRAFT             GRE Tunnel Bonding           October 31, 2016


                 +-+                            +-+
                 | +---- Bonding Connection ----+ |
                 | |                            | |
                 | | +-+                    +-+ | |
      subscriber |C| |E+-- LTE Connection --+ | |G| Internet
                 | | +-+                    |H| | |
                 | | +-+                    | | | |
                 | | |D+-- DSL Connection --+ | | |
                 +-+ +-+                    +-+ +-+
                 \_____/                    \_____/
                    HG                        HAAP

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

   Figure 3.1: Offloading from DSL to LTE, increased access capacity

   If a Service Provider runs heterogeneous networks, such as fixed and
   mobile, subscribers 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, 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 which are widely used
   nowadays, the use case described in this document requires a per-
   packet offloading approach. For per-flow load-balancing, the maximum
   bandwidth that may be used by a traffic flow is the bandwidth of an
   individual connection. While for per-packet offloading, a single flow
   may use the added-up 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 on top of the DSL and LTE connections which are ended at D and
   H or E and H, as shown in Figure 3.1. These tunnels are bonded
   together to form a single logical bonding connection between HG and
   HAAP. Subscribers use this logical connection without knowing the
   composing GRE tunnels.

4.1. Control Plane




Mingui Zhang, et al       Expires May 4, 2017                   [Page 6]


INTERNET-DRAFT             GRE Tunnel Bonding           October 31, 2016


   A clean-slate control protocol is designed to manage the GRE tunnels
   that are setup per heterogeneous connection between HG and 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 forwarding of control
   plane packets. The GRE header (shown in Figure 5.1) as specified in
   [RFC2890] is being used. The GRE Protocol Type (0xB7EA) is used to
   identify this GRE Channel. A family of control messages are
   encapsulated with GRE header and carried over this channel.
   Attributes, formatted in Type-Length-Value style, are further defined
   and included in each control message.

   With the newly defined control plane, the GRE tunnels between HG and
   HAAP can be established, 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 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., DSL GRE tunnel, and another
   GRE tunnel is ended at the LTE WAN interfaces, e.g., LTE GRE tunnel.
   Each tunnel may carry 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.

   The GRE header [RFC2890] is used to encapsulate data packets. The
   Protocol Type is either 0x0800 [RFC2784] or 0x86DD [RFC7676], which
   indicates the inner packet is either an IPv4 packet or an IPv6
   packet. The Key field is set to a unique value for the entire bonding
   connection. The 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
   [RFC2698] is being used to classify subscriber's IP packets, both
   upstream and downstream, into the DSL GRE tunnel or the LTE GRE
   tunnel. Packets colored as green will be distributed into the DSL GRE
   tunnel and packets colored as yellow 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 is
   out of the scope for this document.



Mingui Zhang, et al       Expires May 4, 2017                   [Page 7]


INTERNET-DRAFT             GRE Tunnel Bonding           October 31, 2016


   The Committed Information Rate (CIR) of the coloring mechanism is set
   to the total DSL WAN bandwidth minus the bypassing DSL bandwidth (See
   Section 4.4.). 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 using ANCP [RFC6320].

4.4. Traffic Recombination

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

4.5. Bypassing

   Service Providers provide some services that should not be delivered
   over the bonding connection. For example, Service Providers do not
   expect real-time IPTV to be carried by the LTE GRE tunnel. It is
   required that these services bypass the GRE Tunnel Bonding and use
   the raw DSL bandwidth. In this way, they are not subject to the
   traffic classification and distribution specified above. There are
   two kinds of bypassing:

   o Full bypassing: The raw DSL connection used for bypassing is not
     controlled by the HAAP. It may or may not go through HAAP.

   o Partial bypassing: The HAAP device controls the raw DSL connection
     used for bypassing. The raw DSL connection goes through the HAAP.

   For either type of bypassing, the HAAP announces the service types
   that need to bypass the bonded GRE tunnels 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 bypassing 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 are used to carry the timestamp information and the Round
   Trip Time (RTT) value can therefore be calculated based on the
   timestamp.




Mingui Zhang, et al       Expires May 4, 2017                   [Page 8]


INTERNET-DRAFT             GRE Tunnel Bonding           October 31, 2016


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

4.7. Policy Control Considerations

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

   Operators and customers may offer the service types that need to
   bypass the bonded GRE tunnels. These service types will be delivered
   from the HAAP to the HG, and the HG will use the raw DSL interface to
   transmit traffic for these service types.

   Since the GRE tunnels are setup 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 to a traditional transmission mode, where the LTE GRE tunnel
   is disabled while all traffic is transmitted over the DSL GRE tunnel.
   Operators are allowed to define this threshold and period.

   Operators may determine the maximum allowed size (See
   MAX_PERFLOW_BUFFER in [RFC2890]) of the buffer for reordering. They
   may also define the maximum time (See OUTOFORDER_TIMER in [RFC2890])
   that a packet can stay in the buffer for reordering. These parameters
   impact the traffic recombination.

   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.

5. Control Protocol Specification (Control Plane)

   Control messages are used to establish, maintain, measure and tear
   down GRE tunnels between the HG and the HAAP. Also, the control plane
   undertakes the responsibility 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 packets.
   The new GRE Protocol Type (0xB7EA) is allocated for this purpose and
   the standard GRE header as per [RFC2890] is used. The format of the
   GRE header is as follows:




Mingui Zhang, et al       Expires May 4, 2017                   [Page 9]


INTERNET-DRAFT             GRE Tunnel Bonding           October 31, 2016


    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |C| |K|S| Reserved0       | Ver |   Protocol Type 0xB7EA        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Key (optional)                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   C (Bit 0)
      Checksum Present. Set to zero (0).

   K (Bit 2)
      Key Present. Set to one (1).

   S (Bit 3)
      Sequence Number Present. Set to zero (0).

   Protocol Type (2 octets)
      Set to 0xB7EA.

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

   The general format of the entire control message 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 (optional)                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |MsgType|T|Rsvd1|                                               |
   +-+-+-+-+-+-+-+-+           Attributes                          +
   ~                                                               ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Figure 5.1: The format of control messages of GRE Tunnel Bonding

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







Mingui Zhang, et al       Expires May 4, 2017                  [Page 10]


INTERNET-DRAFT             GRE Tunnel Bonding           October 31, 2016


                   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

   T (1 bit)
      Tunnel Type. Set to 1 if the control message is sent via the DSL
      GRE tunnel. Set to 0 if the control message is sent via the LTE
      GRE tunnel

   Rsvd1 (3 bits)
      Reserved1. Reserved for future use. These bits MUST be set to zero
      and ignored by the receiver.

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

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

      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.

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

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

5.1. GRE Tunnel Setup Request



Mingui Zhang, et al       Expires May 4, 2017                  [Page 11]


INTERNET-DRAFT             GRE Tunnel Bonding           October 31, 2016


   HG uses the GRE Tunnel Setup Request message to request that the HAAP
   establish the GRE tunnels. It is sent out from 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 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 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 |                   (1 byte)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Attribute Length             |   (2 bytes)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+
   |  Client Identification Name       (40 bytes)  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+

   Attribute Type
      CIN, set to 3.

   Attribute Length
      Set to 40.

   Client Identification Name
      This is a 40-byte ANSI string value 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 fails
   and 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:



Mingui Zhang, et al       Expires May 4, 2017                  [Page 12]


INTERNET-DRAFT             GRE Tunnel Bonding           October 31, 2016


   +-+-+-+-+-+-+-+-+
   |Attribute Type |                   (1 byte)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Attribute Length             |   (2 bytes)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+
   |  Session ID                       (4 bytes)   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+

   Attribute Type
      Session ID, set to 4.

   Attribute Length
      Set to 4.

   Session ID
      This is a 4-byte ANSI string value generated by the HAAP. It is
      used as the identification of bonded GRE 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 |                   (1 byte)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Attribute Length             |   (2 bytes)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+
   |  DSL Synchronization Rate         (4 bytes)   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+

   Attribute Type
      DSL Synchronization Rate, set to 7.

   Attribute Length
      Set to 4.

   DSL Synchronization Rate
      This is 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



Mingui Zhang, et al       Expires May 4, 2017                  [Page 13]


INTERNET-DRAFT             GRE Tunnel Bonding           October 31, 2016


   GRE tunnels. Attributes that need be to 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 WAN interface
   IP address (D/E)). The LTE GRE Tunnel Setup Accept message MUST
   include the H IPv4 Address attribute.

   +-+-+-+-+-+-+-+-+
   |Attribute Type |                   (1 byte)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Attribute Length             |   (2 bytes)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+
   |  H IPv4 Address                   (4 bytes)   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+

   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. an IP address of a
      Line Card in the HAAP) which is used as the endpoint IP address of
      GRE tunnels by the HAAP.

5.2.2. H IPv6 Address

   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 addresses
   of the GRE tunnels are respectively DSL/LTE WAN interface IP address
   (D/E)). The LTE GRE Tunnel Setup Accept message MUST include the H
   IPv6 Address attribute.

   +-+-+-+-+-+-+-+-+
   |Attribute Type |                   (1 byte)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Attribute Length             |   (2 bytes)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+
   |  H IPv6 Address                   (16 bytes)  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+




Mingui Zhang, et al       Expires May 4, 2017                  [Page 14]


INTERNET-DRAFT             GRE Tunnel Bonding           October 31, 2016


   Attribute Type
      H IPv6 Address, set to 1.

   Attribute Length
      Set to 16.

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

5.2.3. Session ID

   The LTE GRE Tunnel Setup Accept message MUST include 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 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 |                   (1 byte)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Attribute Length             |   (2 bytes)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+
   |  RTT Difference Threshold         (4 bytes)   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+

   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



Mingui Zhang, et al       Expires May 4, 2017                  [Page 15]


INTERNET-DRAFT             GRE Tunnel Bonding           October 31, 2016


   time period indicated by this interval. The LTE GRE Tunnel Setup
   Accept message MUST include the Bypass Bandwidth Check Interval
   attribute.

   +-+-+-+-+-+-+-+-+
   |Attribute Type |                   (1 byte)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Attribute Length             |   (2 bytes)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+
   |  Bypass Bandwidth Check Interval  (4 bytes)   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+

   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 0 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 Type |                   (1 byte)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Attribute Length             |   (2 bytes)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+
   |  Active Hello Interval            (4 bytes)   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+

   Attribute Type
      Active Hello Interval, set to 14.

   Attribute Length
      Set to 4.

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



Mingui Zhang, et al       Expires May 4, 2017                  [Page 16]


INTERNET-DRAFT             GRE Tunnel Bonding           October 31, 2016


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. The LTE GRE Tunnel Setup Accept message MUST
   include the Hello Retry Times attribute.

   +-+-+-+-+-+-+-+-+
   |Attribute Type |                   (1 byte)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Attribute Length             |   (2 bytes)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+
   |  Hello Retry Times                (4 bytes)   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+

   Attribute Type
      Hello Retry Times, set to 15.

   Attribute Length
      Set to 4.

   Hello Retry Times
      An unsigned integer, which 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 timeout value to terminate the DSL GRE tunnel. When an LTE
   GRE 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 Tunnel Setup Accept message MUST include the Idle Timeout
   attribute.

   +-+-+-+-+-+-+-+-+
   |Attribute Type |                   (1 byte)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Attribute Length             |   (2 bytes)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+
   |  Idle Timeout                     (4 bytes)   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+

   Attribute Type
      Idle Timeout, set to 16.




Mingui Zhang, et al       Expires May 4, 2017                  [Page 17]


INTERNET-DRAFT             GRE Tunnel Bonding           October 31, 2016


   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 granularity of 60. The default
      value is 1,440 (24 hours). The value 0 indicates 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 is to 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.

   The method used to generate this number is up to implementations. The
   Pseudo Random Number Generator defined in ANSI X9.31 Appendix A.2.4
   is RECOMMENDED.

   +-+-+-+-+-+-+-+-+
   |Attribute Type |                   (1 byte)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Attribute Length             |   (2 bytes)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+
   |  Bonding Key Value                (4 bytes)   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+

   Attribute Type
      Bonding Key Value, set to 20.

   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 for the DSL link
   [RFC2698]. The DSL GRE Tunnel Setup Accept message MUST include the
   Configured DSL Upstream Bandwidth attribute.






Mingui Zhang, et al       Expires May 4, 2017                  [Page 18]


INTERNET-DRAFT             GRE Tunnel Bonding           October 31, 2016


   +-+-+-+-+-+-+-+-+
   |Attribute Type |                   (1 byte)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Attribute Length             |   (2 bytes)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+
   | Configured DSL Upstream Bandwidth (4 bytes)   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+

   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 |                   (1 byte)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Attribute Length             |   (2 bytes)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+
   |Configured DSL Downstream Bandwidth(4 bytes)   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+

   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 Section 5.2.4.) may be violated before the HG MUST



Mingui Zhang, et al       Expires May 4, 2017                  [Page 19]


INTERNET-DRAFT             GRE Tunnel Bonding           October 31, 2016


   stop using the LTE GRE 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 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 the RTT Difference
   Threshold (See Section 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, 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 |                   (1 byte)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Attribute Length             |   (2 bytes)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+
   |  RTT Diff Threshold Compliance    (4 bytes)   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+

   Attribute Type
      RTT Diff Threshold Compliance, set to 25.

   Attribute Length
      Set to 4.



Mingui Zhang, et al       Expires May 4, 2017                  [Page 20]


INTERNET-DRAFT             GRE Tunnel Bonding           October 31, 2016


   RTT Diff Threshold Compliance
      An unsigned integer which 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 longer than the "No Traffic Monitored Interval" (See
   Section 5.2.15.). The LTE GRE Tunnel Setup Accept message MUST
   include the Idle Hello Interval attribute.

   +-+-+-+-+-+-+-+-+
   |Attribute Type |                    (1 byte)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Attribute Length             |    (2 bytes)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+
   |  Idle Hello Interval               (4 bytes)  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+

   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 the range 100 through 86,400 (24 hours) with the 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.









Mingui Zhang, et al       Expires May 4, 2017                  [Page 21]


INTERNET-DRAFT             GRE Tunnel Bonding           October 31, 2016


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

   HAAP MUST sends the GRE Tunnel Setup Deny message to HG if the GRE
   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 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 |                    (1 byte)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Attribute Length             |    (2 bytes)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+
   |  Error Code                        (4 bytes)  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+

   Attribute Type
      Error Code, set to 17.

   Attribute Length
      Set to 4.

   Error Code



Mingui Zhang, et al       Expires May 4, 2017                  [Page 22]


INTERNET-DRAFT             GRE Tunnel Bonding           October 31, 2016


      An unsigned integer. The list of the codes are listed as follows.

      1: The HAAP was not reachable over LTE during the GRE tunnel setup
         request.
      2: The HAAP was not reachable via DSL during the GRE 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 ID (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 because a bonding
         session with the same User ID already exists.
      9: The HAAP denied the GRE 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.
      12: There was a communication error between the HAAP and
         management system during the DSL 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
   the HAAP acknowledges 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 DSL GRE Tunnel Hello message MUST include
   the Timestamp attribute.

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

   Attribute Type
      Timestamp, set to 5.



Mingui Zhang, et al       Expires May 4, 2017                  [Page 23]


INTERNET-DRAFT             GRE Tunnel Bonding           October 31, 2016


   Attribute Length
      Set to 8.

   Timestamp
      The high-order 4 octets indicate an unsigned integer in units of
      one second; the low-order 4 octets indicate an unsigned integer in
      unit of one 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. 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 |                    (1 byte)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Attribute Length             |    (2 bytes)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+
   |  IPv6 Prefix Assigned by HAAP      (16 bytes) |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+

   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 encode an IPv6 address. The lowest-
      order one octet 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 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 which is
   transmitted either through the DSL GRE tunnel or LTE GRE tunnel to



Mingui Zhang, et al       Expires May 4, 2017                  [Page 24]


INTERNET-DRAFT             GRE Tunnel Bonding           October 31, 2016


   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 is an
   exception for the Filter List Package. Since the size of the Filter
   List Package attribute can be very large, a special attribute is
   specified in Section 5.6.12 as the acknowledgement.

   Attributes that need be to 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 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 bypass bandwidth. The available DSL bandwidth will be
   used as the Committed Information Rate (CIR) of the coloring system
   [RFC2698].

   +-+-+-+-+-+-+-+-+
   |Attribute Type |                    (1 byte)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Attribute Length             |    (2 bytes)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+
   |  Bypass Traffic Rate               (4 bytes)  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+

   Attribute Type
      Bypass Traffic Rate, set to 6.

   Attribute Length
      Set to 4.

   Bypass Traffic Rate
      An unsigned integer measured in kbps.




Mingui Zhang, et al       Expires May 4, 2017                  [Page 25]


INTERNET-DRAFT             GRE Tunnel Bonding           October 31, 2016


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. Each
   Filter List Package carries a collection of Filter List TLVs and each
   such Filter List TLV specifies a filter item. At the HG, a list of
   filter items is maintained. Also, the HG needs to maintain an
   exception list of 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 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 GRE Tunnel Notify message MAY include the
   Filter List Package attribute. The DSL GRE Tunnel Notify message is
   preferred.

   +-+-+-+-+-+-+-+-+
   |Attribute Type |                    (1 byte)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Attribute Length             |    (2 bytes)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+
   |  Filter List TLVs                  (variable) ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+

   Attribute Type
      Filter List Package, set to 8.

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

   Filter List TLVs
      Each Filter List TLV has the following format.
















Mingui Zhang, et al       Expires May 4, 2017                  [Page 26]


INTERNET-DRAFT             GRE Tunnel Bonding           October 31, 2016


    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             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Type                  |          Length               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Enable                |     Description Length        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                 Description Value (0~4 bytes)                 ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                        Value (0~32 bytes)                     ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Commit_Count
         An unsigned integer which identifies the version of the Filter
         List Package. HG will refresh its filter list when a new
         Commit_Count is received.

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

      Packet_ID
         The fragmentation index of this Filter List Package.

      Type
         The Type of the Filter List TLV. Currently used types are
         described as follows.

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



Mingui Zhang, et al       Expires May 4, 2017                  [Page 27]


INTERNET-DRAFT             GRE Tunnel Bonding           October 31, 2016


                 Destination IP Range&Port       14
                 Reserved

      Length
         The length of the Filter List TLV. Commit_Count, Packet Sum,
         Packet ID, Type and Length are excluded.

      Enable
         Whether the filter item defined in this Filter List TLV is
         enabled. One means enabled and zero means disabled. Other
         possible values are reserved.

      Description Length
         The length of the Description Value.

      Description Value
         A variable ASCII string that describes the Filter List TLV
         (e.g., "FQDN").

      Value
         A variable ASCII string that specifies the value of the Filter
         List TLV (e.g. "www.yahoo.com"). As an example, Type = 1 and
         Value = "www.yahoo.com" means that packets whose FQDN field
         equals "www.yahoo.com" match the filter item.

   The lengths of the auxiliary Description Value and Value fields are
   restricted to a maximum of 4 bytes and 32 bytes respectively, which
   aims to limit the size of the Filter List TLV sent on the GRE tunnel.

5.6.3. Switching to DSL Tunnel

   If the RTT difference is continuously detected to violate the RTT
   Difference Threshold (See Section 5.2.4.) more than the times
   specified in the RTT Difference Threshold Violation (See Section
   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.



Mingui Zhang, et al       Expires May 4, 2017                  [Page 28]


INTERNET-DRAFT             GRE Tunnel Bonding           October 31, 2016


   Attribute Length
      Set to 0.

5.6.4. Overflowing to LTE Tunnel

   If the RTT difference is continuously detected to not violated the
   RTT Difference Threshold attribute (See Section 5.2.4.) more than the
   number of times specified in the RTT Difference Compliance attribute
   (See Section 5.2.13), the HG uses the Overflowing to LTE Tunnel
   attribute to inform HAAP that 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 the DSL WAN interface status is down, it MUST
   tear down the DSL GRE tunnel. It informs HAAP about the failure using
   the DSL Link Failure attribute. The HAAP MUST tear down the DSL GRE
   tunnel upon the DSL Link Failure attribute is received. 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




Mingui Zhang, et al       Expires May 4, 2017                  [Page 29]


INTERNET-DRAFT             GRE Tunnel Bonding           October 31, 2016


   When the HG detects the LTE WAN interface status is down, it MUST
   tear down the LTE GRE tunnel. It informs the HAAP about the failure
   using the LTE Link Failure attribute. HAAP MUST tear down the LTE GRE
   tunnel upon the LTE Link Failure attribute is received. 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 |                    (1 byte)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Attribute Length             |    (2 bytes)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+
   |  IPv6 Prefix Assigned to Host      (16 bytes) |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+

   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 encode an IPv6 address. The lowest-
      order one octet 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



Mingui Zhang, et al       Expires May 4, 2017                  [Page 30]


INTERNET-DRAFT             GRE Tunnel Bonding           October 31, 2016


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




Mingui Zhang, et al       Expires May 4, 2017                  [Page 31]


INTERNET-DRAFT             GRE Tunnel Bonding           October 31, 2016


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

   Attribute Length
      Set to 0.

5.6.11. Diagnostic End

   The HG uses the Diagnostic End attribute to inform th 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 |                    (1 byte)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Attribute Length             |    (2 bytes)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+
   |  Filter List Package ACK           (5 bytes)  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+

   Attribute Type
      Filter List Package ACK, set to 30.

   Attribute Length
      Set to 5.

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



Mingui Zhang, et al       Expires May 4, 2017                  [Page 32]


INTERNET-DRAFT             GRE Tunnel Bonding           October 31, 2016


      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.
      2: The Filter List Package is not acknowledged. The HG has already
         got a valid Filter List Package. The filter list on the HG will
         continue to be used while HAAP need do nothing.

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 Section 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 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,
   start RTT detection and start sending GRE Tunnel Hello messages with
   the Active Hello Interval (See Section 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 when the bonding of
   GRE Tunnels is successfully established and the LTE GRE Tunnel Setup
   Accept message carrying the Idle Hello Interval attribute (See
   Section 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, clear RTT state and send



Mingui Zhang, et al       Expires May 4, 2017                  [Page 33]


INTERNET-DRAFT             GRE Tunnel Bonding           October 31, 2016


   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 switch to idle hello state,
   stop RTT detection, clear RTT state as well and start sending GRE
   Tunnel Hello messages with the Idle Hello Interval (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 and it takes much longer time to detect this
   tunnel.

   When the HAAP receives an LTE GRE Tunnel Setup Request and finds the
   requested tunnel is conflicting with an existing tunnel, the HAAP
   initiates the 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 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 process
   immediately.

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



Mingui Zhang, et al       Expires May 4, 2017                  [Page 34]


INTERNET-DRAFT             GRE Tunnel Bonding           October 31, 2016


   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 in turn are carried in IP (outer)
   packets. The general structure of data packets of the GRE Tunnel
   Bonding protocol is shown as below.

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

6.1. The GRE Header

   The GRE header is first standardized in [RFC2874]. [RFC2890] adds the
   optional key and sequence number fields which makes the whole GRE
   header have the following format.













Mingui Zhang, et al       Expires May 4, 2017                  [Page 35]


INTERNET-DRAFT             GRE Tunnel Bonding           October 31, 2016


    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |C| |K|S| Reserved0       | Ver |  Protocol Type 0x0800/86DD    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Checksum (optional)      |       Reserved1 (Optional)    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Key (optional)                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Sequence Number (optional)                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Figure 6.1 The GRE header for data packets of GRE Tunnel Bonding

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

   The Key bit is set to one 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 and notified to HG (See Section 5.2.9).

   The S bit is set to one, 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.

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 Point-to-Point Protocol over Ethernet
   (PPPoE), and gets the LTE WAN interface IP address (E) through 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) 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



Mingui Zhang, et al       Expires May 4, 2017                  [Page 36]


INTERNET-DRAFT             GRE Tunnel Bonding           October 31, 2016


   the LTE WAN interface IP address (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 path to reach)
   in the HAAP group, which receives the GRE Tunnel Setup Request
   message, will initiate the Authentication and Authorization
   procedure, as specified in [TS23.401], to check whether the HG is
   trusted by the PGW.

   If the Authentication and Authorization succeed, the HAAP sets the
   LTE WAN interface IP address (E) which is obtained from the GRE
   Tunnel Setup Request message (i.e., its outer source IP 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. 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) 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 and the HG MUST terminate the tunnel set up
   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 over the tunnel from the HAAP through 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) 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 in order to check whether
   the HG is trusted by the BRAS.

   If the Authentication and Authorization succeed, the HAAP sets the
   DSL WAN interface IP address (D) which is obtained from the GRE
   Tunnel Setup Request message (i.e., its outer source IP 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 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 and 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 process once it



Mingui Zhang, et al       Expires May 4, 2017                  [Page 37]


INTERNET-DRAFT             GRE Tunnel Bonding           October 31, 2016


   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.

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 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
   password, except the first GRE Setup Request message per bonding
   connection sent from HG to HAAP, whose Key field is filled with all
   zeros. HAAP and HG validate the Key value and the outer source IP
   address and discard packets with any invalid combination.

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

8. IANA Considerations

   The GRE Protocol Type for the GRE Channel is set to 0xB7EA which is
   under the control of IEEE Registration Authority. Please update the
   "IEEE 802 Numbers" IANA web page [802Type] which is of primarily
   historic interest.

9. Contributors

   Li Xue Individual

   Email: xueli_jas@163.com

10. References

10.1. Normative References

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

   [RFC2698] Heinanen, J. and R. Guerin, "A Two Rate Three Color
             Marker", RFC 2698, DOI 10.17487/RFC2698, September 1999,
             <http://www.rfc-editor.org/info/rfc2698>.

   [RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE",



Mingui Zhang, et al       Expires May 4, 2017                  [Page 38]


INTERNET-DRAFT             GRE Tunnel Bonding           October 31, 2016


             RFC 2890, DOI 10.17487/RFC2890, September 2000,
             <http://www.rfc-editor.org/info/rfc2890>.

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

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

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

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


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

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

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






Mingui Zhang, et al       Expires May 4, 2017                  [Page 39]


INTERNET-DRAFT             GRE Tunnel Bonding           October 31, 2016


Author's 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
   Email: heidemannc@telekom.de


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

   EMail: zhangmingui@huawei.com


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

   EMail: sarikaya@ieee.org


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

   EMail: margaret@painless-security.com






Mingui Zhang, et al       Expires May 4, 2017                  [Page 40]


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