tech-invite   World Map
3GPP     Specs     Glossaries     UICC       T+       IETF     RFCs     Groups     SIP     ABNFs       Search

RFC 8157

Informational
Pages: 44
Top     in Index     Prev     Next
in Group Index     Prev in Group     No Next: Highest Number in Group     Group: ~encaps

Huawei's GRE Tunnel Bonding Protocol

Part 1 of 2, p. 1 to 24
None       Next Section

 


Top       ToC       Page 1 
Independent Submission                                        N. Leymann
Request for Comments: 8157                                  C. Heidemann
Category: Informational                              Deutsche Telekom AG
ISSN: 2070-1721                                                 M. Zhang
                                                             B. Sarikaya
                                                                  Huawei
                                                               M. Cullen
                                                       Painless Security
                                                                May 2017


                  Huawei's GRE Tunnel Bonding Protocol

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 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.  This document will enable other
   developers to build interoperable implementations.

Status of This Memo

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

   This is a contribution to the RFC Series, independently of any other
   RFC stream.  The RFC Editor has chosen to publish this document at
   its discretion and makes no statement about its value for
   implementation or deployment.  Documents approved for publication by
   the RFC Editor are not a candidate for any level of Internet
   Standard; see Section 2 of RFC 7841.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   http://www.rfc-editor.org/info/rfc8157.

Top      ToC       Page 2 
Copyright Notice

   Copyright (c) 2017 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.

Table of Contents

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

Top      ToC       Page 3 
      5.3. GRE Tunnel Setup Deny .....................................24
           5.3.1. Error Code .........................................24
      5.4. GRE Tunnel Hello ..........................................25
           5.4.1. Timestamp ..........................................25
           5.4.2. IPv6 Prefix Assigned by HAAP .......................26
      5.5. GRE Tunnel Tear Down ......................................26
      5.6. GRE Tunnel Notify .........................................27
           5.6.1. Bypass Traffic Rate ................................27
           5.6.2. Filter List Package ................................28
           5.6.3. Switching to DSL Tunnel ............................31
           5.6.4. Overflowing to LTE Tunnel ..........................31
           5.6.5. DSL Link Failure ...................................32
           5.6.6. LTE Link Failure ...................................32
           5.6.7. IPv6 Prefix Assigned to Host .......................33
           5.6.8. Diagnostic Start: Bonding Tunnel ...................33
           5.6.9. Diagnostic Start: DSL Tunnel .......................34
           5.6.10. Diagnostic Start: LTE Tunnel ......................34
           5.6.11. Diagnostic End ....................................35
           5.6.12. Filter List Package ACK ...........................35
           5.6.13. Switching to Active Hello State ...................36
           5.6.14. Switching to Idle Hello State .....................37
           5.6.15. Tunnel Verification ...............................37
   6. Tunnel Protocol Operation (Data Plane) .........................38
      6.1. The GRE Header ............................................38
      6.2. Automatic Setup of GRE Tunnels ............................39
   7. Security Considerations ........................................41
   8. IANA Considerations ............................................41
   9. References .....................................................41
      9.1. Normative References ......................................41
      9.2. Informative References ....................................42
   Contributors ......................................................43
   Authors' Addresses ................................................44

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; this service will provide increased access capacity and
   improved reliability.

   This document focuses on the use case 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

Top      ToC       Page 4 
   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 of scope for
   this document.  Also, the protocol specified in this document is
   limited to the single-operator scenario only, i.e., the two peering
   boxes -- the HG and the HAAP -- are operated by a single provider.
   The adaptation of the GRE Tunnel Bonding Protocol to the
   multi-provider scenario is left for future work.

   This document bases the solution on GRE (Generic Routing
   Encapsulation [RFC2784] [RFC2890]), since GRE is widely supported in
   both fixed and mobile networks.  Approaches specified in this
   document might also be used by other tunneling technologies to
   achieve tunnel bonding.  However, such variants are out 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 the HAAP,
   respectively, serve as the common termination point of the two
   tunnels at both ends.  Those GRE tunnels are further bonded together
   to form a logical GRE tunnel for the subscriber.  The HG conceals the
   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).

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

2.  Acronyms and Terminology

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

   DSL: Digital Subscriber Line.  A family of technologies 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.

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

   CIR: Committed Information Rate [RFC2697].

   RTT: Round-Trip Time.

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

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

   FQDN: Fully Qualified Domain Name.  Generally, a host name with at
      least one domain label under the top-level domain.  For example,
      "dhcp.example.org" is an FQDN [RFC7031].

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

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

   PGW: Packet Data Network Gateway.  In the Long Term Evolution (LTE)
      architecture for the Evolved Packet Core (EPC), 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 over Ethernet.  A network protocol for
      encapsulating PPP frames inside Ethernet frames.

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

Top      ToC       Page 6 
   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 --+ |*
                  | | *+-+                    +-+*
                  +-+ ****************************
                  \______/                    \__/
                     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 the HG.
       H: The endpoint for each heterogeneous connection at the HAAP.

      Figure 1: Offloading from DSL to LTE, 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 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 combined bandwidth of the two connections.

Top      ToC       Page 7 
4.  Overview

   In this document, the widely supported GRE is chosen as the tunneling
   technique.  With the newly defined control protocol, GRE tunnels are
   set up on top of the DSL and LTE connections, which are ended at
   D and H or at E and H, as shown in Figure 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 GRE tunnels.

4.1.  Control Plane

   A clean-slate control protocol is designed to manage the GRE tunnels
   that are 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 forwarding of
   control-plane packets.  As shown in Figure 2 (see Section 5), the GRE
   header [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 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, 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 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 3 (see Section 6.1), the GRE header [RFC2784] with
   the Key and Sequence Number extensions specified by [RFC2890] is used
   to encapsulate data packets.  The Protocol Type is either 0x0800
   (listed as "0x800" in [RFC2784]) or 0x86DD [RFC7676], which indicates
   that the inner packet is either an IPv4 packet or an IPv6 packet,

Top      ToC       Page 8 
   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 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, 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 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
   Section 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 using 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 via the Sequence Number field [RFC2890] of the
   GRE header.  All packets carried on GRE tunnels that belong to the
   same bonding connection go into a single reordering buffer.

   Operators may configure the maximum allowed size (see
   MAX_PERFLOW_BUFFER in [RFC2890]) of the buffer for reordering.  They
   may also configure the maximum time (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 have demonstrated that there is usually a
   large margin for the value of MAX_PERFLOW_BUFFER.  Values larger than
   the multiplication of the sum of the line rate of the two connections
   and the value of OUTOFORDER_TIMER should be used.

Top      ToC       Page 9 
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 bypass the GRE Tunnel Bonding and 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 in which the HAAP 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.4 are used to carry the timestamp information, and the 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 Section 5.6.1).

4.7.  Policy Control Considerations

   Operators and users 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 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 Section 4.1), and the HG will use the raw
   connection to transmit traffic for these service types.  Users may
   also define bypass service types on the HG.  Bypass service types
   defined by users need not be delivered to the HAAP.

Top      ToC       Page 10 
   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 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
   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, 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 packets.
   The new GRE Protocol Type (0xB7EA) is allocated for this purpose, and
   the standard GRE header as per [RFC2784] with the Key extension
   specified by [RFC2890] is used.  The Checksum Present bit is set
   to 0.  The Key Present bit is set to 1.  The Sequence Number Present
   bit is set to 0.  So, the format of the GRE header for control
   messages of the GRE Tunnel Bonding 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
      For security purposes, the Key field is used to carry a random
      number.  The random number is generated by the HAAP, and the HG is
      informed of it (see Section 5.2.9).

Top      ToC       Page 11 
   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                              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |MsgType|T-Type |                                               |
    +-+-+-+-+-+-+-+-+           Attributes                          +
    ~                                                               ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        Figure 2: Format of Control Messages of GRE Tunnel Bonding

   MsgType (4 bits)
      Message Type.  The control message family contains the following
      six types of control 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

   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.

Top      ToC       Page 12 
   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
         The Attribute Type specifies the type of the attribute.

      Attribute Length
         Attribute Length indicates the length of the Attribute Value
         in bytes.

      Attribute Value
         The Attribute Value includes the value of the attribute.

   All control messages are sent in network byte order (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 decide to
   consume the GRE packet locally rather than 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

   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
   contain the CIN attribute while the GRE Tunnel Setup Request message
   sent out from the DSL WAN interface does not contain this attribute.

Top      ToC       Page 13 
   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 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 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 Type |                   (1 byte)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Attribute Length             |   (2 bytes)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+
   |  Session ID                       (4 bytes)   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+

Top      ToC       Page 14 
   Attribute Type
      Session ID, set to 4.

   Attribute Length
      Set to 4.

   Session ID
      An unsigned integer 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
      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 to be included in this message are
   defined below.

Top      ToC       Page 15 
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 the DSL WAN interface IP address (D)
   and the LTE WAN interface IP address (E), respectively, as shown in
   Figure 1).  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

   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 IPv6
   addresses of the GRE tunnels are the DSL WAN interface IP address (D)
   and the LTE WAN interface IP address (E), respectively, as shown in
   Figure 1).

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

Top      ToC       Page 16 
   Attribute Type
      H IPv6 Address, set to 2.

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

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

Top      ToC       Page 18 
   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 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.  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 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 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 GRE Tunnel Setup Accept message MUST include the
   Idle Timeout attribute.

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

   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 a granularity of 60.  The default
      value is 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 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 security purposes.

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

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

Top      ToC       Page 20 
   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 CIR [RFC2697] for the DSL link.  The DSL GRE Tunnel
   Setup Accept message MUST include the Configured DSL Upstream
   Bandwidth attribute.

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

Top      ToC       Page 21 
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 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)   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+

Top      ToC       Page 22 
   Attribute Type
      RTT Difference Threshold Violation, set to 24.

   Attribute Length
      Set to 4.

   RTT Difference Threshold Violation
      An unsigned integer 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 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
   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 |                   (1 byte)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Attribute Length             |   (2 bytes)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+
   |  RTT Diff Threshold Compliance    (4 bytes)   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+

   Attribute Type
      RTT Difference Threshold Compliance, set to 25.

   Attribute Length
      Set to 4.

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

Top      ToC       Page 23 
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 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
      in the range 100 through 86,400 (24 hours) with 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 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)  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+

Top      ToC       Page 24 
   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.



(page 24 continued on part 2)

Next Section